AI Agent 架构之争：多智能体是否必要？Anthropic和Cognition两大巨头观点疑似分歧

最近，AI又出了一个有意思的事情，关于是否要使用多智能体架构，Anthropic（Claude）和Cognition（Devin）几乎同时发了两篇看似观点完全相反的文章：Anthropic 发表了How we bulit our multi-agent research system（我们如何构建多智能体研究系统），介绍了他们构建多智能体的成功经验，而Cognition则发表了一片标题极具挑衅的文章：Don't Build Muliti-Agents（不要构建多智能体）。一个像激进的创新团队，一个像谨慎的老派工程师，这场神仙打架背后，藏着 AI Agent 架构最核心的灵魂拷问：多智能体到底是效率神器，还是自找麻烦的坑？

Anthropic 的「团队作战」哲学 —— 用分工碾压复杂任务
Anthropic 的思路像极了顶级科研团队：一个「领头大佬」坐镇指挥，带着一堆「专项研究员」分头干活。领头负责分解任务并协同多个子智能体并行搜索信息，最终汇总处理得到最终结果。

核心技术：比如研究一个行业，领头智能体拆成「市场数据组」「竞品分析组」「技术趋势组」，子智能体并行搜索后，大佬把关键信息压缩整合，效率比单打独斗高 90.2%！（想象一下，别人熬夜查资料时，你派 10 个助理同时开工）
提示工程：通过精准的提示词指引智能体进行明确分工、策略制定、工具选择和生成结果等任务
踩坑预警：但这玩法烧钱 —— 算力消耗是普通聊天的 15 倍，而且要是「助理们」分工没说清，可能有人重复查数据，有人用错工具（就像团队协作没开清楚会）。
适合场景：查公司信息、写综述论文这种「信息大海捞针」的活，多智能体就是「扫地僧」，但写代码这种需要前后逻辑咬合的事，它反而容易「掉链子」。

Cognition 的「独行侠」宣言 —— 上下文才是生命线
Cognition 泼了盆冷水：多智能体就像一群没磨合过的临时工，各干各的容易出乱子！

致命短板：
上下文不一致：子智能体无法共享完整的上下文，导致理解出错。
决策矛盾：子智能体独立做决策，这些决策可能存在相互矛盾，导致影响最终结果。
比如做游戏时，负责角色设计的子智能体不知道场景组的风格，结果搞出赛博朋克风坦克配仙侠地图 —— 上下文断了就全崩。早期有个代码模型让大模型写指令、小模型执行，结果因为「传话不准」直接翻车。

推荐方案：不如让一个智能体「一条道走到黑」，配上「记忆压缩器」把关键信息存下来。就像老中医看病，每次问诊都带着之前的病历，绝不会开错药。
灵魂拷问：编程时你敢让多个智能体并行写代码吗？这边改函数那边调接口，分分钟把代码搞成「千层饼」，debug 能让人崩溃。

惊人共识：大佬们偷偷在这些地方达成一致
两大AI巨头在架构选择、上下文管理和任务适用性上存在分歧，但其实看起来更像是互补。对于“低依赖，可并行”的任务，适用于多智能体，对于“高依赖，高耦合”的任务，更适合用单智能体。

表面吵翻天
私下全认同
多智能体要不要用
都承认：得看任务类型，研究类适合多智能体，编程类适合单智能体
怎么避免踩坑
都强调：提示词工程的重要性，让智能体能理解清楚任务，还要要科学可信的评估
未来怎么搞
都认可：上下文管理的重要性，要么让智能体学会协同传递关键信息，要么让单智能体有超长的上下文

给开发者的「选架构避坑指南」
如果你接的是「搬砖」任务：比如汇总 100 家公司年报数据，学 Anthropic 组个「临时工团队」，但记得给每个子智能体写清楚「工作清单」（提示词），还要定期抽查成果。
如果你做的是「绣花」活：比如写复杂程序、陪用户聊 100 轮天，果断选单智能体 +「记忆压缩」，宁可慢点也别让系统「精神分裂」。
偷偷说个趋势：现在多智能体算力消耗高？但模型进步比摩尔定律还快，说不定明年「15 倍算力消耗」就变成「1.5 倍」了 —— 技术打脸来得比翻书还快。

本文由开放猫和子木联合共创，往期资料，回复“开放猫AI”添加下方二维码免费领取。