不要再构建多 AI 智能体架构系统 原创

在构建多 AI 智能体系统架构时，许多现有的框架并不理想，通过我们自己的实践经验和试错，提出了一些构建 AI 智能体的原则，并解释了为什么一些看似吸引人的想法在实际中可能并不好用。

在这篇文章中，我将分享以下内容：

1. 上下文工程的原则
2. 构建长期运行 AI 智能体的架构设计
3. 应用这些架构设计原则

下文详细剖析之。

1、上下文工程的原则

我们先来谈谈以下原则：

• 共享上下文
• 行为隐含决策
• 为什么需要原则？

HTML 于1993年问世。2013年，Facebook 向世界发布了 React。如今是2025年，React 及其衍生产品主导了开发者构建网站和应用的方式。为什么？因为 React 不仅仅是一个写代码的框架，它是一种哲学。通过使用 React，你接受了以反应式和模块化的方式构建应用的架构设计模式，这现在被认为是标准，但早期的网络开发者并不总是这么认为。

在 LLM 和构建 AI 智能体的时代，我们感觉像是还在用原始的 HTML 和 CSS，试图将它们组合在一起以获得良好的体验。目前还没有一种构建 AI 智能体的方法成为标准，除了最基础 MCP 的部分。

在某些情况下，像 OpenAI 的 Swarm 和微软的 AutoGen 这样的库，积极推广我认为是错误的构建 AI 智能体的概念，尤其是使用多 AI 智能体架构，我会解释为什么。

当然，如果你是 AI 智能体构建的新手，有很多资源可以教你如何搭建基本的框架。但当涉及到构建严肃的生产应用时，情况就大不相同了。

2、构建长期运行 AI 智能体架构设计

我们先从可靠性开始。当 AI 智能体需要长时间运行并保持连贯的对话时，为了防止错误的累积，你必须采取一些措施。否则，如果不小心，事情很快就会失控。可靠性的核心是上下文工程。

到了2025年，现有的大模型非常智能。但即使是最聪明的人类，如果没有他们被要求做的事情的上下文，也无法有效地完成工作。“Prompt 工程”是一个术语，指的是为 LLM 大模型编写理想格式的任务所需的努力。“上下文工程”是这一概念的升级版。它是在动态系统中自动完成的，需要更多的细微差别，实际上是构建 AI 智能体的工程师的首要任务。

举一个常见类型的 AI 智能体例子：

• 这个 AI 智能体将工作分解为多个部分；
• 启动子 AI 智能体来处理这些部分；
• 最后将这些结果合并。

这种 AI 智能体架构很有吸引力，尤其是如果你的工作领域中有许多并行的任务组件。然而，它非常脆弱。关键的失败点是：

假设你的任务是“构建一个 Flappy Bird 的克隆版”。这被分解为子任务1“构建一个带有绿色管道和碰撞框的移动游戏背景”和子任务2“构建一个可以上下移动的鸟”。

结果是，子 AI 智能体1误解了你的子任务，开始构建一个看起来像超级马里奥兄弟的背景。子 AI 智能体2构建了一个鸟，但它看起来并不像游戏资产，移动方式也和 Flappy Bird 中的鸟不一样。现在，最终的 AI 智能体不得不面对将这两个误解结合起来的不愉快任务。

这听起来可能有些牵强，但大多数现实世界的任务都有许多层次的细微差别，这些都有可能被误解。你可能会认为一个简单的解决方案是将原始任务作为上下文复制给子 AI 智能体。这样，它们就不会误解它们的子任务了。但请记住，在真正的生产系统中，对话很可能是多轮的，AI 智能体可能需要进行一些工具调用来决定如何分解任务，任何细节都可能影响对任务的解释。

原则1：共享上下文，共享完整的 AI 智能体轨迹，而不仅仅是单个消息。

我们再来看看我们的 AI 智能体，这次确保每个 AI 智能体都有前一个 AI 智能体的上下文。

不幸的是，我们还没有完全摆脱困境。当你给 AI 智能体相同的 Flappy Bird 克隆任务时，这次你可能会得到一个鸟和背景，它们的视觉风格完全不同。子 AI 智能体1和子 AI 智能体2看不到对方的工作，因此它们的工作彼此不一致。

子 AI 智能体1和子 AI 智能体2的行为是基于冲突的假设，而这些假设没有提前规定。

原则2：行为隐含决策，冲突的决策会带来糟糕的结果。

我认为原则1和原则2至关重要，而且很少值得违反，因此你应该默认排除任何不遵守这些原则的 AI 智能体架构。你可能会觉得这很受限，但实际上，你仍然可以探索许多不同的 AI 智能体架构。

遵循这些原则的最简单方法是使用单线程线性 AI 智能体：

在这里，上下文是连续的。然而，你可能会遇到一些非常大的任务，它们有许多子部分，上下文窗口开始溢出。

说实话，简单的架构可以让你走得非常远，但对于那些真正长期的任务，以及愿意付出努力的人来说，你可以做得更好。有几种方法可以解决这个问题，今天我介绍其中一种：

在这个世界中，我们引入了一个新的 LLM 模型，其主要目的是将行动和对话的历史压缩成关键细节、事件和决策。这很难做好。它需要投入精力去弄清楚什么是关键信息，并创建一个擅长于此的系统。根据领域，你甚至可以考虑微调一个较小的模型。

你得到的好处是一个在更长上下文中有效的 AI智能体。但你最终还是会遇到限制。我鼓励你思考更好的管理任意长上下文的方法。这最终会成为一个很深的兔子洞！

3、应用这些架构设计原则

如果你是一个 AI 智能体构建者，确保你的 AI 智能体的每一个行为都受到系统其他部分所做所有相关决策的上下文的指导。理想情况下，每一个行为都能看到其他所有内容。不幸的是，由于上下文窗口有限和实际的权衡，这并不总是可能的，你可能需要决定你愿意承担多大的复杂性，以实现你所追求的可靠性水平。

当你思考如何架构你的 AI 智能体以避免冲突的决策制定时，这里有一些现实世界的例子供你思考：

第一、Claude Code 子 AI 智能体

截至2025年6月，Claude Code 是一个会生成子任务的 AI 智能体的例子。然而，它从未与子任务 AI 智能体并行工作，子任务 AI 智能体通常只被要求回答一个问题，而不是编写任何代码。为什么？子任务 AI 智能体缺乏来自主 AI 智能体的上下文，否则它将需要做任何超出回答一个明确定义的问题的事情。如果它们运行多个并行的子 AI 智能体，它们可能会给出冲突的回应，导致我们之前看到的 AI 智能体的可靠性问题。在这种情况下拥有一个子 AI 智能体的好处是，子 AI 智能体的所有调查工作不需要保留在主 AI 智能体的历史中，这允许在上下文耗尽之前有更长的追踪。Claude Code 的设计者采取了一种有意识的简单方法。

第二、编辑应用模型

2024年，许多模型在编辑代码方面真的很糟糕。编码 AI 智能体、IDE、应用构建器等（包括 Devin）的常见做法是使用“编辑应用模型”。关键思想是，实际上，让一个小模型根据你想要的更改的 markdown 解释来重写你的整个文件，比让一个大模型输出一个格式正确的 diff 更可靠。因此，构建者让大模型输出代码编辑的 markdown 解释，然后将这些 markdown 解释输入到小模型中，以实际重写文件。然而，这些系统仍然会有很多故障。例如，小模型经常因为指令中的最轻微的歧义而误解大模型的指令，并做出错误的编辑。今天，编辑决策和应用通常更多地由一个单一模型在一个动作中完成。

4、多 AI 智能体系统架构

如果我们真的想从我们的系统中获得并行性，你可能会认为让决策者“交谈”并解决问题。

这就是我们在意见不合时（在一个理想的世界里）人类所做的。如果工程师 A 的代码与工程师 B 的代码发生合并冲突，正确的协议是讨论差异并达成共识。然而，今天的 AI 智能体并不能像单个 AI 智能体那样可靠地进行这种长上下文的主动讨论。人类在相互传达最重要的知识方面相当高效，但这种效率需要非平凡的智能。

自从 ChatGPT 推出以来不久，人们就一直在探索多个 AI 智能体相互交互以实现目标的想法。虽然我对 AI 智能体相互协作的长期可能性持乐观态度，但很明显，在2025年，运行多个 AI 智能体进行协作只会导致脆弱的系统。决策过于分散，上下文无法在 AI 智能体之间充分共享。目前，我没有看到任何人致力于解决这个困难的跨 AI 智能体上下文传递问题。我个人认为，随着我们让单线程 AI 智能体更擅长与人类沟通，这个问题会自动解决。当这一天到来时，它将释放出更多的并行性和效率。

本文转载自​​玄姐聊AGI​​  作者：玄姐