别急着搞多Agent协作，单线程就够了
别急着搞多Agent协作，单线程就够了
最近AI Agent火得一塌糊涂，各路大佬都在搞自己的智能体系统。
我身边也有不少朋友兴奋地跟我聊："我们可以让Agent A负责前端开发，Agent B负责后端，Agent C专门做测试，然后它们互相协作，自动把整个项目干完！"
听起来是不是特别美好？分工明确，各司其职，简直就像一个完美运作的开发团队。
但是当我真的动手去尝试的时候，发现——完全不是那么回事。😵(((φ(◎ロ◎;)φ)))
最近读了Cognition（就是做Devin的那个团队）写的一篇文章，感触挺深的。他们从实战经验出发，把多Agent协作的问题讲得非常透彻。今天就来聊聊这个话题。
先搞清楚一个概念：上下文工程 > 提示词工程
在聊多Agent之前，得先铺垫一个很重要的认知转变。
2025年的大模型已经足够聪明了，你给它一段代码让它debug，给它一个需求让它写方案，它都能给你一个像模像样的结果。但问题是——再聪明的人，如果你不告诉他背景信息，他也干不了活。
打个比方，你把一个顶级架构师扔进一间会议室，不告诉他项目是什么、技术栈是什么、团队有多少人、预算多少、deadline是什么时候，然后跟他说"你来设计一下系统架构"——他能设计出什么？啥也设计不出来。
所以这里有两个概念需要区分：
- 提示词工程（Prompt Engineering）：就是我们在ChatGPT、Claude这种对话框里写提示词的技巧。说白了就是"怎么跟AI聊天能获得更好的回答"。
- 上下文工程（Context Engineering）：在动态系统中，自动地为AI组装和提供正确的上下文信息。这才是构建AI Agent的人真正要干的活。
你可以理解为：提示词工程是你去面试时怎么回答HR的问题，上下文工程是HR在面试前有没有把你的简历给到面试官。
没有简历，面试官再厉害也评估不了你。（不是）
一个让人崩溃的例子：Flappy Bird
Cognition在文章里举了一个特别直观的例子，我觉得拿来解释再合适不过了。
假设我们要让AI Agent做一个Flappy Bird的克隆游戏。
在多Agent的思路下，我们把任务拆成两个子任务：
- 子Agent 1：构建移动的背景和绿色管道
- 子Agent 2：构建一个可以移动的小鸟
看起来拆得挺合理的对吧？每个子Agent各干各的，最后合并一下就完事了。
但实际运行起来呢？
- 子Agent 1看到"移动的背景和绿色管道"，脑子里想到的是超级马里奥那种横版卷轴背景，于是吭哧吭哧搞了一个马里奥风格的砖块地面和管道
- 子Agent 2看到"可以移动的小鸟"，也不去参考原版Flappy Bird的素材风格，自己凭感觉画了一个卡通鸟出来
- 最后负责合并的Agent看着这两个风格完全不搭的东西发呆——一边是马里奥世界，一边是一只不知道从哪个游戏里飞出来的鸟
你说这拼在一起能看吗？
你可能觉得，那我在子任务里把原始需求也附上去不就好了？比如告诉子Agent 1"你要做的是Flappy Bird游戏的背景"。
但这依然不够。因为在多轮对话和工具调用的过程中，会不断产生新的细节和隐含决策。你没法把所有这些微妙的信息都塞给每个子Agent。
两个核心问题
从这个例子可以提炼出两个根本性的问题：
问题一：上下文共享的困境
你可能会想，那我让所有子Agent共享上下文不就行了？
问题是，光共享"消息"是不够的。你需要共享的是完整的Agent执行轨迹——包括它做了什么决定、为什么这么做、中间经历了哪些尝试和修正。
但即使你做了完整的上下文共享，子Agent之间仍然有一个致命问题：它们看不到彼此在做什么。
子Agent 1在设计背景风格的时候，子Agent 2已经在画鸟了。两边各自为战，出来的东西风格南辕北辙。这就像两个设计师在不同房间里各自画同一个APP的UI，没有沟通没有对齐，最后拼在一起肯定是要打架的。
问题二：隐含决策的冲突
这是更深层的问题。
当Agent在执行任务时，每一步操作都携带着隐含的决策。比如子Agent 1在绘制背景时选择了像素风格，这就是一个隐含决策——没有人明确告诉它要选像素风格，它自己推断出来的。
而子Agent 2在画鸟时选择了矢量插画风格，这又是一个隐含决策。
两个隐含决策互相冲突，但没有任何机制能在事前就协调好这些决策。因为很多决策只有在执行过程中才会产生，你不可能在任务开始前就预见到所有的分支选择。
推荐方案：单线程线性Agent
那怎么办？Cognition给出的答案是：别搞多Agent并行协作了，老老实实用单线程线性Agent。
什么叫单线程线性Agent？就是一条道走到黑：
- 接收任务
- 规划
- 执行第一步
- 根据第一步结果执行第二步
- 以此类推直到完成
这种方式的最大优势就是上下文是连续的。
Agent在执行每一步时，都能看到之前所有步骤的结果、决策和中间产物。不存在"我不知道你干了啥"的问题，也不存在"咱俩风格不一致"的问题。
用一个不太恰当的比喻：多Agent协作像是把一道菜的做法拆成多个人同时做，一个人切菜、一个人调料、一个人炒锅——看起来并行效率高，但最后炒出来的味道可能是各干各的。单线程则是一个厨师从头做到尾，虽然慢一点，但味道至少是协调统一的。
长任务怎么办？
你可能会问：如果任务很长，上下文窗口放不下怎么办？
Cognition给出的方案是用一个上下文压缩LLM来处理。
简单说就是：用一个专门的LLM，把之前的历史记录（包括对话、工具调用、决策等）压缩成一份摘要——保留关键细节、重要事件和核心决策，丢掉不重要的细枝末节。
就像一个项目的会议纪要，你不需要记录每个人说的每一句话，但你需要记录"我们决定了什么"、"为什么这么决定"、"目前进展到哪了"。
真实案例：Claude Code
其实不用看太远，Claude Code本身就是一个很好的例子。
Claude Code在工作中会生成子任务，但它的设计有一个非常克制的地方：它永远不会和子Agent并行工作。
子Agent在Claude Code里扮演的角色非常有限——它们只负责回答主Agent提出的问题，不写代码。
为什么不写代码？因为子Agent缺乏主Agent的完整上下文。如果让它们也动手写代码，就会出现前面说的那些问题——风格不一致、决策冲突、互相打架。
这是一个非常刻意的设计选择。Anthropic团队完全有能力让Claude Code搞多Agent并行，但他们选择了不做。不是技术做不到，而是做了之后系统会变得脆弱且不可靠。
我的想法
说实话，读完Cognition的这篇文章，我有一种"终于有人把这件事说明白了"的感觉。
之前在各种技术社区里看到大家疯狂吹多Agent协作，总觉得很酷但哪里不对劲。现在想明白了——多Agent协作的问题不在于每个Agent不够聪明，而在于协调成本太高了。
这其实跟我们日常的团队协作是一回事。一个五人小团队，如果沟通顺畅、信息同步到位，效率可能比一个二十人团队还高。因为人越多，信息同步的成本就越高，出现信息偏差的概率就越大。
Agent也是一样的道理。
当然，我对多Agent协作的长期前景还是持乐观态度的。随着模型能力的提升和协调机制的完善，多Agent系统肯定会越来越成熟。但至少在2025年的今天，如果你真的需要构建一个可靠的、能跑在生产线上的AI Agent，单线程线性架构才是最务实的选择。
与其花时间去研究怎么让多个Agent不打架，不如把精力放在上下文工程上——怎么给你的Agent提供更好的、更完整的、更精准的上下文信息。
毕竟，一个带着完整上下文的单线程Agent，比五个互相不知道对方在干嘛的多Agent，靠谱得多。
参考
- 原文来自 Cognition 团队博客，也就是做 Devin（第一个AI软件工程师）的那个团队