从 Subagent 到 Agent OS：我越来越不相信“一个 Agent 搞定一切”这件事

最近一段时间基本都在做 AI coding 相关的东西，也持续在用和拆各种编程 Agent，像 Claude Code、Codex CLI、Roo Code，这类东西碰得很多。

刚开始的时候，我其实也挺容易被一种叙事带跑：模型越来越强，工具越来越全，给它文件系统、shell、git、测试能力，它迟早会变成一个能独立开发的软件工程师。

理论上很美。

但真的上手做复杂任务之后，你会发现这事没那么简单。甚至可以说，很多时候不是“不够强”，而是“根本撑不住”。

尤其是任务一长、代码库一大、依赖一多，单个 Agent 很快就开始飘：前面刚定好的计划，后面自己改了；本来只想修个 API，最后把半个模块重写了；测试没过，它也不是不会修，而是会一路修到你不认识仓库。

这种情况我遇到过不止一次。

所以这篇文章我不想写成教程，也不想写成某种“未来已经到来”的行业判断。我更想把自己这段时间的一个真实感受说清楚：

软件开发里的 Agent，确实在从 IDE Assistant 往 Autonomous Developer 走，但真正决定上限的，越来越不是模型本身，而是系统架构。

我现在看到的一条很明显的演进路径，大概是这样：

Single Agent
   ↓
Planner + Executor
   ↓
Subagent / Delegation
   ↓
Multi-Agent System
   ↓
Agent Runtime / Agent OS

下面我主要想聊三件事：

1. 为什么编程 Agent 迟早会走到 Subagent / Multi-Agent

2. 为什么大部分 Agent Framework 最后都死在 orchestration 上

3. 为什么我越来越觉得，后面会冒出来的不是“超级 Agent”，而是某种 Agent OS

---

一开始大家都想简单点，但简单架构真的有天花板

先说结论：单 Agent 架构不是没用，而是只适合中短任务。

这一点很多人其实都知道，但真做久了，体感会比结论更强。

---

1. 一个 Agent 干到底，确实省事，但也最容易崩

现在很多主流编程 Agent，本质上都还在这个模式里：

• Codex CLI

• Copilot Agent

• Cursor Agent

大概结构就是这样：

User
  ↓
Agent
  ↓
Agent Loop
  ↓
Tools
 ├ filesystem
 ├ shell
 ├ git
 └ tests

执行循环也很熟：

think
→ run tool
→ observe
→ think

这种架构的优点非常直接：

• 简单

• 稳

• 调试容易

• 出问题也好定位

所以它为什么流行，我完全理解。因为工程上它就是便宜，能跑，能上线。

但问题也非常明确：

• 上下文很快变脏

• 长任务很容易失控

• 推理链一长，行为就不再可预测

我一开始也挺喜欢这种系统，因为它看起来最像“真正的 autonomous coding”。你把权限给够，它就一直干。

可真跑复杂仓库的时候，问题特别明显：它不是不能做，而是做着做着会忘。

忘之前为什么这么改，忘当前子任务是什么，忘哪些 warning 可以忽略，忘哪条报错只是副作用。

最后你会发现，整个系统表面上很智能，实际上内部状态管理跟垃圾堆差不多。

说难听点，就是越来越乱。

---

2. Subagent 这套东西火起来，不是因为酷，是因为单 Agent 装不下了

后来很多系统开始搞 delegation，也就是主 Agent 带一堆 Subagent。

典型例子像：

• Claude Code Subagents

• Roo Code Subagents

结构一般是这种：

Main Agent
   ├ Subagent A
   ├ Subagent B
   └ Subagent C

主 Agent 负责分任务，Subagent 去做局部工作，比如：

• 搜代码

• 看依赖

• 跑测试

• 查某个模块的行为

流程一般是：

main agent
   ↓
spawn subagent
   ↓
subagent run task
   ↓
return summary

这套东西表面上看像“多智能体协作”，但我自己越用越觉得，它最核心的价值其实就四个字：

上下文隔离。

这点非常关键。

很多人一开始会把 Subagent 理解成“能力增强”，我反而觉得它更像“污染控制”。

因为一个主 Agent 一旦在长链路里待久了，context 真的会变得很脏。里面混着：

• 旧计划

• 中间日志

• 失败尝试

• 无效观察

• 已经过时的结论

这些东西全塞在一个上下文里，模型后面还能推理得稳，那才奇怪。

我自己遇到过一种很典型的情况：主 Agent 已经在前面试了三轮错误修复，脑子里全是旧结论。这个时候你让它继续定位一个新问题，它会非常容易被自己前面的错误路径带偏。

换个新开的 Subagent 去看，反而一下子就看明白了。

这不是玄学，这就是上下文干净。

---

3. 再往后走，就是 Multi-Agent，但这东西开始像团队，不像工具了

再进一步，就是 Multi-Agent Collaboration。

这类系统你会看到更强的角色分工，比如：

• Claude Code Agent Teams

• Devin

• OpenDevin 这类尝试

结构大概会变成这样：

Lead Agent
   │
Team Workspace
   │
 ├ Architect
 ├ Developer
 ├ Reviewer
 └ Tester

这时候系统就不再只是“一个 Agent 调几个 helper”，而是开始模拟软件团队：

• Architect 关心结构

• Developer 关心实现

• Reviewer 关心改动质量

• Tester 关心边界和回归

从抽象上讲，这当然更合理。因为软件开发本来就不是一个单一认知任务。

但这里也有个现实问题：它越像团队，协调成本就越像团队。

这个后面讲 orchestration 的时候会更明显。因为 Multi-Agent 不是免费午餐，它不是你多开几个窗口就自动变强了。很多时候，它只是把单 Agent 的混乱，升级成了多 Agent 的混乱。

人数一多，锅也多。

---

为什么复杂编程任务最后一定会走到 Subagent

这个问题我现在的答案很明确：

不是大家喜欢把系统做复杂，而是单个 LLM Agent 没法稳定管理复杂软件任务。

重点是“稳定”两个字。

不是偶尔做不出来，而是你没法相信它每次都能做对。

---

1. 上下文窗口再大，也不等于你真的能理解整个仓库

很多人喜欢把希望寄托在 context window 上，觉得窗口够大，把整个 repo 塞进去就行。

但实际不是这么回事。

一个真实点的项目，随便就是：

repo
├── 2000+ files
├── 100k+ lines
├── build system
├── tests

一个看似普通的 feature 修改，可能同时动到：

• API

• 数据库

• 配置

• 测试

• CI 逻辑

你把这些全塞到一个 prompt 里，结果往往不是“理解更完整”，而是“噪音越来越多”。

最后就会变成：

context noise ↑
signal ↓

这事我自己感受特别明显。context 一大，模型不是马上变傻，而是开始“看起来还在思考，实际上抓不到重点”。

有时候最致命的不是它不会，而是它会忽略。

尤其是中间信息，特别容易丢。这就是很多人说的 Lost-in-the-Middle 问题。理论上大家都知道，实践里你会被它反复教育。

中间那段最关键，它偏偏看漏了。

很烦。

---

2. 规划和执行，本来就不是一类脑力活

软件开发里有两种完全不同的认知模式：

Planning：

architecture design
module boundary
dependency analysis

Execution：

edit files
fix compile errors
run tests

这两件事放在人类团队里，很多时候都不是同一个人在同一个时间片里做的。因为一个偏抽象、偏全局；另一个偏局部、偏操作。

但单 Agent 架构经常要求它既做架构师，又做打工仔。

然后问题就来了：计划漂移。

本来计划是：

原计划：修改API

结果执行过程中变成：

重写模块

最后系统结构都被它顺手改了。

这种事特别常见。因为模型在执行时会不断根据局部观察更新判断，而这种更新很多时候不是“修正计划”，而是“直接忘了原计划”。

我后来越来越认同把系统拆成：

planner agent
executor agent

不是因为这样更高级，而是因为这样更像工程。

至少谁负责想，谁负责干，边界清楚一点。

不然很容易边干边改主意，越改越离谱。

---

3. 真正毁掉长任务的，不是任务难，而是 context 被污染了

这是我现在非常在意的一个点。

Agent 在长任务里会积累一大堆历史信息：

旧计划
tool output
logs
中间推理
失败尝试

前面十轮还好，二十轮之后基本就开始脏了。再往后，你会明显感觉它的判断质量下降，不是线性下降，是突然塌。

所以 Subagent 最实际的作用是：

spawn subagent
clean context
run task
return summary

就是把一个脏上下文切开，把局部问题丢到一个干净工作区里处理，然后只把摘要带回来。

这个设计非常朴素，但真的有效。

我有次让主 Agent 直接排查一个测试失败，转了很多轮都在旧错误上打转；后来拆成三个小任务分别扔给 Subagent，一个看配置，一个看依赖，一个看逻辑，结果逻辑那个几轮就定位到了。

不是因为它更聪明。

是因为它没背着一车历史垃圾。

---

4. 很多工程问题，本质上不是推理问题，是搜索问题

比如一个 test fail，背后原因可能有很多：

config
dependency
logic bug
environment

单 Agent 的工作方式通常是：

假设A → 测试
假设B → 测试

一个个串着试。

这当然能跑，但效率很差，而且特别容易因为前一个假设失败而把后面思路也带偏。

多 Agent 的优势在这时候就很明显：

agent A → config
agent B → dependency
agent C → logic

大家并行查。

这更接近真实工程团队，也更接近真实排障流程。因为现实里很多问题根本不是“谁能一眼看穿”，而是谁能更快排除错误方向。

很多时候不是智商问题，是搜索宽度问题。

---

5. 软件工程天生就是多角色系统，硬塞成一个 Agent 其实很别扭

真实开发里，本来就有不同角色：

architect
developer
reviewer
tester

他们关注的点完全不一样：

architect → 结构设计
developer → 具体实现
tester → 边界情况
reviewer → 风险与质量

所以你让一个 Agent 同时承担所有视角，它不是做不到，而是很容易顾此失彼。

我自己很早就有这个感觉：单 Agent 更像“超级实习生”，Multi-Agent 才开始有点像“团队”。

但像团队，不代表就能跑得顺。这事真正难的部分，其实不在角色设计，而在 orchestration。

说白了，难点不是“分工”，难点是“怎么不打架”。

---

大部分 Agent Framework，最后都死在 orchestration 上

这是我这段时间感受最深的一件事。

很多 Agent Demo 看起来都挺强，规划、执行、反思、协作，什么都有；但真放进持续的软件工程任务里，问题会集中暴露在 orchestration，也就是调度与协同层。

不是模型不够大，也不是 prompt 不够花。

是系统层没兜住。

---

1. 第一种死法：plan drift，计划写得很好，执行时直接跑偏

LLM 的推理不是程序执行，它是概率过程。

所以你给它一个看上去很合理的计划：

Step1: 设计缓存
Step2: 修改API
Step3: 写测试

执行着执行着，它可能突然决定：

重写整个模块

这事在 demo 里不一定明显，因为 demo 很短，几轮就收工了。

但在长任务里，plan drift 简直是常态。

我自己见过最离谱的一种情况，是它本来只需要 patch 一个局部逻辑，结果因为某个中间错误，开始对整个目录结构做“顺手优化”。最后你回头一看，原任务没做完，副作用做了一堆。

这时候你会特别清楚一件事：没有强约束的计划，不叫计划，只能叫建议。

模型经常不把建议当回事。

---

2. 第二种死法：状态根本没真的管理，只是塞在 prompt 里假装管理

复杂任务至少需要维护这些状态：

当前任务
完成步骤
修改文件
测试结果
已知约束
关键决策

但很多 Agent Framework 的状态管理，本质上只有一个东西：

prompt context

这其实很脆。

因为 prompt 不是状态机，它只是文本缓存。你把状态全寄托在文本里，迟早会出现：

• 重复做同一步

• 忘记之前的决定

• 把过期信息当成当前事实

这类问题我碰到特别多，尤其是多轮修复任务里。前面明明已经决定“不改这个接口”，后面转几轮，它又把接口改了。不是因为它故意叛逆，而是因为系统没有把这个决策变成真正受约束的状态。

全靠模型“记得住”，那基本等于没管理。

很虚。

---

3. 第三种死法：错误恢复能力太差，一出错就进入死循环

真实开发里，失败才是常态：

编译失败
测试失败
依赖冲突
环境异常

问题不在于失败，而在于失败后怎么恢复。

很多 Agent 的典型路径是：

修复A → 引入B
修复B → 引入C
修复C → 回到A

直接进入 error loop。

我真见过这种场面：它在一个 import 错误上修了十几轮，每次都像有点进展，实际上只是换了不同方式把仓库继续搞坏。

你站在旁边看，会有一种非常强烈的感觉：

它不是在解决问题，它是在制造更多需要解决的问题。

这时候如果系统层没有明确的 rollback、checkpoint、失败分类、重试边界，这个 Agent 基本就会一路崩下去。

而且它还挺自信。

这就更麻烦了。

---

4. 第四种死法：工具调用不稳定，模型对工具输出的理解也不稳定

Agent 真正落地，一定要接工具：

shell
git
filesystem
API
test runner

而只要接工具，就一定会遇到一个特别脏的现实：工具输出根本不总是干净、规范、可预测的。

比如：

• shell 输出混着 warning 和 error

• test runner 日志格式变化

• 某个 CLI 升级后返回字段变了

• 同一个错误在不同环境下长得完全不一样

然后模型就会误判。

最常见的一种就是：

warning

被它理解成：

error

或者反过来，真正的失败被它当成“可以忽略的信息”。

这类问题单看很小，但放到长链路里非常致命。因为 orchestration 假设“上一步返回的状态是可靠的”，而工具层一旦不稳定，整个调度逻辑都会跟着乱。

底层信号脏，上层判断一定会飘。

这个基本逃不掉。

---

5. 第五种死法：Multi-Agent 不是乘法，很多时候是复杂度爆炸

很多人对 Multi-Agent 的想象太乐观了，总觉得多几个角色就能并行提效。

但真实情况往往是，你多开几个 Agent，也顺手多开了这些问题：

任务冲突
责任不清
通信开销
状态不一致
重复劳动

最典型的例子就是：

两个 agent 修改同一文件

你以为是在协作，实际上是在互踩。

还有一种特别烦的情况：每个 Agent 都各自做了“局部最优”决策，单看都对，拼起来就是一坨。Architect 改了边界，Developer 沿旧接口继续写，Reviewer 又基于另一版状态给意见。

最后不是团队，是群聊。

所以我现在对 Multi-Agent 的看法有点保守：它不是天然更强，只是给了系统更多组织复杂任务的可能性。能不能变强，全看 orchestration 层能不能兜住。

兜不住就完蛋。

---

我为什么越来越觉得，未来更像 Agent OS，而不是更大的 Agent

这部分是我最近一个越来越强的判断。

很多人讨论未来的时候，直觉还是“换个更大的模型，一切都会好起来”。我现在没那么信。

因为 LLM 本质上还是这个东西：

next_token = f(context)

它再强，底层也还是基于上下文做局部决策。

但一个复杂的软件系统要稳定跑起来，靠的不只是“会想”，还得有这些东西：

长期状态
任务调度
资源管理
错误恢复
执行隔离

这些能力，明显更像系统层能力，不像模型层能力。

所以我现在越来越倾向于一个方向：

未来真正有竞争力的，不是“一个更大的编程 Agent”，而是“LLM + Agent Runtime + Agent OS”。

模型是脑子，但系统才是骨架。

没有骨架，脑子再大也容易摔。

---

Agent OS 这玩意，听着玄，其实一点都不玄

很多人第一次听到 Agent OS，会觉得像概念包装。但如果你真做过长任务编排，你会发现这个方向其实非常自然。

一个比较像样的结构，大概会是这样：

User
 │
Task Manager
 │
Planner Agent
 │
Task Graph
 │
Executor Agents
 │
Tools

再展开一点，可能像这样：

              ┌──────────────┐
              │ Task Manager │
              └──────┬───────┘
                     │
              ┌──────▼──────┐
              │ Planner     │
              └──────┬──────┘
                     │
            ┌────────▼────────┐
            │ Task Graph      │
            └────────┬────────┘
                     │
      ┌──────────────┼──────────────┐
      │              │              │
Executor A     Executor B     Executor C

这时候系统的关键点就不再是“某个 Agent 有多聪明”，而是：

• 任务怎么拆

• 状态怎么存

• 谁能并行

• 谁能回滚

• 出错后谁接管

• 哪些上下文该保留，哪些该丢弃

说白了，这已经很像操作系统在干的事了。

是不是这种感觉还挺好玩的。

---

一个成熟的 Agent 系统，迟早会长出这些部件

我现在觉得，后面凡是能真正落到生产里的 Agent 系统，大概率都会往这些组件上长：

Task Graph

任务 DAG

不是所有事都串行，也不是所有事都能并行。任务关系必须显式化，不然调度全靠模型脑补，迟早翻车。

Planner

任务分解
任务排序

规划必须从执行里剥出来，不然计划永远会被执行细节污染。

Executor Agents

执行具体操作

执行单元要足够小、足够专注，别让一个 Agent 又想又干又复盘又背锅。

Memory System

short-term memory
long-term memory
vector memory

很多人现在一提 memory 就开始讲检索增强，但我自己更关心的是：哪些状态是运行时强约束，哪些只是参考记忆。这两者混在一起，系统一定乱。

Tool Runtime

filesystem
git
shell
browser
database

工具不是附件，工具就是执行环境本身。没有稳定 runtime，Agent 再聪明也只能当聊天机器人。

---

这条路看起来很像早期计算机系统的发展

这一点我最近也越想越觉得像。

AI 系统的演进，可能不会只是模型参数越来越大，而更像计算机系统早期的演化过程：

LLM
↓
Agent Framework
↓
Agent Runtime
↓
Agent OS

也就是说，前面大家在拼“怎么让模型会做事”，后面真正拉开差距的，可能是“怎么让整套系统可持续地做事”。

未来的软件开发环境，我觉得很可能会长成这样：

User
 │
AI Shell
 │
Agent OS
 │
Agent Runtime
 │
LLM cluster
 │
Tools

到那一步，AI coding 可能就不再只是“IDE 里多了个助手”，而是变成一种新的计算环境。

这件事我现在不敢说一定会这么走，但我对这个方向的信心，已经比“单个超级 Agent 通吃一切”高多了。

后者我真的被坑过太多次了。

---

这段时间我最大的认知变化，不是模型有多强，而是我开始更重视系统

如果一定要说这篇文章最后想表达什么，那不是“Subagent 很重要”，也不是“Multi-Agent 是未来”。

我真正的认知转变是：

编程 Agent 的核心瓶颈，越来越不像模型能力问题，而像系统工程问题。

单 Agent 做不好复杂任务，不一定是因为模型弱，很多时候只是因为它没有一个能长期稳定运行的系统外壳。

所以我现在对这件事的几个判断基本是：

1. 单 Agent 能解决很多问题，但很难稳定解决复杂问题

2. Subagent 和 Multi-Agent 本质上是在解决 context scaling 和任务分解问题

3. orchestration 才是整个 Agent 系统里最难、也最容易被低估的一层

4. 真正成熟的 AI 开发系统，最后很可能会往 Agent OS 这种形态走

换句话说：

复杂任务最终拼的不是“模型够不够大”，而是“系统能不能把复杂性接住”。

这也是我最近越来越信的一件事。

接下来几年，这个方向应该会非常有意思。