大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



用于 LLM 代理的框架令人失望。我想根据我们自己的试错经验，提供一些构建代理的原则，并解释为什么一些诱人的想法在实践中实际上相当糟糕。

我们将逐步深入以下原则：

1. 分享上下文
2. 行为隐含着决策

为什么要思考原则？

HTML 于 1993 年引入。2013 年，Facebook 向世界发布了 React。如今是 2025 年，React（及其后继者）主导了开发者构建网站和应用程序的方式。为什么？因为 React 不仅仅是一个编写代码的脚手架。它是一种哲学。通过使用 React，你拥抱了以响应性和模块化模式构建应用程序，现在人们接受这成为一项标准要求，但这对于早期的网页开发者来说并不总是显而易见的。

在 LLMs 和构建 AI Agent 的时代，感觉我们仍然在玩原始的 HTML & CSS，并试图弄清楚如何将这些组合起来以创造良好的体验。目前还没有单一的构建 Agent 的方法成为标准，除了某些绝对的基础之外。

在某些情况下，OpenAI 的  https://github.com/openai/swarm 和微软的  https://github.com/microsoft/autogen 等库积极推动我认为是错误构建 Agent 的方法。具体来说，是使用多 Agent 架构，我将解释原因。

话虽如此，如果你是 Agent 构建的新手，有很多资源可以指导你如何搭建基本框架[1][2]。但当涉及到构建严肃的生产应用时，情况就不同了。

让我们从可靠性开始。当代理在长时间运行时必须真正可靠并保持连贯的对话时，你必须做某些事情来控制潜在的错误累积。否则，如果你不小心，事情很快就会崩溃。可靠性的核心是上下文工程。

上下文工程

到 2025 年，现有的模型非常智能。但即使是最高智能的人类，如果没有他们被要求完成的任务的上下文，也无法有效地完成工作。“提示工程”作为一个术语被创造出来，用于描述需要以适合 LLM 聊天机器人的理想格式编写任务的精力。“上下文工程”是这一步的下一级别。它是在动态系统中自动完成这项工作。它需要更多的细微差别，并且实际上是构建 AI 代理工程师的首要工作。

以一个常见类型的代理为例。这个代理

1. 将其工作分解为多个部分
2. 启动子代理来处理这些部分
3. 最终将这些结果组合起来

这是一个诱人的架构，特别是如果你在一个具有多个并行组件的任务领域工作。然而，它非常脆弱。关键故障点是：

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

结果子代理 1 实际上误解了你的子任务，开始制作一个看起来像超级马里奥兄弟的背景。子代理 2 为你制作了一只鸟，但它看起来不像游戏资源，而且它的移动方式与 Flappy Bird 中的鸟完全不同。现在，最终代理不得不处理这两个误解的组合任务。

这可能看起来有些刻意，但现实中的大多数任务都包含许多层次的细微差别，这些细微差别都有可能被误解。你可能会认为一个简单的解决方案就是将原始任务作为上下文复制到子代理中。这样，它们就不会误解自己的子任务。但请记住，在一个真实的生产系统中，对话很可能是多轮的，代理可能需要调用一些工具来决定如何分解任务，而且任何细节都可能对任务的理解产生后果。

原则一
共享上下文，并共享完整的代理追踪记录，而不仅仅是单个消息

让我们再次修改我们的代理，这次确保每个代理都有前一个代理的上下文。

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

子代理1采取的行动和子代理2采取的行动基于事先未规定的相互冲突的假设。

原则2
行动包含隐含的决策，而相互冲突的决策会导致不良结果

我认为原则1和原则2如此关键，以至于几乎不值得违反，因此你应该默认排除任何不遵守这些原则的代理架构。你可能会认为这很限制，但实际上，你仍然可以探索许多不同的代理架构。

遵循这些原则最简单的方法就是只使用单线程线性代理：

这里上下文是连续的。但是，对于包含大量子部分的大型任务，可能会导致上下文窗口开始溢出。

说实话，简单的架构已经能让你走得很远了，但对于那些真正有长期任务需求，并且愿意付出努力的人来说，你可以做得更好。有几种方法可以解决这个问题，但今天我将只介绍一种：

在这个世界，我们介绍一种新的 LLM 模型，其关键目的是将行动与对话的历史压缩成关键细节、事件和决策。这很难做到正确。 这需要投入资源去弄清楚最终成为关键信息的内容，并创建一个擅长于此的系统。根据领域，你甚至可以考虑微调一个较小的模型（事实上，这正是我们在 Cognition 所做的事情）。

你获得的好处是一个在长上下文中表现有效的智能体。但最终你仍会碰到限制。对于热衷于阅读的人，我鼓励你思考更好的方式来管理任意长的上下文。这最终会变成一个相当深的兔子洞！

如果你是智能体构建者，确保智能体的每个行动都受到系统中其他部分做出的相关决策的上下文信息的影响。理想情况下，每个行动都应该看到所有其他部分。不幸的是，由于上下文窗口的限制和实际权衡，这并不总是可能的，你可能需要决定你愿意承担的复杂程度，以实现你期望的可靠性水平。

多智能体

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

这就是我们在理想情况下会做的事情。如果工程师 A 的代码与工程师 B 的代码产生合并冲突，正确的协议是讨论差异并达成共识。然而，目前的智能体还不太能够进行这种长上下文、主动的对话，其可靠性远不如单个智能体。人类在向彼此传达最重要的知识方面非常高效，但这种效率需要非平凡的智能。

自从 ChatGPT 发布后不久，人们就开始探索多个智能体相互协作以实现目标的想法[3][4]。虽然我对智能体之间长期协作的可能性持乐观态度，但很显然，在 2025 年，运行多个智能体进行协作只会导致脆弱的系统。决策最终变得过于分散，智能体之间无法充分共享上下文。目前，我看不到任何人专门致力于解决这个困难的跨智能体上下文传递问题。我个人认为，随着我们让单线程智能体在与人类沟通方面变得更好，这个问题将自然而然地得到解决。当这一天到来时，它将解锁更大程度的并行性和效率。

迈向更通用的理论

关于上下文工程的这些观察只是我们未来可能考虑的构建智能体标准原则的起点。还有许多更多未讨论的挑战和技术。在 Cognition，智能体构建是我们关注的关键前沿。我们围绕这些反复发现并重新学习的原则构建内部工具和框架，以此强制执行这些理念。但我们的理论可能并不完美，随着该领域的进步，我们预期事情会发生变化，因此也需要一定的灵活性和谦逊。