使用 Inwit 精读《Agent 评测全览》

之前使用 Inwit 精读了很多文章一直没时间写个blog总结下，这次趁着国庆用美团技术团队的《Agent 评测白皮书》系列 01：Agent 评测全览这篇文章做一个Inwit 精读总结。这篇文章接着前一篇《Agent 评测漫谈》，讨论一个更具体的问题：项目里需要建哪些评测能力，当前阶段又该先做什么。

我觉得这篇适合精读，因为里面有不少容易混用的概念。离线评测和在线评测有什么区别，监控正常为什么还会交付错误结果，发现 Bad Case 后是不是都该改 Agent？只记住几个模块名称，遇到问题时还是不知道怎么判断。

Inwit 里的这篇文档我划线了 28 条批注、Agent推荐了 12 张复习卡。我把原文和章节脑图放在一起看，再把需要区分的概念做成题。

之前介绍 Inwit 时，我写过它与 MarginNote、Anki 的关系。这次阅读更能说明它适合处理哪类材料：篇幅长、概念之间有关系，而且读完之后还需要反复使用的技术文章。

对照原文理解概念

阅读页左边是原文，右边可以看脑图。禅模式收起文档列表后，这两部分可以同时留在屏幕上。当前这篇的 28 条批注主要来自章节标题，提供了一个浏览全文的索引。

这对区分概念有直接帮助。例如读到在线巡检时，可以回到离线回测的章节，比较它们的样本、运行环境和目的。笔记里的概括如果让人产生疑问，也能回到原文查看限定条件，不必只依赖那句被摘出来的结论。

脑图在这里主要用来找位置、查看结构。章节标题本身不能解释概念之间的关系，还需要结合正文理解。Inwit 也提供针对当前文档提问的侧栏，适合把阅读中没有弄懂的问题留在资料旁边，再对照原文核查回答。

把容易混淆的地方变成复习题

这篇的 12 张卡里，我觉得更适合复习的是对比题。例如：端到端评测和过程评测各自回答什么问题，只用其中一种会漏掉什么？在线评测和在线监控分别检查什么，能否举出调用成功但结果错误的例子？

这些题要求自己组织答案。读正文时，两段解释挨在一起，很容易觉得已经理解；拿掉解释后，能否说清各自的职责和限制，才比较容易暴露没想明白的地方。

挖空题则适合检查明确的判断。比如回测时固定哪些条件、负向 Case 除了修改 Agent 还需要检查什么、两条迭代路径共享什么。其他卡片覆盖了样本分类、监控维度、分层门禁等内容。

卡片进入复习队列后，翻面前先尝试回答，再按记忆情况反馈。Inwit 用 SM-2 安排后续间隔。这样读完文章之后，这些问题还会再次出现，不需要每次想复习时都从头翻整篇长文。

对我来说，Inwit 适合精读的原因就在这些衔接上：读到疑问时原文还在旁边，整理时能保留章节位置，需要记住的区别可以继续进入复习。只想快速了解一篇文章的大意时，做这些整理未必划算；准备以后在项目中用到它时，才值得花时间。

下面是这次阅读留下的笔记。

原文讲了什么

文章以商家经营分析 Agent 为例：它要调用多个 Skill，处理数据，最后交付一份分析结果或 PPT。这样的任务没有唯一的标准答案，中间步骤出错也未必会表现为调用失败。

作者把评测体系分成四个模块：

这些模块合起来，要能发现问题、定位问题，并验证修改是否有效。长期保留下来的是评测标准和样本：团队用什么标准判断质量，哪些结果已经达标，哪些错误不能再犯，还有哪些难题暂时做不到。

这套划分是作者为了讨论方便做的约定。Arize、Langfuse、Braintrust 等产品对在线评测、监控、观测的边界并不完全相同。放到自己的团队里，可以按分工调整，但每项职责都需要有人承担。

全文反复讨论的，是线上问题怎样影响下一轮修改。一个问题可能暴露 Agent 的缺陷，也可能说明评测标准不合理。两种情况要分别处理。

Bad Case 也可能说明评测有问题

这是我读完最想保留的提醒。

看到低分样本，很容易直接去改 Prompt、换模型，或者修 Skill。但如果 Agent 的做法合理，只是 Rubric 写得有偏，继续按这个分数优化，就会把合理的行为改掉。

这里的 Rubric 指具体的评分细则。比如“PPT 做得好不好”太笼统，可以拆成章节是否符合大纲、数据是否准确等可检查的项目。这样能减少不同评测者之间的分歧；至于这些检查项是否符合业务需要，仍然要另行验证。

原文因此区分了两条迭代路径：

• Agent 有问题，就修改 Prompt、Skill、上下文管理或模型，回测后再上线观察。
• 评测有问题，就补充漏掉的场景，或修改 Metrics 和 Rubric，让评测更符合真实需求。

两条路径共享线上样本，也共享评测集。新发现的问题补进评测集后，后续版本就能检查是否再次出错。如果 Case 只在工单里修掉，没有更新评测集，下次换模型或改 Prompt 时仍可能重犯。

评测标准还有一个时间上的问题。用户群体、业务目标、Agent 功能变了，原来的样本和标准可能已经不再合适。除了让不同的人、人与机器对同一个样本给出尽量一致的判断，还要定期检查：现在测的这些东西，是否仍然代表用户的需求。

离线评测为什么需要控制环境

离线回测比较的是版本变更前后的表现。因此样本、评价标准和执行环境都应固定，尽量只让 Agent 版本变化。

环境这一项很容易被忽略。测试环境的下游数据与生产不一致，或者沙箱里没有用户的历史文件，都会让 Agent 拿不到原本应该有的上下文。这时离线分数低，未必说明新版本退化；离线分数高，也不能保证线上效果。

原文给了一个可以直接用的检查办法：拿同一批样本，分别在离线环境和线上影子流量里跑，比较两边的结论。差异大时，要检查环境保真度。

评测集里的每个 Task 包含问题、参考答案和评价标准。文章借用了 Anthropic《Demystifying evals for AI agents》对 Task 的定义，即具有明确输入和成功标准的单个测试。

对问答任务，参考答案可能是一个可核对的事实；对长程 Agent，它还需要描述预期行为和最终状态。交付 PPT 的任务，要看交付物是否符合要求，也要检查相关执行过程。把最终回复写得像成功了，不能作为完成任务的依据。

端到端评测和过程评测分别检查什么

端到端评测从用户角度看交付结果。底下调用了几个 Skill、用了几个子 Agent，不改变这个视角。

原文举的例子是：100 个任务里，有 68 个交付了可用的 PPT。后来变成 55 个，这能说明整体效果下降，却不能直接解释原因。

过程评测用来进一步定位。如果投放数据 Skill 的调用成功率从 95% 掉到 70%，就有了排查方向。如果调用成功率没变，数据合并正确率却下降，就要查另一个环节。若过程指标都没变，最终交付率仍然下降，说明现有指标还没覆盖到问题，需要继续查 Trace，并补充评测。

只看过程，也会漏掉整体质量：每个模块各自达标，拼起来的结果仍可能无法满足用户。所以两类评测都需要。功能增加后，还可以按用户可见的功能分别建端到端评测集，例如门店经营分析和门店百科；过程评测再细分到知识库、Skill 或子 Agent。

拆分不必一步到位。先有端到端和核心模块的过程评测，等到现有数据解释不了问题时，再补更细的检查。这样每多建一层，都有明确的排查需求。

回测怎样影响发布

模型输出有随机性，同一个 Task 需要多次运行，不能凭一次通过就认定稳定。不同类型的检查也不宜混成一个总分：安全、数据准确性等检查可以设为必过项，体验类和加分项再设置阈值。检查结果还要接进 CI/CD 或发布流程，才能实际约束发布。

离线评测能验证的范围受样本限制。评测集一直在测制作 PPT，用户却开始大量要求对比三家门店的数据，原来的分数就解释不了新需求。这也是上线后仍然需要评测的原因。

在线监控正常，结果也可能不合格

原文有个直观的例子：Skill 调用成功率是 100%，返回的数据却是错的。监控没有报错，交付质量仍然不合格。

在线监控主要记录系统的运行情况，包括成功率、超时率、Token 消耗、任务步数和耗时。任务类型分布、Skill 调用频次、平均对话轮次也值得看，它们可能反映用户需求发生了变化。

在线评测则检查真实环境中的任务效果。文章介绍的几种方式，各有使用条件：

巡检同时具有评测和监控的用途：判断任务质量，也记录分数变化和失败样本。起步时可以从离线评测集抽一批代表性任务，之后按需要单独维护巡检集。

把这些数据放在一起，才能缩小排查范围。原文比较了两种情况：任务完成率下降 5 个百分点，同时某个 Skill 的失败率从 2% 涨到 15%，应优先查工程问题；如果 Skill 运行正常，但数据对比类任务占比从 10% 涨到 35%，则需要检查 Agent 是否能应对新的任务分布。

怎样收集 Case，以及修完后留下什么

Case 来源不同，能发现的问题也不同。用户反馈接近真实感受，但主动反馈的人只占一部分；监控和巡检能自动收集异常，却依赖已有指标；业务规则适合筛选资金、优惠券配置、批量修改等已知需要重点复核的任务。

原文还强调随机抽样，例如每周随机抽 50 条真实会话复核。它的成本高，发现问题的比例可能低，但可以减少只盯着投诉和既有规则的偏差，给尚未想到的问题一个被发现的机会。

收集完还要分类使用：

黄金集值得单独注意。只有错误样本，团队仍然可能对“做到什么程度算好”意见不一。保留具体的好样本，讨论标准时就有东西可以对照。

这些分类与端到端、过程评测是两个维度。一个 Skill 的过程评测集里，同样可以有黄金样本和必过项。

归因需要查看执行记录。意图理解错了，可能要改 Prompt 或追问策略；路由错了，可能要改 Skill 描述；工具执行出错，要查实现和参数；长任务丢掉了最初的约束，要查上下文压缩。知识口径错误与模型能力不足，也需要分别处理。若问题来自评分标准，则应由评测负责人调整 Rubric。

这些方向不能只凭最终回复来判断。至少要留下完整的模型调用输入输出和 Skill 调用记录，才能还原失败发生在哪一步。原文称之为“最小可归因”。后续发现某个判断缺少数据时，再补相应埋点和检索能力。

冷启动阶段先做到什么程度

文章虽然画了完整的体系图，但没有要求每个项目一开始就建齐。冷启动阶段先做到：

• 有完整 Trace，可以人工回放一个失败案例。
• 有一份端到端种子评测集，并持续维护。
• 发版前用这份集手工回测一次。

在文末 L0 到 L3 的成熟度表里，这对应观测、评测集和回测门禁的 L1。扩量后重点补评测标准和在线评测，推到 L2，少量指标到 L3；全量运营时再考虑更大范围的自动化。

我更愿意用这张表检查具体缺口。只有离线集，容易出现分数上涨、投诉不降；只有线上反馈，修复后又缺少回归保障。还有一种情况不太显眼：离线集和监控看板都有，但线上 Case 没人归因，也进不了评测集。此时继续增加报表，很难解决问题反复出现的情况。

FAQ 还解释了为什么不要求 Agent 每次发布的离线分数都高于上一版。必过集主要保障核心功能，挑战集又可能跟不上业务变化。作者更看重线上 AB 中的业务指标。这里的前提仍然是保证已知问题得到处理；如果维护挑战集，也要随真实任务分布更新。