让 AI 像一个小团队一样干活：我的 Subagent 流水线

用 AI 写代码的人多半有过这个体验：一个会话刚开始很聪明，聊到一两个小时后开始变笨——早前说过的约定它忘了，改 A 文件时把 B 文件里已经确认过的逻辑又改回去了，甚至开始重复问已经回答过的问题。

第一反应往往是”模型不行了”或者”今天服务降级了”。但真实原因大概率朴素得多：上下文窗口被垃圾塞满了。

上下文是工作记忆，不是硬盘

大模型的上下文窗口相当于人的工作记忆：正在处理的所有东西都得装在里面，装不下就得扔。而一场编码会话里，真正值钱的信息其实很少——需求约定、几个关键决策、当前任务进展。占地方的是什么？是排查问题时读过的十几个文件全文、跑过的命令输出、搜索时命中又没用上的代码片段。

这些东西读的时候有用，读完就是废纸。但它们不会自己消失，一直躺在上下文里往后挤。等真正重要的约定被挤出窗口（或者被淹没在噪音里），AI 就开始”忘事”。

人怎么解决这个问题？不会让一个人脑子里同时装着所有细节，而是分工：你是负责人，让实习生去翻资料，他翻完只汇报结论，翻过的一百页纸留在他自己桌上，不进你的脑子。

Subagent 干的就是这件事。

派活出去，只把结论带回来

Subagent（子代理）是现在各家 AI 编码工具都在做的机制，我日常用的 Claude Code 里它长这样：主会话可以把一个子任务”派”出去，由一个独立的 AI 实例在独立的上下文窗口里执行，干完把结果汇报回来。

关键在”独立”两个字。子代理读了多少文件、跑了多少命令、走了多少弯路，都发生在它自己的窗口里；主会话只收到最后那份几百字的报告。相当于实习生把一百页纸消化成一页纸备忘录——主会话的工作记忆始终干净。

我搭这个博客的时候就是这么干的。比如要选静态站点框架，我让一个子代理去调研 Astro 的内容集合方案，另一个同时去调研部署选项，主会话该干嘛干嘛。两个”实习生”回来各交一页纸，主会话拿着两份结论做决策——它自始至终没读过任何一篇框架文档，工作记忆里只有干净的结论。

这里面有个不太直观的经济账：子代理还可以用更便宜的模型。查资料、找文件这类跑腿活不需要最强的脑子，派个快而便宜的小模型去干，又快又省。团队里也不会让资深工程师去干复印装订的活，是一个道理。

审查-修复循环：最值得学的一招

分工里最有意思的不是”跑腿”，而是审查。

我现在写完一段重要的代码，会固定加一步：派一个子代理去挑毛病。它拿到的指令大意是”审查这些改动，找出逻辑错误和边界情况的遗漏，汇报问题清单”。它报回来的问题，主会话逐个修掉，改动大就再审一轮。

你可能会问：都是同一个模型，自己审自己，能审出什么？

能，而且效果好得反直觉。原因还是上下文。主会话写代码时，脑子里装着完整的”心路历程”——为什么这么设计、当时怎么权衡的。让它自己检查，它会顺着自己的思路滑过去，就像人检查自己刚写的文章，明明有错别字就是看不见，因为你读的不是纸上的字，是记忆里的意思。

而审查用的子代理是全新的上下文，它没有心路历程，没有沉没成本，只看得到代码本身。写的时候”显然没问题”的假设，在一双没有预设的眼睛面前经常当场露馅。

我这个博客的构建脚本里好几个边界问题——比如文章 slug 里带斜杠会把路由搞崩——都是审查循环抓出来的，主会话自己是发现不了的，因为那些坑就是它自己挖的。

交接靠说明书，不靠默契

Subagent 好用，但有个特性必须先想明白，否则第一次用就会栽跟头：子代理看不到主会话的对话历史。

它不知道你们刚才聊了什么。你在任务描述里写”按我们刚才讨论的方案改一下那个文件”，它收到的就是这句没头没尾的话——“刚才讨论的方案”是什么？“那个文件”是哪个？全都不存在。

所以派活的质量取决于任务说明书的质量。一份能用的说明书得有：背景（在做什么项目、什么前提）、任务（具体做什么，涉及哪些文件路径）、汇报要求（返回什么格式、什么范围）。第三条最容易被忽略也最重要——不写清楚汇报要求，子代理经常给你抱回一堆原始文件内容，你派它出去本来就是为了不看这些东西，结果它全倒回你的上下文里，白派了。

写过需求文档的人会发现这套东西眼熟：这不就是给外包写工单吗？确实就是。子代理之间没有默契可言，一切交接都得显式写出来——这是约束，其实也是好处，它逼着你把任务想清楚。任务说明书写不出来，往往说明你自己还没想明白要干什么。

什么时候别用

分工不是免费的。每次派活都有固定开销：说明书要写、子代理要从零建立对现场的认知、报告要读。一句话能查到的事——“这个函数在哪个文件里”——直接查就完了，专门派个人去，纯属把简单事办复杂。

我的粗略判断标准：这个任务会不会产生大量”读完即弃”的中间内容。会（翻大量文件、通读长文档、反复试错），派出去，垃圾留在别人窗口里；不会（一两步就出结果），自己干。另一个信号是独立性：几个任务互相不依赖，就同时派几个子代理并行跑，坐收几份报告，这是单会话串行永远给不了的速度。

收尾

这套流水线用了几个月，我慢慢意识到它真正的启示不在 AI 本身：subagent 机制不过是把软件工程里最古老的智慧——分工、接口、职责边界——搬到了 AI 协作上。上下文隔离是模块化，任务说明书是接口契约，审查循环是 code review，并行派活是任务调度。

所以”会用 AI”这件事，越来越不像一种新技能，而像一种老技能的迁移：能把任务拆清楚、把交接写明白、知道什么该委托什么该自己盯的人，带 AI 团队和带人类团队，用的是同一套本事。工具在变，把事情想清楚的能力一直是那个瓶颈。