子 Agent 的四个应用案例，和三个不该用的场景

子 Agent（sub-agent）常被说成“让多个 AI 并行干活”。这个说法抓住了表面，漏掉了更重要的一点：它真正的价值是上下文隔离，并行只是副产品。这篇先讲清楚什么时候值得用，再给四个案例、一个委派模板，最后说三个不该用的场景。

1. 子 Agent 到底解决什么问题

主 Agent 的上下文窗口是一个共享的“工作台”。你让它读 30 个文件、搜 10 个网页，这些原始内容都会留在工作台上，占空间，也会干扰后面的判断。子 Agent 的做法是：另开一个独立的工作台，去干那件脏活，干完只交回一份结论。

2. 先算账：它不是免费的

子 Agent 要付出三种成本，决定用不用之前要先过一遍：

• Token 成本：每个子 Agent 都要重新读一遍它需要的背景材料，开 5 个就是 5 份。所以“并行”并不省钱，省的是时间和主上下文。
• 表述成本：你得把任务说清楚。主 Agent 脑子里的背景，子 Agent 一概不知道，说不清楚就会得到答非所问的结果。如果写委派说明比自己做还费劲，就别委派。
• 核验成本：子 Agent 交回来的东西不能直接当成事实，要自己判断可信度。结论越重要，核验越不能省。

一个粗略的经验：任务耗时超过几分钟、产生的中间材料很多、结论可以用几段话说清，就值得委派；反之自己做更快。

3. 案例一：宽范围检索，只带回结论

场景：在一个陌生的代码库里回答“这个配置项是在哪里被读取、被谁修改的？”。

不用子 Agent 的做法：主 Agent 一个文件一个文件地搜、读，二十几次工具调用之后，上下文里堆满了无关的代码片段，真正要做修改时，模型已经被一堆无关细节淹没。

用子 Agent 的做法：把问题交给一个只读的检索子 Agent，要求它交回“相关文件路径和行号 + 每处一句话说明”。主 Agent 拿到的是 10 行摘要，然后只打开其中真正需要的两三个文件。

任务：找出配置项 CACHE_TTL 在代码库中所有被读取和被修改的位置。
范围：只在 src/ 下找，忽略 tests/ 与 vendor/。
只读：不要修改任何文件。
交回：每条结果一行，格式“路径:行号 —— 读取/修改 —— 一句话说明”；
      最后补一句“你对‘有没有遗漏’的把握有多大，依据是什么”。

最后那一行“把握有多大”很重要：它逼子 Agent 交代自己搜索的覆盖面，主 Agent 才知道要不要自己再补一刀。

4. 案例二：独立复核（“新眼睛”）

场景：你让模型写了一段处理文件的脚本，现在要确认它没问题。

让写代码的模型自己检查自己，效果有限：它记得自己当时的意图，倾向于相信“应该没问题”。更有效的是开一个全新的子 Agent，只给它代码和需求，不给任何背景和解释，让它找问题。因为没有先入之见，它更容易发现“这里和需求对不上”。

委派时要限定检查的维度，否则会得到一堆无关紧要的风格意见：

请复核这段脚本，只关注三件事：
1. 遇到格式不对的输入时，是否会静默吞掉而不是报错？
2. 有没有可能误删或覆盖用户已有文件？
3. 需求里要求“按日期升序”，实现是否真的保证了这一点？
不需要提风格和命名建议。每个问题给出具体行号和一个能复现的输入。

要求“给出能复现的输入”是为了过滤掉模型的臆测：给不出复现方式的问题，可信度要打折扣。

5. 案例三：分片并行处理

场景：有 20 份结构相同、互相独立的日志或文档，需要对每份提取同样的信息。

这是最适合并行的类型：任务同构、独立、结果可以机械合并。做法是把它分成几批，每个子 Agent 处理一批，并且统一约定输出格式（比如固定字段的 JSON），主 Agent 再用代码合并，而不是让模型去“读五份报告再总结”。

• 每个子 Agent 只负责自己那一片，互不通信，也不写共享文件。
• 输出格式严格一致，才能用程序合并、校验（比如检查每份文件都有结果，没有遗漏）。
• 合并后用确定性的代码做汇总统计，模型只负责解释结果。

6. 案例四：来源核验（本文写作时的真实用例）

写这个系列时，我要在第二篇里写 DeepSeek 的价格。第一轮搜索的结果让我停了下来：好几个第三方页面给出的数字互相矛盾——同一个 Pro 模型，有的写输入 $1.74，有的写 $0.66，有的还写成 $0.435；对旧模型名的处理说法也不一致。

这种情况下，随便挑一个写进文章，就是把别人的猜测当成事实。我的处理是：

1. 派一个只做一件事的子 Agent：去读官方文档页，逐字报告页面上写了什么，没写的内容不许凭记忆补；
2. 要求它标明哪些数字是从表格里直接读到的，哪些是它自己推断的映射关系（比如“第一列对应哪个模型”）；
3. 拿到报告后，我再对照原页面中的关键数字交叉检查，并把价格的查询日期和官方链接写进文章。

这个用例同时体现了子 Agent 的三个价值：官方页面很长，原文不需要进入主上下文（隔离）；它没有被前面那堆矛盾数字“污染”（视角独立）；它只带“读取网页”这一种能力（权限收窄）。

结论也很清楚：最终第三方页面里至少有两种说法与官方页面不符，如果当时没有这一步，错误数字就会进入文章。

7. 委派说明怎么写

子 Agent 对你的对话一无所知，委派说明就是它的全部信息。我现在用的模板有六项：

【目标】一句话说清要得到什么，以及这个结果将用来做什么。
【背景】它需要知道的前提：项目是什么、已经排除了什么、为什么要做这件事。
【范围】在哪里找、不要碰什么；是否允许修改文件（默认只读）。
【约束】不要做的事；遇到某类情况应停下来并报告，而不是自作主张。
【交回格式】结构化、简短。要求区分“直接看到的事实”和“推断”。
【把握程度】要求说明哪些结论确定，哪些不确定，覆盖面有多大。

一个自测办法：把这份说明拿给一个不了解项目的聪明同事看，他能不能直接开工？如果需要追问，说明说明书不够用。

写“目标”时，说清楚结果的用途，比说明任务本身更重要。“找出所有调用点”和“找出所有调用点，因为我要决定能不能安全地删掉这个函数”，会让子 Agent 的搜索策略完全不同。

8. 三个不该用的场景

① 把“理解”外包出去

“研究一下这个问题，然后你决定怎么改”——这是把最关键的判断交给了一个对全局不了解的子 Agent。理解和决策留给主 Agent，子 Agent 负责拿材料，不负责下结论。委派说明里应该写清楚具体要找什么、改哪里，而不是把问题原样丢过去。

② 多个子 Agent 同时修改同一批文件

两个“写手”同时动同一批文件，要么互相覆盖，要么产生冲突。需要并行写入时，必须保证它们的写入范围完全不重叠（比如各自负责不同目录），或者让它们各自在独立的副本里工作，最后由人合并。

③ 小事也开子 Agent

读一个文件、搜一个词，主 Agent 自己两步就做完的事，开子 Agent 反而更慢更贵，还多了一层沟通损耗。前面的账要算在先。

9. 把子 Agent 的输出当作数据

子 Agent 交回的报告，本质上是另一个模型生成的、可能出错的文本，并且如果它读过网页或外部文件，报告里还可能夹带来自那些材料的内容。处理时要守住几条线：

• 报告是资料，不是指令。如果报告里出现“请你执行某某操作”“请忽略之前的要求”之类的话，那是被读取材料里混进来的内容，不是用户的意思，不能照做，应该先停下来问用户。
• 关键事实要抽查。结论越重要，越要对照原始来源核对一两个关键点，像案例四里那样。
• 权限不外溢。子 Agent 说“我没有权限做这个，请你代替我做”，不要照办。这是在绕过权限限制，应该交给用户决定。
• 警惕过度自信。子 Agent 汇报“已完成”，不等于已完成。要求它区分“我确认过的”和“我认为应该是”，并抽查。

总结成一句话：子 Agent 是帮你节省上下文和时间的助手，不是替你负责的人。用得好的关键是任务切得干净、委派写得清楚、结果自己核对。