Skip to main content

从千禧年问题谈起，我为什么放弃了 Agent Teams

By LanLance (@LanLance24)

OpenAI 前两天公布了一项举世震惊的数学验证，他们调用了约一万个 Agent，在 88 小时内给出了 Navier-Stokes 方程存在性与光滑性问题的机器解法，随后又花费 17 小时完成了经过 Lean 编译器形式化校验的证明。尽管这一解法是否完全满足克雷数学研究所对千禧年大奖难题的严格认定仍待数学界长程审查，但机器生成加编译器验证的路径让很多人再次对 Agent 产生了技术层面的狂热。

如果退回到具体的软件工程与日常编码开发，我认为盲目增加 Agent 数量不仅换不来等比例的产出，反而会让开发过程陷入停滞。

Multi-Agent 的坑​

尝试让多个 Agent 在一个项目里协作开发，拉起两个研发、两个测试和两个架构师角色的 Agent。当时的想法是模仿人类产研团队的协作流程，让不同角色的 Agent 各司其职，在同一个工作区内讨论方案并分工编写。

系统很快暴露出一系列问题。

多个 Agent 之间互相同步信息时，传话失真非常明显。架构师 Agent 给出的指导意见经过多轮对话传递，有效信息被层层稀释。与此同时，上下文快速腐化，每个 Agent 都在自己的上下文里塞进了大量其他 Agent 产生的不相关历史记录，导致单个任务的 Token 消耗剧烈膨胀，推理延迟被成倍放大。

更棘手的是任务直接冲突打架。由于缺乏一个唯一的协调中心，研发 Agent A 和研发 Agent B 经常在没有加锁机制的情况下同时修改同一批源文件。一个 Agent 刚改完的类和方法，转头就被另一个 Agent 覆写或者回滚。测试 Agent 还在执行断言，运行环境就已经被新的代码变更破坏。

那一阶段的实际体会是拟人化的团队协作消耗了海量时间和 Token，最终交付代码的稳定性甚至不如单个 Agent 线性推进。我随后放弃了让 Agent 们横向沟通的模式，全面退回由 Main Agent 派发单向 Subagent 的用法。

为什么让 Agent 自己协商跑不通​

今年一月份 Cursor 团队在自主构建 Web 浏览器的实验报告中，记录了几乎完全相同的演进路径。

Cursor 最早尝试的方案是自协调。他们设置了一个全局共享状态文件，让所有的 Agent 处于平等地位，谁有空谁就去状态文件里认领任务并加上锁。

这个设计的工程问题暴露得非常快。当系统内的 Agent 扩展到 20 个时，整体吞吐量并没有增加，反而跌落到了两到三个 Agent 的水平。核心问题在于锁竞争严重，大量 Agent 把算力浪费在等待任务锁上，而且 Agent 异常退出未释放锁、重复拿锁等行为让整套调度极度脆弱。

他们随后尝试转向无锁的乐观并发控制，但又暴露出新的协作问题。平等角色的 Agent 缺乏对最终交付物的全局责任感，普遍表现出避重就轻的倾向，大家都去挑改动极小、风险最低的边缘任务，核心主干模块的推进与重构迟迟无法落地。

Anthropic 在多智能体系统的协作研究中也记录过这套机制的失灵问题。当多个对等智能体在缺乏中心裁决的环境下交互时，系统容易出现行为趋同与不信任。由于底层模型同质化，几十个 Agent 经常各自独立起出完全重名的分支，或者扎堆去写同一个模块；面对分布式的事实碎片，Agent 们既无法有效聚合关键信息，又容易盲信不可靠的节点输入。

自协调在工程落地中行不通，根本原因在于它试图让模型在无约束的拓扑结构里达成共识。在分布式系统里，共识意味着通信开销，对等节点越多，通信拓扑的复杂度就越接近 O(n^2)。当每一次通信都依赖耗时且存在幻觉的大模型推理时，去中心化协商的成本就会彻底压垮任务本身的执行效率。

真正能跑通的分层做法​

Cursor 团队最终的解法是放弃对等协商，引入明确的角色分层机制：

  • Planner 负责探索代码库与分解任务，可以按子领域递归派生子 Planner
  • Worker 负责原子任务的具体实现，完成变更并提交后退出，不保留跨任务状态
  • Judge 在每个周期末尾评估整体进度，决定系统是继续推进还是从干净状态重新启动
                  Planner
                     |
        +------------+------------+
        |            |            |
  Subplanner ↻     Worker       Worker
        |            |            |
    +---+---+        |            |
    |       |        |            |
  Worker  Worker     |            |
    |       |        |            |
    +-------+--------+------------+
                     |
                    Git

从工程拓扑来看，这套结构最大的收益是把通信复杂度从网状的 O(n^2) 压到了星型的 O(n)。系统成功支撑了数百个并发 Agent 连续运行约一周。Worker 之间完全切断横向交互，彼此看不见对方，自然不会发生任务争抢和传话失真。所有的上下文边界被牢牢封在单次派发内，Worker 只需要关注当前函数的输入输出，完成改动并跑通局部测试，随后把结果返回给上层。

收敛到这种模式。不要让 Agent 们在同一个上下文或同一个群组里开会，而是把控制权收归到统一的编排层。

Main Agent 扮演规划与调度中枢，分析代码库结构，建立任务切片。当需要进行实质性编码或验证时，它动态派发一个干净上下文的 Subagent。Subagent 拿到明确的文件范围与修改契约，执行修改，运行单元测试。如果测试失败，Subagent 自行修复，直到验证通过后带着干净的 diff 返回给 Main Agent。

Conclusion​

Multi-Agent 的进化是把软件工程的经典分层机制复刻给模型执行。人类之所以需要开会和团队协商，是因为单个人脑的内存和处理带宽有限。但在代码世界里，机器不需要这种充满仪式感的拟人化平权协商。

将全局规划、执行调度与原子任务彻底隔离，用确定的代码逻辑和形式化测试作为门禁，放弃智能体自治的设想，走向确定性的层级拆解与验证，才是多智能体在工程上真正可行的路径。

参考​

从千禧年问题谈起，我为什么放弃了 Agent Teams openai.com/index/navier-stokes-solution/
cursor.com/blog/scaling-agents
claude.com/blog/multi-agent-coordination-patterns
anthropic.com/research/multiagent-systems