一个 Agent 能撑多久？长程任务倒逼的多 Agent 真需求

上一篇文章我说多 Agent 协作是伪命题。现在我要反驳我自己。

但我反驳的不是结论，是前提。

上篇文章的核心论点是：同构的 Agent 团队没有认知多样性，所以群体智能不成立。这个论点在「短任务」场景下是对的。

但它忽略了一个关键变量：任务的时长。

当你处理一个五分钟的任务时，一个 Agent 够了。当你处理一个需要持续运行五天的任务时，一个 Agent 就远远不够了——不是因为它不够聪明，而是因为它有一个硬性的物理限制。

上下文窗口。

大模型的「金鱼脑」

大语言模型有一个被严重低估的瓶颈：上下文窗口是有限的。

不管你用的是 128K 还是 200K 的上下文窗口，它都是一块固定的、有限的工作台。所有你和 AI 的对话、它读取的文件、执行的命令、产生的中间结果，都塞在这块工作台上。

工作台满了怎么办？要么丢弃最早的内容，要么压缩它。无论哪种方式，信息都在丢失。

这就好比一个人在一间固定大小的房间里工作。房间里堆满了草稿、笔记、参考资料。当房间满了，你不得不把旧的东西扔掉，才能放新的东西进来。

扔掉旧东西意味着什么？意味着你忘了之前做过什么。

一个长程任务——比如开发一个完整的功能模块——可能需要：

• 阅读 20 个文件来理解现有架构
• 编写 10 个新文件
• 执行 50 次编译和测试
• 修复 15 个错误
• 重构 3 次

这些操作的中间结果加在一起，很容易就填满上下文窗口。当窗口满了，AI 开始「忘记」早期读过的文件、做过的决策、遇到过的问题。它会重新犯已经修过的 Bug，会重写已经讨论过的方案，会问已经回答过的问题。

这不是智力问题。这是记忆问题。

人类是怎么解决这个问题的？

人类在处理长程任务时，用的不是一个「无限大的大脑」。我们用的是：

分工： 一个大项目拆成子任务，每个人负责一块。你不需要理解整个系统的所有细节，你只需要理解你负责的那部分。

交接： 你在下班前写交接文档，告诉明天接手的人：做到哪了、遇到什么问题、下一步做什么。第二天来的人读完文档就能继续干。

检查点： 代码提交、设计文档评审、里程碑会议。这些都是「固化中间状态」的机制。即使某个人的记忆出了问题，检查点保存的状态可以恢复。

重启： 有时候一个问题卡了太久，最好的方式是从头来过。不是因为之前的思路不对，而是因为上下文太混乱了，重新整理一遍反而更快。

这四个机制——分工、交接、检查点、重启——本质上都是在解决同一个问题：有限的认知资源如何支撑长程任务？

AI 面临的是完全一样的问题。解法也应该是完全一样的。

多 Agent 不是为了「讨论」，是为了「重启」

上篇文章把多 Agent 系统的主要场景定义为「角色扮演式协作」——Agent A 和 Agent B 讨论、辩论、达成共识。

这个场景我依然认为价值有限。

但多 Agent 有一个完全不同的用法，我之前忽略了：通过多 Agent 实现上下文的重启和传递。

具体来说：

Agent 1 负责理解需求、阅读相关代码、制定方案。它在一个干净的上下文里工作，不会被实现细节污染。

Agent 2 接收 Agent 1 的方案，开始实现。它在一个新的上下文里工作，有充足的空间放代码、测试、调试信息。

Agent 3 接收 Agent 2 的实现，做代码审查和测试。它从一个全新的视角审视代码，不会被实现过程中的妥协和临时方案影响。

这不是「三个 Agent 讨论」。这是三个接力选手，每人跑一段，交接棒是方案文档。

每个 Agent 都在自己的上下文窗口里从零开始。每一段都从一个清晰的起点出发。总任务长度可以远超单个 Agent 的上下文限制。

长程任务的三个层级

不是所有长程任务都需要多 Agent。根据任务的复杂度和时长，可以分成三个层级：

第一层：会话内长任务（分钟级）

一个 Agent 在一个上下文窗口内完成的任务。写一个函数、修一个 Bug、做一次代码审查。

不需要多 Agent。 单个上下文窗口足够装下所有需要的信息。

第二层：会话间长任务（小时级）

一个任务需要多个独立会话来完成。比如今天写了一半的代码，明天继续。

这时候单个 Agent 不够用了，但还不需要多 Agent 协作。需要的是上下文持久化——把当前状态保存下来（文件、文档、checklist），下一个会话从保存的状态继续。

Claude Code 的 CLAUDE.md、Cursor 的规则文件、各种 AI 工具的记忆系统，都是在解决这个问题。

第三层：多线程长任务（天/周级）

一个大任务可以拆成多个相对独立的子任务，这些子任务可以并行或串行执行。比如：

• 「开发用户系统」拆成：数据库设计 + API 开发 + 前端页面 + 测试 + 文档
• 这些子任务之间有依赖关系，但也有相当大的独立性

这是多 Agent 真正有价值的层级。

每个子任务由一个 Agent 独立处理，有自己专属的上下文窗口。子任务之间的通过产物（文件、文档、接口定义）传递，而不是通过对话传递。

分布式系统的教训

计算机科学里有一个经典问题：单机性能不够怎么办？

上世纪的答案是「造更快的机器」——更大的 CPU、更多的内存。这就是纵向扩展（Scale Up）。

但单机有物理极限。于是后来的答案变成了「用多台机器」——把任务分布到多台普通的机器上。这就是横向扩展（Scale Out）。

横向扩展不简单。你需要解决一堆难题：

• 任务拆分： 怎么把一个大任务拆成可以并行执行的小任务？
• 状态管理： 多个节点之间的共享状态怎么同步？
• 故障处理： 一个节点挂了，怎么不影响整体？
• 结果合并： 多个节点的输出怎么合并成最终结果？

这些难题催生了 MapReduce、Spark、Kubernetes 等一系列分布式系统技术。

AI Agent 的多 Agent 系统，本质上面临的是同一类问题。

单个 Agent 的上下文窗口就像单机的内存——有物理极限。要处理更长的任务，就必须用多个 Agent 来「横向扩展」。

这意味着我们可以从分布式系统领域借鉴大量现成的设计模式：

MapReduce 模式： 大任务拆成多个独立子任务（Map），每个 Agent 处理一个子任务，最后合并结果（Reduce）。比如同时分析 10 个代码文件，最后汇总分析报告。

Pipeline 模式： 任务分阶段处理，每个 Agent 负责一个阶段，阶段之间通过产物传递。比如 Agent 1 设计方案 → Agent 2 实现代码 → Agent 3 写测试。

Leader-Follower 模式： 一个 Agent 做总指挥（拆任务、分配、合并结果），多个 Agent 做执行。指挥者不需要长上下文——它只需要管理任务清单和结果汇总。

Checkpoint-Resume 模式： 每个 Agent 在完成子任务时生成一个检查点（总结文档），下一个 Agent 从检查点恢复，不需要继承完整的执行历史。

真正的技术挑战

多 Agent 处理长程任务看起来很美，但实际落地有几个硬骨头：

挑战 1：上下文传递的信息损耗

Agent 1 做完工作后，怎么把「足够的上下文」传给 Agent 2？

写太详细的文档？传递成本高，而且文档本身也会占用 Agent 2 的上下文窗口。

写太简略的文档？Agent 2 会丢失关键信息，做出错误的决策。

这本质上是一个信息压缩问题。 你需要把一个 Agent 的完整工作状态压缩成另一个 Agent 能用的摘要。压缩必然有损，关键是怎么把损失误差控制在可接受范围内。

目前的实践方法：

• 结构化交接： 定义固定的交接文档模板（问题描述、已尝试方案、当前状态、下一步建议），让每个 Agent 按模板输出
• 代码即记忆： 把中间状态写入文件系统（代码、配置、测试），文件本身就是最忠实的交接文档
• 人作为仲裁者： 关键决策点由人类确认，不完全依赖 Agent 之间的自动传递

挑战 2：错误传播和放大

Agent 1 做了一个错误的决策。它把决策写入交接文档。Agent 2 基于这个错误决策继续工作。Agent 3 发现问题了，但它不知道错误的根源是 Agent 1。

在多 Agent 系统中，错误会沿着 Agent 链传播并放大。 每个 Agent 在前一个 Agent 的输出基础上工作，如果基础有瑕疵，上面的每一层都会有更大的瑕疵。

解法：在关键节点设置「审查 Agent」——不负责实现，只负责验证前一个 Agent 的输出是否合理。类似于 CI/CD 流水线中的 lint 和 test 节点。

挑战 3：全局一致性

多个 Agent 并行工作时，怎么保证它们的输出是一致的？

Agent A 写了一个接口定义用 camelCase，Agent B 写的实现用了 snake_case。单独看都对，合在一起就报错。

这在分布式系统中叫一致性问题。解法也类似——用「契约」（接口规范、编码标准、架构约束）来约束每个 Agent 的输出格式。

挑战 4：谁来兜底？

当多个 Agent 的协作出了问题——产出的结果不符合预期、任务没有完成、代码不能运行——谁来兜底？

在人类团队中，有 Tech Lead、有项目经理、有 QA。在多 Agent 系统中，这个角色目前只能由人类来承担。

现阶段，多 Agent 系统需要一个「人类编排者」来监督整个流程。 不是让 Agent 自己组队然后等结果，而是人类设定框架、监控进度、在关键节点做决策。

同构 vs 异构：修正我的观点

上篇文章的核心论点是：同构 Agent 团队没有认知多样性，所以无效。

现在我要修正这个观点。

同构 Agent 团队在「讨论」场景下确实价值有限。但在「分工」场景下，同构完全足够。

你不需要 Agent A 和 Agent B 有不同的「思维模式」。你只需要它们处理不同的文件、不同的模块、不同的任务。它们可以是完全相同的模型——只要它们的工作范围不重叠，就不会有同构的副作用。

就像一个公司雇佣了 10 个同样水平的程序员，分别负责 10 个不同的模块。他们水平一样，但他们处理的代码不一样，所以他们能产生 10 倍的产出。

同构的问题不在于「能力相同」，而在于「视角相同」。

分工不会导致视角相同（因为每个 Agent 看到的数据不同），只有「角色扮演讨论」才会。

所以，上篇文章应该这样修正：

• ❌ 多 Agent 协作是伪命题
• ✅ 多 Agent 讨论（Role Play）是伪命题
• ✅ 多 Agent 分工（Task Distribution）是有价值的
• ✅ 多 Agent 接力（Context Passing）是解决长程任务的关键

现在能做什么？

长程多 Agent 不是等技术成熟了再做。现在就有落地路径：

做法 1：任务拆解 + 子 Agent

把一个大任务拆成子任务。每个子任务用一个独立的 Agent 会话来处理。父 Agent 负责拆解和汇总，子 Agent 负责执行。

Claude Code 的 subagent 功能就是这个模式。你让它做一个大的改动，它自动拆成多个子任务并行执行。

做法 2：Checkpoint 驱动

每完成一个阶段，让 Agent 输出一份结构化的 checkpoint 文档。下一个阶段从 checkpoint 文档开始，不需要继承完整的对话历史。

这个文档就是「Agent 的交接棒」。

做法 3：Code 作为持久记忆

与其依赖 Agent 的对话历史来保持上下文，不如让 Agent 把所有中间状态写入文件系统。代码、测试、文档、注释——这些都是持久化的记忆。

下一个 Agent 只需要读取文件系统就能恢复全部上下文。这比任何对话记忆系统都可靠。

做法 4：人类编排 + Agent 执行

人类负责整体架构和关键决策（这些需要全局视野和判断力），Agent 负责具体的执行任务（这些需要大量的操作但不需要全局视野）。

人是编排者，Agent 是执行者。这不是降级，这是合理的角色分配。

写在最后

上篇文章说「一个 Agent 比十个 Agent 更有价值」。这篇文章说「不，长程任务需要多个 Agent」。

这两个观点不矛盾。它们说的是不同长度的任务。

短任务，一个 Agent 就够了。 不要为了「多 Agent 酷」而多此一举。

长任务，多 Agent 是刚需。 不是因为需要「讨论」，而是因为需要「接力」。

多 Agent 系统的价值不在于让 Agent 聊天，而在于突破单个 Agent 的物理极限。上下文窗口是有限的，但任务的长度可以是无限的。用多个有限的窗口拼出无限的执行长度——这才是多 Agent 的真正意义。

不是十个 Agent 比一个 Agent 聪明。而是一个 Agent 能记住的事情是有限的，十个 Agent 的记忆总量是十倍的。

单个 Agent 的能力是智力问题。多个 Agent 的协作是架构问题。长程任务需要的不是更聪明的 Agent，而是更好的架构。

"