这可能是所有做 Agent 落地的人心里最没底的事情系统跑起来了工具也接上了但没有人能说清楚它的回答到底好不好。我见过太多团队把 Agent 部署到测试环境之后只能靠“看起来还行”“偶尔抽风”这种玄学判断效果。等到发现问题的时候往往已经积累了一堆线上投诉。这篇文章想基于 LangSmith 的 12 种评估方法把“Agent 做得好不好”从玄学变成可以被量化、被追踪、被回归验证的问题。适合正在做 Agent 产品化、准备搭评估体系、或者已经在用 LangSmith 但只用了 tracing 功能的朋友。我会直接把每种方法怎么配、怎么用、踩过什么坑讲清楚你可以照着抄。1. 为什么 Agent 评估这么难先想清楚评估体系的核心问题1.1 Agent 评估和传统软件测试的根本区别传统软件测试的核心是确定性。输入一个数字程序返回一个结果你写一个 assert 就能判断对错。可以构建完整的单元测试、集成测试、回归测试体系。但 Agent 不是这样它每次回答都是 LLM 采样出来的结果同一个问题问两次答案可能不一样工具调用的路径也可能不一样。没有唯一正确的输出可以硬比较所以“用例断言式”的测试思路直接失效。我习惯用一个类比来理解传统测试像质检员检查螺丝钉标准固定、卡尺一量就知道合不合格Agent 评估更像考核一位新来的客服每次接待的用户不同、回答的话不同你只能从多个维度去打分比如信息是否准确、态度是否礼貌、是否解决了问题。这就决定了评估体系必须走“多指标打分 过程记录 逐步回归”的路线。1.2 评估体系必须先回答三个问题搭建评估体系前先想清楚三个问题第一用什么数据来评估第二用什么标准来评判第三评估结果怎么变成可追踪、可对比的数据。这三个问题对应 LangSmith 的三层能力数据集管理负责“用什么数据”评估器负责“按什么标准”评估报告和 trace 记录负责“结果怎么用”。很多人一上来就急着写评估函数其实数据集才是最花功夫的部分。数据没覆盖边界场景评估跑了也是白跑。我后面会详细讲数据集怎么冷启动。1.3 为什么选 LangSmith 而不是自己写一套自己写评估脚本当然可行但会卡在一个很尴尬的点评估一个 Agent不只要看最终答案还要看它调用了哪些工具、传了什么参数、中间是不是绕了远路。普通脚本很难拿到完整的过程数据。LangSmith 的核心优势就是全链路可观测一次运行里LLM 调用、工具调用、中间状态全都自动记录成 trace评估器可以直接从这些 trace 里取数据来打分。也就是说LangSmith 把“评估”和“可观测性”绑在了一起。某次评估分数异常可以直接点开对应的 trace看到中间哪一步出了问题两次版本评估做 diff可以直接定位到某一次工具调用参数的变化。这个闭环是自己写脚本很难实现的。2. 12种评估方法的整体地图与选型逻辑2.1 先把12种方法归成三类答案质量、行为轨迹、人工运营12种方法听起来很多但按用途归堆以后就好理解了。第一类是答案质量类专门回答“Agent 产出的最终内容好不好”LLM 单点评分、LLM 多标准评分、成对比较、带参考标准的评分、语义相似度、字符串距离、JSON 结构匹配、正则表达式校验。第二类是行为轨迹类回答“Agent 做事的过程对不对”工具调用正确性、工具调用错误捕获、Agent 轨迹验证。第三类是人工与运营类回答“用户和团队怎么看待效果”人工评估与在线反馈另外延迟与成本监控虽然不是打分类评估但生产环境里必须放在一起看。这12种方法的定位差异很大。前八种偏“裁判”试图判断内容质量第九到第十一种偏“过程审计”关注 Agent 动作是否合规第十二种偏“价值闭环”把真实用户的反馈拖回评估体系。2.2 选型逻辑场景决定方法不要贪多具体选哪种要看你的 Agent 场景属性。如果业务有明确的标准答案比如客服问答、SQL 生成、信息抽取优先用带参考标准的 LLM 评分再叠加字符串匹配或者 JSON 校验如果业务开放性强比如创意文案、方案生成没有标准答案就靠 LLM-as-Judge 和成对比较如果 Agent 接了多个工具比如搜索、数据库、计算器工具调用正确性、工具错误捕获和轨迹验证必须上否则答案再漂亮也是空中楼阁。我见过不少团队一开始把全部方法都挂上结果报告里十几个指标谁也不知道该盯哪个。合理的做法是每个维度选最少一个代表先跑两周再看哪个指标真正能反映问题。2.3 组合参考典型的评估器搭配这里给一个可以直接抄的组合逻辑。客服型 Agent 最常见多标准评分正确性加语气看答案质量工具调用正确性看执行过程延迟监控看体验人工评估兜底。如果是代码生成 Agent带参考标准的评分看代码正确性正则校验看输出格式工具错误捕获看编译执行失败率成对比较留到模型版本升级时用。表格看起来更直观场景推荐方法组合选择理由客服问答 Agent多标准评分 工具调用正确性 延迟监控有部分标准答案但回答要兼顾语气代码生成 Agent带参考标准评分 正则校验 工具错误捕获正确性优先格式强约束开放创作 AgentLLM单点评分 成对比较 人工评估没有标准答案以裁判和用户反馈为主SQL/信息抽取 Agent字符串距离 JSON结构匹配 轨迹验证输出结构固定过程允许灵活3. 答案质量类评估方法实操8种方法逐个上手3.1 单点评分(CriteriaEvaluator)30分钟搭起第一个裁判单点评分是上手门槛最低的一种本质上是让一个 LLM 按照你给的评分标准给 Agent 的输出打一个分。LangSmith 内置了一批常用标准比如相关性、帮助性、无害性直接通过 CriteriaEvaluator 调用就行。代码大致长这样from langsmith.evaluators import CriteriaEvaluator result evaluate( agent_runner, dataagent-qa-set, evaluators[ CriteriaEvaluator(criteriarelevance), ], )这个评估器会返回一个 1 到 5 的分数并附带 LLM 给的理由。第一次跑通以后我建议先别急着调阈值而是先抽二十条结果出来人工读一下看看 LLM 打 3 分和打 4 分的答案你的主观感受是否认同。如果完全不认同说明评分标准描述和你的业务目标有偏差需要把 criteria 换成更具体的描述比如“回答必须直接解决用户问题避免只给背景介绍”。有个小经验评分标准用一段话描述的效果通常比一个单词更好。内置的 relevance 只是起步真正能用的标准往往长这样“判断回答是否在 100 字以内直接给出可操作步骤不包含与问题无关的背景信息。”3.2 多标准评分同时看正确性、相关性和语气单点评分只能看一个维度但真实业务往往需要同时考核多个方面。比如客服 Agent回答可能是准确的但语气非常生硬用户不会满意。多标准评分就是一次调用同时返回多个维度的分数。LangSmith 的 CriteriaEvaluator 支持传多个 criteria你还可以通过打标签的方式输出每个维度的独立分evaluators[ CriteriaEvaluator(criteria{ correctness: 答案是否准确回答用户问题, friendliness: 回答是否礼貌友好, conciseness: 回答是否简洁不啰嗦, }) ]这里有个容易踩的坑不要同时放语义过于接近或者互相矛盾的维度比如同时要求“详细全面”和“简明扼要”LLM 会左右为难分数波动很大。我自己的经验是一次最多三个维度每个维度用一句业务语言描述清楚别用抽象词。多标准评分适合日常监控。每次跑批以后重点看各维度是否均衡如果一个版本正确性从 4.2 涨到了 4.6但友好性从 4.1 掉到 3.4说明这版 prompt 为了准确性牺牲了语气到底是好是坏要结合业务定位判断。3.3 成对比较版本迭代时的AB测试神器成对比较的逻辑很简单把同一个输入喂给两个不同版本让评判者二选一。它天然适合模型升级、prompt 改版、工具顺序调整这类场景评估的是“新版比旧版好还是差”而不是“具体多少分”。LangSmith 里通常通过 ComparisonEvaluator 或者自定义的双输入评估器实现。流程上是把两个 Agent 版本对应的 run 绑定到一个 example 上再由 LLM 给出胜者。实际使用中有几个经验位置偏差是最大的坑。LLM 对先出现和后出现的答案有偏好解决方法是同一批数据跑两次交换两者顺序最后合并结果胜率取平均。把比较标准和业务目标挂钩比如“哪个回答让用户更快完成退款操作”而不是笼统的“哪个更好”。胜率在 50% 左右时说明两者差不多别为了选出赢家硬调。这时候更应该关注成本、延迟有没有改善。成对比较不适合天天挂在流水线上它更适合在每次做版本决策的时候用一次做横向对比。3.4 带参考标准的评分最稳的 LLM 评分方式带参考标准的评分是很多场景的首选。它在数据集的 outputs 里预先放一个标准答案评估器把 Agent 的回答和标准答案一起交给 LLM让 LLM 判断是否在关键信息上一致。这比没有参考的纯主观打分稳得多因为 LLM 有了锚点。LangSmith 里用 LabeledCriteriaEvaluator 实现from langsmith.evaluators import LabeledCriteriaEvaluator evaluators[ LabeledCriteriaEvaluator(criteriacorrectness), ]标准答案的质量直接决定了评估结果。如果参考答案本身有错或者覆盖了错误信息评估器会把错的当标准把对的答案误判成低分。所以准备数据集的时候参考内容要经过至少两个人复核尤其是那种有明确数字、条款、流程的场景。还有一点带参考的评分更适合事实型任务不适合开放创作。如果你让 Agent 写营销文案标准答案反而会限制对多样性的评判。这类场景要回到成对比较或者纯 LLM 裁判。3.5 语义相似度意思对就行字面不重要语义相似度评估的思路是把两个文本分别嵌入到向量空间用余弦相似度衡量语义接近程度。它解决的是“意思对了但表述不一样”的评估问题适合摘要生成、开放问答、FAQ 匹配这类不要求逐字一致的任务。LangSmith 里有 EmbeddingDistanceEvaluator用法很简单from langsmith.evaluators import EmbeddingDistanceEvaluator evaluators[ EmbeddingDistanceEvaluator(distancecosine, threshold0.8), ]这里要提醒的是阈值设定。通用嵌入模型在专业领域文本上分数普遍偏低原因是行业术语和日常语义分布差异大。所以不要直接照搬文档推荐阈值先跑一批数据画出分数分布再根据分布取一个分位数作为阈值。另一个坑是 embedding 模型的选择要和你的业务领域匹配。做法律文本和做商品评论用的是不同领域的词分布建议选在相似语料上训练过的嵌入模型否则语义相似度这个指标会有很大的系统性偏差。3.6 字符串距离硬匹配也有用武之地字符串距离包括完全匹配 Exact Match 和编辑距离 Edit Distance。很多人觉得这方法太傻但它对固定格式的输出非常有效比如订单号、手机号、产品编码、证件号这类必须一字不差的字段。信息抽取类的 Agent如果最终要落到结构化数据里这类硬校验反而比 LLM 评分更可靠。LangSmith 里可以用 StringDistanceEvaluator 或者自定义一个简单的 equality evaluator。我的建议是把它当作“守门员”而不是“裁判”单独用容易误伤但作为兜底校验在所有 LLM 评分之前先跑一遍硬格式错了直接判零分不需要再让 LLM 去评价它。实际经验是很多线上事故不是语义理解错了而是差了一个空格、一个大写字母。硬匹配在这个场景下是最便宜的防线。3.7 JSON结构匹配给结构化输出套上约束当 Agent 的输出要交给下游系统解析时JSON 格式是否合规比内容好坏更重要。JSON 结构匹配评估器检查的是字段是否存在、类型是否正确、枚举值是否在允许范围内。LangSmith 里你可以把 JSON Schema 写成一个 evaluator 的校验逻辑跑批时逐条验证。import jsonschema REQUIRED_SCHEMA { type: object, properties: { amount: {type: number}, currency: {enum: [CNY, USD]} }, required: [amount, currency] } def json_schema_evaluator(run, example): outputs run.outputs.get(result, ) try: data json.loads(outputs) jsonschema.validate(data, REQUIRED_SCHEMA) return {key: json_valid, score: 1} except Exception: return {key: json_valid, score: 0}我踩过的坑是输出里混进了 markdown 代码块标记就是 json 这种包裹导致 json.loads 失败。评估器里最好先把这类包裹标记剥掉再做校验。另外JSON 校验只能保证结构对不能保证业务对两个字段类型正确但业务含义错误的场景还是需要配合带参考标准的 LLM 评分。3.8 正则表达式校验绕不开的格式守门员正则表达式是所有格式校验里最轻量的一种适合验证邮箱、日期、金额、手机号这类格式固定的字段。LangSmith 里可以快速写一个自定义 evaluator用 re.search 或 re.fullmatch 做匹配。正则评估器很简单但很多人会犯一个错误正则写得太严导致合法输出被误杀。比如日期格式究竟是“2025-01-01”还是“2025/01/01”还是“2025年1月1日”业务系统到底支持哪一种必须提前确认清楚而不是在评估器里拍脑袋定。格式越严格误伤的概率越高。另外正则是顺序敏感的pattern 的写法会影响匹配结果。建议先在本地拿真实 Agent 输出测一遍再挂到跑批流程里。否则评估结果突然大量飘零的时候你会分不清是 Agent 的问题还是正则的问题。4. Agent行为与效率类评估方法实操过程可见才能控制结果4.1 工具调用正确性不只是“调了没”更是“调对没”工具型 Agent 的评估最终答案只是表象真正的关键在过程。一个客服 Agent 说要帮忙查订单如果它调错了工具把“查询订单”调成了“取消订单”即使最终回答写得再流畅也是事故。工具调用正确性评估就是干这个用的。LangSmith 的 run 结构里Agent 的每次工具调用会记录成 child run类型是 tool_openai 之类的 tool 类型。评估器里可以遍历 child_runs检查实际调用的工具名和参数与期望值对比def tool_call_correctness_evaluator(run, example): tool_calls [ child for child in run.child_runs if child.run_type tool ] expected example.outputs[expected_tool] matched any( call.name expected[tool] and call.extra.get(args, {}).get(order_id) for call in tool_calls ) return {key: tool_call_correctness, score: int(matched)}这个评估器的前提是数据集里得存期待的工具及关键参数。很多团队会漏掉这一步只看工具名。实际业务中参数错误比工具选择错误更常见比如把“收货地址”传给了“退款接口”名字是对的参数是错的。所以评估器里一定要检查关键参数是否出现、格式是否正确。4.2 工具调用错误捕获把异常当作可评估指标工具调用过程中经常出现异常比如下游接口超时、传参格式不合法、数据源返回空。LangSmith 会把这些异常记录在 trace 里我们可以把异常当成一种明确的负向指标来统计。工具错误捕获和工具调用正确性侧重点不同。正确性看“动作选得对不对”错误捕获看“动作执行是否成功”。举个实际例子某个 Agent 每次都选对了天气查询工具但天气接口三天两头超时导致用户体验很差。这类问题用正确性指标看不出用工具错误率一眼就能发现。实现方式是在评估器里检查 child run 的 status 是否为 error或者输出内容是否包含异常标记然后统计整批结果中错误调用占总调用数的比例。这个指标非常适合做成持续监控如果在某一次模型升级后工具错误率突然上升大概率不是工具本身坏了而是 Agent 生成的工具参数格式变了没对齐接口要求。4.3 Agent轨迹验证过程比结果更能说明问题有些 Agent 业务对执行顺序有强要求。比如一个审批助手必须先调用“权限校验”再调用“数据查询”最后调用“通知发送”。如果 Agent 先查询了再校验权限顺序就错了哪怕最终结果看起来正常也存在安全隐患。轨迹验证就是用来守护这一类顺序约束的。LangSmith 的 trace 记录了 Agent 的完整执行序列评估器可以提取所有 child run 的名称形成序列然后用子序列匹配判断期望的步骤顺序是否被满足def trajectory_evaluator(run, example): steps [ child.name for child in run.child_runs if child.run_type in (tool, chain) ] expected_seq example.outputs[expected_trajectory] # 检查 expected_seq 是否按顺序出现在 steps 中 idx 0 for step in steps: if idx len(expected_seq) and step expected_seq[idx]: idx 1 return {key: trajectory_match, score: int(idx len(expected_seq))}这里有一个容易误判的点Agent 可能额外调用了一些辅助工具比如先搜了一下知识库再进入主流程这些额外步骤不影响正确性子序列匹配算法天然兼容这种情况。但如果业务要求严格禁止某些步骤比如“绝对不允许调用删除接口”轨迹评估器里还要加一个黑名单检查抓到直接零分。4.4 人工评估与在线反馈最后一公里任何自动评估器都有误差最终兜底的一定是人工评估和真实用户反馈。人工评估适合在数据集上做离线标注LangSmith 支持在界面上直接对一次运行的结果标记正确、错误、部分正确同时可以附加文字说明。我建议每周抽一定比例线上样本做人工复盘专门盯自动评估器识别不了的模糊案例比如两个回答意思相近但一个表述更专业这类判断只有人做得准。在线反馈的价值则在于真实用户的行为信号。用户点赞、点踩、追问、退出都可以关联到具体的 trace 上。如果评价体系搭建得早建议从第一天就给 trace 打上用户反馈标签看到某类问题用户反复点踩就把它作为数据集的种子补进评估集里形成“线上反馈到离线回归”的闭环。另外有些团队会给反馈分级用 P0、P1、P2 这种优先级标签标记严重程度。P0 意味着回答直接导致重大错误或安全事故这种反馈优先级最高必须立刻进评估集并触发回归。分级之后评估结果就不只是平均分而是能反映严重问题分布情况的报告。4.5 延迟与成本监控评估体系里不能少的两个运行指标严格来说延迟和成本不算“打分方法”但生产环境的 Agent 评估如果不看这两个指标其他都是空谈。Agent 的延迟不是单次 LLM 调用延迟而是完整执行链路所有子调用的总时长。你算成本也不能只算一次主调用工具调用的 token、内部多次思考的 token都要逐级汇总。LangSmith 的 trace 天然记录了这些数据。一次 Agent 运行展开后可以看到每一级调用的耗时和 token 消耗汇总起来就是这次请求的真实成本和延迟。实际运营中重点观察两个趋势延迟是否随着模型升级明显上升成本是否在复杂场景下失控。比如某次效果提升是通过多调三次 LLM 换来的胜率只涨了 2%成本却涨了 50%这个决策是否划算就值得掂量。这几个运营指标建议做成看板每天看趋势而不是看具体某一条。因为单次请求的延迟受网络影响波动大看中位数和 P95 才有参考意义。5. 从零搭一条完整的评估流水线数据集、跑批、回归门禁5.1 第一步数据集的冷启动与结构设计评估体系的地基是数据集。冷启动阶段不要贪多20 到 50 条高质量用例比 500 条凑数的有用得多。这些用例要覆盖三类内容线上最常见的主流程问题、边界和极端输入、历史上真实出过事的失败案例。三条线缺一不可只有常见问题会漏掉边界风险只有失败案例又无法衡量日常体验。数据集的每条 example 由 inputs 和 outputs 组成。inputs 是用户的输入内容outputs 是期望结果和辅助信息比如标准答案、期望调用的工具、期望的执行轨迹。给数据集做字段设计时宁可多预留几个辅助字段也别等需要用时重建因为重建数据集意味着之前的评估报告都没法横向对比了。我习惯把数据集分成基准集和回归集。基准集内容稳定只在业务重大调整时改回归集在每次版本迭代时追加新出现的问题案例。这样既有长期可比性也有对新问题的敏感度。5.2 第二步用 evaluate() 跑出第一版基准准备完数据接下来就是把 Agent 跑一遍加上评估器用 LangSmith 的 evaluate 函数执行。你需要提供一个被评估的函数它接收 inputs 里的内容返回 Agent 的输出LangSmith 会把它作为一次经验数据记录下来。from langsmith import Client from langsmith.evaluation import evaluate def agent_runner(inputs): question inputs[question] response my_agent.query(question) return {result: response} result evaluate( agent_runner, dataagent-qa-set, evaluators[ CriteriaEvaluator(criteriarelevance), LabeledCriteriaEvaluator(criteriacorrectness), tool_call_correctness_evaluator, ], )第一版跑出来的分数就作为 baseline 存档。如果 baseline 本身很低比如正确率只有 30%不要急着调评估器这大概率是 Agent 本身的问题先回去修 prompt。如果 baseline 看着还行比如 80%也别高兴太早抽几条低分样本看是偶发还是系统性问题。首次跑批最重要的产出不是分数而是确认“评估器和业务直觉是否一致”。跑完以后LangSmith 界面上会生成评估报告能看到每个评估器的得分分布、每条用例的详细结果。这一步做完评估体系的骨架就搭起来了。5.3 第三步迭代对比与回归门禁有了 baseline 以后后续每次修改 prompt、换模型、调整工具描述都重跑同一个数据集。LangSmith 支持对两次评估结果做对比直接点开两个版本的 diff看每个指标的变化情况再下钻到具体某个 trace 去定位差异原因。更进一步是把评估集成到 CI 里做回归门禁。比如每次代码合入之前自动跑一个精简版评估集如果关键指标低于阈值构建就失败。精简集控制在 10 到 15 条选最具代表性的用例保证几分钟内能出结果。完整评估集留到发布前再跑防止 CI 阻塞。需要提醒的是自动门禁的阈值不能拍脑袋。我的做法是先跑两周把指标的均值和标准差算出来取“均值减两倍标准差”作为预警线。这个线太低没有保护作用太高又会频繁误报导致大家对报警麻木。先松后紧逐步收紧比一开始定死更实际。5.4 实操注意事项从跑批到落地的习惯养成有几个细节直接影响评估体系的长期可用性。第一数据集要有版本概念每次修改要能回溯否则跑批结果没法对比。第二评估器最好是确定性的能在本地先对少量样本跑一遍确认稳定后再挂到流水线上。第三跑批结果要定期人工抽样抽检防止评估器和业务目标慢慢脱节。还有一个我吃过亏的地方Agent 的评估不要只在测试集上做线上真实流量同样需要漂移监控。用户输入分布会随时间变化旧数据集的代表性会衰减要定期用线上日志补齐新出现的问法。建议每个月抽一次线上日志把新出现的坏案例追加到回归集里保证评估体系自己也在持续进化。6. 常见问题与避坑实录6.1 LLM 裁判的偏差怎么治理LLM-as-Judge 虽然方便但它本身也是一只概率模型有系统性偏差。位置偏差是最常见的两个答案放一起评判时有的模型更偏好第二个答案有的偏好第一个。自我偏好也容易踩模型会对自己的输出打高分导致你用弱模型评估强模型时分数失真长度偏好更普遍字数多的答案经常被误认为更好。治标的方法是做去偏处理成对比较时交换位置跑两遍取平均评分时对标准答案和候选答案做随机顺序用更强的模型当裁判把你部署到生产环境的模型高出一个量级。治本的方法是定期抽检 LLM 裁判的判断和人评结果做一致性对比人评占比不用高一个月 100 条就够能有效发现裁判模型思路漂移。6.2 分数忽高忽低是为什么同一批数据跑两次评估结果差异大先别怀疑评估器有问题。先看温度参数Agent 的采样温度直接影响输出稳定性温度越高输出方差越大。评估器本身如果是 LLM 调用它也有温度评分时应该把评估器的温度设为 0。还有一类常见问题是数据集里混入了含误导性参考的样本。比如参考答案是错的一次跑批正好抽到了这部分平均分就被拉低了。遇到分数异常波动不要只看平均分点开具体用例看哪些样本的分数和上一版差异最大逐条分析原因。把评估的“可解释性”用好比单纯盯着总分有用得多。6.3 数据集太少怎么办冷启动阶段不可能有几百条高质量用例数据少不代表不能跑评估。20 条用例就能暴露最明显的问题只是结论置信度不高。解决办法是把“数据量少”这个约束写进报告明确告诉团队当前分数是参考级的同时用线上反馈持续倒灌数据集把真实用户点踩的案例每天新增进评估集。还有一种临时做法用规则生成一些变异用例比如改写正确句式的措辞、替换同义表达。但这类合成数据只能用于格式类校验不能用来评估语义质量合成样本的语义覆盖范围有限且带有生成痕迹。6.4 指标互相打架怎么取舍正确率涨了延迟也涨了工具调用成功率高了但回答友好度降了。这是评估体系的常态不是 bug。关键是在搭体系之前就想清楚核心决策目标。我习惯给每个指标定一个角色核心指标、重要指标、参考指标。核心指标是业务价值的直接体现不可妥协重要指标是核心指标的支撑正常情况下要兼顾参考指标只做观察不参与决策。指标冲突时以核心指标为准但前提是核心指标的定义是业务方认可的不是开发自己拍的。6.5 没有标准答案的纯工具型 Agent 怎么评估有些 Agent 的主要工作不是生成回答而是执行一系列操作比如自动运维助手、数据分析流水线。这种场景没有标准答案可以比对评估重点要放在行为结果上任务是否完成、工具调用是否成功、执行顺序是否合规、资源消耗是否在预算内。如果工具链本身有明确的完成态比如文件处理任务最终产出了一个文件可以直接检查产物是否存在、格式是否合法。如果工具链没有硬性完成态可以用 LLM 对最终状态做一个合理性判断参考的是任务描述而不是标准答案。这类评估更依赖轨迹类评估器对数据集的要求相对低但对 trace 记录质量的要求更高。我在实际项目里最后把评估收敛到三个数字关键问题的答案正确率、工具调用成功率、单次请求的 P95 延迟。评估体系的价值不在于指标多而在于你清楚每个数字背后对应产品体验的哪一块。刚开始恨不得把 12 种方法全挂上跑两周以后会发现能真正帮助你做决策的指标永远只有少数几个。先把这几个找出来再慢慢补充比一步到位更扎实。