模型变强了，架构为什么反而要变？——从"折叠 subagent"到"Super-agent"
原文地址：
本文并非原文的翻译，是经过我自己理解后的输出，这是最近关注最多的两篇 Agent 的文章了。我挑选了自己感兴趣的部分，让 AI 辅助理解并总结。感兴趣的朋友也可以查看原文。
表面上，两家在"打架"
最近这段时间，两家公司先后抛出了两份关于 Agent 架构的论述，方向看起来完全相反。
Anthropic 在《When to fold subagents into your main agent loop》里说：企业把系统拆成一堆 subagent 的做法，大多是在替模型做它已经不再需要的事。正确的方向是把 subagent 折叠回单个 agent loop，用 skills 和 tools 来承载领域知识。
DeepSeek Harness 团队在《Super-agent 设计探索》里却说：要打破 Agent 与单次会话的绑定，引入一个常驻的 Router 层，下面挂一群隔离的 Worker 去并发干活。
一家在"拆"，一家在"加"。一家说 subagent 是负担，另一家看起来就像是在 subagent 上面加了个 leader。
这两篇讲的是同一件事吗？它们矛盾吗？我读完之后的判断是：不矛盾，而且它们其实是被同一股力量推着走的。这篇文章想讲清楚那股力量是什么。
一个统一的框架：棘轮
先放下两篇文章，抽象出一个机制。Agent 架构的演进，是一个不断重复的过程：
这里的关键词是"内化"：模型一旦把某项能力学进了自己体内，当初为了补偿"它不会"而搭的脚手架，就从资产变成了负债。它不但没用，还会拖慢系统、污染上下文、甚至卡住新长出来的能力。
但这里有个容易被忽略的区分。不是所有"约束"都能内化：
| 约束类型 | 例子 | 模型变强后 | 对应做法 |
|---|---|---|---|
| 能力型约束（模型"不会"） | 规划、选工具、自检、follow 多步推理 | 会内化 | 拆掉脚手架，把决策交回模型 |
| 机械型约束（物理/系统"受限"） | 上下文窗口大小、延迟、成本、单机生命周期 | 不会内化 | 仍需工程手段绕过 |
记住这个区分，它是理解两篇文章为什么不矛盾的关键。Anthropic 砍掉的是"能力型脚手架"，而 DeepSeek 建的，是绕过"机械型约束"的系统设计。两者并不在同一层。
Anthropic 那一侧：内化已经发生，subagent 从补偿变成了负担
Anthropic 的观察来自企业部署的实战。他们的 Applied AI 团队发现，很多企业的 agent 架构长成了组织架构的翻版：每个团队负责一个能力，就各自搭一个 subagent，最后上面再压一个 orchestrator。这被作者点名为"Conway 定律在 agent 上的重演"。
这种设计看起来最自然，但立刻带来五个问题：
- 上下文管理难：agent 之间要交换什么上下文？来回传递中细节不断丢失。
- subagent 泛滥：每个团队都 ship 自己的 subagent，最后几百个重叠、无人负责、无统一标准。
- Frankenprompt：每个团队往系统提示词里加一句，规则互相冲突，语气不再统一。
- eval 碎片化：每个人都只优化自己那一小块，没人对整体负责。
- 延迟翻倍：有个客户把多 agent 框架换成单 agent loop 后，运行时间快了约 2 倍。
那为什么是"现在"才折叠？Anthropic 给了三个理由，前两个是技术手段，第三个才是根本原因：
- 共享上下文答案更好：长任务里，前面每一步的结果都留在主上下文里，模型能把它们串起来；而 subagent 只能交回一份有损摘要。
- 渐进披露能防上下文膨胀：skills 和 tool search 让模型只按需加载，不必把全部知识塞进一个长提示词。Anthropic 自己已经把 Claude Code 的系统提示词削减了 80% 以上。
- 模型更强了——这才是核心。原文写道：从 Opus 4.5 开始，模型在单循环里能 handle 的东西远超团队预期；更新的模型"边做边讲、自我检查"，让很多 harness 元素变得多余。每一代新模型，都在让你把更多决策从 harness 移回模型本身。
有意思的是，Anthropic 一边砍 subagent，一边仍在大力讲渐进披露。为什么？因为"模型变聪明"解决的是能力型约束，但上下文窗口的物理上限还在，所以仍需渐进披露去绕开它。这正是上一节那个区分的活例证。
折叠不是一口气推倒。Anthropic 给出的路径是逐步的：先建端到端 eval，再按共享上下文合并 domain agent，再把还需要的 subagent 降级成"被主循环当作 tool 调用"，最后把它们的提示词变成 skills、API 调用变成 MCP tools。每一步都用 eval 说话，而不是凭感觉。
DeepSeek 那一侧：单任务内化后，瓶颈上移到了"人的注意力"
DeepSeek 的起点和 Anthropic 其实是同一个，只是看向另一个方向。
他们观察到：过去一年，以 Coding Agent 为代表的单任务 Agent 已经证明，模型能自己用工具解决复杂问题，"越来越少需要人类持续监控和逐步干预"。单任务的执行，已经内化得差不多了。
于是瓶颈就变了。不再是"模型做不好任务"，而是"人跟不上任务"：现有 Agent 以单次 Session 为基本单位，不同 Session 彼此独立，而一个人通常只能同时跟进 3 到 5 个活跃 Session。用原文的话说——单任务的上限取决于模型能力，多任务的上限取决于人的注意力。
所以 Super-agent 的目标不是"把单个任务做得更好"，而是打破 Agent 与单次会话的绑定，让它变成一个跨会话、多任务、长期在线的连续实体。它要同时具备四个特征：连续、高效、主动、持久。
支撑这四个特征的，是五个模块：
- 双层架构：Router 层常驻，负责所有对外交互和全局协调；Worker 层上下文隔离，挂最强模型，专注执行单一任务。Router 靠"批处理"（把推理期间积压的事件合并进一次调用）来扛吞吐，实测单个常驻 Router 在团队规模下够用。
- 事件驱动：把驱动输入从"人类逐条输入"改成"环境事件（Trigger）"。用 Fast Path / Slow Path 两级过滤噪音，用 Thread 订阅直通把后续事件直接路由给对应 Worker，用 Inline & Spill 把上下文窗口当 Cache 管，还引入了投机执行——在不确定结果会不会被采用时，先在后台尝试，有价值就交付、没价值就丢弃。
- 面向人的交互：把耗时的工具调用改成异步的
start()/stop()，让前台对话不再被后台任务阻塞；针对 IM 和 GitHub 等不同信道定制输出密度（例如 IM 单次回复不超过 100 词）。 - 存算分离：把推进 Agent Loop 的"计算"与持久化的"状态"分离，让 Agent 摆脱单机生命周期；再用端侧 daemon 接入原地不动的执行环境，支持 BYOM（Bring Your Own Machine）。
- Watchdog：一个外部的控制回路，不仅探测进程存活，还由模型判断各 Worker 是否有实质进展、是否偏离目标。
这里有个必须点破的细节：DeepSeek 的 Router 层，不是"单任务里拆解步骤的 Team Lead"。 原文明确写了——Router 只做任务之间的高层分派，不介入单任务内部的拆解；真正执行任务的 Worker 内部，反而可以是一个"单 loop + skills"，甚至可以是 subagent 或 agent team。作者甚至专门对比了"Agent Team"和"Super-agent Router"的区别：前者要深入理解任务细节、高频协调成员，后者只处理任务间关联。
实验也印证了这一点。在约 300 条消息（其中约 20 条是真实工作请求）的端到端对比里，Super-agent 的任务完成时间 p50 是 12.4 分钟、p95 是 15.7 分钟；而"单 Session + Subagent 工具"在中性提示下，模型 5 次运行一次都没委派，全都自己干、不断被新消息打断，p95 拖到了 29.5 分钟。换成"提示优先委派"后有所改善，但仍不如 Super-agent 稳定。
把两张图叠起来：它们为什么不矛盾
现在可以把两篇文章放到同一张图里看了。
看清这张图，"矛盾"就消失了：
- Anthropic 讲的是层级①——单个任务内部，别拆成一堆 subagent，回到单 loop + skills + tools。
- DeepSeek 讲的是层级②——多个任务/会话之间，怎么用一个常驻 Router 编排并发。
- 而 DeepSeek 的 Worker 内部，恰恰就是 Anthropic 说的单 loop。两家的建议是嵌套关系，不是对立关系。
甚至，两家还在互相引用：DeepSeek 第 5 节的"存算分离"直接对上了 Anthropic 的"脑手分离"（Decoupling the brain from the hands），只是场景不同——Anthropic 讲的是托管服务里的沙箱与客户 VPC，DeepSeek 讲的是用户间歇在线的个人机器和本地凭据。
回到开头的棘轮：它们是被同一股力量推着走的。 模型把"单任务执行"内化之后，Anthropic 低头看见了"该拆的旧脚手架"（单任务内部的 subagent），DeepSeek 抬头看见了"该建的新脚手架"（跨任务的编排）。方向相反，是因为它们在棘轮的两个相邻位置。
唯一称得上张力的细点在于：Anthropic 说"别在单任务上加 orchestrator"，而 DeepSeek 的 Router 确实是个 orchestrator。但只要 Router 守住"不做单任务拆解"这条线（DeepSeek 自己也这么约束），它就不是 Anthropic 反对的那个东西。
给普通开发者的五条
抛开两家的产品和团队规模，落到个人开发者和中小团队，我提炼出五条可执行的：
- 默认从"单 agent + skills + tools"起步。不要一上来就画多 agent 拓扑图。只有命中三个条件——上下文明显膨胀、需要并行且结果可丢弃、模型选工具开始混乱——才引入 subagent。
- 用渐进披露管上下文。skills 管"怎么做"，tool search 管"有哪些能力"，知识库管"参考材料"。别把所有东西塞进一个长提示词。
- eval 先行，一次只改一件事。用端到端 task-completion eval 决定"折叠还是保留"，而不是凭感觉。Anthropic 的核心原则就一句：measure, change one thing at a time, keep what holds up。
- 只有做长期在线、多任务才上 Router/Worker。那是系统级工程，涉及事件驱动、异步循环、存算分离，成本和心智负担都远高于单任务提示词。个人项目多数用不上。
- 记住那个终极心法：把更多决策下放给模型本身，harness 只守底线（预算、审批、验证门）。脚手架的职责是"守底线"，不是"替模型思考"。
小结
这两篇文章表面上在打架，底层却讲着同一个故事：模型能力在持续内化，于是"该拆的脚手架"和"该建的新脚手架"同时出现。Anthropic 提醒你别把已经内化的能力再外包给 subagent；DeepSeek 提醒你，单任务内化之后，瓶颈会转移到人的注意力，需要新的编排范式。
判断自己站在哪，只需要问两个问题：我的脚手架，是在替模型思考，还是在守底线？我的瓶颈，是在单个任务内部，还是在多个任务之间？ 答清楚这两个问题，该拆还是该建，就自然有答案了。