一半的 subagent，只是没删干净的 system prompt

准备再加一个 subagent 之前，先问它到底解决什么问题。Google Chrome 团队的 Addy Osmani 给出的答案有点扫兴：多数时候，那个问题是 system prompt 太臃肿。

subagent 的做法是另开一个上下文窗口干活，跑完只把结论交回主线程。吸引力很明显，主循环不用读几十个文件、几百行日志。代价也在这里：分出去的那段过程，你看不见。

他给的经验法则只有三条，满足才值得拆：工作真能并行、需要一份全新的上下文、单个 agent 确实选不对工具。剩下的情况，折回主循环，把原来的 prompt 改写成 skill，跑一遍 eval，谁赢留谁。

评论区有人把话说得更难听。Hardik 说，他见过的一半 subagent，就是一个长到离谱的 system prompt。Adam 补了一句，还有人给这种东西起了个名字叫架构。

Rohan 的判据更硬：看父 agent 需不需要完整记录。只要几行回传，拆得值；如果要整份 transcript，拆分只是把上下文问题挪到了另一个地方。

Akash Hadagali 提到一个容易被忽略的收益：折回主循环后，所有 tool call 落在同一条 trace 里，eval 跑挂的时候好查得多。

Bits and Mettle 给了个自查方法。翻一遍 system prompt，找出只对某一类任务有用的段落，挪进按需加载的 skill。主线程会被测试日志和搜索结果塞满时，subagent 才站得住。

还有两个维度值得加进判断表。Bragi 说权限：做研究的 subagent 能读帖子，不该有发布权。Kabel-Salat 说场景：最干净的是嘈杂搜索配一个短答案，让 subagent 啃 40 个文件，回十行。

也有人不同意全折。0xserenade 认为上下文窗口是稀缺资源，都塞成 skill 会遇到首次调用变贵、职责过载的问题。打螺丝的Dave 提醒得更实际：上个月有效的拆分，模型升级一次可能就不值那个位置了。Aapakari 补了个数字，工具定义超过 30 到 50 个之后，工具选择质量会下降，那种情况可能只需要 tool search。

Dusan 那句提醒我认为最该记住：subagent 只交回摘要，它悄悄跳过了什么，你永远看不到。

所以问题不是能不能拆，是拆完谁受益。上下文没省下来，调试链路还多断了一截，那就是给自己加了一层抽象。

下次手痒想加 agent，先删 prompt。