别让 Agent 自己检查自己的活

前面几篇，把主循环里的独角戏讲完了：一个模型、一套工具、一段上下文、一份记忆。但真做一个专用 Agent，几乎一定会走到这一步：有些活，交给同一个模型在主循环里顺手做，效果并不好。这篇讲什么时候该把活派出去，交给一个子 Agent。

子 Agent 解决三件事：并行、上下文隔离、客观性。野行 Y 里有两个真实的子 Agent，正好覆盖这三件，我一个个说。

第一个叫 research，管并行和隔离。排一条自驾环线，模型常常一次要核实一批事实：折多山十月封不封路、稻城亚丁最佳季节、某个网红观景台是不是真的存在。早期这些靠模型一个个调搜索串着查，两个毛病：慢，五个点串行等五轮；脏，五次搜索的原始网页摘要全堆进主上下文，就是上一篇讲的上下文膨胀的元凶。research 把它改成了一个并行子 Agent。模型一次把要核实的一批问题交给它，它并行搜，最多六个同时打出去，墙上时间从五轮之和压到最慢那一轮。实测四个点并行大约九秒，串行要四倍。

更妙的是上下文隔离。原始的那五坨网页摘要，全部消化在子 Agent 内部，它在返回之前先用一次模型调用把每个主题压成一句结论，主循环的上下文里只回来五句蒸馏过的干货。噪音留在子 Agent，干货回主循环。子 Agent 天然就是一道上下文防火墙。这跟 Claude Code 派一个子 agent 去「搜整个代码库找某个用法」是同一个道理，你不想让几十个文件的内容涌进主对话，你只想要那句「它在这三个地方被调用」。

第二个子 Agent 解决的问题完全不同，也是这篇标题说的那件事：客观性。

模型排完一条主线，正要拿给你确认。这时候有个风险，它可能漏了你的硬约束：你说怕高反，它排了个四千七的垭口还连着长途；你带着老人，它给你排一天开八小时；三个人结伴，其中一个人的必去点被漏掉了。

你不能指望排方案的那个模型自己揪出这些。它刚生成完方案，上下文里全是「我为什么这么排」的理由，让它自查，它倾向于自我确认，「嗯，我排得挺合理」。这是 Agent 的一个通病，也是人的通病。

Claude Code 的解法叫 verify-before-done，完事之前用一次独立的核对，确认真做对了。野行 Y 照这个思路加了一个换了脑子的核对子 Agent，它有几个讲究。它是无工具的一次纯核对，不搜不算，就对着「用户要什么」和「方案是什么」逐条比，角色单一就不会跑偏去干别的。它换了一套上下文，拿到的是重新抽取的用户约束加主线摘要，主 Agent 那一大堆推理过程它看不到，干净的新脑子，这正是它比主 Agent 自查客观的原因。它接在给你确认那一步之前，所以有问题的主线你根本看不到，已经被它打回重排了。它只回弹一次，打回去让主 Agent 改一版、重新核对，就放行，核对是为了兜住硬伤，别追求完美到把你晾在那儿反复改。

验证过它真管用：一个「怕高反却安排四千七加长途」的方案，它揪出好几条真硬伤；而一个「成都轻松三天」的正常方案，它零误报、静默放行、不打扰。方案本身好的时候它一声不吭，有硬伤时它在你看到之前拦下来。

这两个例子，指向同一套可迁移的判断。当你在主循环里遇到下面任一种情况，就该考虑派个子 Agent 出去。一批同类的活，比如核实多个点，串行慢，派出去并行。会产生大量中间噪音的活，比如搜索、扫库，污染主上下文，派出去隔离，只让它回结论。要客观评判自己刚产出的东西，自我确认偏差，派出去换个脑子核对。

有个成本要认：子 Agent 有代价，它多花一次或几次模型调用，也多一层延迟和复杂度。所以别滥用。判据很简单：这件活如果留在主循环里做，会不会让主循环变慢、变脏、或者变得不客观？三个里中一个，就值得派出去；一个都不中，就别为了架构好看而拆。

还得记住一个前提：子 Agent 的质量，取决于它用的模型。这个项目里核对子 Agent 用的是主模型链，一旦主力模型降级到弱模型，它的核对质量会同步下降。子 Agent 没那么神，它只是把同一个模型，用在了更合适的角色和时机上。

到这儿，Agent 架构的地基就搭齐了：循环、工具、上下文、记忆、子 Agent。但这套骨架得有个大脑来驱动，而一个专用 Agent 往往不止用一个模型。下一篇进入模型层，讲怎么给不同的活配不同的模型，难的重活用强的、高频的用快的，以及主力挂了怎么兜底、不让整个 Agent 断线。