Lab 07 · Agent 评测（对应 Part 9 进阶与避坑）
墨叔：老哥，前面 6 个 lab 你都在”造”。这最后一个 lab 教你”怎么知道它变好了”。不会评测的 agent 团队，等于蒙眼开车——你以为在加速，其实在撞墙。
这个 lab 在练什么
把 Part 9.1 的 offline eval 落成代码：
- 定义一组任务（输入 + 期望答案里的关键词）
- 逐个跑 agent，检查最终回答是否命中关键词 → 通过 / 失败
- 统计通过率，并对比”弱 prompt”和”强 prompt”两版
跑起来你会看到：V1（弱 system prompt）第三个任务失败，通过率 67%；V2（强制”先检索再答”）三个全过，通过率 100%。这就是把”玄学调参”变成”可度量迭代”。
怎么跑
python main.py你该看懂的几点
- 为什么单体测试救不了 agent。 它是概率程序——同样的输入两次可能走出不同轨迹（真实模型尤其明显）。所以评测要跑一批任务，看统计意义上的通过率，而不是”这一个 case 过了没”。
- 通过率只是最粗的指标。 Part 9.1 还讲了：步数（=成本/效率）、人工干预率、轨迹合理性（有没有走弯路）。本 lab 的
steps列就是效率信号——步数越多越贵越慢。 - eval 是迭代的仪表盘。 V1→V2 的提升不是靠”换个更聪明的模型”，是靠在 system prompt 里加一条约束。没有 eval，你根本不知道这条约束有没有用；有了 eval，每次改动都能量化。
- 常见反模式（Part 9.2）：过度工具化、无边界 system prompt、把 LLM 当数据库、忽略失败路径。本 lab 的 V1 就犯了一个——“检索类问题没要求先检索”，导致模型凭记忆瞎答漏了关键词。
思考题
【思考题】
- 本 lab 用”最终回答含关键词”判通过，这叫”字符串匹配 eval”。它的致命盲区是什么？（提示：答案可能恰好含关键词但其实答非所问）
- 真实生产里，除了通过率，你还想加哪几个指标？为什么？（至少说两个，呼应 Part 9.1）
- 如果 V2 通过率 100% 但步数比 V1 多一倍，你怎么判断”改得好还是改坏了”？这引出了 Part 9.3 说的什么趋势？
【参考答案】
- 字符串匹配只看”有没有这几个字”，不看”对不对”。模型完全可以输出”文档”二字但答非所问（比如”没有文档”）。更稳的做法是轨迹评估（看它走没走 search_docs 这一步）+ LLM-as-judge（让另一个模型评判答案质量）+ 人工抽检。Part 9.1 把”offline eval（跑成功率）“和”轨迹评估（看步骤合不合理）“分开讲，就是这个原因。
- 至少两个：(a) 人工干预率 / HITL 触发率——如果 agent 动不动就要人确认，说明它不自信或边界不清，生产里会拖垮体验；(b) 单任务成本（token 数 / 步数）——通过率高但每个任务烧 10 倍 token，成本不可接受；(c) 失败路径覆盖率——专门造一批”工具报错 / 输入非法”的用例，看 agent 会不会崩。这三个分别对应”敢不敢放""贵不贵""稳不稳”。
- 不能只看通过率。要做一个多目标权衡：通过率是”效果”，步数是”成本/延迟”。V2 通过率 100% 但步数翻倍，说明它更稳但更贵更慢——是否改进取决于业务：如果错误代价高（如改生产代码），多花步数换准确率值得；如果只是闲聊，步数翻倍就不可接受。这引出了 Part 9.3 的agentic 系统趋势：agent 不再追求”单次答对”，而是在”效果 / 成本 / 延迟 / 风险”的帕累托前沿上持续调优，用 eval 当导航仪。
全部 lab 到此结束
从 lab00 跑通第一个循环，到 lab06 造出能改 bug 的迷你 Claude Code，再到 lab07 学会评测它——你手里已经有了一套”心智模型 + 可运行零件 + 度量方法”。剩下的，是把这些零件按你自己的场景焊起来。去造吧。