一根针指向所有方向：挂谷猜想对 LLM Agent 技能-记忆架构的启示

王虹刚证明了三维挂谷猜想。这个"一根针如何扫过所有方向"的百年难题，恰好是一面镜子，照出我们做 Agent、技能与记忆架构时一直没说清的一个问题：到底要多"厚"的记忆，才能覆盖所有任务方向。

一、挂谷猜想到底在说什么

1917 年，挂谷宗一问了一个看起来很朴素的问题：平面上如果一个集合里装得下一根单位长度的针，并且这根针能转到每一个方向，那么这个集合最小能有多小？

直觉告诉你，至少得是个直径 1 的圆那么大。1919 年 Besicovitch 给了数学界一记耳光：在二维里，这个集合的面积可以任意小，甚至等于 0。这种集合后来叫 Besicovitch 集，或者 Kakeya 集。它装着指向所有方向的针，自己却几乎没有面积。

这就是挂谷猜想最反直觉的地方：方向的全覆盖，不要求"体积"的全覆盖。

到了三维，故事反转。二维可以任意薄，但三维里一个 Kakeya 集的 Hausdorff 维数必须是满的 3——它没法再被压扁。王虹和 Joshua Zahl 在 2025 年 2 月用一篇 127 页的预印本证明了这件事，结束了这个悬了一个多世纪的问题。顺带一提，王虹是史上第三位女性菲尔茨奖得主。

我第一次读到这个结论时，脑子里冒出来的不是数学，而是一个工程问题：我们的 Agent 系统，是不是也一直在问同一个挂谷问题，只是没人把它说成"容量下限"？

二、把猜想翻译成 Agent 的语言

先做一个直白的映射，后面几节都建立在这张表上。

一句话概括：用户每一次提问，就是在任务空间里指定了一个"方向"。一个称职的 Agent，必须对这个空间里的每一个方向都能把针稳稳指向它。挂谷猜想问的是"覆盖所有方向最少要占多大地方"，我们分析技能-记忆架构时，其实也该问一句：覆盖所有任务方向，最少要占多少记忆与参数？

二维那个"面积为零"的结论，是压缩派的梦想——一个很小的模型、很小的技能集、很小的记忆，照样能指向所有任务方向。这正好是技能驱动 Agent、工具调用、检索增强记忆背后的信念：你不需要存下每个问题的答案，你只需要存下"把针转到任意方向的能力"。

但三维那个"维数必须满 3"的结论，是给压缩派泼的冷水。在更高维、彼此耦合的任务空间里，覆盖是有硬下限的。你不能无限压缩记忆和技能而不丢失方向覆盖。我把它叫做 Agent 领域的"Kakeya 容量猜想"：对于任意任务空间，存在一个由任务耦合度决定的记忆-技能体积下限，低于它，就一定有某些方向指向不了。这不是已经证明的定理，目前只是个有启发力的类比，但它比"上下文越长越好"或者"越小越便宜"这类口号，更接近工程真相。

三、重叠即是效率，技能不必彼此隔离

Besicovitch 集之所以能把面积压到零，靠的是把一根根针巧妙地重叠起来（Perron 树构造）。如果每根针都占一块互不重叠的地盘，面积早就爆了。

做技能架构时我们常犯一个相反的错：把每个技能当成独立的、互不干涉的模块。结果是一大堆几乎不重叠的"针领地"，系统越来越臃肿，维护成本越来越高。

真正的效率来自纠缠而非隔离。一个分词器、一个规划器、一个检索例程，应该被多个技能共享，就像 Kakeya 里的针互相交叠。技能之间的重叠不是缺陷，是省体积的手段。设计技能时该问的不是"这个功能归哪个技能"，而是"哪几个技能可以共用同一段能力，从而把整体体积压下来"。

四、多尺度记忆：我们其实已经在跑一套 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 树那样，可控地交叠。