原文作者：Walden Yan 原文链接：Cognition Blog 原文时间：2025年6月12日
📌 背景与核心观点在LLM（大语言模型）领域，很多开发者都在尝试构建“多智能体”系统 —— 让多个Agent并行合作完成任务。但 Cognition 的作者通过实践发现，这种架构看似先进，实则问题重重，尤其在真实生产环境中极易出错。这篇文章通过讲解“上下文工程（Context Engineering）”的原则，说明了为什么多智能体不是一个好选择，并提供了更稳妥的替代方案。
🧱 上下文工程的两个核心原则原则一：共享上下文（Share Context） 常见代理类型的例子：将工作分解成多个部分启动子代理来处理这些部分最后将这些结果结合起来所以，在多个智能体协作时，如果上下文（任务、对话历史、决策逻辑）没有同步好，就很容易造成理解偏差，最终输出南辕北辙的结果。举个例子：
任务是“开发一个山寨版 Flappy Bird”。
子任务1被分配去做背景，结果它做成了超级玛丽的风格子任务2做了只鸟，但像素风格完全不同，还飞不动。
最后主Agent拿这两个风格割裂的产物，根本拼不成完整游戏。
原则二：行为中隐含了决策（Actions carry implicit decisions）不同Agent在任务中采取的行动，其实隐含了各自的“前设”。如果这些前设没对齐，产出的结果也必然冲突。让我们对代理进行另一次修改，这次确保每个代理都有上一个代理的上下文：
例如：
子Agent 1选择“复古像素风”，子Agent 2却默认“3D卡通风” —— 没人规定统一风格，最终只能产出一个四不像。
❌ 多智能体架构的主要问题上下文碎片化：多个Agent各做各的，彼此看不到对方的状态，容易产生误解。协作成本高：不像人类程序员可以沟通协调，现在的LLM还没有高效的“集体沟通”能力。出错难定位：哪个Agent的误判导致整体失败，很难追踪和调试。✅ 更推荐的方案：单线程 Agent + 上下文压缩✅ 推荐方案一：线性 Agent（single-threaded linear agent）
让一个Agent顺序处理所有子任务，保证上下文连续。优点：上下文一直在同一个Agent中，决策更统一；容错率更高，调试更方便。缺点：对于特别长的任务，容易上下文溢出。
✅ 推荐方案二：压缩上下文（compressed history）设计一个专门的“上下文压缩模型”，定期把前面的决策、信息提炼成摘要，以节省token并保持有效信息。
这很难做好，但一旦做到，就能支持更长任务，也能提升决策一致性。🔍 实际应用中的例子Claude Code 的子智能体Claude 会生成子Agent去分析代码问题，但不会让它们“写代码”，而只是查信息，避免上下文丢失导致的混乱。Edit Apply 模式早期AI改代码时，常常把修改解释写成Markdown，再让另一个模型根据描述去改代码。但这个过程经常出错，因为“描述”和“理解”之间很容易出歧义。现在更推荐用一个模型直接做出修改，避免中间人。🚫 对“多智能体并行协作”的质疑很多项目尝试构建“Agent A + Agent B + Agent C”的协同机制，甚至让它们“互相沟通”。
理想情况是像程序员那样“对线解决冲突”，但现实是 —— 模型并不能高效沟通、上下文理解力也有限，最终导致系统非常脆弱。
构建 Agent 的黄金法则默认不要用多智能体架构，除非你有强力理由和技术手段支撑上下文同步。每一个Agent行为都应该尽可能看见“整个上下文”。能用简单架构完成的，不要搞复杂；能串行就不要并行。
📮 推荐参考 & 工具链接OpenAI Swarm: https://github.com/openai/swarm
Microsoft Autogen: https://github.com/microsoft/autogen
Anthropic Agent Guide: https://www.anthropic.com/engineering/building-effective-agents
Cognition Devin: https://app.devin.ai
如果你也在设计多智能体系统，建议把这篇文章当作红灯警告，看完可能会省下无数调试时间。如需进一步了解Agent设计中的“上下文压缩”、“子任务分解”、“工具调用”等问题，也欢迎继续交流。