传统软件有单元测试：给定输入，断言输出。AI 不行。
同一个提示词，两次运行返回的文本不会一模一样；几个完全不同的回答，可能都是对的。字符串断言在这种场景下直接失效。
于是出现了一种妥协：靠人工逐条看。自己测几条、觉得不错就上线。这套做法有几个代价，而且是连锁的——
- 自测样本太小：真实用户的输入你根本没测过，上线即踩雷；
- 人工不可规模化：人无法穷举组合，也进不了 CI 流水线，回归问题抓不住；
- 修一处崩一处：改提示词优化语气，结果模型开始编造内容，要等投诉才知道。
结果就是：你连换个模型都不敢。效果到底变好还是变差，只能靠几周的人工测试，还说不清楚。
要把这件事做成工程，有两个概念必须分清。
追踪链路（Traces），就是 AI 应用的日志。每一次智能体调用、每一次工具调用、每一轮大模型请求的输入输出，都以树形结构记下来，还包括耗时、token 用量和元数据。它回答的问题是：刚才到底发生了什么。
评估（Evals），就是 AI 场景的单元测试。给定输入，检查输出是否达标，只不过判定方式从「断言相等」变成了「分数 + 标签」。它回答的问题是：做得好不好。
一句话：链路告诉你发生了什么，评估告诉你做得好不好。
有了这两样，三件事会从玄学变成工程：换模型可以跑一遍评估套件、几小时出结论；改提示词有分数和失败理由支撑；每次改动重跑数据集，立刻知道有没有把原有能力弄坏。
做评估容易犯的错，是以为有一种方法能解决所有问题。实际上有三类，各管一段：
- 代码评估：确定性的函数校验，毫秒级、零成本、可复现。适合格式合法、长度限制、必填字段、关键词这类硬性规则。短板是僵化——措辞不同但意思正确的回答，可能被判失败。
- 大模型裁判：让另一个大模型对照评分标准（rubric）打分，擅长语义判断，比如内容是否正确、是否忠于原始素材。短板是它也会犯错，而且有调用成本。
- 人工评估：懂业务的人阅读打分，是质量的黄金标准。短板是慢、贵、人会疲劳。
关键不是选哪一种，而是让它们叠起来用。
这里有个很贴切的比喻：瑞士奶酪模型。每一层评估都像一片奶酪，各自有漏洞，但多层叠加之后，漏洞不会完全对齐。质量来自组合，而不是来自某个不出错的评估器。
顺便说一句，裁判本身也需要被评估。它有位置偏见、长度偏见，偏爱更长或语气更笃定的回答；还可能对同厂商模型生成的内容更宽容。所以做设计时，业务场景一般优先保召回率——宁可误报，不要漏报严重故障。
一次普通的大模型调用，输入输出就一步。智能体不是：它要连续调工具、多轮决策，误差会层层放大。
有个案例很典型：用户想查某家公司，智能体上网搜索，结果搜到了同名的历史人物，结果交付了一份排版精美、内容整体跑偏的报告。每一步工具调用都没有报错，但整体答非所问——只看最终输出的评估，根本抓不住这种问题。
还有一种反向的坑：评估写得死板，会惩罚对的解法。有测试要求改签一张不可改签的机票，智能体先升舱、再改签，成功达成目标，却因为不符合预设路径被判失败。
所以评估的原则是：评判产出物，不评判执行步骤。不要强行规定「必须先调 A 再调 B」，智能体经常会想出设计者没预料到的有效路径。
下面这条路径落地成本不高，也容易被团队接受。
- 埋点：先让数据进来。基于 OpenTelemetry 标准，两行代码接入，把提示词、返回、token、工具调用都记下来。这一步不需要写任何评估代码。
- 读链路，定义成功标准：亲自读一遍真实数据，输入是什么、输出是什么、到底哪儿坏了。然后和产品、QA 一起把「什么算合格」写清楚。跳过这一步直接自动化，评估只会去测容易测的指标。
- 写代码评估：从一条确定性的检查开始。比如校验报告里有没有出现用户查询对应的股票代码——一条字符串逻辑，就能抓出「答了一半」的硬性缺陷。
- 上大模型裁判：先试内置评估，往往不够用。比如用「正确性」评估去衡量一份依赖实时搜索的报告，裁判的知识截止更早，会把新信息全判为错误。换成「事实一致性」——把原始素材一起交给裁判，让它判断内容有没有编造——结果立刻就对了。
- 用人工标注校准裁判：拿裁判的判定和人工真值比对，分歧大就回头看 rubric 是不是写模糊了。注意，评估提示词本身就是一份大模型应用，同样要迭代、要版本管理。
- 沉淀数据集，跑对照实验：把失败链路存成回归测试集，每次改动重跑；同时保留一批成功样本，避免把原来的功能弄坏。做实验时只改变版本这一个变量，分数变化才能归因。
至于改动顺序，有个反直觉但很实用的优先级：先修数据源（搜索来源、知识库内容错误），再改提示词，再考虑换更强的模型，再考虑温度这类超参数。 数据源是错的，提示词优化到天上去也没用。
本文整理自 Laurie Voss（Arize AI 开发者关系负责人）在 AI Engineer 大会的实操工作坊 《From Vibes to Production: Evaluating and Shipping AI Agents That Work》（101 / 201 两场），以及同一讲者的 《Ship Real Agents: Hands-On Evals for Agentic Applications》。
