这是最近看的第二篇比较好的文章——不要构建多智能体系统。看起来反常识。
一般的认为：构建不同的智能体解决不同的（垂直）问题，然后这些智能体组合起来，解决更复杂的问题。
Google 也是这样认为，今年上半年就推出了A2A Protocol,用来实现 Agent 之间的通信，但是当前，几乎没有进展。

问题出在哪里？

• • 垂类的 Agent 面对一个敌人：通用的 Agent。
  类似 Manus 这种，通过虚拟机环境+AI Coding，目标是做任何事情。
  比如我想做一个数据分析类的 Agent，但是 Manus 完全可以做，毕竟都可以通过coding 实现。
  所以，就要找独特的数据、独特的 know-how 的 Agent（产品） 。

• • 现在的模型能力，很难一次性解决问题
  特点是类似 Cursor/Manus，本质上是 chat+虚拟环境。时刻人工接管，至少调整、重试。

• • 构建多 Agent 的难度大。
  下文详细展开。

来源： https://cognition.ai/blog/dont-build-multi-agents#applying-the-principles

上下文工程原则

We'll work our way up to the following principles:
我们将逐步建立以下原则：

1. 1. Share context

2. 2. Actions carry implicit decisions

1. 共享上下文
2. 行动承载隐含决策

Why think about principles?
为什么要思考原则？

HTML was introduced in 1993. In 2013, Facebook released React to the world. It is now 2025 and React (and its descendants) dominates the way developers build sites and apps. Why? Because React is not just a scaffold for writing code. It is a philosophy. By using React, you embrace building applications with a pattern of reactivity and modularity, which people now accept to be a standard requirement, but this was not always obvious to early web developers.
HTML于1993年推出。2013年，Facebook向世界发布了React。现在是2025年，React（及其衍生产品）主导着开发者构建网站和应用程序的方式。为什么？因为React不仅仅是编写代码的脚手架。它是一种哲学。通过使用React，你拥抱了以反应性和模块化模式构建应用程序的理念，人们现在接受这是标准要求，但这对早期的Web开发者来说并不总是显而易见的。

In the age of LLMs and building AI Agents, it feels like we're still playing with raw HTML & CSS and figuring out how to fit these together to make a good experience. No single approach to building agents has become the standard yet, besides some of the absolute basics.
在LLM和构建AI智能体的时代，感觉我们仍在使用原始的HTML和CSS，并试图弄清楚如何将这些组合在一起以创造良好的体验。除了一些绝对基础之外，还没有单一的构建智能体的方法成为标准。

In some cases, libraries such as https://github.com/openai/swarm by OpenAI and https://github.com/microsoft/autogen by Microsoft actively push concepts which I believe to be the wrong way of building agents. Namely, using multi-agent architectures, and I'll explain why.

在某些情况下，OpenAI的https://github.com/openai/swarm和Microsoft的https://github.com/microsoft/autogen等库积极推广我认为是构建智能体错误方式的概念。即使用多智能体架构，我将解释原因。

That said, if you're new to agent-building, there are lots of resources on how to set up the basic scaffolding [1] [2]. But when it comes to building serious production applications, it's a different story.
也就是说，如果你是智能体构建的新手，有很多关于如何设置基本脚手架的资源[1][2]。但是当涉及到构建严肃的生产应用程序时，情况就不同了。

构建长期运行智能体的理论

Let's start with reliability. When agents have to actually be reliable while running for long periods of time and maintain coherent conversations, there are certain things you must do to contain the potential for compounding errors. Otherwise, if you're not careful, things fall apart quickly. At the core of reliability is Context Engineering.
让我们从可靠性开始。当智能体必须在长时间运行时实际可靠并保持连贯的对话时，你必须做某些事情来控制复合错误的可能性。否则，如果你不小心，事情会很快崩溃。可靠性的核心是上下文工程。

Context Engineering
上下文工程

In 2025, the models out there are extremely intelligent. But even the smartest human won't be able to do their job effectively without the context of what they're being asked to do. "Prompt engineering" was coined as a term for the effort needing to write your task in the ideal format for a LLM chatbot. "Context engineering" is the next level of this. It is about doing this automatically in a dynamic system. It takes more nuance and is effectively the #1 job of engineers building AI agents.
在2025年，现有的模型极其智能。但即使是最聪明的人，如果没有他们被要求做什么的上下文，也无法有效地完成工作。"提示工程"被创造为一个术语，用于描述为LLM聊天机器人以理想格式编写任务所需的努力。"上下文工程"是这个的下一个层次。它是关于在动态系统中自动执行此操作。它需要更多的细致入微，实际上是构建AI智能体的工程师的第一要务。

Take an example of a common type of agent. This agent

1. 1. breaks its work down into multiple parts

2. 2. starts subagents to work on those parts

3. 3. combines those results in the end

以一个常见类型的智能体为例。这个智能体：
1. 将其工作分解为多个部分
2. 启动子智能体来处理这些部分
3. 最后合并这些结果

Multi-agent architecture diagram 1

This is a tempting architecture, especially if you work in a domain of tasks with several parallel components to it. However, it is very fragile. The key failure point is this:
这是一个诱人的架构，特别是如果你在一个有几个并行组件的任务领域工作。然而，它非常脆弱。关键的失败点是：

Suppose your Task is "build a Flappy Bird clone". This gets divided into Subtask 1 "build a moving game background with green pipes and hit boxes" and Subtask 2 "build a bird that you can move up and down".

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

It turns out subagent 1 actually mistook your subtask and started building a background that looks like Super Mario Bros. Subagent 2 built you a bird, but it doesn't look like a game asset and it moves nothing like the one in Flappy Bird.

Now the final agent is left with the undesirable task of combining these two miscommunications.

结果子智能体1实际上误解了你的子任务，开始构建一个看起来像超级马里奥兄弟的背景。子智能体2为你构建了一只鸟，但它看起来不像游戏资产，移动方式也不像Flappy Bird中的那只。现在最终智能体面临着合并这两个误解的不良任务。

This may seem contrived, but most real-world tasks have many layers of nuance that all have the potential to be miscommunicated. You might think that a simple solution would be to just copy over the original task as context to the subagents as well. That way, they don't misunderstand their subtask. But remember that in a real production system, the conversation is most likely multi-turn, the agent probably had to make some tool calls to decide how to break down the task, and any number of details could have consequences on the interpretation of the task.
这可能看起来很牵强，但大多数现实世界的任务都有许多层次的细微差别，都有被误解的可能性。你可能认为一个简单的解决方案是将原始任务作为上下文也复制给子智能体。这样，他们就不会误解他们的子任务。但请记住，在真正的生产系统中，对话很可能是多轮的，智能体可能必须进行一些工具调用来决定如何分解任务，任何数量的细节都可能对任务的解释产生后果。

Principle 1
Share context, and share full agent traces, not just individual messages

原则1
共享上下文，并共享完整的智能体跟踪，而不仅仅是单个消息

Let's take another revision at our agent, this time making sure each agent has the context of the previous agents.
让我们对我们的智能体进行另一次修订，这次确保每个智能体都有前一个智能体的上下文。

Multi-agent architecture diagram 2

Unfortunately, we aren't quite out of the woods. When you give your agent the same Flappy Bird cloning task, this time, you might end up with a bird and background with completely different visual styles. Subagent 1 and subagent 2 cannot not see what the other was doing and so their work ends up being inconsistent with each other.
不幸的是，我们还没有完全脱离困境。当你给你的智能体相同的Flappy Bird克隆任务时，这次，你可能最终得到一只鸟和背景，它们具有完全不同的视觉风格。子智能体1和子智能体2无法看到对方在做什么，因此他们的工作最终彼此不一致。

The actions subagent 1 took and the actions subagent 2 took were based on conflicting assumptions not prescribed upfront.
子智能体1采取的行动和子智能体2采取的行动基于事先未规定的冲突假设。

Principle 2
Actions carry implicit decisions, and conflicting decisions carry bad results

原则2
行动承载隐含决策，冲突的决策带来糟糕的结果

I would argue that Principles 1 & 2 are so critical, and so rarely worth violating, that you should by default rule out any agent architectures that don't abide by then. You might think this is constraining, but there is actually a wide space of different architectures you could still explore for your agent.
我认为原则1和2是如此关键，很少值得违反，以至于你应该默认排除任何不遵守它们的智能体架构。你可能认为这是限制性的，但实际上你仍然可以为你的智能体探索广泛的不同架构空间。

The simplest way to follow the principles is to just use a single-threaded linear agent:
遵循这些原则的最简单方法是使用单线程线性智能体：

Single-threaded architecture diagram

Here, the context is continuous. However, you might run into issues for very large tasks with so many subparts that context windows start to overflow.
在这里，上下文是连续的。然而，对于非常大的任务，有如此多的子部分，你可能会遇到上下文窗口开始溢出的问题。

Context overflow diagram

To be honest, the simple architecture will get you very far, but for those who have truly long-duration tasks, and are willing to put in the effort, you can do even better. There are several ways you could solve this, but today I will present just one:
说实话，简单的架构会让你走得很远，但对于那些真正有长期任务并愿意付出努力的人，你可以做得更好。有几种方法可以解决这个问题，但今天我只提出一种：

Compression architecture diagram

In this world, we introduce a new LLM model whose key purpose is to compress a history of actions & conversation into key details, events, and decisions. This is hard to get right. It takes investment into figuring out what ends up being the key information and creating a system that is good at this. Depending on the domain, you might even consider fine-tuning a smaller model (this is in fact something we've done at Cognition).
在这个世界中，我们引入了一个新的LLM模型，其关键目的是将行动和对话的历史压缩为关键细节、事件和决策。这很难做对。它需要投资于弄清楚什么最终成为关键信息，并创建一个擅长此事的系统。根据领域，你甚至可能考虑微调一个较小的模型（这实际上是我们在Cognition所做的事情）。

The benefit you get is an agent that is effective at longer contexts. You will still eventually hit a limit though. For the avid reader, I encourage you to think of better ways to manage arbitrarily long contexts. It ends up being quite a deep rabbit hole!
你得到的好处是一个在更长上下文中有效的智能体。不过，你仍然会最终达到一个限制。对于热心的读者，我鼓励你思考管理任意长上下文的更好方法。这最终是一个相当深的兔子洞！

应用原则

If you're an agent-builder, ensure your agent's every action is informed by the context of all relevant decisions made by other parts of the system. Ideally, every action would just see everything else. Unfortunately, this is not always possible due to limited context windows and practical tradeoffs, and you may need to decide what level of complexity you are willing to take on for the level of reliability you aim for.
如果你是智能体构建者，请确保你的智能体的每一个行动都由系统其他部分做出的所有相关决策的上下文通知。理想情况下，每个行动都会看到其他一切。不幸的是，由于有限的上下文窗口和实际权衡，这并不总是可能的，你可能需要决定你愿意为你追求的可靠性水平承担什么复杂性水平。

As you think about architecting your agents to avoid conflicting decision-making, here are some real-world examples to ponder:
当你考虑架构你的智能体以避免冲突的决策制定时，这里有一些现实世界的例子可以思考：

Claude Code Subagents
As of June 2025, Claude Code is an example of an agent that spawns subtasks. However, it never does work in parallel with the subtask agent, and the subtask agent is usually only tasked with answering a question, not writing any code. Why? The subtask agent lacks context from the main agent that would otherwise be needed to do anything beyond answering a well-defined question. And if they were to run multiple parallel subagents, they might give conflicting responses, resulting in the reliability issues we saw with our earlier examples of agents. The benefit of having a subagent in this case is that all the subagent's investigative work does not need to remain in the history of the main agent, allowing for longer traces before running out of context. The designers of Claude Code took a purposefully simple approach.
Claude Code子智能体
截至2025年6月，Claude Code是一个生成子任务的智能体的例子。然而，它从不与子任务智能体并行工作，子任务智能体通常只被任务回答问题，而不是编写任何代码。为什么？子任务智能体缺乏来自主智能体的上下文，否则需要这些上下文来做除了回答明确定义的问题之外的任何事情。如果他们要运行多个并行子智能体，他们可能会给出冲突的响应，导致我们在早期智能体示例中看到的可靠性问题。在这种情况下拥有子智能体的好处是，所有子智能体的调查工作不需要保留在主智能体的历史中，允许在用完上下文之前进行更长的跟踪。Claude Code的设计者采用了有目的的简单方法。

Edit Apply Models
In 2024, many models were really bad at editing code. A common practice among coding agents, IDEs, app builders, etc. (including Devin) was to use an "edit apply model." The key idea was that it was actually more reliable to get a small model to rewrite your entire file, given a markdown explanation of the changes you wanted, than to get a large model to output a properly formatted diff. So, builders had the large models output markdown explanations of code edits and then fed these markdown explanations to small models to actually rewrite the files. However, these systems would still be very faulty. Often times, for example, the small model would misinterpret the instructions of the large model and make an incorrect edit due to the most slight ambiguities in the instructions. Today, the edit decision-making and applying are more often done by a single model in one action.
编辑应用模型
在2024年，许多模型在编辑代码方面真的很糟糕。编码智能体、IDE、应用程序构建器等（包括Devin）的常见做法是使用"编辑应用模型"。关键想法是，给定你想要的更改的markdown解释，让一个小模型重写你的整个文件实际上比让一个大模型输出正确格式的差异更可靠。因此，构建者让大模型输出代码编辑的markdown解释，然后将这些markdown解释提供给小模型以实际重写文件。然而，这些系统仍然会非常有缺陷。例如，小模型经常会误解大模型的指令，并由于指令中最轻微的歧义而进行错误的编辑。今天，编辑决策制定和应用更经常由单个模型在一个行动中完成。

Multi-Agents
多智能体

If we really want to get parallelism out of our system, you might think to let the decision makers "talk" to each other and work things out.
如果我们真的想从我们的系统中获得并行性，你可能会想让决策制定者彼此"交谈"并解决问题。

This is what us humans do when we disagree (in an ideal world). If Engineer A's code causes a merge conflict with Engineer B, the correct protocol is to talk out the differences and reach a consensus. However, agents today are not quite able to engage in this style of long-context proactive discourse with much more reliability than you would get with a single agent. Humans are quite efficient at communicating our most important knowledge to one another, but this efficiency takes nontrivial intelligence.
这是我们人类在不同意时所做的（在理想世界中）。如果工程师A的代码与工程师B发生合并冲突，正确的协议是讨论差异并达成共识。然而，今天的智能体还不能够以比你用单个智能体获得的可靠性更高的方式参与这种长上下文主动话语。人类在向彼此传达我们最重要的知识方面相当高效，但这种效率需要非平凡的智能。

Since not long after the launch of ChatGPT, people have been exploring the idea of multiple agents interacting with one another to achieve goals [3][4]. While I'm optimistic about the long-term possibilities of agents collaborating with one another, it is evident that in 2025, running multiple agents in collaboration only results in fragile systems. The decision-making ends up being too dispersed and context isn't able to be shared thoroughly enough between the agents. At the moment, I don't see anyone putting a dedicated effort to solving this difficult cross-agent context-passing problem. I personally think it will come for free as we make our single-threaded agents even better at communicating with humans. When this day comes, it will unlock much greater amounts of parallelism and efficiency.
自ChatGPT推出后不久，人们一直在探索多个智能体相互交互以实现目标的想法[3][4]。虽然我对智能体彼此协作的长期可能性持乐观态度，但很明显，在2025年，运行多个智能体协作只会导致脆弱的系统。决策制定最终过于分散，上下文无法在智能体之间充分共享。目前，我没有看到任何人专门致力于解决这个困难的跨智能体上下文传递问题。我个人认为，当我们让单线程智能体在与人类交流方面变得更好时，这将免费到来。当这一天到来时，它将释放更大量的并行性和效率。

Toward a More General Theory
朝向更一般的理论

These observations on context engineering are just the start to what we might someday consider the standard principles of building agents. And there are many more challenges and techniques not discussed here. At Cognition, agent building is a key frontier we think about. We build our internal tools and frameworks around these principles we repeatedly find ourselves relearning as a way to enforce these ideas. But our theories are likely not perfect, and we expect things to change as the field advances, so some flexibility and humility is required as well.
这些关于上下文工程的观察只是我们有朝一日可能考虑的构建智能体标准原则的开始。还有许多这里没有讨论的挑战和技术。在Cognition，智能体构建是我们思考的关键前沿。我们围绕这些我们反复发现自己重新学习的原则构建我们的内部工具和框架，作为强制执行这些想法的方式。但我们的理论可能并不完美，我们预期随着领域的发展事情会发生变化，因此也需要一些灵活性和谦逊。

参考文献

如何学习AI大模型 ？

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。【保证100%免费】🆓

CSDN粉丝独家福利

这份完整版的 AI 大模型学习资料已经上传CSDN，朋友们如果需要可以扫描下方二维码&点击下方CSDN官方认证链接免费领取 【保证100%免费】

读者福利： 👉👉CSDN大礼包：《最新AI大模型学习资源包》免费分享 👈👈

（👆👆👆安全链接，放心点击）

对于0基础小白入门：

如果你是零基础小白，想快速入门大模型是可以考虑的。

一方面是学习时间相对较短，学习内容更全面更集中。
二方面是可以根据这些资料规划好学习计划和方向。

👉1.大模型入门学习思维导图👈

要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。

对于从来没有接触过AI大模型的同学，我们帮你准备了详细的学习成长路线图&学习规划。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。（全套教程文末领取哈）

👉2.AGI大模型配套视频👈

很多朋友都不喜欢晦涩的文字，我也为大家准备了视频教程，每个章节都是当前板块的精华浓缩。

👉3.大模型实际应用报告合集👈

这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示。（全套教程文末领取哈）

👉4.大模型实战项目&项目源码👈

光学理论是没用的，要学会跟着一起做，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战项目来学习。（全套教程文末领取哈）

👉5.大模型经典学习电子书👈

随着人工智能技术的飞速发展，AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型，如GPT-3、BERT、XLNet等，以其强大的语言理解和生成能力，正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。（全套教程文末领取哈）

👉6.大模型面试题&答案👈

截至目前大模型已经超过200个，在大模型纵横的时代，不仅大模型技术越来越卷，就连大模型相关的岗位和面试也开始越来越卷了。为了让大家更容易上车大模型算法赛道，我总结了大模型常考的面试题。（全套教程文末领取哈）

为什么分享这些资料?

只要你是真心想学AI大模型，我这份资料就可以无偿分享给你学习，我国在这方面的相关人才比较紧缺，大模型行业确实也需要更多的有志之士加入进来，我也真心希望帮助大家学好这门技术，如果日后有什么学习上的问题，欢迎找我交流，有技术上面的问题，我是很愿意去帮助大家的！

这些资料真的有用吗?

这份资料由我和鲁为民博士共同整理，鲁为民博士先后获得了北京清华大学学士和美国加州理工学院博士学位，在包括IEEE Transactions等学术期刊和诸多国际会议上发表了超过50篇学术论文、取得了多项美国和中国发明专利，同时还斩获了吴文俊人工智能科学技术奖。目前我正在和鲁博士共同进行人工智能的研究。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

CSDN粉丝独家福利

这份完整版的 AI 大模型学习资料已经上传CSDN，朋友们如果需要可以扫描下方二维码&点击下方CSDN官方认证链接免费领取 【保证100%免费】

读者福利： 👉👉CSDN大礼包：《最新AI大模型学习资源包》免费分享 👈👈

（👆👆👆安全链接，放心点击）