Agent 质量怎么测：样本集、评审与影子运行

Agent 更新了一版提示词，退款邮件识别得更准，普通订阅邮件却开始被乱标成紧急。总体准确率仍有 96%，测试集上的精确率和召回率都有 97%，问题出在哪？

原文用虚构邮件助手 Mailmind 说明：评估 Agent，得同时检查答案、执行过程和真实流量表现。它提出的组合是黄金数据集、模型评审和影子模式。对正在把 AI 接进业务的程序员，这套方法最有用的地方，是把「感觉变好了」变成可以讨论的上线依据。

同一道题答得不同，该怎么测

传统单测习惯断言一个固定答案，但 Agent 面对相同邮件，可能 90% 的运行判断为紧急，另外 10% 判断为普通。作者建议重复运行同一案例，记录通过率，再确定业务能接受的范围。

这不代表所有检查都要变成概率。日期解析、输出格式、工具权限仍可以严格断言；需要容忍变化的是合理措辞、判断路径等部分。

原文把指标分成六个方向：

• 正确性：用 precision 看标出的紧急邮件有多少确实紧急，用 recall 看真正紧急的邮件漏了多少，F1 用来平衡两者。
• 完整性：会议时间、退款金额、物流单号等字段有没有漏。
• 一致性：相同输入重复运行，结果变化是否超出允许范围。
• 性能：例如处理一批 20 封邮件的 p95 延迟，以及每封邮件的美元成本。
• 可靠性：工具调用失败、输出格式错误、执行循环卡住的频率。
• 安全性：提示注入、越权工具调用和个人身份信息泄露。

p95 表示 95% 的批次完成得比这个时间更快。它能暴露平均耗时掩盖的慢请求。安全指标也要看具体事件，拦住攻击和误拦正常请求，需要分别解释。

总体分数只能提供概况，分类指标才能帮助定位谁受到了影响。

开头的例子中，提示词可能把带金额的内容都当成退款信号，连提到「价值 $10 的免运费」的订阅邮件也被命中。只看整体准确率，这类局部退化很容易藏起来。

黄金数据集要覆盖哪些麻烦

黄金数据集是经过专家确认的输入、正确输出和允许变化范围。Mailmind 的设定从 100 个匿名化真实收件箱快照开始，由两名标注者独立判断，再由第三名评审处理分歧。

它既要反映真实分布，也要覆盖低频难题。例如原始邮件里 90% 是普通订阅内容，评估不能忽略它们；缺订单号的退款、时间含糊的邀请、伪装紧急的垃圾邮件，也要有足够样本。

样本够不够，要看你希望识别多小的变化。原文给出的近似值是：某类别有 100 个样本，测得 90% 时，95% 置信区间约为 84%～96%；增加到 400 个，约为 87%～93%。想发现召回率下降 3 个百分点，100 个样本显然吃力，400 个也只是更接近要求，比较两个版本还需要更多证据。

数据集还应旁挂对抗样本，包括攻击邮件、畸形输入和超长线程。这里的通过条件可以很硬：没有禁止的工具调用，没有数据泄露，无法处理时正确拒绝或转交。

用户报告的漏判、新增的业务类别，都要匿名化、复核后补进数据集。否则测试长期全绿，只能证明系统还擅长旧题。

更进一步，Agent 案例还要保存预期执行过程。退款任务可以要求先查订单、再查退款政策、最后起草回复，并禁止调用 send_email。评估分别检查工具选择、参数、迭代步数，以及是否完成任务或正确转交。合理的步骤顺序可以灵活，禁止发送邮件的边界必须严格。

模型当裁判，谁来检查裁判

LLM-as-judge 是让另一个模型按照评分规则评审输出。例如提取会议时间时，把原邮件、提取值和时区判断要求一起交给裁判，输出「完全正确、部分正确、错误」等结构化结果。

裁判也会犯错。原文建议让人工与模型共同评审 200 个黄金案例，再把「模型与人的一致程度」和「人与人的一致程度」比较，而且要按标签分别统计。

作者引用 Zheng 等人在 2023 年的研究：较强裁判与人类偏好的一致率超过 80%，接近人类之间的一致水平。这支持用模型扩大评审规模，但不能证明你选的裁判也达到了这个水平。

尤其要防止它被漂亮文案骗过。回复很礼貌，退款日期却写错，评分规则应重罚事实错误。原文还提出三种偏差及处理方式：交换候选答案顺序，检查结论是否一致；明确要求忽略篇幅优势；尽量选择与被评 Agent 不同模型家族的裁判。

有确定标签的分类任务，可以直接计算指标；事实核对、表达质量和复杂执行轨迹，再交给裁判辅助判断。人工则负责初始标注、每周随机抽查生产输出，以及处理裁判无法确定的案例。

通过离线测试，为什么还要影子运行

原文把评估拆成五道关卡。下面的流程说明变更如何逐步接近真实环境：

graph TD
  A[Unit tests] --> B[Integration baseline]
  B --> C[Regression check on every change]
  C --> D[Shadow mode]
  D --> E[Production monitoring]

注意 C --> D：回归检查通过后，才进入真实流量验证。上线之后，监控仍要继续。

单元阶段检查工具和独立功能；集成阶段跑完整 Agent，建立各类别基线；回归阶段在提示词、工具或阈值变化时重跑。例如 300 个案例交给 10 个 worker 并行执行，作者认为可以在几分钟内完成，但没有给出实测配置。

原文用一组假设结果说明取舍：退款召回率从 88% 升到 94%，普通订阅邮件相关的精确率却从 97% 降到 91%。这类变化应在合并前被看见，而不是被一个总分抵消。

影子模式让新旧 Agent 同时处理生产输入，新版本只记录结果，不向用户展示。作者建议运行约一周，覆盖工作日和周末，同时观察真实负载下的延迟与成本。

影子模式必须拦住写操作，否则它仍会产生真实业务影响。

读取工具可以访问真实数据，发送、归档、修改日历等写入工具则要替换成记录器。离线回放也类似：读工具返回录制数据，写工具只记录尝试执行的动作。

新旧输出不能按字符串是否相同评分，也不能把两者一致当成正确。应该结合邮件上下文分别评分，再看分差分布。全面镜像大致会让这段时间的模型账单翻倍，也可以只抽样流量。

我的判断

这套框架最值得采纳的是：把数据、答案、执行过程和上线流量放进同一条评估链路。尤其对能调用工具的 Agent，最终回复写得对，不能抵消过程中的越权行为。

但 Mailmind 是虚构案例。90% 的通过率、300 个案例的回归、约一周的影子运行，都是说明性设定，没有团队实测对照。不能据此承诺评估耗时或事故下降幅度。影子运行多久，也应由业务周期、流量和风险决定。

还有一个统计前提：重复运行同一道题有助于观察波动，却不能代替新增独立案例。对难例过采样能提高排错能力，但汇总结果时需要交代样本比例，否则也会误读线上表现。

原文以 2026 年 10 月为时间点，列出 LangSmith、Langfuse、Arize Phoenix、Braintrust 和 Promptfoo。文中称 Langfuse 自 2026 年 1 月起属于 ClickHouse，核心保持 MIT 许可；Phoenix 支持自托管，追踪基于 OpenTelemetry。这些是原文提供的产品信息，不是横向实测结论，选型仍要检查实际能力与成本。

能拿来做什么

• 给现有 Node Agent 保存一批经过人工确认的输入，按业务类别分别记录 precision、recall 和误报率，再对容易波动的案例重复运行，避免只看平均分。
• 把工具调用轨迹纳入回归检查，对工具名、订单号、金额和禁止写操作做确定性校验；对允许多种合理路径的部分，再引入模型评审。
• 修改提示词后，同时比较收益类别和可能受损的类别。遇到订阅邮件被误判的情况，先回滚，再补充含金额的普通邮件样本，定位导致过度敏感的指令或示例。
• 为涉及决策、工具调用和用户可见输出的变更接入影子运行，先替换全部写工具，再比较质量、p95 延迟和成本；上线后持续监控分类指标及人工复核率。