21 · 子代理（Subagents）：把活儿拆出去并行跑，但只有“你开口”它才拆

子代理听起来很高级，其实你可以理解成：让 Codex 叫几个助手分别干活。

关键不是“能不能拆”，而是“该不该拆”。 小白阶段最容易犯的错，是把一个简单任务硬拆复杂。

先问：这个任务真的需要拆吗？

子代理适合多个独立任务并行。

不适合：

1. 只改一篇文章。
2. 只修一个小 bug。
3. 多个任务都要改同一个文件。
4. 你还没想清楚目标。

小白最稳的方式：先让子代理只读检查，不让它们同时改文件。

先用“能不能互不影响”判断

只有满足这 3 条，才适合拆子代理：

1. 每个小任务目标清楚。
2. 每个小任务能独立完成。
3. 它们不会同时改同一个文件。

比如：

• 一组人只检查错别字。
• 一组人只检查安全风险。
• 一组人只检查链接和图片。

这种可以拆。

如果大家都要改同一篇文章，就先别拆。

01 先搞懂：子代理到底是什么

子代理是一个独立处理某类任务的助手。 它可以有自己的上下文、目标、甚至模型设置。

主线程负责指挥和汇总。 子代理负责某一块具体工作。

你可以这样问：

请用小白能懂的话解释子代理是什么。
再告诉我当前任务是否有必要使用子代理。

02 它解决什么：以及那条反共识的线

子代理主要解决两个问题。

病一：上下文污染（context pollution）

一个会话里塞太多不相关内容，Codex 容易乱。

比如你同时让它看设计、修 bug、查安全、写文案。 这些上下文混在一起，会影响判断。

病二：上下文腐烂（context rot）

会话太长，旧信息越来越多，新任务反而被旧线索拖住。

这时把某个独立检查拆出去，能让结果更清爽。

反共识的线：哪些活别拆

这些别拆：

1. 需求还没说清。
2. 只是改一篇文章。
3. 多个任务都会改同一个文件。
4. 你还没能力验收多个结果。

小白最稳用法：先让子代理只检查，不修改。

03 不用配也能拆：三个内置 agent + 怎么唤起

有些环境会有内置 agent。 你不用一开始自定义。

先问：

当前环境有哪些可用的内置 agent？
它们分别适合做什么？
只解释，不要启动。

启动前要说清楚范围：

请只启动一个只读检查 agent。
目标是检查当前文章是否适合小白。
不要修改文件。

04 管在跑的 agent：/agent 进去看，或直接喊话指挥

抓手一：用 /agent 切换和查看

如果环境支持 /agent，它通常用于查看或切换正在工作的 agent。

你可以先问：

/agent 在当前环境里能做什么？
请只解释，不要切换。

抓手二：直接喊话指挥

你也可以直接说：

请让负责内容检查的 agent 只看第 18 篇。
输出问题清单，不要修改。

05 自定义 agent：写一个 TOML 文件，给它配专属模型

如果你经常需要同一种角色，就可以自定义 agent。

比如：

• 只读侦察 agent。
• 小白可读性检查 agent。
• 安全风险检查 agent。

给不同 agent 选不同模型和思考强度

复杂检查可以给强一点的模型。 简单分类可以用更快的设置。

但小白先别急着配模型。 先把 agent 角色写清楚。

06 动手：写一个只读侦察 agent 并让它干活

练习目标：

1. 只读项目。
2. 不修改文件。
3. 输出结构化报告。

提示词：

请帮我设计一个“只读侦察 agent”。
职责：
1. 查看项目结构
2. 找出当前任务相关文件
3. 不修改任何内容
4. 输出下一步建议
先给设计，不要创建文件。

07 进阶顺一句：批量处理 CSV（实验性）

子代理也可以用于批量任务。 比如很多行数据、很多文件、很多独立检查。

但这属于进阶。 新手先别从这里开始。

08 小结

子代理不是“越多越强”。 它适合拆清楚、互不干扰、能汇总的任务。

普通人先记一句： 小任务不拆，大任务先拆成只读检查。