建设 Harness 轨迹分析工具以后，我改掉了几个想当然

开始建设 Harness 轨迹分析工具时，我以为最难的部分会是评分：先定义一套标准，再让模型或人工给结果打分，最后做成一个排行榜。真正做下去才发现，分数只是入口。它能够告诉我哪些任务出了问题，却很少告诉我问题为什么发生，更不能直接告诉我应该改模型、改提示词，还是改工具。

这里说的 Harness，不只是把模型包起来的一层调用代码。系统提示、工具说明、工具实现、上下文压缩、中间件、技能配置和子 Agent 的协作方式，都会影响同一个模型最后做出什么。模型固定不变，只要调整其中一个环节，结果就可能明显不同。如果分析时把这些东西混在一起，最后得到的往往只是“这个模型不行”或者“那个模型更强”之类过于粗糙的结论。

我在一组 250 个用例的轨迹里见过几种很有代表性的失败。一个模型反复读取同一批文件，调用次数已经多到没有新增信息，却仍然停不下来，最后把上下文推到容量边缘；另一个模型在执行中出现了一次空的 assistant 消息，整个任务因此失去后续动作；还有一些任务的最终答案看上去没有大错，但回看过程才发现，它早就漏掉了用户给出的关键限制，只是碰巧得到了一个还能接受的结果。如果只看最后一屏文字，这些差别几乎都会被抹平。

这使我改掉了第一个想当然：评分不等于诊断。一个 70 分和另一个 70 分，背后可能是完全不同的问题。前者也许理解正确，只是最后少做了一项验证；后者也许从第三步开始就走偏，靠措辞完整保住了表面质量。两者需要的改法完全不同。轨迹分析工具必须能够把任务拆到具体步骤，保留工具调用、返回结果、上下文变化和停止原因，评分才有解释力。

第二个变化是，我不再认为“保存全部日志”就等于可观测。原始轨迹很容易达到几十万甚至上百万字。信息都在，但人无法有效阅读，模型也会在重复内容中失去重点。真正有用的工具需要做分层：底层保留原始记录，便于追责和复现；中间层把重复调用、错误、关键决策和上下文异常整理成证据；上层再给出面向一次改动的结论。压缩不能只追求短，还要保证每个判断都能回到原始步骤验证。

第三个变化与工具建设本身有关。早期很容易不断加功能，仿佛支持的模型越多、图表越丰富，工具就越成熟。后来我更看重一条完整的证据链：某个问题在哪些用例中出现，我准备修改哪个 Harness 组件，我预计它会改善什么，又可能伤害什么，下一轮用什么指标验证。如果结果不符合预期，能不能快速回退。只有把这条链走通，工具才不只是一个结果展示页，而是能够帮助工程师作决定的工作台。

这项工作也改变了我看待模型能力的方式。模型更新很快，今天领先的版本，几个月后可能就被新的版本替代；但如何观察过程、如何区分偶然成功与稳定能力、如何让一次失败变成可复用的经验，这些问题不会随版本升级自动消失。它们需要长期积累，而且越早建立统一的记录方式，后面的比较越可靠。

到了这个阶段，我对“再接入一个更强模型”仍然有兴趣，但不会像以前那样把它当成答案。一个系统是否值得信任，最终取决于我们能不能解释它做过什么，能不能找到失败发生的位置，也能不能证明一次修改真的让它变好了。建设 Harness 轨迹分析能力带给我最大的心得，就是把注意力从结果的热闹，移回到过程的证据上。