文章目录一、挂谷猜想到底在说什么二、把猜想翻译成 Agent 的语言三、重叠即是效率技能不必彼此隔离四、多尺度记忆我们其实已经在跑一套 Kakeya 式证明五、波包分解与上下文预算六、真正的突破在交叉处七、落到我们自己的系统王虹刚证明了三维挂谷猜想。这个一根针如何扫过所有方向的百年难题恰好是一面镜子照出我们做 Agent、技能与记忆架构时一直没说清的一个问题到底要多厚的记忆才能覆盖所有任务方向。一、挂谷猜想到底在说什么1917 年挂谷宗一问了一个看起来很朴素的问题平面上如果一个集合里装得下一根单位长度的针并且这根针能转到每一个方向那么这个集合最小能有多小直觉告诉你至少得是个直径 1 的圆那么大。1919 年 Besicovitch 给了数学界一记耳光在二维里这个集合的面积可以任意小甚至等于 0。这种集合后来叫 Besicovitch 集或者 Kakeya 集。它装着指向所有方向的针自己却几乎没有面积。这就是挂谷猜想最反直觉的地方方向的全覆盖不要求体积的全覆盖。到了三维故事反转。二维可以任意薄但三维里一个 Kakeya 集的 Hausdorff 维数必须是满的 3——它没法再被压扁。王虹和 Joshua Zahl 在 2025 年 2 月用一篇 127 页的预印本证明了这件事结束了这个悬了一个多世纪的问题。顺带一提王虹是史上第三位女性菲尔茨奖得主。我第一次读到这个结论时脑子里冒出来的不是数学而是一个工程问题我们的 Agent 系统是不是也一直在问同一个挂谷问题只是没人把它说成容量下限二、把猜想翻译成 Agent 的语言先做一个直白的映射后面几节都建立在这张表上。挂谷猜想里的概念Agent 架构里的对应物给我们的启示指向某个方向的针一次技能调用 / 一条推理链 CoT所有方向都要覆盖系统要能处理任意用户请求Kakeya 集的体积下限技能记忆的最小容量下限针的重叠 Perron 树技能共享子能力 / 参数复用多尺度归纳证明云/用户/工作区 三层记忆波包分解任务拆成子技能 上下文预算一句话概括用户每一次提问就是在任务空间里指定了一个方向。一个称职的 Agent必须对这个空间里的每一个方向都能把针稳稳指向它。挂谷猜想问的是覆盖所有方向最少要占多大地方我们分析技能-记忆架构时其实也该问一句覆盖所有任务方向最少要占多少记忆与参数二维那个面积为零的结论是压缩派的梦想——一个很小的模型、很小的技能集、很小的记忆照样能指向所有任务方向。这正好是技能驱动 Agent、工具调用、检索增强记忆背后的信念你不需要存下每个问题的答案你只需要存下把针转到任意方向的能力。但三维那个维数必须满 3的结论是给压缩派泼的冷水。在更高维、彼此耦合的任务空间里覆盖是有硬下限的。你不能无限压缩记忆和技能而不丢失方向覆盖。我把它叫做 Agent 领域的Kakeya 容量猜想对于任意任务空间存在一个由任务耦合度决定的记忆-技能体积下限低于它就一定有某些方向指向不了。这不是已经证明的定理目前只是个有启发力的类比但它比上下文越长越好或者越小越便宜这类口号更接近工程真相。三、重叠即是效率技能不必彼此隔离Besicovitch 集之所以能把面积压到零靠的是把一根根针巧妙地重叠起来Perron 树构造。如果每根针都占一块互不重叠的地盘面积早就爆了。做技能架构时我们常犯一个相反的错把每个技能当成独立的、互不干涉的模块。结果是一大堆几乎不重叠的针领地系统越来越臃肿维护成本越来越高。真正的效率来自纠缠而非隔离。一个分词器、一个规划器、一个检索例程应该被多个技能共享就像 Kakeya 里的针互相交叠。技能之间的重叠不是缺陷是省体积的手段。设计技能时该问的不是这个功能归哪个技能而是哪几个技能可以共用同一段能力从而把整体体积压下来。被多个技能复用被多个技能复用被多个技能复用任意用户请求 一个方向路由共享子能力层: 分词/规划/检索/工具调用领域技能 A领域技能 B领域技能 C记忆层反馈路由四、多尺度记忆我们其实已经在跑一套 Kakeya 式证明王虹的证明是多尺度的。她在小尺度上把集合 bound 住再用尺度归纳induction on scales一路推到全局。局部对了跨尺度组合对了全局才对。回头看我们手上的记忆架构它本来就是多尺度的只是没人这么命名云侧 profile 记忆长期、只读、服务端托管。这是大尺度结构决定这个人是谁。用户级本地 MEMORY.md跨项目习惯中尺度。工作区日志 MEMORY.md项目专属、只追加小尺度。这三层不是随便分的它正好对应从局部到全局的尺度归纳。一次会话里的短期上下文最小尺度喂给工作区日志工作区日志沉淀成项目记忆项目记忆再上升到用户级习惯最后并入云侧画像。全局的能处理任意问题的能力不是靠某一个巨大记忆块而是靠每一层在各自尺度上正确、再正确组合。我甚至觉得这套三层结构本身就是对三维 Kakeya 下限的承认你没法把记忆压成单层、压到零体积还指望覆盖所有方向。尺度必须存在因为覆盖率有下限。五、波包分解与上下文预算王虹的主场是调和分析。挂谷问题在调和分析里连着限制型估计restriction estimates本质是在问不同方向的波包叠在一起时会互相吃掉多少能量。翻译成 Agent 语言把一个复杂任务分解成若干子技能每个子技能就是一个波包——它有方向干什么也有位置在流程的哪一步。限制型估计 bound 的是这些波包如何相互作用落到工程上就是 bound 不同子技能在同一段对话里重叠时会消耗多少上下文和计算。这给上下文预算和技能干扰提供了天然的数学语言。我们做 DeepSeek V4 压测时一直在凭经验定上下文窗口和并发其实背后该有一套波包叠加的账同时激活的技能越多、越重叠上下文占用和延迟怎么涨。不是拍脑袋而是像限制型估计那样给出可计算的边界。六、真正的突破在交叉处王虹自己说过一句话我反复读了几遍我感觉自己是在把前面两个领域的方法结合起来。她说的是调和分析与几何测度论。丘成桐点评这次双获奖时也说两人路径不同但共同显示了学科交叉融合正成为推动数学的关键力量。这对我们做系统的人是一句很直白的提醒最大的收益出现在技能动态能力和记忆持久结构的交界处而不在各自的内部优化里。大多数框架把技能系统和记忆系统分开做。技能组拼命加工具、加路由记忆组拼命换向量库、调切分。两边都觉得自己重要但很少把技能写记忆、记忆路由技能当成一个耦合系统来设计。挂谷猜想的教训是——它本来就是调和分析波、动态和几何测度论形状、结构两门学问打架打出来的结果。Agent 的下一个真实突破大概率也长在技能 × 记忆这条交线上而不是在把某一侧推到极致。七、落到我们自己的系统说点具体的。我们在内网跑了 DeepSeek V4 Gradio又在看知识湖做智能客服和企业知识管理。挂谷的视角能直接改写这两件事的打法知识湖不要存答案要存转向能力。用户问题是无限多个方向你永远存不下每个问题的标准答案二维 Kakeya 的教训也别试图去存。正确做法是构建一层紧凑、彼此重叠的检索 技能基底让它能就任意问题方向把针转过去。这其实就是 RAG 加Agentic 技能但目标函数要改从召回最像的文档变成用最小检索体积覆盖最全的问题方向。给记忆容量设下限别一味求小。压测时我们盯着成本曲线想把它压到最低但三维 Kakeya 告诉我们耦合任务空间里覆盖率有硬下限。低于它某些客户问题方向就必然答不准。与其盲目砍记忆和上下文不如先估一下自己任务空间的维数再反推最小容量。把技能重叠当成指标。技能库的重叠度应该被度量。重叠太低说明在重复造针领地体积浪费重叠太高说明边界模糊、互相干扰。理想状态是像 Perron 树那样可控地交叠。