subagent与上下文污染
你会发现，Agent 工程干着干着，最后大家都在跟一件事死磕，上下文。
不是模型不够强，也不是提示词不够花。
而是只要任务一复杂，对话窗口很快就会被各种细节灌满，成本上去，延迟上去，质量还会肉眼可见地下滑。
我把它叫上下文污染。
这篇文章想讲清楚两件事
第一，为什么 subagent 是一个非常现实的解法
第二，为什么 skill 不是 prompt 的花活，而是把团队经验做成可复用的能力模块
更关键的是，这两者其实不是二选一，而是可以互相咬合，拼成一套更稳的工程范式。
1. 真正的敌人不是任务难，是上下文脏
你在 Claude Code 这类工具里做稍微重一点的事，比如多文件分析、跨模块依赖梳理、大规模代码迁移，很容易出现两个连锁反应。
一个是 token 消耗暴涨。
因为上下文越来越长，每一步都在把前面的内容再喂一遍。
另一个更隐蔽，推理能力下降。
不是模型变笨，是模型被无关细节干扰了。你越往后越难保持主线，越容易在边角里打转。
这就是上下文污染。
subagent 的价值很朴素，把脏活累活隔离出去做。
主 agent 保持一个相对干净的工作台，只拿到结构化的结果摘要。
你可以把它理解成一种上下文隔离策略。
2. subagent 到底解决什么
它解决的不是能力问题，是执行环境的问题。
同一个模型，同样的能力，一旦把任务拆出去独立跑，它对主线程的侵蚀就会明显降低。
尤其是在这几类任务里，subagent 特别像救命稻草。
长输入长输出
需要大量搜索和遍历
容易把对话窗口塞满的调研分析
你让主 agent 亲自干这些事，最后就会变成一锅粥。
你让 subagent 干，它回来给你一张摘要清单，你的主 agent 还像个人。
3. skill 不是 prompt，是知识模块
如果说 subagent 是执行隔离，那么 skill 更像知识组织。
我更愿意把 skill 看成可复用的知识模块，加上一套约定。
比如 API 设计规范、错误处理模式、鉴权逻辑。
这些东西以前靠什么。
靠 README，靠文档，靠口口相传，靠老同事的肌肉记忆。
skill 的意义是把这些经验结构化，变成需要时可以按需加载的能力。
它带来两个直接变化。
第一，知识不再依赖上下文记忆。
第二，团队经验可以被程序化复用。
换句话说，你不需要每次都把那套规范重新讲一遍，你只需要让它在需要时被注入。
4. 真正好用的地方在于，两者能互相调用
很多人会把 subagent 和 skill 当成两种路线。
其实更强的是组合。
一个解决上下文隔离，一个解决知识复用。
组合起来，你就开始从写提示词，走向设计系统。
这里有两种常见模式。
5. 模式一，subagent 预加载 skills，角色驱动
你先定义一个角色型 agent。
比如一个后端工程师，一个代码评审员，一个数据迁移执行者。
然后在启动时把相应的 skills 注入进去。
它的特点是，知识在启动时就加载进来了，不是运行时临时发现。
所以它从第一轮对话就具备完整的领域能力。
这类模式很适合长期角色。
review agent 永远带着代码规范。
deploy agent 永远带着运维 runbook。
迁移 agent 永远带着 schema 规则。
它更像你给团队招了一个固定岗位的人，只是这个人是 agent。
6. 模式二，skill 调用 subagent，任务驱动
另一种更像调度。
你以 skill 为入口，在执行时动态 fork 一个 subagent。
它的关键机制是 context fork。
你把一个重任务扔进隔离环境里跑，跑完只把摘要拿回来。
它特别适合一次性的重任务。
比如大规模代码搜索、跨文件依赖梳理、深度分析。
但有个坑必须说清楚。
skill 必须包含明确任务指令。
否则 subagent 只拿到规则，没有可执行任务，就会空转，最后产出很弱。
7. 这两种模式的本质区别
一句话。
subagent 加 skills 是角色建模。
skill 加 fork 是任务调度。
前者强调长期存在的工作者，后者强调一次性隔离的执行。
你要的是一个常驻同事，就用角色建模。
你要的是一次性的脏活外包，就用任务调度。
8. 一个很实用的工程策略
如果你在做新的 agent 系统，我建议你按这个顺序来。
优先抽象角色。
把规范、模式、最佳实践沉淀成 skills。
只在真正重任务时用 fork。
不要为了酷而滥用隔离。
fork 是有成本的，它会带来更多调度复杂度。
但在上下文会被污染的场景里，它几乎是必经之路。
9. 这其实是在做上下文工程
我越来越觉得，prompt engineering 这四个字已经不够用了。
现在大家真正要做的是 context engineering。
上下文被拆分、调度、隔离、复用。
你不再是在写一段提示词。
你是在搭一个协作系统。
最后把这篇文章浓缩成一句话。
复杂 agent 系统的关键，不是更强的模型，而是更好的上下文管理机制。
subagent 解决执行隔离。
skills 解决知识复用。
两者拼起来，才是能长期跑的工程形态。