昨天刚介绍了探索 Anthropic 的多智能体研究系统：揭秘Agent工程与创新的融合，今天的文章从另外一个角度分析多智能体的构建原则，编译自海外AI公司Cognition发布的内容
在大语言模型（LLM）智能体框架领域，许多看似诱人的想法在实际应用中却表现糟糕。今天，我们将基于实际的试错经验，分享构建可靠智能体的核心原则，并解释为什么多智能体架构并不是最佳选择。
🔍 当前AI智能体开发的现状
HTML于1993年问世，2013年Facebook向世界发布了React。如今已是2025年，React及其衍生框架主导着开发者构建网站和应用的方式。为什么？因为React不仅仅是编写代码的脚手架，更是一种哲学。通过使用React，你拥抱了响应式和模块化的应用构建模式，这些现在被认为是标准要求，但对早期web开发者来说并非显而易见。
在LLM和AI智能体时代，我们仍然像在摆弄原始的HTML和CSS，试图弄清楚如何将这些组合在一起以创造良好的体验。除了一些绝对基础的方法外，还没有单一的智能体构建方法成为标准。
在某些情况下，OpenAI的https://github.com/openai/swarm 和 Microsoft 的 https://github.com/microsoft/autogen 等库会积极推动我认为是构建代理的错误方式的概念。也就是说，使用多代理架构，本文将解释原因。
📋 构建长期运行智能体的理论基础
可靠性是核心
当智能体需要在长时间运行中真正可靠，并维持连贯的对话时，你必须采取某些措施来控制错误复合的可能性。否则，如果不小心，事情会很快分崩离析。可靠性的核心是上下文工程。
什么是上下文工程？
2025年，现有的模型极其智能。但即使是最聪明的人，如果没有他们被要求做什么的上下文，也无法有效地完成工作。’提示工程’这个术语是为了描述为LLM聊天机器人以理想格式编写任务所需的努力。’上下文工程’是这个概念的下一个层次——在动态系统中自动完成这项工作。它需要更多的细节处理，实际上是构建AI智能体的工程师的首要工作。
⚠️ 多智能体架构的致命缺陷
让我们看一个常见智能体类型的例子：
-
将工作分解为多个部分 -
启动子智能体处理这些部分 -
最后合并结果
这是一个诱人的架构，特别是如果你在一个有多个并行组件的任务领域工作。然而，它非常脆弱。关键的失败点是这样的：
假设你的任务是’构建一个Flappy Bird克隆版’。这被分为子任务1’构建一个带有绿色管道和碰撞盒的移动游戏背景’和子任务2’构建一个可以上下移动的鸟’。
结果子智能体1实际上误解了你的子任务，开始构建一个看起来像超级马里奥兄弟的背景。子智能体2为你构建了一只鸟，但它看起来不像游戏资产，移动方式也与Flappy Bird中的完全不同。现在最终智能体面临着合并这两个误解的不理想任务。
这可能看起来是人为的，但大多数现实世界的任务都有许多层次的细节，所有这些都有被误解的可能。你可能认为一个简单的解决方案是将原始任务作为上下文复制给子智能体。但请记住，在真实的生产系统中，对话很可能是多轮的，智能体可能必须进行一些工具调用来决定如何分解任务，任何数量的细节都可能对任务的解释产生影响。
🎯 构建可靠智能体的核心原则
原则1：共享上下文
共享上下文，并共享完整的智能体跟踪，而不仅仅是单个消息
让我们重新审视我们的智能体，这次确保每个智能体都有前一个智能体的上下文。
不幸的是，我们还没有完全脱离困境。当你给智能体相同的Flappy Bird克隆任务时，这次你可能会得到完全不同视觉风格的鸟和背景。子智能体1和子智能体2看不到对方在做什么，所以他们的工作最终彼此不一致。
原则2：行动承载隐含决策
行动承载隐含决策，冲突的决策产生糟糕的结果
子智能体1采取的行动和子智能体2采取的行动基于事先未规定的冲突假设。
我认为原则1和2如此关键，如此少有违反的价值，以至于你应该默认排除任何不遵守它们的智能体架构。你可能认为这是限制性的，但实际上你仍然可以为你的智能体探索各种不同架构的广阔空间。
💡 推荐的智能体架构
单线程线性智能体
遵循这些原则的最简单方法是使用单线程线性智能体：在这里，上下文是连续的。然而，对于非常大的任务，有这么多子部分，你可能会遇到上下文窗口开始溢出的问题。
老实说，简单的架构会让你走得很远，但对于那些有真正长期任务，并愿意付出努力的人，你可以做得更好。有几种方法可以解决这个问题，但今天我只提出一种：
带压缩机制的高级架构
在这个方案中，我们引入一个新的LLM模型，其关键目的是将行动和对话的历史压缩成关键细节、事件和决策。这很难做对。它需要投资来弄清楚什么最终成为关键信息，并创建一个擅长此事的系统。根据领域，你甚至可以考虑微调一个较小的模型（这实际上是我们在Cognition所做的事情）。
你得到的好处是一个在更长上下文中有效的智能体。不过你仍然会最终达到极限。对于热心的读者，我鼓励你思考管理任意长上下文的更好方法。这最终是一个相当深的兔子洞！
🔧 原则的实际应用
如果你是智能体构建者，确保你的智能体的每个行动都由系统其他部分做出的所有相关决策的上下文来指导。理想情况下，每个行动都只是看到其他一切。不幸的是，由于有限的上下文窗口和实际权衡，这并不总是可能的，你可能需要决定你愿意为你追求的可靠性水平承担什么复杂性水平。
实际案例分析
Claude Code子智能体
截至2025年6月，Claude Code是一个生成子任务的智能体示例。然而，它从不与子任务智能体并行工作，子任务智能体通常只被赋予回答问题的任务，而不是编写任何代码。为什么？子任务智能体缺乏来自主智能体的上下文，否则就需要这些上下文来做除了回答明确定义的问题之外的任何事情。
编辑应用模型
2024年，许多模型在编辑代码方面真的很糟糕。编码智能体、IDE、应用构建器等（包括Devin）的常见做法是使用’编辑应用模型’。关键思想是，给定你想要的更改的markdown解释，让小模型重写你的整个文件实际上比让大模型输出正确格式的差异更可靠。
然而，这些系统仍然会非常有缺陷。例如，小模型经常会误解大模型的指令，由于指令中最轻微的歧义而进行错误的编辑。今天，编辑决策制定和应用更经常由单个模型在一个行动中完成。
🤖 为什么多智能体协作还不成熟
如果我们真的想从我们的系统中获得并行性，你可能会想让决策者彼此’交谈’并解决问题。这是我们人类在意见不合时所做的（在理想世界中）。如果工程师A的代码与工程师B造成合并冲突，正确的协议是讨论分歧并达成共识。
然而，今天的智能体还不能进行这种长上下文主动话语的风格，其可靠性比你用单个智能体获得的要高得多。人类在向彼此传达我们最重要的知识方面相当高效，但这种效率需要非凡的智力。
自ChatGPT发布后不久，人们一直在探索多个智能体相互交互以实现目标的想法。虽然我对智能体彼此协作的长期可能性持乐观态度，但很明显，在2025年，运行多个智能体协作只会导致脆弱的系统。决策制定最终变得过于分散，上下文无法在智能体之间充分共享。
目前，我没有看到任何人致力于解决这个困难的跨智能体上下文传递问题。我个人认为，当我们让单线程智能体在与人类交流方面变得更好时，这将免费到来。当这一天到来时，它将解锁更大程度的并行性和效率。
🚀 迈向更通用的理论
这些关于上下文工程的观察只是我们有朝一日可能考虑的构建智能体标准原则的开始。还有许多这里没有讨论的挑战和技术。在Cognition，智能体构建是我们思考的关键前沿。我们围绕这些我们反复发现自己重新学习的原则构建我们的内部工具和框架，作为强化这些想法的方式。
但我们的理论可能并不完美，我们期望随着领域的发展事情会发生变化，因此也需要一些灵活性和谦逊。
📊 核心要点总结
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
💭 写在最后
构建可靠的AI智能体需要深入理解上下文工程的重要性。虽然多智能体架构看起来很诱人，但在2025年的技术现状下，单线程智能体配合适当的上下文管理仍然是最可靠的选择。
随着技术的不断发展，我们期待看到更成熟的多智能体协作方案出现。但在那之前，让我们专注于构建真正可靠、可投入生产的智能体系统。
#artContent h1{font-size:16px;font-weight: 400;}#artContent p img{float:none !important;}#artContent table{width:100% !important;}
