WorkBuddy 子 Agent 实测笔记：拆与不拆的边界

子 Agent 最大的价值不是并行，是隔离——把一堆无关的搜索、试错、失败重试关在另一个上下文里，只把结论带回来。但拆错了，主 Agent 反而会失去判断力。

我在 WorkBuddy 上做了一批自用工具的开发与运维，日常会用到子 Agent（subagent）机制。一开始把它当成"并行加速器"——一个任务拆成四份同时跑，理论上是四倍速。

跑了两周之后发现，并行只是副产品，真正的价值在上下文隔离。而并行本身，如果拆得不对，反而会拖慢甚至搞砸任务。

一、子 Agent 到底隔离了什么

子 Agent 是一个独立启动的执行实例，有自己的上下文窗口、自己的工具调用循环。它做完之后，只有它最后返回的那段文字会回到主 Agent，中间几十轮搜索、试错、报错、重试，全都留在它自己的上下文里，不会污染主线。

这一点比"并行"重要得多。原因是主 Agent 的上下文是有限且昂贵的资源：

所以子 Agent 本质上是一个上下文过滤器：输入一堆噪声，输出一句结论。并行能力是顺带的。

我实际跑下来，有四类任务拆出去收益明显：

比如"这个项目里所有调用鉴权中间件的地方在哪、有没有遗漏"。这类任务会读几十个文件、走很多死胡同，但最终结论可能只有五行。放在主线里做，上下文会被垃圾填满；扔给子 Agent，回来的就是五行。

比如"这个前端构建为什么失败"。可能的原因有十几个，挨个排除。这类探索的价值不在过程，在于最后确定的那一条根因。过程留在子 Agent 上下文里，主 Agent 只拿到"是 X 文件第 N 行的循环引用"。

构建、跑测试、批量拉取、轮询等待。这类任务可以后台跑，主 Agent 继续干别的，跑完再回来收结果。这一点对交互体验影响很大——人不用干等。

同一个问题让三个子 Agent 用不同思路各做一版，主 Agent 拿三份结果对比。这比自己顺序试三遍快，而且三个方案之间互不影响，不会出现"第二个方案被第一个带偏"。

这部分是踩坑换来的，比"该拆"更值得记。

比如"这次改动会不会影响线上登录链路"。这需要同时掌握认证、会话、网关、缓存几块的信息，任何一块交给子 Agent，它都只能看到局部，给出的结论会显得很有道理但漏掉关键。

主 Agent 花了很多轮才搞清楚的一些隐含前提（某个约定、某个历史原因），子 Agent 完全不知道。你要么花很大篇幅写在指令里，要么它就做错。如果写指令的成本已经接近自己做的成本，就别拆。

把"改三个文件里的三处字符串"拆成三个子 Agent，纯属自找麻烦：启动开销、指令编写、结果合并加起来，比直接改慢好几倍，还容易出现改动冲突。 子 Agent 的调度成本不低，粒度太细就是净亏损。

涉及生产环境、涉及不可逆操作的任务，不适合扔到后台。这一类我坚持留在主线上，一步一确认。

子 Agent 只返回一段文字，这意味着所有它认为不重要的东西都会消失。而它判断"什么重要"的依据，只有你给的那句指令。

我遇到过的典型问题：让子 Agent 去查"部署脚本为什么失败"，它回了一句"是权限问题，已确认"。看起来解决了，但主 Agent 没法判断到底是哪个文件、哪个用户、哪种权限，也就没法决定要不要回滚。

解法很土但有效：在指令里明确要求输出格式。不要写"查一下为什么失败"，写清楚"返回四项：错误原文、出错文件绝对路径、触发命令、你建议的下一步"。这四行写进去，回来的信息就能直接用。

给子 Agent 的指令，要像给外包写的验收标准：不是描述任务，是描述交付物。

后台跑（先拿任务号，稍后取结果）这个能力，改变的是工作节奏而不是速度。耗时的构建、长时间的数据处理，扔到后台之后，主 Agent 可以继续处理别的事情，人也不必盯着屏幕等进度条。

另一个不太被提到但很有用的能力是续接：子 Agent 跑完一轮后，可以带着它原来的上下文继续下一轮，而不是重开一个。这适合"先侦察、再根据侦察结果深入"的两段式任务—— 如果重开，第一段的发现就白费了。

问自己一个问题：这件事的中间过程，我需要看到吗？不需要，就拆出去；需要，就留在主线。跟它有多少行代码、多少个文件没关系。

明确要回什么字段、什么格式、什么精度。 "帮我看看"是最贵的四个字——它会让子 Agent 自由发挥，然后你要花更多时间追问。

子 Agent 回来之后，主 Agent 要做的不是"再检查一遍"，而是"判断这份结论是否足以支撑决策"。如果不确定，让它带着原上下文补一轮，而不是自己重新查一遍—— 后者等于放弃了隔离带来的全部收益。

最后一句体会：多 Agent 系统里最稀缺的资源不是算力，是判断力。子 Agent 能替你查、替你跑、替你试，但最后那个"这样做对不对"的问题，还是得有一个角色来答。这个角色通常是主 Agent，有时候还得是人。