传统软件测试很简单，给定输入，断言输出等于期望值。Agent 的测试把这个范式彻底打破了。
同一个输入，Agent 今天可能这么回答，明天换个说法回答，逻辑都对但字面不同。你没法用一个 assert 判断它「对不对」。而且 Agent 的输出往往是一连串动作加一段自然语言，哪部分算「正确」本身就很难定义。
这就是 Agent 评估的核心难题。用传统软件的测试方法，几乎评估不了 Agent。但不上评估，Agent 的质量就是一笔糊涂账，改了不知道有没有变好，上线不知道会不会出问题。这篇讲怎么给 Agent 建立一套能用的评估体系。
为什么 Agent 评估这么难
图：四个难点共同决定了 Agent 评估不能照搬传统 assert 断言，需要专门方法论。
先充分理解难点，才能找到对策。
输出不确定性。同样的输入，LLM 的输出有随机性（temperature 大于 0 的话），两次调用结果不完全一样。传统测试期望精确匹配，这里行不通。
正确性模糊。Agent 的回答可能是对的，但表述不同。或者大部分对，有一小部分错。或者逻辑对但事实错了。怎么定义「通过」是个主观判断，不像算「1+1」有确定答案。
路径多样性。完成同一个任务，Agent 可能走不同的路径（先调 A 再调 B，或者先调 B 再调 A），只要最终结果对，路径不同也应该算通过。但路径不同意味着中间步骤也对不上断言。
长尾失败。Agent 在 99% 的 case 上表现正常，但在某些边缘情况会犯很蠢的错。这些长尾是评估的重点也是难点，因为你不一定知道它们在哪。
理解了这四个难点，就知道为什么 Agent 评估不能照搬传统测试，要建立专门的方法论。
评估的第一层，定义清楚「任务完成」是什么
评估的前提是，明确什么叫「任务完成」。这听起来废话，但很多团队的 Agent 连完成标准都没定义清楚。
任务完成的定义要具体到可判断。不能是「回答得好」，要是「回答里包含了正确的数据来源、没有幻觉、格式符合要求」。把模糊的「好」拆成几个可检查的维度，每个维度有明确的判断标准。
常见的维度包括，任务完成度（有没有解决用户的问题）、准确性（信息对不对）、安全性（有没有越权或者有害输出）、效率（用了多少步、多少 token）、用户体验（表述清不清楚、有没有多余的废话）。
每个维度定一个评分标准，比如完成度用「完成、部分完成、未完成」三档，准确性用「全对、有小错、有大错」三档。有了标准，评估才有依据。
LLM as Judge，用模型评估模型
图：评判模型按评分标准给被测 Agent 打分，再靠人工抽检校准，形成可迭代的评估闭环。
这是目前 Agent 评估的主流方法。用一个 LLM（通常是更强的模型）来评判另一个 LLM 的输出。
做法是，准备一批测试用例（输入加期望的输出特征），让被测 Agent 跑一遍，拿到实际输出。然后用评判模型，把输入、期望、实际输出喂给它，让它按照你定义的维度打分。
LLM as Judge 的好处是能处理自然语言的模糊性。评判模型能理解「这个回答虽然措辞不同但语义正确」，这是传统断言做不到的。它还能给出打分理由，帮你理解为什么这个 case 没通过。
代价是评判本身也不完全可靠。评判模型可能打分不一致（同一个 case 评两次分数不同），可能有偏差（偏袒某种风格的回答），可能自己也会判断错误。所以 LLM as Judge 的结果要看趋势，不能太迷信单个 case 的分数。
提高评判可靠性的几个办法。用更强的模型当评判。把评判标准写得很具体，别让评判模型自由发挥。多个评判模型投票，减少单一模型的偏差。对评判结果做人工抽检校准，发现系统性偏差就调整评判标准。
黄金测试集，人工标注的基准
无论 LLM as Judge 多方便，都需要一个高质量的、人工标注的测试集作为基准。
这个测试集是你精心准备的，每个 case 都有明确的人工标注的「正确答案」或者「可接受答案」。它的作用是，给 Agent 的质量一个稳定的参照系。每次改动之后跑一遍这个集子，看分数是涨了还是跌了。
测试集的质量决定评估的有效性。几个原则。覆盖要全，包含常见 case、边界 case、对抗 case（故意刁难的）。标注要准，每个 case 的期望答案要经过认真推敲。大小要够，太少没统计意义，几十到几百个 case 比较实用。
测试集要随业务演进。发现线上有新的失败模式，把它加进测试集。这样测试集会越来越能反映真实的质量挑战。
没有黄金测试集的 Agent 开发，是在没有标尺的情况下改代码。你以为优化了，可能其实倒退了，只是你测不出来。建测试集是一次性投入大、长期回报高的事情，值得在早期就认真做。哪怕只有 50 个高质量 case，也比 500 个随意的 case 有用。
人工评估，不可替代的一环
LLM as Judge 再好，也替代不了人工评估。有些维度的判断，人比模型准。
主观体验。回答读起来顺不顺、有没有让人困惑的地方、语气合不合适，这些主观感受模型评判不准，要真人来体验。
复杂推理的正确性。涉及多步推理或者领域知识的 case，评判模型可能自己也搞不清楚对错，要领域专家来判断。
边缘情况的合理性。Agent 在某些奇怪输入下的行为，是不是合理、会不会有风险，往往需要人来判断。
人工评估成本高，所以通常做抽检。从 Agent 的实际输出里随机抽一批，人工过一遍，记录问题。抽检的目的是发现 LLM as Judge 漏掉的问题，校准自动评估的偏差。
把评估纳入开发流程
图：离线评估守发布、人工评估补主观、线上监控抓真实失败，三者闭环让 Agent 质量持续受控。
评估不是上线前才做的事，要嵌入日常开发流程。
每次改动跑一遍黄金测试集，看分数变化。分数跌了，先搞清楚为什么，是改动引入了回归，还是测试集本身要更新。这个「改动、跑评估、看分数」的循环，是 Agent 质量迭代的基本节奏。
线上持续监控。评估不仅在离线测试集上跑，还要在线上采样评估。从真实流量里抽样，自动评估质量，发现质量下降或者新的失败模式。线上监控能捕捉到离线测试集覆盖不到的真实场景。
建立评估文化。让团队习惯「用数据说话」，而不是「我觉得变好了」。一个改动好不好，看评估分数，不看个人感觉。这种文化能避免 Agent 质量在主观判断里漂移。
Agent 评估是个没有终点的工作。模型在变、需求在变、用户在变，评估体系也要跟着演进。但只要有一套能用的评估方法，哪怕粗糙，Agent 的质量就是可控的。没有评估的 Agent，永远是凭感觉的黑盒，上了线就是赌博。
