看得见才改得好：日志、评测与闭环

先看出事的那一刻

2026 年 7 月 26 日，AI 导师接上第三方模型，跑了一遍冒烟测试：五项检查全部失败，报错是 401。

第 11 课讲过它的原因：运行环境里一个同名的变量，悄悄盖掉了配置文件。这节课看的是另一面：这一次，前后不到两分钟就找到了原因。靠的是两样提前准备好的东西：

1. 一组冒烟测试，第一时间告诉你"坏了"；
2. 启动时打印实际生效的配置：请求发往哪个地址、用哪个模型。日志里写着请求发往官方地址，而不是配置文件里的第三方端点，这就告诉你"坏在哪"。

再加上加载配置的那个库，自己打出一行提示，说只注入了 2 个变量，而文件里写的是 3 个，原因一下就对上了。

要是没有这两样，看到的多半只有一句"密钥不对"，排查很可能要从重新复制密钥开始。

这节课要回答的是：Agent 上线以后，怎么知道它哪里答得不好？改了之后，怎么确认是真的变好了？

装备几个词

为什么要懂

日志：记下实际发生了什么

Agent 的日志，至少要回答三个问题：

几条从这个项目里学到的记法：

• 好坏都收：只收 👎，就分不清没点的回答是"答得好"还是"懒得点"，算不出质量。
• 删除只做标记：用户删掉的对话，往往正是答得差的那些。真删了，最该分析的样本也一起没了。
• 同一个数字，只用一个来源：界面上的用时，用前端自己的计时；SDK 报的用时只在结束时才到，两个来源混着用，数字会在收尾时突然一跳，看着像 bug。SDK 报的耗时和用量照样存下来，只用来分析，不显示。
• 记到能直接定位原因：被点了 👎 的、拒答了的回答，进了待处理清单，会被标上原因。搜了却一个文件都没读到，标"缺文档"，该补资料；读到了文件却还是拒答，标"可能是提示词"，该查提示词。

评测：先有标准答案

知识库 Agent 在写代码之前，先写好了 25 道评测题：15 道正样本，答案在资料里，必须答出来，还要标对出处；10 道负样本，资料里没有，必须拒答。通过标准是正样本 90% 以上、负样本全部拒答。以后每次换模型，都要重跑一遍。

题出错了，评测会骗人。这个项目踩过两次：

• 第一次实跑，三道负样本的内容其实就在资料里：资料里收的是论文全文的译文，比当初盘点用的摘要丰富得多。模型照着原文答对了，反而被判成"泄漏"。
• 两天后再查，10 道负样本里有 6 道的主题，资料里都提到过。这些题测的不是"会不会拒答"，而是"这一次挖得够不够深"，同一道题会在通过和失败之间来回跳。

所以后来立了一条规矩：写负样本之前，先在资料全文里搜这个词，一处都搜不到才入库。

判定方式也改过一次。第一版草稿把要点写成了整句，可模型每次措辞都不同，整句比对注定失败；写判定程序时就改成了"必须命中的几个要点"，每个要点还允许几种写法，比如"截断"或"truncated"出现一个就算。

闭环：反馈要变成下一次的考题

只把问题列出来，清单只会越来越长，下周再看，分不清哪些是新的、哪些跟进过。知识库 Agent 后来把处理一条 👎 定成四步：

1. 写标准答案：维护者写下给用户的正式答复，再列出"必须命中的要点"，一行一个。一个要点都不填，就不让提交：没有判定依据的考题永远会通过，比没有还糟。
2. 改：按清单上的原因，补资料或者调提示词。
3. 验证：把这道题拿去跑评测；想用肉眼看，就开一个新会话重问。接着旧对话问，会带上之前的上下文，验的就不是改动本身了。
4. 标记已处理：评测跑通了，再手动标记，这一条才从清单上消失。

这个流程的起点，是站长自己的一句话：给用户的正式答复，就应该拿来当测试集。AI 第一次还理解偏了，把正式答案直接写进了资料；站长指出本意是拿它当测试的标准，这才撤掉，改成现在的做法。第一次跑，两道题过了一道；没过的那道漏了"轨迹发散"这个要点，说明它还没修好。评测如实指出这一点，正是它该做的事。

本站自己也在用同一个办法：快测题曾经能靠"挑最长的选项"猜对，修好之后，正确选项比最长的错误选项长一半以上就构建失败，这条规则写进了构建检查；自动驾驶分区去掉课件代号之后，正文里再出现代号，构建就直接失败。一次判断，写成一条自动检查，下次就不用再靠人记得。

找茬

 1  # 知识库 Agent 的第一版评测题（eval/cases.yaml，7 月 19 日，节选）
 2  # 所有 expect_points 关键事实已于 2026-07-19 逐条 grep 语料核验
 3  
 4  - id: pos-01
 5    question: DiffusionDrive 为什么要做 truncated diffusion？效果如何？
 6    expect_points:
 7      - 截断扩散减少去噪步数（相比原始 diffusion policy 减少 10 倍，仅用 2 步）
 8  
 9  - id: neg-02
10    question: MOTR 的 QIM（Query Interaction Module）训练策略具体是怎么设计的？
11    note: 边界题——语料有 MOTR 译文和导读，但只到"解决什么问题"层面，QIM 训练细节未展开；若模型用译文泛泛作答不算通过，需人工复核本条判定
12  
13  - id: neg-08
14    question: DPO 和 RLHF 相比有什么优势？
15    note: TrajHF 只讲 RLHF（reward model 路线），DPO 语料完全未提

快测

判断时刻

带走