单智能体还是多智能体？一场被低估的架构之争

当企业纷纷押注“智能体时代”，真正的分歧才刚刚开始：是构建高度协作的多智能体系统，还是打磨一个上下文完整、足够可靠的单智能体？Anthropic与Cognition给出了几乎相反的答案，而这场分歧，决定了AI系统能走多远。

为什么“智能体架构”突然成了企业级问题

如果你觉得“单智能体 vs 多智能体”只是工程师的小众争论，那你可能低估了它的重要性。在视频一开始，The AI Daily Brief 就点出一个关键信号：在 Microsoft Build 大会上，微软几乎跳过了“强大单一智能体”的阶段，直接进入了“多智能体编排时代”。这不是实验室里的炫技，而是面向企业的基础设施选择。

原因很现实。企业真正需要的不是聊天机器人，而是能完成“完整任务”的系统——做研究、写代码、调用工具、跨系统协作。这些任务往往是开放式的、不可预先规划路径的。正如主持人所说，智能体系统正在从“有趣的概念”变成“企业内部的常态配置”。

也正是在这个背景下，两篇立场几乎对立的文章被放在了一起讨论：Anthropic 的《How we built our multi-agent research system》，以及 Cognition（Devon 的开发团队）那篇标题直白的博客——《Don’t build multi-agents》。一个来自前沿模型公司，一个来自实战型代码工具团队，分歧本身就很耐人寻味。

Anthropic的答案：复杂研究，只能靠多智能体硬扛

Anthropic 给出的，是一个非常“教科书级”的多智能体案例：他们的 Research Agent，也就是 Claude 深度研究功能背后的系统。它的目标很明确——在互联网上搜索信息、整理证据、输出一份完整报告。

Anthropic 在文中直言，研究型任务的本质是“不可预测”。你无法提前写好一条固定流程，因为每一步发现都会影响下一步方向。他们写道，线性的 one-shot 管道“无法处理这些任务”，而智能体必须“自主运行多个回合，根据中间发现不断做决策”。

具体架构上，这是一个典型的“编排者 + 子智能体”系统：一个主智能体负责拆解任务、制定策略，多个子智能体并行调用搜索工具，专注于极其细碎的信息点。Anthropic 举了一个很生动的例子：如果用户要查找 S&P 500 所有公司的董事会成员名单，每个子智能体只负责一家公司的信息。

这种设计带来了几个实打实的好处。第一，并行化显著提速，几十个子智能体同时工作。第二，系统更健壮，某个子任务失败，编排智能体可以“重新生成一个子智能体再试一次”。第三，也是最反直觉的一点：他们发现，用更小、更便宜的模型当子智能体，反而效果更好。

在内部评测中，一个“Claude 4 Opus 作为编排者 + Claude 4 Sonnet 作为子智能体”的多智能体系统，比单一 Claude 4 Opus 智能体的表现高出 90.2%。Anthropic 甚至坦率地总结道：“多智能体系统之所以有效，主要是因为它们能花足够多的 token 来解决问题。”他们发现，仅 token 使用量就解释了 80% 的性能提升。

当然，代价也同样清晰：多智能体系统非常昂贵。他们的数据表明，数据智能体通常消耗约 4 倍于聊天的 token，而多智能体系统则高达 15 倍。结论很现实——只有“价值足够高”的任务，才值得用这种方式。

Cognition的反击：多智能体在真实世界里太脆弱

如果说 Anthropic 的文章充满了“系统工程的优雅”，那 Cognition 的博客则更像是一篇踩坑实录。作者 Walden Yan 开门见山：“LLM 智能体框架的表现，出人意料地令人失望。”

他们的核心立场很明确：在复杂、长时、强依赖上下文的任务中（尤其是代码生成），与其构建脆弱的多智能体系统，不如打造一个能端到端完成任务的单智能体。

这里的“单智能体”并不是把所有上下文一股脑塞给模型，而是一种“线性交接”的设计。第一个智能体拆解任务，然后把完整上下文交给下一个子智能体，后者完成一步后，再把“原始上下文 + 新增决策”交给下一步。关键不在于并行，而在于上下文的连续性。

Cognition 提出了一个很有洞见的概念：Context Engineering（上下文工程）。他们认为，Prompt Engineering 只是“人类手动写提示词”，而上下文工程才是 2025 年构建智能体的核心工作——让系统自动、动态地维护正确的上下文。

他们也解释了为什么并行多智能体在实践中容易失败。以“做一个 Flappy Bird 克隆”为例，不同子智能体可能各自正确，却在接口、假设或隐含决策上互相冲突，最终让主智能体陷入“拼接错误结果”的噩梦。

博客中有一句非常值得记住的话：“行动本身就包含隐含决策，而冲突的决策会带来糟糕的结果。”因此，他们提出两条几乎是“红线级别”的原则：第一，必须共享完整上下文和完整行动轨迹，而不只是消息；第二，违反这两点的架构，原则上就不该使用。

真正的分歧点：任务是否能被“真正并行化”

视频最后，并没有简单站队，而是给出了一个更成熟的判断：这两种架构，服务的是完全不同的问题空间。

Cognition 专注的是代码智能体——任务长、状态多、上下文强依赖，任何一个步骤的误解都会在后面被放大。而 Anthropic 明确讨论的是研究型工作流，那些子任务“彼此独立、依赖极少、天然适合并行”。事实上，Anthropic 自己也承认：需要所有智能体共享同一上下文、或者子任务高度耦合的领域（比如大多数编程任务），并不适合多智能体。

他们发现，多智能体最擅长三类事情：高度并行的任务、信息量超过单一上下文窗口的任务、以及需要同时调用大量复杂工具的场景。

一个容易被忽略的细节是，这场争论本身只是“时间截面”。即便是写下《Don’t build multi-agents》的 Walden Yan，也对未来的智能体协作持乐观态度——只是认为当下的模型能力和上下文机制，还不足以支撑稳定的多智能体协同。

换句话说，这不是“谁对谁错”，而是“在什么条件下，用什么架构”。而真正决定答案的，不是理念，而是你的任务结构。

总结

这场关于单智能体与多智能体的争论，揭示了一个更深层的事实：智能体系统的上限，往往不是模型能力，而是架构是否尊重任务本身的结构。能并行的，就大胆并行；不能并行的，就老老实实维护上下文。对企业和开发者而言，最危险的不是选错立场，而是不加区分地套用“流行架构”。

关键词： AI Agent， 多智能体系统， 上下文工程， Token， Claude

事实核查备注： 视频来源：The AI Daily Brief；Anthropic 多智能体研究系统；Claude 4 Opus 与 Claude 4 Sonnet 组合；内部评测提升 90.2%；Token 使用量解释约 80% 性能提升；多智能体 Token 消耗约为聊天的 15 倍；Cognition 作者 Walden Yan；博客标题《Don’t build multi-agents》；Context Engineering 概念