智能体架构之争：一个 Agent 管所有，还是多招几个 Agent？
十月底这十来天，两家做智能体最狠的公司，几乎同时抛出了两篇看起来"对着干"的文章。
一边是 Anthropic。10 月 22 日，它的 Applied AI 团队发了一篇《Building agents: When to fold subagents into your main agent loop（构建智能体：何时该把子智能体收回到主循环）》，核心意思一句话：别搞那么多子智能体了，一个 Agent 配一堆技能（Skills），在质量、成本、延迟上往往都更划算。
另一边是 DeepSeek。10 月 31 日晚，它的 Harness 团队发了《Super-agent 设计探索：迈向更自主的 Agent 系统》，讲的反而是怎么搭一套**"常驻在线、能同时干多件事、会主动找活干、出问题能自愈"的多层智能体**架构，还顺手把原型开源了。
如果你两篇都扫了一眼，第一反应大概率是困惑：一个说"别拆"，一个说"要分层"，这俩不打架吗？
这篇文章想把这事掰开讲清楚。先立个判断：它们并不矛盾，只是站在同一枚硬币的两面。 真正让人纠结的，是很多人把两个不同层面的问题混成了一件事。
一、Anthropic：子智能体正在变成"架构的补丁"
先说 Anthropic 这篇。它的结论不是坐在实验室里拍脑袋想出来的，而是来自它 Applied AI 团队过去帮一批企业落地 Claude 时的反复观察。
这个团队看到了一个相当普遍的现象：过去一年，"一个调度器 + 一群专职子智能体"成了很多企业做智能体的默认姿势。业务上分几个团队，架构上就长出几个子智能体，平台团队再在上面套一个调度器。听起来很合理，但跑着跑着，四个毛病几乎必然出现：
第一，交接丢上下文。 子智能体之间靠什么通信？靠彼此传"摘要"。一个任务从"写特性"传给"写测试"再传给"审代码"，每过一道手，细节就丢一层。Anthropic 打过一个比方，这像传话游戏------传到最后，最初那句话早就走样了。
第二，子智能体泛滥。 每个团队都造自己的 Agent，最后堆出上百个功能重叠、无人认领、没有统一标准的 Agent。Anthropic 管这叫"智能体版的康威定律"------你的架构最终会变成你组织架构图的翻版。
第三，"弗兰肯提示词"。 每个团队都往系统提示词里加一句自己的规则，最后这些规则互相打架、语气也支离破碎。
第四，评测失焦。 每个团队只盯着自己那个子任务的分数优化，没有人对"端到端到底行不行"负责，领导看到的是一堆被稀释过的局部好成绩。
Anthropic 的替代方案也简单：把子智能体收回去，换成 Skills 和工具，让一个 Agent 在一个循环里按需加载。 具体就是，模型一开始只看到每个技能的一句话简介，真正用到的时候才把完整内容拉进来------这叫"渐进式披露"。这样既能装下很多能力，又不会一开始就把上下文窗口撑爆。
这背后有几个能核实的数字。Anthropic 说，靠这种按需加载，Claude Code 面向新模型的系统提示词砍掉了 80% 以上 。而在一家客户的真实对比里，把多智能体框架换成一个单循环之后，运行速度大约快了一倍。
但要注意，Anthropic 这篇文章不是无脑反子智能体。它明确划了三条线，说下面这些情况下，子智能体仍然该留：
- 单个 Agent 的上下文已经长到出现可测量的性能下降；
- 多个任务需要并行、且各自要独立的上下文窗口；
- 单个 Agent 在工具选择或指令冲突上已经明显吃力。
它还坦承过一个反例：在某次客服 Agent 的测试里，把一个子智能体合并进来确实降低了延迟，却把一条原本能跑通的流程弄坏了------主 Agent 开始自己抢答，不再去问那个负责发货的专家。而且这个 bug 是跑两次才出现一次。所以它的建议从来不是"赶紧全拆了"，而是"先搭一套端到端评测，再一个接一个地收，看哪些任务翻了车"。
顺带说一句，Anthropic 为此开源了一个 single-agent-loop-kit，把"度量、合并、折叠"这三步迁移流程都做了出来。这才是它真正想卖的：不是某个结论，而是一套敢动手改架构之前先量一量的方法。
二、DeepSeek：单 Session 的上限，是人的注意力
再看 DeepSeek 这篇。它的出发点跟 Anthropic 完全不在一个地方。
DeepSeek Harness 团队观察到的是另一个瓶颈：模型本身已经强到能用一个 Session 干完很多复杂的单任务了，于是真正的上限，从"模型行不行"转移到了另一个地方------人的注意力。
它的观察很具体：现在大多数 Agent 的设计，还是以"单 Session"为基本单位。不同 Session 之间彼此独立，上下文不通。当一个人要并行推进好几件事时，他得手动在不同 Session 之间切来切去，还得自己记住每个 Session 说到哪了。而据这个团队的观察，一个人通常只能同时跟进三到五个活跃 Session。
换句话说，在这个形态下：单任务的上限由模型决定，多任务的上限由人决定。 模型再强，人被自己的注意力卡死了。
DeepSeek 要解决的问题，是让一个 Agent 跨会话保持上下文、并行推进多个任务、而且是"常驻在线、事件驱动"的------不是"等你下了指令才动一下"，而是"群里有人反馈了个问题，哪怕没人喊它，它也能自己醒来去复现、去修"。
为了这个目标，它给出的架构是五大模块：双层架构、事件驱动、异步多信道交互、存算分离、外部看门狗（Watchdog）。最核心的是前两个。
双层架构，说白了就是"一层分派、一层干活"。 上面一层叫 Router，常驻在线，负责跟人打交道、做全局协调，但自己不干活；下面一层叫 Worker，彼此上下文隔离，各自挂完整工具，专心把一件事做完。为什么这么拆？因为"跨信道保持连续"和"高并发干活"这两个诉求天然有张力：全塞进一个 Session，上下文最连续但吞吐低；全开独立 Session，吞吐高但上下文割裂。拆成两层，各管各的。
事件驱动，则是把"等人喂指令"改成"环境事件就是输入"。 群聊消息、邮件、代码评审评论、CI 结果，这些都叫 Trigger。系统监听这些 Trigger，自己判断要不要行动。为了不让每一条噪音消息都烧一次大模型，它还借了计算机里的 Fast Path / Slow Path 思想：先用确定性代码做一层快速过滤（哪些频道、哪些人、要不要理），筛剩下的才交给模型做语义判断。
至于那个"主动"到底有多主动，文章给过一个很生动的例子：团队在内部群里配了一条"静默复现并修复"的策略。有人在群里反馈问题，哪怕没人 @ 它，Agent 也会在后台自己尝试复现、找修复方案，只有在真确认了问题、还找到了简单修法之后，才把结果交出来，否则全程保持安静。
这篇文章同样给了几个实验数字，虽然作者反复强调"这是合成负载下的初步结果，不是正式产品结论"：
- Super-agent 架构下，一半任务在 12.4 分钟内完成，95% 的任务在 15.7 分钟内完成，明显好于"带子 Agent 工具的单 Session"；
- 如果去掉"订阅直通"机制，Router 的决定数会增加约 30%，读缓存的 token 从 2323 万涨到 3177 万------直通不提升速度，但为 Router 省了约 37% 的 token；
- 单独压测 Router 的批处理时，当事件拥堵、多条触发自动合并，单个决定分摊的推理时间从 6.4 秒降到了 1.6 秒。
同样，它也不是无事生非地多搞一层。文章里明说，这套系统能以较低的复杂度跑起来，是因为做了大量"当前阶段"的简化和工程假设。超出这些适用范围，它自己列了四道还过不去的坎：双层架构怎么继续扩容、脱离 Session 之后人和 Agent 怎么协作、多个实例之间怎么通信、云端 Agent 拿到本地凭据之后的安全与隐私。
顺带一提，这个原型 dsh-superagent-prototype 在仓库里写得很直白：只是研究原型，不是正式产品，代码主要是靠编程 Agent 自己写的，可能有 bug。 这点挺重要，决定了该用什么心态读它。
三、所以，到底矛盾在哪？
回到开头那个直觉：一个说"别拆"，一个说"要分层"，是不是打架？
我的判断是：不矛盾，因为它们在回答两个不同层面的问题。
Anthropic 反对的，是一个任务内部的过度拆分------同一个任务，被硬按"团队"或"问题类型"切成一串子 Agent，交接一次丢一点信息，还要付十几倍的 token 成本。它说的是"别为拆而拆"。
DeepSeek 要解决的，是多个任务之间的调度与持久------任务本身早就超出了"一个 Session 串行能干完"的范围，需要并发、需要常驻、需要主动。它说的是"该分层的时候要系统化地分层"。
把坐标轴摆正，就一点不冲突了：
- 横轴是"任务内 vs 任务间"。 任务内该不该拆子 Agent？Anthropic 说大多数时候不用，用 Skills 就够。任务间要不要分层调度？DeepSeek 说，要，否则多任务上限卡在人的注意力上。
- 纵轴是"要不要在这一层引入新结构"。 单任务内，越简单越好；跨任务、长时运行，才值得把复杂度请进来。
再往深看一层，其实两篇的底层判断是惊人地一致 的，就一条：智能体架构应该由任务的形态决定，而不该由组织习惯或会话边界决定。 Anthropic 说的是"别按团队边界切 Agent"，DeepSeek 说的是"别按 Session 边界串行跑多任务"。两句批评，指向的是两处相反的过度设计，合的却是同一条工程纪律。
甚至，一个挺有意思的事实是：DeepSeek 那套双层架构，跟很多人自己推演出来的"单 Agent + 多 Session + Skills，外面再套一层调度"几乎是同一个东西。 Router 对应的是调度层，Worker 对应的是并行 Session，Skills 就是每个 Session 里被按需调用的能力。换句话说，单 Agent + Skills 不但没被 DeepSeek 推翻，反而是它 Worker 层的基本组成单位。
所以更准确的说法也许是：Anthropic 讲的是"最小作战单元"怎么设计（一个 Agent、一份共享上下文、按需加载 Skills）；DeepSeek 讲的是"系统级"怎么编排（怎么让很多个这样的最小单元，被一个调度层持续、并发、主动地驱动起来）。 前者是零件，后者是产线。
四、留几个问题，想听听你的看法
到这里，两件事本身已经讲得比较清楚了。但真正有意思的，是这两篇放到一起之后留下的开放地带。这几条是我自己还没想透的，抛出来，欢迎在评论区掰扯：
1. "该不该拆"的判据，真的能量化吗？
Anthropic 说"上下文出现可测量的性能下降"才拆，DeepSeek 说"任务需要并行独立上下文"时分层。但"可测量的下降"和"需要独立上下文"这两条，落到具体工程里，到底怎么判断？有没有一个比"感觉该拆了"更硬的标准？还是说，最终只能靠那套"先搭端到端评测、跑了再说"的方法兜底？
2. Skills 会不会变成下一种"泛滥"？
当年大家热衷于多招 Agent，现在风向转到"多写 Skills"。可 Skills 也是要人维护的------如果每个团队又开始堆自己的 Skill，会不会重演"上百个重叠子 Agent"的剧本，只是换了个名字？Anthropic 提到的 skill-doctor（看每个 skill 花了多少、用了多少次、该不该删）是不是意味着，接下来卷的不是模型，而是"知识资产的管理"？
3. "单 Agent + Skills"的天花板在哪？
Anthropic 的结论有个隐藏前提：模型（从 Opus 4.5 起）已经强到能在一个循环里扛住大部分复杂计划。那对于那些"上下文本来就该隔离、任务本来就该并行"的场景，单 Agent 是不是迟早会撞墙？撞墙的那一刻，是不是正好掉进 DeepSeek 那张架构图里？
4. 主动这件事，边界该谁定？
DeepSeek 的 Super-agent 最吸引人、也最让人不安的，是那个"没人 @ 也自己行动"的主动性。它自己用"只有确认问题、找到修法才交付，否则全程安静"来约束。但"什么时候该安静、什么时候该出手"，这条线该由谁画？模型自己？写策略的人？还是最后都要回到"人来做决策和验收"这件事上？
5. 你现在在做的，更接近哪一边？
如果你是做编程 Agent、做个人助手、或者做企业工作流的，你手上的活，是"一个任务里该不该拆"的问题，还是"一堆任务该怎么并行、怎么常驻"的问题？还是说，你正卡在这两者交界的地方？
这几条没有标准答案，可能也正是这两篇文章最有价值的地方：它们没给出一锤定音的结论，却把两个此前被混着谈的问题，逼到了台面上。
参考文献
- Anthropic Applied AI, Building agents: When to fold subagents into your main agent loop, claude.com, 2026-10-22. 配套开源仓库：github.com/anthropics/single-agent-loop-kit.
- DeepSeek Harness, Super-agent 设计探索：迈向更自主的 Agent 系统, 微信公众号"DeepSeek Harness", 2026-10-31. 配套开源原型：github.com/deepseek-ai/dsh-superagent-prototype（MIT 协议，研究原型）。
- The Decoder, Anthropic says one AI agent beats many subagents now that models can handle complexity alone, 2026-10-25.
- 智东西（李水青），DeepSeek 又开源了！公布 Super-agent 架构, 2026-11-01.
说明：文中涉及的具体数字（如"约 2 倍提速""系统提示词削减 80%""p50 12.4 分钟""批处理单决定 6.4s→1.6s"等）均来自上述两篇原文及随附开源仓库中作者自述的实验结果；其中 DeepSeek 的实验数据基于合成负载与简化环境，作者已明确标注为"初步参考、非正式产品结论"，请读者酌情采信。