【精读】理念的Pk: Cognition VS Anthropic：多智能体系统的两种截然不同的态度

最近研究 Agent 框架发现了一场有趣的“撞车”事件：Cognition（Devin 的开发公司）刚发布文章说"不要构建多智能体"，Anthropic 第二天就发布了"我们是这样做多智能体的"。看起来是完全对立的两个理念。

我们来一起精读这两篇文章，来了解目前的 AI 头部公司是如何看待多智能体系统（Multi-Agent）的。

不要构建多智能体

Cognition （Devin的开发公司） 认为现在 LLM Agent 框架都很令人失望，目前仍处于早期阶段，尚未形成统一标准。

为什么不要构建多智能体？

对于需要长期运行并保持连贯对话的生产级 Agent ，可靠性至关重要。而实现可靠性的核心在于“上下文工程（Context Engineering）”。

你肯定指导提示词工程（Prompt Engineering），你需要编写一段最佳的让 LLMs 理解的格式指令来让它们来执行任务。而上下文工程（Context Engineering） 是这个进阶形态，它意味着在动态系统中实现这一过程的自动化。这一技术需要更精妙的处理，实质上已成为构建 AI Agent 的工程师们的核心工作。

如图，这个是一个多智能体的案例架构：

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

假设你期望的任务是“制作一个《Flappy Bird》的游戏”。

• Agent 理解你的任务，并将任务拆分给两个子 Agent 来完成
• Subagent 1: 构建一个带有绿色管道和碰撞箱的移动游戏背景
• Subagent 2: 制作一只可以上下移动的鸟
• 最终的 Agent 将 Subagents 的结果汇总并输出结果

看似非常合理的任务拆分，但是会给子任务带来误解，对于 Subagent 1 来说，没有获取到足够的上下文，可能会误解为要开发一个马里奥的游戏背景。

所以这里提出了一个核心原则：共享上下文

核心原则1: 共享上下文

我们需要共享完整的 Agent 跟踪记录，而不仅仅是单个消息。

如下图，我们对架构进行了修改，Subtask 都接收了前文所有的上下文，最终的 Agent 又集合了所有的上下文。

但是这个架构仍旧可能存在问题，Subtask 1 和 Subtask 2 并行执行，他们各自可能会存在偏差，生成不同的视觉风格，从而导致最终的结果不理想。

PS: 这里假设子任务之间存在事先没有规定的冲突决策

核心原则2: Agent 执行存在隐性决策

Agent 的任务执行可能存在隐性决策，冲突的决策会导致糟糕的结果。

如果要同时遵循这两个原则，最简单的办法就是使用线性执行的 Agent 架构。

这已经是比较简单又可靠的 Agent 架构了，但是由于 LLMs 都有上下文长度限制，我们还需要处理上下文溢出的问题。

对于需要长期运行的任务，需要将历史对话进行关键内容提取和压缩。

现实的应用问题和小结

他们还举例了两个现实应用中的案例：

• Claude Code 的 SubAgent 常只负责回答问题，而不是编写代码，他们缺乏主 Agent 上下文。
• “编辑-应用”模型（Edit Apply Models）（常用于代码编辑器中）早期存在让大型模型生成修改指令，小型模型执行文件重写，但是经常会因为小模型会误解指令而发生错误。所以 Edit Apply 模型都是有单个模型在一个操作中完成的。

总的来说，他们倡导使用更可靠的单线程智能体架构，以确保长期运行任务的稳定性和一致性。

说实话，看到这里我也有点被 Cognition "劝退"了。但转念一想：如果多智能体真的这么不靠谱，为什么还有这么多大企业在开发并推广呢？

构建多智能体

Anthropic 介绍了他们如何构建用于研究（Research）的多智能体系统，该系统更有效地探索复杂主题。

多智能体系统的核心优势

1. 能够应对开放式问题：研究类任务难以预设固定流程，而多智能体可以像人类专家一样不断调整策略，灵活探索。
2. 并行处理与信息压缩：可以同时探索问题的多个方面，每个子智能体在自己的上下文中处理信息，分而治之的策略减少了路径依赖，实现了更全面的调查。
3. 性能的规模化扩展：处理广度优先的查询时，多智能体系统性能比单个最强模型（Claude Opus 4）高出 90.2%

PS: 不过也存在缺点，提升性能的同时也增加了成本， Token 消耗比普通聊天高出 15 倍。

Research 系统的架构

下图是多智能体架构运作实例，是一个编排器-工作者模式 (Orchestrator-Worker Pattern)。

主导研究员智能体（LeadResearcher Agent）作为编排器，负责分析用户查询、制定研究计划，并创建多个专门的子智能体（Subagents）作为工作者并行执行任务。

下图是多智能系统时序图。

提示工程的原则和评估方法

想象一下就像管理一个团队，人越多，沟通成本越高，多智能体系统也是一样，协调的复杂度也会随之飙升。他们的解决方案是精雕细琢每一个提示词。下面总结了提示工程的八个原则：

1. 像智能体一样思考：通过模拟智能体的工作流程来理解其行为，从而发现并修复失败模式。
2. 指导协调器如何委托：为主智能体提供清晰的指令，使其能为子智能体生成包含明确目标、输出格式和任务边界的详细任务描述。
3. 根据查询复杂性调整投入：需要制定规则，据任务的简易程度（如事实查找、对比分析、复杂研究）分配合适的资源（子智能体数量、工具调用次数）
4. Tools 设计和选择至关重要：为 Tools 提供清晰、明确的描述，并制定 Agent 如何及何时调用 Tools 的规则。
5. 让智能体自我改进：让 LLMs 作为提示词工程师，诊断和改进提示或工具描述。
6. 先广后窄的搜索策略：先从宽泛的查询开始，评估可用信息，再逐步聚焦到具体细节，避免因查询过于具体而找不到结果。
7. 引导思考过程：使用“扩展思考模式”（Extended Thinking）让智能体在执行前先输出其思考和规划过程。这能显著提高准确率和效率。
8. 并行工具调用：并行启动子智能体，子智能体并行调用 Tools，两种并行策略可以缩短 90%的时间。

三大评估方法：

1. 从少量样本立即开始评估：开发早期少量的样本也能快速发现重大改进。
2. 规模化使用“LLM-as-judge”：使用一个 LLMs 充当“评委”，根据一套标准（如事实准确性、引用准确性、完整性等）来打分，是一种高效且可扩展的评估方法。
3. 人工评估发现自动化盲点：人工测试能发现评估集无法覆盖的边缘案例和微妙的行为偏差，例如智能体对 SEO 优化内容的偏好问题。

生产环境的可靠性和挑战

• 状态管理与错误处理：智能体是长时间运行且有状态的，错误会累积。系统需要具备持久化执行和从故障点恢复的能力，而非简单地从头重启。
• 调试非确定性系统：由于智能体的动态决策，调试非常困难。需要引入全链路生产追踪，监控智能体的决策模式和交互结构，是诊断问题的关键。
• 部署协调：由于系统是高度状态化的，更新部署时需采用“彩虹部署”（Rainbow Deployments）等策略，新旧版本共存，逐步迁移流量，避免中断正在运行的智能体任务。
• 同步执行的瓶颈：当前系统是同步等待所有子智能体完成后再继续的。未来的方向是实现异步执行，以获得更高的并行度和效率，不过也带来了复杂性。

尽管存在这些挑战，Anthropic 认为多智能体系统在开放式研究任务中已被证明非常有价值，能帮助用户发现商业机会、解决技术难题并节省大量工作时间。

总结

Cognition 和 Anthropic 之间的观点看似对立，实则反映了在构建 AI 代理时，针对不同目标和投入水平的策略差异。

Cognition 采取了更为谨慎和务实的立场，强调单智能体的可靠性和上下文工程对于构建稳定、长运行的生产级代理至关重要。

Anthropic 则展现了多智能体系统在特定高价值领域（如开放式研究）的强大潜力，并通过大量精密的工程实践、提示工程和评估策略成功克服了其中的挑战。

对于 Devin 这样需要长时间专注编程的场景，单智能体的稳定性确实更重要。而对于 Anthropic 这样的研究场景，多智能体的探索能力则更有价值。综合来看，我们还是需要根据不同的场景和团队现状来选择适用的方案。我的建议是：先把单智能体做稳定，再考虑做复杂度更高的多智能体。

拓展阅读

• Cognition AI: Don’t Build Multi-Agents
• Anthropic: How we built our multi-agent research system
• Anthropic: Building effective agents
• OpenAI: A practical guide to building agents

如果你觉得这篇文章对你有帮助，欢迎点赞、分享，你的支持是我持续创作的最大动力！