前两天晚上和一位同事单聊，他发来一篇自己刚写的内部总结。里面讲的是最近很多人都会碰到的一个麻烦。我们自己电脑上的主 Agent 用久了以后，磨合得非常顺手，这时候往往会想分拆一部分能力出来，单独做个服务给团队用，或者放进业务群里帮忙答疑。这种小工具搭个架子很快，但是一旦真的放到群里运行，交出来的东西总是差点意思。为了让它好用一点，我们又只能自己守在窗口前面，一遍遍测试和修改提示词。同事在文章里提出了一个办法，就是不要自己亲手去教，而是把这个新 Agent 交给平时用熟了的主 Agent，让主 Agent 带着它练，等练成熟了再放出去干活。
我看完非常有共鸣，顺口回了他一句调侃：培养出来嫡系，就让嫡系带团队！ 在真实的团队管理里面，搞山头和搞嫡系当然不是什么好事。我当时开这个玩笑，心里想的其实是团队里最知根知底，也最明白你意图的骨干。带过团队的人都知道，一个人的管理精力很快就会见顶，队伍变大以后，你不可能亲手去带每一个新人。要想把事情铺开而且不走样，只能先带出几个配合默契的团队骨干。他们知道你的要求在哪里，也明白你的判断标准是什么，由他们去带业务和带新人，你只需要在关键的地方把关拍板就可以。
往外分拆 Agent 面临的也是同一个管理问题。如果我们想分出一批 Agent 对外提供服务，要如何保证它们做决定的时候还带着我们的判断标准呢？最省力的方法，其实就是把带新人的工作交给平时最了解我们意图的主 Agent。我们可以让两个 Agent 之间直接沟通，这样就能避开人在中间传话带来的信息走样和背景遗漏，然后再让主 Agent 出题测试它，通过跑评测的方法把它一点点训练出来。
污染和缺失，往往出在人身上
手头的主 Agent 之所以好用，并不完全是因为底层的模型有多聪明。它平时陪着我们处理了大量的日常工作，已经积累了很多隐性的背景。比如我们在哪些细节上要求很严，讨厌什么样的套话，或者以前在哪类问题上纠正过它。这些分寸感平时不会写进任何说明文档里，都是在实际对话里面一点点积累下来的。
等到我们要把能力分拆出去做成一个独立服务的时候，写代码本身并不复杂，麻烦的地方是如何给这个新 Agent 提供合适的背景信息。如果直接把所有历史记录都塞给它，我们个人的习惯和很多不适合公开的内部资料就会混进去，带来上下文污染。但是如果给的信息太少，只写几条简单的规则说明，平时积累下来的判断标准又会丢掉，跑起来就像一个普通的客服机器人，形成背景缺失。同事在文章里面也专门提到，新服务的底层权限必须和私人数据隔开，如果只是在提示词里面写一句不要对外泄露，是没有办法解决问题的。
以前碰到这个矛盾，大家往往会习惯性地自己去做信息搬运。屏幕上面同时开着主 Agent 和新 Agent 两个窗口，人在中间来回切换。看到新 Agent 回答偏了，我们就自己总结两句加进规则里面。如果发现它听不懂业务上的简称，我们又会从自己这边复制一大段背景贴过去。这样来回折腾几次以后就会发现，很多上下文的污染和缺失，其实都是人夹在中间搬运信息造成的。
因为人去传话的话，很容易省掉步骤或者改变原意。嫌麻烦就会随手删掉重要的前提，赶时间又会把带着私人信息的大段记录直接贴过去。而且我们自己总结出来的修改意见，往往已经加进了自己的猜测，新 Agent 看到的只是我们以为它犯的错，并没有看到真实的原始现场。我之前在《当碳基生命在削减中层的时候，硅基生命却在增加中层》里面讨论过这个问题，信息每多传递一层，就一定会经历一次压缩和变形。如果人非要卡在两个 Agent 中间传话，自己就会变成信息损耗最大的那一层。
如果把中间传话的人去掉，让主 Agent 和新 Agent 直接对话，这个问题就很容易解决了。主 Agent 可以查看新 Agent 的完整执行记录，对照原始材料逐条检查，发现哪一步走偏了就可以让它重做。同事在文章里记录过一个例子，有个新 Agent 看到群里另一个机器人回复了一句“已经记下了”，就自己判断这件事已经有同事接手处理。这种细微的理解偏差，如果让人在中间口头转述，来回几次也很难说清楚，但是主 Agent 翻一下原始聊天记录就能发现问题所在。而且给新服务准备背景规则的时候，到底哪些经验可以提炼成公共规则，哪些私人信息必须留在本机，本来就是主 Agent 最清楚的事情。它里面有和你长期积累下来的完整上下文，整理起来比人凭着记忆去挑要准确得多。这就好比让团队骨干去带新人，不需要负责人站在两个人中间来回传话。
带新 Agent，本质上是在做评测
同事在文章里把这个做法叫作 Coach，意思是老带新。我看完他的具体操作以后，觉得这个流程之所以有效，核心还是因为用了工程上的评测方法。我们需要准备一批真实的业务题目交给新 Agent，然后让主 Agent 在旁边观察它的完成情况，看看最终输出的结果和我们的预期差了多少。
我们自己手动调整 Agent 的时候，经常会做一件效率很低的事。改完两行提示词以后，顺手问它一句理解了没有，看它回答得很有条理，然后再用刚才出错的例子重新跑一遍，看到跑通了就觉得已经改好了。同事在总结里专门提醒过这个问题，模型嘴上说“我明白了”没有任何意义，只用刚改过的错题去验证也说明不了问题。要想知道它是不是真的学会了，必须留出一批没有见过的新题目，打开一个全新的会话去测试。
分拆出去的 Agent 最终是要在没有人在场的情况下，替我们做出接近一致的判断。衡量它合不合格，唯一的标准就是处理问题的方式像不像你。在我们手头所有的工具里面，没有谁比天天配合你的主 Agent 更适合担任这个评委了。
而且测试一旦运行起来，暴露出来的往往不只是新 Agent 的问题，有时候主 Agent 自己理解偏差的地方也会一起显现出来。同事在实验里就碰到过一次这样的情况。当时群里进来一条消息，主 Agent 觉得应该马上跟进处理，但是同事看了一眼上下文，认为这条消息本来是问另一位同事的，应该先等对方回复。可以看到，一旦主 Agent 和我们的判断出现分歧，就是需要人出面拍板的时候了。
平时带团队做一对一沟通的时候，我一直有个习惯，就是少问下属这周干了什么，多问他是如何理解手头这件事的。放到 AI 上面，跑评测做的也是同一件事。我们不需要听它在对话框里如何表态，而是用真实的业务题目去测试，看它具体如何处理。这样我们也可以从盯着每一轮对话的体力活里面退出来，只需要挑出有分歧的样本，明确告诉它碰到类似情况应该按照什么标准处理就可以。
评测是老道理，变的是谁来干活
用评测代替手动调优这个思路，让我想到前段时间在微信群里面看到一位朋友鸭哥分享过一个去除 AI 味道的开源工具，后来我还专门去他的 GitHub 仓库里面看了一遍实现过程。给文章去除 AI 味道，大家一直觉得是很难量化的事情。当时群里很多人都在讨论，觉得这个东西全凭语感，很难给它下定义或者打分。但是鸭哥用了一套非常标准的评测方法把它做出来了。他用自己以前写的博客文章做语料，先留出一部分不参与训练的段落作为测试集。开始微调模型以前，他先用提示词加上几段原文例子的方法做了一组基础对比，因为微调的效果如果不能比写提示词更好，那就没有必要做了。等到最后验收的时候，脚本会自动生成一个盲测网页，把模型改写的 20 个段落和原文混在一起让他分辨。结果那 20 段模型改写出来的文字里面，有 16 段让他认成了自己写的原文。
在这个实验里面，最触动我的地方其实是人在整个流程里需要亲自做的事情已经非常少了。看他在仓库文档里记录的步骤，从头到尾需要人介入的地方只有四处，就是圈定哪些旧文章是自己写的，确定要改写的目标文章类型，协调一块训练用的显卡，然后最后坐下来做完那套盲测题。至于中间最繁琐的准备工作，比如切分语料、构造训练样本、跑对比测试和检查模型有没有训练过头，一直到生成最后的盲测网页，全部都是由 AI 自己完成的。
通过建评测集来保证质量，这个道理大家很早就知道。我自己在《真正该越积越厚的不是 Prompt，是 Eval》里面也写过，提示词只是和眼前这一代模型签的短期合同，评测集才是和未来的自己签的长期合同。虽然道理都懂，但是平时真正做项目的时候，大多数人碰到问题还是会退回去手动改提示词。
大家之所以知行不一，主要是因为以前建评测集和跑评测的人工成本太高了。我们需要自己去翻历史记录找样本，自己整理正反例和编写评测脚本，跑完以后还要人工一条条核对输出。如果是大团队做核心产品，还可以专门投入人力去做这件事。但如果只是个人想调整一下文章的文风，或者给团队分拆一个答疑小助手，光搭建评测环境这一步就足够把人劝退了。现在这个情况完全变了。以前最花时间的准备工作，AI 已经可以接过去大半，普通人随手拉起一套评测的门槛已经低到了日常随时可用的程度。
如果我们把同事带新 Agent 和鸭哥训练文风模型这两件事放在一起看，可以发现它们背后用到的其实是同一种个人积累。鸭哥之所以可以把这套盲测跑起来，是因为有他过去几年写下来的博客文章。主 Agent 之所以可以替我们指导和评测新 Agent，是因为有它平时陪我们工作积累下来的对话和纠偏记录。这些过去留下来的日常记录，以前最多只能算是一堆历史档案，偶尔翻出来参考一下。现在有了 AI 的帮助，它们几乎不需要什么额外成本，就可以变成现成的测试题和评判标准，用来训练下一个替我们干活的分身。
重新排一下人和 Agent 的位置
现在很多重度使用 AI 的人，手头其实都已经养出了一个非常懂自己的主 Agent。比较可惜的是，每次想往外分拆一个独立服务给别人用，大家还是习惯把这位老搭档放在一边，自己重新从头开始当传话筒和测试员。人一旦陷进这种重复的体力活里面，耐心很快就会耗尽，最后勉强凑合出来的 Agent，处理起问题来自然也很难让人满意。
更合理的分工方式，是把我们自己的精力收回到源头和终点。平时我们可以多花一点心思用好身边的主 Agent，让它在实际工作里面充分理解我们的背景和判断标准。等到需要往外分拆新服务的时候，我们只需要定义好什么结果才算合格，然后在主 Agent 拿不准的分歧点上做最终决定就可以。至于中间如何裁剪上下文，还有如何出题测试和督促新 Agent 修改，完全可以交给最懂我们意图的主 Agent 去完成。
过去大家经常说，要想让 AI 干活可靠，就需要让人一直留在操作流程里面。但是如果我们的个人能力开始通过一批 Agent 往外延伸的话，人最不需要待的地方，其实就是两边传话和逐条跑测试的这个执行回路。人留在标准里就好，让你的“嫡系”留在回路里。