同样能完成任务的 Agent性能差距可能天差地别该怎么量化工业级 Agent 完整评估方案结果层轨迹层系统层三层指标拆解如果你负责过一个 Agent 项目的验收大概率遇到过这种场景两个候选 Agent 在演示环境下都能完成任务Demo 跑得都很流畅于是选了更便宜的那个。结果一上生产问题开始密集暴露——任务偶尔失败、工具调用不稳定、遇到边界情况直接卡死、日志里全是看不明白的报错。很多人第一反应是“运气不好”但更本质的原因是Agent 的能力评估根本没有被量化。LLM 应用开发到现在代码层面的测试手段已经很成熟了但 Agent 层面的评估仍然像一个“盲盒”。常规做法是看最终输出对不对可这在 Agent 场景下远远不够。一个 Agent 可能结果是对的但中间调用了 20 次工具花了 3 倍预算另一个 Agent 可能第一轮就选错了工具靠重试和兜底逻辑硬是绕回了正确答案。前者让人放心后者让人不安可如果只按“最终结果”打分两者得到的分数可能一样。这篇文章要聊的就是如果想让 Agent 真正进入生产环境评估体系应该怎么搭。我会拆解结果层、轨迹层、系统层三套指标每一层解决什么问题、有哪些核心指标、怎么配置和落地以及评估过程中最容易踩的坑。无论你是在做 Agent 开发、Agent 框架选型还是负责评估体系建设这篇文章都值得从头读一遍。1. 这篇文章真正要解决的问题先摆一个观点Agent 评估的难点不在于“定义什么是好”而在于“把好拆成可测量的维度”。很多团队不是不愿意做评估而是不知道评估什么。1.1 传统评估方案的局限如果你用过传统的 Prompt 评测工具会发现它们的核心逻辑是“给一段输入比对模型输出”。这在纯文本生成任务里很有效但放到 Agent 场景里就不成立了。原因很简单Agent 不是“一步到达终点的”它是一个多轮决策系统。它要理解用户意图、选择工具、解析工具结果、修正错误、决定下一步动作。这个过程中任何一个环节出问题都可能导致最终结果偏离预期但出问题的位置千差万别。单看结果会漏掉信息单看中间步骤又会陷入细节无法判断整体质量。这就是为什么需要一套分层评估方案。1.2 Agent 评估到底难在哪里对比传统软件测试Agent 评估的难点集中在四个方面输出的不确定性同一个任务同一个 Agent跑两次可能给出不同的过程路径。状态的动态性Agent 操作的是一个变化的外部环境数据库、API、文件系统同样的动作在不同时间执行结果可能不同。路径的多样性到达同一个正确终点的路径可能有几十条如何判断哪条路径是“好路径”成本的隐蔽性过程越长、重试越多、工具调用越频繁成本越高。但这些成本不会直接体现在“任务是否完成”上。所以说评估 Agent 不能停留在“看最终答案”而是要把评估维度拉宽。结果层解决“做没做成”轨迹层解决“做得对不对”系统层解决“能不能长期稳定地做”。1.3 哪些读者最需要这套方案Agent 开发者需要知道自己写的 Agent 在真实场景里表现得怎么样哪里该优化。技术负责人/架构师需要为团队选择一个评估框架或建立自己的评估流程。算法工程师需要对比不同模型、不同 Prompt 策略、不同工具编排方式的效果。运维/平台工程师需要确保 Agent 上线后有监控、有告警、有回归能力。如果你只是在做原型验证那这套方案可能显得“重”。但只要你打算把 Agent 推向生产环境这三层指标就是绕不开的基础设施。1.4 本文的结构安排先讲清楚一个容易被忽视的前提再逐层拆解三层指标体系。结果层重点讲任务完成度和结果质量轨迹层重点讲路径合理性、工具调用效率、错误恢复能力系统层重点讲稳定性、可观测性和安全边界。每一层我都会给出具体的指标定义、配置思路和代码示例最后汇总成一个可以直接落到工程里的评估方案。2. 基础概念为什么三层指标缺一不可在具体拆指标之前需要先建立两个认知Agent 的“任务”和传统程序里的“函数调用”不是一回事Agent 的“过程”本身就是可评估的产品资产。2.1 什么是结果层、轨迹层、系统层为了讲清楚我用一个简单的类比评估一个 Agent 就像是评估一个外卖骑手。结果层只看“外卖是否准时送到”这是最基本的业务指标。轨迹层看“骑手走的是什么路线、有没有绕路、有没有闯红灯、有没有在中途停下来处理异常”。系统层看“这个骑手长期来看靠谱吗下雨天会不会爆单车坏了有没有备用方案平台能不能实时监控他的位置”。对应到 Agent结果层关注任务的最终产出判断 Agent 是否完成了用户的目标。轨迹层关注 Agent 的决策过程、工具调用序列、错误恢复行为判断路径是否高效合理。系统层关注 Agent 在真实运行环境中的稳定性、性能、安全性和可观测性判断它是否具备生产条件。三层缺一不可。结果层告诉你“做成没有”轨迹层告诉你“做得怎么样”系统层告诉你“能不能长期做”。2.2 为什么单看结果不靠谱“结果正确”在 Agent 场景里是一个模糊概念。一个 Agent 可能输出了一段正确代码但它是在第三次重试时靠系统自动修复才成功的另一个 Agent 第一次就找到了正确 API 并高效返回。最终交付物一样但两者的可靠性完全不同。更麻烦的是结果正确性本身也分层次。任务完成可能意味着“最终答案正确”也可能只是“最终答案部分正确”“答案格式对了但内容不对”“工具返回了错误但 Agent 没有识别出来”。这些情况如果只用一个 pass/fail 标记会丢失大量信息。所以在结果层我们需要做到比“正确/错误”更细的评级。2.3 轨迹为什么重要Agent 过程是有成本的与 LLM 单轮生成不同Agent 的每一个动作都消耗资源。模型推理消耗 token工具调用消耗网络和计算资源重试策略消耗额外时间。一条“能到达终点但极其曲折”的轨迹可能在性能上没有大问题但在成本上无法接受。轨迹层的核心就是把“决策过程”变成可量化的指标工具调用有没有偏差、有没有无效循环、错误发生后多久能恢复、路径长度是否合理。这些指标直接影响生产环境中的成本和体验。2.4 系统层解决的是“能不能信你”的问题一个 Agent 在测试集上跑得好不代表在线上就能稳定运行。系统层关注的是非功能性指标延迟是否稳定、并发时是否还能正常工作、失败时有没有优雅降级、是否具备完整的可观测性。这些问题不解决Agent 在黑盒状态下上线就如同带着隐患跑生产。从工程实践来看系统层往往是团队最容易忽视的部分因为它的反馈周期比业务准确率长很多。但恰恰是系统层的缺失导致 Agent 项目难以从“实验室阶段”走到“生产阶段”。3. 结果层评估任务完成度与结果质量结果层是评估体系的基石它回答“Agent 有没有把任务做成”这个问题。但它不是简单跑一个用例、比对一下答案而是需要设计一套合理的评分规则。3.1 结果层核心指标结果层建议至少覆盖以下五个维度指标名称定义说明任务完成率Agent 成功完成任务的用例数 / 总用例数最基本的能力指标结果正确率达到预期标准的用例数 / 已完成用例数需要明确“正确”标准首轮成功率不依赖重试第一次就完成任务的比率反映 Agent 的初始决策质量结果质量评级对完成结果进行 A/B/C 分级评估区分“勉强完成”和“高质量完成”用户满意度代理分通过规则或 LLM 对结果进行用户视角评分适合业务场景需要校准3.2 任务完成率与正确率的区别这两个指标经常被混用但在评估中应该分开。任务完成率只关心流程是否走完结果正确率关心结果是否符合标准。举例Agent 被要求从数据库查询指定用户信息并生成报表。Agent 成功执行了查询也生成了一个报表文件但报表中漏掉了一个字段。这种情况下任务算“完成”但结果不算“正确”。在实际评估中通常是“先判断是否完成再判断完成质量”。完成率和正确率分开统计才能发现 Agent 是在“能否完成”层面有问题还是在“完成得好不好”层面有问题。3.3 结果评级的实现思路结果评级建议采用分级评分而不是简单的二值判断。以“生成 JSON 配置”这个任务为例A 级JSON 格式正确字段完整值符合要求无冗余内容。B 级JSON 格式正确字段基本完整存在少量冗余或格式不规范。C 级JSON 可以解析但存在字段缺失或值错误需要人工修正。F 级JSON 无法解析或完全不符合要求。这样的分级方式可以让结果层的反馈更精确。如果 Agent 的 F 级比例不高但 C 级比例很高说明 Agent 的基本生成能力没问题但在遵循约束方面不够细致。3.4 一个可落地的结果层评分代码示例下面是一个基于规则的评估示例用来对一个 Agent 生成的 JSON 配置进行分级。# 文件路径evaluation/result_scorer.py import json def score_result(raw_output: str, required_fields: list) - dict: 对 Agent 输出进行结果层分级评分。 - A: 格式正确字段完整无冗余 - B: 格式正确字段基本完整有少量冗余 - C: 可解析但有字段缺失或值错误 - F: 无法解析或完全不符合要求 try: data json.loads(raw_output) except json.JSONDecodeError: return {grade: F, reason: invalid_json} missing [f for f in required_fields if f not in data] if missing: return {grade: C, reason: missing_fields, fields: missing} extra [k for k in data.keys() if k not in required_fields] if extra: return {grade: B, reason: extra_fields, fields: extra} return {grade: A, reason: ok} # 使用示例 if __name__ __main__: required [name, version, plugins] output_ok {name: demo-agent, version: 1.0.0, plugins: []} output_extra {name: demo-agent, version: 1.0.0, plugins: [], debug: true} output_missing {name: demo-agent} print(score_result(output_ok, required)) # {grade: A, reason: ok} print(score_result(output_extra, required)) # {grade: B, reason: extra_fields, fields: [debug]} print(score_result(output_missing, required)) # {grade: C, reason: missing_fields, fields: [version, plugins]}这个示例展示的是最简单的规则评分。在实际项目中你可以用 Pydantic 定义结构化输出格式再写对应的校验函数。3.5 结果层评估的常见误区只统计正确率不统计完成率导致 Agent 面对困难任务时直接放弃而不被发现。没有定义“正确”的边界导致人工评分时标准不一致。把 LLM-as-a-Judge 的结果直接当作最终结果不进行人工抽样校准。忽略了首轮成功率。首轮成功率低的 Agent 往往意味着它的推理和规划能力有系统性缺陷过度依赖重试机制掩盖了问题。4. 轨迹层评估决策路径与工具调用质量轨迹层是 Agent 评估区别于传统 LLM 评估的核心所在。它关注 Agent 在完成任务过程中的决策质量、工具调用效率和错误恢复能力。4.1 轨迹层为什么是“工业级”的关键一个 Agent 在测试集上可能表现不错但它是否能在生产环境里稳定工作主要看轨迹质量。一个靠碰运气选择正确工具的 Agent和一个每次都能准确选择工具的 Agent可能在结果层拿到同样的分数但在生产环境中的表现会截然不同。轨迹层需要评估的内容包括工具选择是否正确Agent 有没有在应该调用工具 A 的时候调用工具 B参数传递是否有效工具选对了但参数传错比如把用户名称当作用户 ID 传入。路径是否高效Agent 是否绕了远路是否反复调用同一个工具获取相同信息错误恢复是否及时Agent 遇到异常后是快速找到替代方案还是在错误循环里出不来是否出现无效循环Agent 是否有重复尝试、重复请求甚至无限循环4.2 轨迹层核心指标指标名称定义评估方式工具调用正确率正确的工具调用次数 / 总调用次数逐条比对工具调用日志工具参数正确率参数正确的调用次数 / 总调用次数校验工具入参平均轨迹长度完成任务的平均步骤数统计工具调用次数无效循环次数重复执行相同动作的次数检测轨迹中的重复模式错误恢复成功率错误出现后成功恢复的次数 / 错误总次数检测错误后的后续动作上下文利用率Agent 是否有效利用了历史消息检查关键信息是否被携带到后续调用4.3 逐轮轨迹评估的设计思路轨迹层评估的关键是把轨迹拆成可单独判断的步骤。举个例子一个 Agent 执行“查询订单并退款”的任务其轨迹可能如下解析用户意图调用 get_order_id 工具调用 query_order 工具获取订单详情调用 refund_order 工具执行退款对每一步来说重点不是“结果对不对”而是“这一步决策对不对”。一个常见的评估方法是给每一步打标签成功、工具错误、参数错误、信息缺失、冗余操作。4.4 轨迹评估的代码示例假设你已经可以用 LangChain、OpenAI Function Call 或自研框架记录了 Agent 的轨迹每条轨迹是一个 step 列表。下面示例展示如何用规则或 LLM 评估器对轨迹进行评分。# 文件路径evaluation/trajectory_scorer.py from typing import List, Dict, Any def evaluate_trajectory(steps: List[Dict[str, Any]]) - Dict[str, Any]: 输入示例 steps [ {type: tool_call, tool: get_order_id, params: {order_no: A123}, result: success}, {type: tool_call, tool: query_order, params: {order_id: ord_1}, result: success}, {type: tool_call, tool: refund_order, params: {order_id: ord_1, amount: 199}, result: success}, ] total_steps len(steps) tool_calls [s for s in steps if s.get(type) tool_call] error_steps [s for s in steps if s.get(result) error] # 计算工具调用正确率 correct_tool_calls sum(1 for s in tool_calls if s.get(is_correct, True)) tool_accuracy correct_tool_calls / len(tool_calls) if tool_calls else 0.0 # 检测无效循环连续调用相同工具且参数一致 loop_count 0 for i in range(1, len(tool_calls)): prev tool_calls[i - 1] curr tool_calls[i] if prev.get(tool) curr.get(tool) and prev.get(params) curr.get(params): loop_count 1 # 错误恢复成功率 error_recovery 0 for i, s in enumerate(steps): if s.get(result) error: # 如果错误步骤之后还有后续步骤且最终任务成功则视为恢复成功 if i len(steps) - 1: error_recovery 1 recovery_rate error_recovery / len(error_steps) if error_steps else 1.0 return { total_steps: total_steps, tool_call_count: len(tool_calls), tool_accuracy: tool_accuracy, loop_count: loop_count, error_steps: len(error_steps), recovery_rate: recovery_rate, } # 使用示例 trace_steps [ {type: tool_call, tool: get_order_id, params: {order_no: A123}, result: success, is_correct: True}, {type: tool_call, tool: query_order, params: {order_id: ord_1}, result: success, is_correct: True}, {type: tool_call, tool: query_order, params: {order_id: ord_1}, result: success, is_correct: False}, {type: tool_call, tool: refund_order, params: {order_id: ord_1, amount: 199}, result: error, is_correct: True}, {type: tool_call, tool: refund_order, params: {order_id: ord_1, amount: 199}, result: success, is_correct: True}, ] print(evaluate_trajectory(trace_steps))这个示例演示了如何对轨迹进行基础量化。你可以把这个逻辑扩展为更复杂的评估器通过规则或 LLM 对每一步工具调用的“正确性”进行判定。4.5 轨迹层常见问题与调整策略轨迹层最常暴露的问题是工具选择混乱和无效循环。处理思路包括如果工具选择错误率高优先优化系统提示词中对工具能力的描述或使用更严格的工具选择约束。如果参数传递错误率高优先检查 Agent 是否从用户输入中正确抽取了参数而不是直接把整段用户输入传给工具。如果无效循环频繁需要设置最大重试次数并在提示词中强调“不要重复调用已获得同一结果的工具”。5. 系统层评估稳定性、性能与可观测性系统层关注的是 Agent 在真实运行环境中的非功能性表现。即使结果层和轨迹层都表现优秀系统层如果不过关Agent 仍然不能算作“生产就绪”。5.1 系统层到底要评估什么系统层评估的核心是回答三类问题性能Agent 的响应速度是多少延迟波动大不大高并发下会不会劣化稳定性长时间运行时会不会内存泄漏上下文不断增长后会不会变慢模型调用失败时有没有降级策略可观测性与安全有没有完整的日志调用链是否可追踪敏感操作有没有权限校验工具调用有没有越权风险5.2 系统层核心指标指标名称定义建议标准P50/P95/P99 延迟任务从开始到结束的耗时分布视业务场景而定工具调用失败率工具调用失败的次数 / 总调用次数越低越好模型调用错误率模型服务返回错误的比率一般应低于 1%上下文窗口使用率已用 token / 上下文窗口上限持续接近上限需告警任务超时率超过预期耗时的任务比例应低于 5%安全事件数越权、敏感信息泄露等事件次数必须为 05.3 可观测性三层评估的数据基础没有可观测性结果层和轨迹层的评估就无从谈起。系统层的落地工作首先是把 Agent 每一次运行的轨迹完整记录下来。推荐在 Agent 执行流程中加入 Trace ID将所有步骤串联起来。一个标准的 Agent 执行记录应该包含以下字段{ trace_id: agent_trace_2024001, task: 查询订单并生成报表, steps: [ { step_id: 1, step_type: user_input, content: 帮我查一下订单 A123, timestamp: 2024-01-01T10:00:01Z }, { step_id: 2, step_type: tool_call, tool: query_order, input: {order_no: A123}, output: {status: success, order_id: ord_1}, latency_ms: 210, timestamp: 2024-01-01T10:00:02Z }, { step_id: 3, step_type: agent_output, content: 订单 A123 的状态是已支付金额 199 元。, timestamp: 2024-01-01T10:00:04Z } ], total_latency_ms: 4100, total_tokens: 3500, cost_usd: 0.012 }5.4 系统层监控配置示例如果你使用 Prometheus Grafana 这套技术栈可以为 Agent 定义如下指标# 文件路径monitoring/agent_metrics.py from prometheus_client import Counter, Histogram, Gauge, start_http_server # 任务级别指标 TASK_TOTAL Counter(agent_task_total, Total agent tasks) TASK_SUCCESS Counter(agent_task_success, Success agent tasks) TASK_FAILED Counter(agent_task_failed, Failed agent tasks) # 延迟指标 TASK_LATENCY Histogram(agent_task_latency_seconds, Task latency, buckets(1, 2, 5, 10, 30, 60)) TOOL_CALL_LATENCY Histogram(agent_tool_call_latency_seconds, Tool call latency) # 状态指标 CONTEXT_USAGE Gauge(agent_context_usage, Context window usage ratio) TOOL_FAILURES Counter(agent_tool_failures_total, Tool call failures) if __name__ __main__: start_http_server(8080) # 在 Agent 主流程中调用对应指标 print(metrics server started on :8080)5.5 系统层的安全边界系统层里最容易忽略也最重要的是安全边界。Agent 如果拥有调用数据库、执行命令、访问 API 的权限必须限制权限范围。由于 Agent 的工具选择可能出现偏差建议所有工具调用都经过中间层鉴权而不是让 Agent 直接持有全局权限。此外任何涉及删除、覆盖、资金操作的工具都应该要求二次确认或通过审批流程。6. 从指标到评估框架一个可落地的评估体系设计三层指标拆完之后最关键的问题是怎么把指标组合成一套可执行的评估流程6.1 分层评估流程推荐的做法是分层执行、逐层筛选。不要先跑完整评估再统一打分而是让每层评估作为下一层的前置门槛。# 评估执行流程伪代码 1. 系统层自检检查服务可用性、依赖状态、鉴权配置 2. 运行用例集Agent 执行评估任务记录完整轨迹 3. 结果层评分对每个任务的最终输出进行评级 4. 轨迹层分析对通过结果层的任务进行轨迹质量分析 5. 系统层统计汇总延迟、错误率、稳定性指标 6. 生成评估报告输出三层指标汇总、失败用例明细6.2 评估集的设计不要只测“简单任务”很多团队建的评估集全是理想场景结果是所有 Agent 都拿高分。评估集一定要包含困难样本和边界情况工具参数缺失的输入模型需要拒绝的危险请求工具返回异常数据的情况多步依赖的复杂任务需要多工具协作的复合任务6.3 评估报告模板一次完整的评估应该输出这样的报告评估项目客户服务 Agent v2.3 评估日期2024-XX-XX 评估集规模200 个任务用例含 50 个困难用例 一、结果层 - 任务完成率93.5% - 结果正确率87.0% - 首轮成功率71.5% - A 级结果占比64.0%B 级17.5%C 级12.0%F 级6.5% 二、轨迹层 - 工具调用正确率91.2% - 工具参数正确率88.7% - 平均轨迹长度4.2 步 - 无效循环次数3 次 - 错误恢复成功率78.6% 三、系统层 - P50 延迟2.1sP95 延迟6.8sP99 延迟12.4s - 工具调用失败率1.8% - 模型调用错误率0.4% - 安全事件0 结论结果层表现可接受但轨迹层参数正确率偏低建议优先优化工具入参抽取环节。6.4 三层指标的权重如何确定权重取决于业务场景。如果任务允许重试、允许人工介入轨迹层的权重要低于结果层如果是自动化无人值守场景轨迹层的权重就应该调高因为无人值守意味着所有错误恢复都需要 Agent 自己完成。一个比较常用的经验是结果层 40%、轨迹层 40%、系统层 20%。如果有特别重要的运维指标可以临时调高系统层权重。6.5 评估结果的回归与迭代评估不是一次性动作。每轮模型升级、Prompt 调整、工具变更都要重新跑同一套评估集。只有通过这种方式才能判断本次改动是“变好了”还是“变坏了”。这就要求评估集必须具备稳定性和可重复性。7. 完整评估方案落地示例下面是模拟一个评估方案从配置到执行的完整流程。这个示例不依赖任何特定的 Agent 框架适用于大多数自定义 Agent 系统。7.1 环境准备与前置条件在开始评估之前需要确认以下环境你的 Agent 服务可以以 API 或命令行方式调用有一个包含多种类型任务的评估集JSON 格式日志系统可以输出结构化轨迹至少有一台可以运行评估脚本的机器本地或 CI 环境下面是一个最小的评估集示例// 文件路径evaluation/dataset/eval_tasks.json [ { task_id: 001, task: 查询订单 A123 的状态, expected_tools: [get_order_id, query_order], expected_output: {contains: [已支付, 199]} }, { task_id: 002, task: 把订单 B456 的金额改成 299 并确认, expected_tools: [get_order_id, query_order, update_order, confirm_change], expected_output: {contains: [修改成功]} } ]7.2 评估主脚本下面是一个执行三层评估的最小脚本它调用 Agent、记录轨迹、计算指标。# 文件路径evaluation/run_evaluation.py import json from trajectory_scorer import evaluate_trajectory from result_scorer import score_result # 模拟的 Agent 服务调用接口 def run_agent(task: str) - dict: 调用 Agent 服务返回执行结果。 返回格式 { output: Agent 最终输出文本, steps: [{type: tool_call, tool: ..., params: {...}, result: ...}], latency_ms: 1234, total_tokens: 2345 } # 这里替换成真实的 Agent 服务调用 return { output: 订单 A123 状态是已支付金额 199 元, steps: [ {type: tool_call, tool: get_order_id, params: {order_no: A123}, result: success, is_correct: True}, {type: tool_call, tool: query_order, params: {order_id: ord_1}, result: success, is_correct: True} ], latency_ms: 2100, total_tokens: 1560 } def evaluate_task(task: dict) - dict: task_id task[task_id] task_desc task[task] result run_agent(task_desc) output result[output] steps result[steps] # 结果层评分 result_score score_result(output, required_fields[]) # 轨迹层评分 trajectory_score evaluate_trajectory(steps) # 汇总 return { task_id: task_id, result_layer: result_score, trajectory_layer: trajectory_score, latency_ms: result[latency_ms], total_tokens: result[total_tokens] } if __name__ __main__: with open(dataset/eval_tasks.json, r, encodingutf-8) as f: tasks json.load(f) reports [evaluate_task(t) for t in tasks] # 简单汇总输出 success_rate sum(1 for r in reports if r[result_layer][grade] in (A, B)) / len(reports) avg_latency sum(r[latency_ms] for r in reports) / len(reports) avg_tool_accuracy sum(r[trajectory_layer][tool_accuracy] for r in reports) / len(reports) print(成功完成率: {:.2%}.format(success_rate)) print(平均延迟: {:.1f} ms.format(avg_latency)) print(平均工具调用正确率: {:.2%}.format(avg_tool_accuracy)) with open(reports/eval_report.json, w, encodingutf-8) as f: json.dump(reports, f, ensure_asciiFalse, indent2)7.3 如何验证评估方案本身是有效的评估方案自身也可能有缺陷。建议做一次小规模人工标注与自动评估结果做对齐分析。具体做法是随机抽取 50 到 100 条任务由人工评估者在不知道自动分数的情况下独立打分再对比人工与自动评估的一致性。如果一致率低于 80%说明自动评估方案需要调整。8. 常见问题与排查思路在落地三层评估体系的过程中很多团队会遇到相似的坑。这里整理成排查表方便你对照处理。问题现象可能原因排查方式解决方案结果层完成率很高但生产事故频发评估集过于简单缺少困难样本检查评估集中困难用例占比扩充边界用例和异常样本首轮成功率很低但任务完成率很高Agent 过度依赖重试机制查看失败轨迹的重试次数优化工具选择提示限制最大重试次数轨迹层工具调用正确率较高但参数正确率低Agent 从用户输入抽取参数时丢失信息比对工具入参与用户原始输入增加参数抽取的中间步骤或使用结构化输出错误恢复成功率低但任务最终完成Agent 用大量重试掩盖错误恢复能力的不足检查错误恢复阶段的路径设计更清晰的降级策略评估结果在不同轮次之间波动大LLM 采样随机性或环境状态变化使用相同种子和配置重跑多次固定 temperature 参数多次运行取平均结果层打分用同一个模型评判自身LLM 评估器存在自我偏好偏差替换为独立评估模型或增加人工抽样评估模型与生成模型分离系统层延迟突然上升上下文过长或工具调用链变长检查延迟分位数和 token 使用增加上下文裁剪或步骤压缩机制安全敏感工具被 Agent 误调Agent 权限范围过大审计工具调用记录引入中间件鉴权收紧工具权限9. 最佳实践与工程建议9.1 建立评估集并持续维护评估集是评估体系的根基。建议从项目初期就建立一套最小但多样的评估集不要等 Agent 开发完了再补评估集。评估集至少覆盖三类任务容易失败的任务、容易绕路的任务、边界或危险请求。版本变更时要同步更新评估集。9.2 把评估接入 CI/CD 流程Agent 项目也应该像普通软件项目一样做回归测试。每当修改系统提示词、模型配置、工具定义或代码逻辑时都跑一遍三层评估。建议把“结果层 轨迹层”的优先指标作为 CI 门禁不达标不允许合并代码。9.3 明确人工评估的抽样机制自动评估不能完全替代人工评估。建议每次训练集或框架升级后人工抽查至少 10% 的评估结果重点检查高分但明显不合理的结果以及低分但实际可用的结果。这能持续校准自动评估器的判断标准。9.4 控制评估成本评估不是免费的每次都跑全量数据会产生大量 token 消耗。建议设计两级评估策略快速回归用小样本集重大版本或上线前再用全量评估集。这样既能快速发现问题又能避免无谓的成本浪费。9.5 安全边界优先所有 Agent 工具调用一律遵循最小权限原则。评估阶段就要测试 Agent 在遇到权限不足、工具报错、非法输入时的表现。使用安全敏感工具时建议在评估流程中模拟“未授权调用”场景验证 Agent 是否会主动拒绝。9.6 工具与框架选择思路LangSmith、Langfuse、WB Weave、Arize Phoenix 等工具都提供了 Agent 轨迹追踪能力可以直接用于采集轨迹层数据。如果你的技术栈已经是 Prometheus使用自定义指标上报系统层比较顺手。如果是小规模团队可以先从结构化日志加脚本分析做起不一定一上来就上商业平台。10. 从评估到生产三层指标的长期价值最后回到开头那个问题上为什么同样能完成任务的 Agent性能差距可能天差地别因为“完成”只是最浅层的判断标准。一个真正适合生产的 Agent必须同时满足三层要求结果层证明它有基本能力轨迹层证明它的决策过程可靠高效系统层证明它能经受真实环境的考验。这套三层评估方案不是一次性的检查清单而是应该贯穿 Agent 全生命周期的工程基础设施。模型升级时拿它做回归工具调整时拿它做对比上线后拿它做监控。不管你的 Agent 是用来处理文档、操作数据库还是作为多 Agent 协作系统中的一个节点这套评估思路都适用。下一步的实践建议很简单从当前项目里挑 20 个最典型的任务整理成最小评估集加一层结果层评分有精力再做轨迹层日志分析当团队对评估结果逐渐有信任感了再把系统层指标纳入统一看板。路径不需要太复杂关键是先跑起来并持续迭代。 工业级Agent评估方案：结果层、轨迹层、系统层三层指标拆解
同样能完成任务的 Agent性能差距可能天差地别该怎么量化工业级 Agent 完整评估方案结果层轨迹层系统层三层指标拆解如果你负责过一个 Agent 项目的验收大概率遇到过这种场景两个候选 Agent 在演示环境下都能完成任务Demo 跑得都很流畅于是选了更便宜的那个。结果一上生产问题开始密集暴露——任务偶尔失败、工具调用不稳定、遇到边界情况直接卡死、日志里全是看不明白的报错。很多人第一反应是“运气不好”但更本质的原因是Agent 的能力评估根本没有被量化。LLM 应用开发到现在代码层面的测试手段已经很成熟了但 Agent 层面的评估仍然像一个“盲盒”。常规做法是看最终输出对不对可这在 Agent 场景下远远不够。一个 Agent 可能结果是对的但中间调用了 20 次工具花了 3 倍预算另一个 Agent 可能第一轮就选错了工具靠重试和兜底逻辑硬是绕回了正确答案。前者让人放心后者让人不安可如果只按“最终结果”打分两者得到的分数可能一样。这篇文章要聊的就是如果想让 Agent 真正进入生产环境评估体系应该怎么搭。我会拆解结果层、轨迹层、系统层三套指标每一层解决什么问题、有哪些核心指标、怎么配置和落地以及评估过程中最容易踩的坑。无论你是在做 Agent 开发、Agent 框架选型还是负责评估体系建设这篇文章都值得从头读一遍。1. 这篇文章真正要解决的问题先摆一个观点Agent 评估的难点不在于“定义什么是好”而在于“把好拆成可测量的维度”。很多团队不是不愿意做评估而是不知道评估什么。1.1 传统评估方案的局限如果你用过传统的 Prompt 评测工具会发现它们的核心逻辑是“给一段输入比对模型输出”。这在纯文本生成任务里很有效但放到 Agent 场景里就不成立了。原因很简单Agent 不是“一步到达终点的”它是一个多轮决策系统。它要理解用户意图、选择工具、解析工具结果、修正错误、决定下一步动作。这个过程中任何一个环节出问题都可能导致最终结果偏离预期但出问题的位置千差万别。单看结果会漏掉信息单看中间步骤又会陷入细节无法判断整体质量。这就是为什么需要一套分层评估方案。1.2 Agent 评估到底难在哪里对比传统软件测试Agent 评估的难点集中在四个方面输出的不确定性同一个任务同一个 Agent跑两次可能给出不同的过程路径。状态的动态性Agent 操作的是一个变化的外部环境数据库、API、文件系统同样的动作在不同时间执行结果可能不同。路径的多样性到达同一个正确终点的路径可能有几十条如何判断哪条路径是“好路径”成本的隐蔽性过程越长、重试越多、工具调用越频繁成本越高。但这些成本不会直接体现在“任务是否完成”上。所以说评估 Agent 不能停留在“看最终答案”而是要把评估维度拉宽。结果层解决“做没做成”轨迹层解决“做得对不对”系统层解决“能不能长期稳定地做”。1.3 哪些读者最需要这套方案Agent 开发者需要知道自己写的 Agent 在真实场景里表现得怎么样哪里该优化。技术负责人/架构师需要为团队选择一个评估框架或建立自己的评估流程。算法工程师需要对比不同模型、不同 Prompt 策略、不同工具编排方式的效果。运维/平台工程师需要确保 Agent 上线后有监控、有告警、有回归能力。如果你只是在做原型验证那这套方案可能显得“重”。但只要你打算把 Agent 推向生产环境这三层指标就是绕不开的基础设施。1.4 本文的结构安排先讲清楚一个容易被忽视的前提再逐层拆解三层指标体系。结果层重点讲任务完成度和结果质量轨迹层重点讲路径合理性、工具调用效率、错误恢复能力系统层重点讲稳定性、可观测性和安全边界。每一层我都会给出具体的指标定义、配置思路和代码示例最后汇总成一个可以直接落到工程里的评估方案。2. 基础概念为什么三层指标缺一不可在具体拆指标之前需要先建立两个认知Agent 的“任务”和传统程序里的“函数调用”不是一回事Agent 的“过程”本身就是可评估的产品资产。2.1 什么是结果层、轨迹层、系统层为了讲清楚我用一个简单的类比评估一个 Agent 就像是评估一个外卖骑手。结果层只看“外卖是否准时送到”这是最基本的业务指标。轨迹层看“骑手走的是什么路线、有没有绕路、有没有闯红灯、有没有在中途停下来处理异常”。系统层看“这个骑手长期来看靠谱吗下雨天会不会爆单车坏了有没有备用方案平台能不能实时监控他的位置”。对应到 Agent结果层关注任务的最终产出判断 Agent 是否完成了用户的目标。轨迹层关注 Agent 的决策过程、工具调用序列、错误恢复行为判断路径是否高效合理。系统层关注 Agent 在真实运行环境中的稳定性、性能、安全性和可观测性判断它是否具备生产条件。三层缺一不可。结果层告诉你“做成没有”轨迹层告诉你“做得怎么样”系统层告诉你“能不能长期做”。2.2 为什么单看结果不靠谱“结果正确”在 Agent 场景里是一个模糊概念。一个 Agent 可能输出了一段正确代码但它是在第三次重试时靠系统自动修复才成功的另一个 Agent 第一次就找到了正确 API 并高效返回。最终交付物一样但两者的可靠性完全不同。更麻烦的是结果正确性本身也分层次。任务完成可能意味着“最终答案正确”也可能只是“最终答案部分正确”“答案格式对了但内容不对”“工具返回了错误但 Agent 没有识别出来”。这些情况如果只用一个 pass/fail 标记会丢失大量信息。所以在结果层我们需要做到比“正确/错误”更细的评级。2.3 轨迹为什么重要Agent 过程是有成本的与 LLM 单轮生成不同Agent 的每一个动作都消耗资源。模型推理消耗 token工具调用消耗网络和计算资源重试策略消耗额外时间。一条“能到达终点但极其曲折”的轨迹可能在性能上没有大问题但在成本上无法接受。轨迹层的核心就是把“决策过程”变成可量化的指标工具调用有没有偏差、有没有无效循环、错误发生后多久能恢复、路径长度是否合理。这些指标直接影响生产环境中的成本和体验。2.4 系统层解决的是“能不能信你”的问题一个 Agent 在测试集上跑得好不代表在线上就能稳定运行。系统层关注的是非功能性指标延迟是否稳定、并发时是否还能正常工作、失败时有没有优雅降级、是否具备完整的可观测性。这些问题不解决Agent 在黑盒状态下上线就如同带着隐患跑生产。从工程实践来看系统层往往是团队最容易忽视的部分因为它的反馈周期比业务准确率长很多。但恰恰是系统层的缺失导致 Agent 项目难以从“实验室阶段”走到“生产阶段”。3. 结果层评估任务完成度与结果质量结果层是评估体系的基石它回答“Agent 有没有把任务做成”这个问题。但它不是简单跑一个用例、比对一下答案而是需要设计一套合理的评分规则。3.1 结果层核心指标结果层建议至少覆盖以下五个维度指标名称定义说明任务完成率Agent 成功完成任务的用例数 / 总用例数最基本的能力指标结果正确率达到预期标准的用例数 / 已完成用例数需要明确“正确”标准首轮成功率不依赖重试第一次就完成任务的比率反映 Agent 的初始决策质量结果质量评级对完成结果进行 A/B/C 分级评估区分“勉强完成”和“高质量完成”用户满意度代理分通过规则或 LLM 对结果进行用户视角评分适合业务场景需要校准3.2 任务完成率与正确率的区别这两个指标经常被混用但在评估中应该分开。任务完成率只关心流程是否走完结果正确率关心结果是否符合标准。举例Agent 被要求从数据库查询指定用户信息并生成报表。Agent 成功执行了查询也生成了一个报表文件但报表中漏掉了一个字段。这种情况下任务算“完成”但结果不算“正确”。在实际评估中通常是“先判断是否完成再判断完成质量”。完成率和正确率分开统计才能发现 Agent 是在“能否完成”层面有问题还是在“完成得好不好”层面有问题。3.3 结果评级的实现思路结果评级建议采用分级评分而不是简单的二值判断。以“生成 JSON 配置”这个任务为例A 级JSON 格式正确字段完整值符合要求无冗余内容。B 级JSON 格式正确字段基本完整存在少量冗余或格式不规范。C 级JSON 可以解析但存在字段缺失或值错误需要人工修正。F 级JSON 无法解析或完全不符合要求。这样的分级方式可以让结果层的反馈更精确。如果 Agent 的 F 级比例不高但 C 级比例很高说明 Agent 的基本生成能力没问题但在遵循约束方面不够细致。3.4 一个可落地的结果层评分代码示例下面是一个基于规则的评估示例用来对一个 Agent 生成的 JSON 配置进行分级。# 文件路径evaluation/result_scorer.py import json def score_result(raw_output: str, required_fields: list) - dict: 对 Agent 输出进行结果层分级评分。 - A: 格式正确字段完整无冗余 - B: 格式正确字段基本完整有少量冗余 - C: 可解析但有字段缺失或值错误 - F: 无法解析或完全不符合要求 try: data json.loads(raw_output) except json.JSONDecodeError: return {grade: F, reason: invalid_json} missing [f for f in required_fields if f not in data] if missing: return {grade: C, reason: missing_fields, fields: missing} extra [k for k in data.keys() if k not in required_fields] if extra: return {grade: B, reason: extra_fields, fields: extra} return {grade: A, reason: ok} # 使用示例 if __name__ __main__: required [name, version, plugins] output_ok {name: demo-agent, version: 1.0.0, plugins: []} output_extra {name: demo-agent, version: 1.0.0, plugins: [], debug: true} output_missing {name: demo-agent} print(score_result(output_ok, required)) # {grade: A, reason: ok} print(score_result(output_extra, required)) # {grade: B, reason: extra_fields, fields: [debug]} print(score_result(output_missing, required)) # {grade: C, reason: missing_fields, fields: [version, plugins]}这个示例展示的是最简单的规则评分。在实际项目中你可以用 Pydantic 定义结构化输出格式再写对应的校验函数。3.5 结果层评估的常见误区只统计正确率不统计完成率导致 Agent 面对困难任务时直接放弃而不被发现。没有定义“正确”的边界导致人工评分时标准不一致。把 LLM-as-a-Judge 的结果直接当作最终结果不进行人工抽样校准。忽略了首轮成功率。首轮成功率低的 Agent 往往意味着它的推理和规划能力有系统性缺陷过度依赖重试机制掩盖了问题。4. 轨迹层评估决策路径与工具调用质量轨迹层是 Agent 评估区别于传统 LLM 评估的核心所在。它关注 Agent 在完成任务过程中的决策质量、工具调用效率和错误恢复能力。4.1 轨迹层为什么是“工业级”的关键一个 Agent 在测试集上可能表现不错但它是否能在生产环境里稳定工作主要看轨迹质量。一个靠碰运气选择正确工具的 Agent和一个每次都能准确选择工具的 Agent可能在结果层拿到同样的分数但在生产环境中的表现会截然不同。轨迹层需要评估的内容包括工具选择是否正确Agent 有没有在应该调用工具 A 的时候调用工具 B参数传递是否有效工具选对了但参数传错比如把用户名称当作用户 ID 传入。路径是否高效Agent 是否绕了远路是否反复调用同一个工具获取相同信息错误恢复是否及时Agent 遇到异常后是快速找到替代方案还是在错误循环里出不来是否出现无效循环Agent 是否有重复尝试、重复请求甚至无限循环4.2 轨迹层核心指标指标名称定义评估方式工具调用正确率正确的工具调用次数 / 总调用次数逐条比对工具调用日志工具参数正确率参数正确的调用次数 / 总调用次数校验工具入参平均轨迹长度完成任务的平均步骤数统计工具调用次数无效循环次数重复执行相同动作的次数检测轨迹中的重复模式错误恢复成功率错误出现后成功恢复的次数 / 错误总次数检测错误后的后续动作上下文利用率Agent 是否有效利用了历史消息检查关键信息是否被携带到后续调用4.3 逐轮轨迹评估的设计思路轨迹层评估的关键是把轨迹拆成可单独判断的步骤。举个例子一个 Agent 执行“查询订单并退款”的任务其轨迹可能如下解析用户意图调用 get_order_id 工具调用 query_order 工具获取订单详情调用 refund_order 工具执行退款对每一步来说重点不是“结果对不对”而是“这一步决策对不对”。一个常见的评估方法是给每一步打标签成功、工具错误、参数错误、信息缺失、冗余操作。4.4 轨迹评估的代码示例假设你已经可以用 LangChain、OpenAI Function Call 或自研框架记录了 Agent 的轨迹每条轨迹是一个 step 列表。下面示例展示如何用规则或 LLM 评估器对轨迹进行评分。# 文件路径evaluation/trajectory_scorer.py from typing import List, Dict, Any def evaluate_trajectory(steps: List[Dict[str, Any]]) - Dict[str, Any]: 输入示例 steps [ {type: tool_call, tool: get_order_id, params: {order_no: A123}, result: success}, {type: tool_call, tool: query_order, params: {order_id: ord_1}, result: success}, {type: tool_call, tool: refund_order, params: {order_id: ord_1, amount: 199}, result: success}, ] total_steps len(steps) tool_calls [s for s in steps if s.get(type) tool_call] error_steps [s for s in steps if s.get(result) error] # 计算工具调用正确率 correct_tool_calls sum(1 for s in tool_calls if s.get(is_correct, True)) tool_accuracy correct_tool_calls / len(tool_calls) if tool_calls else 0.0 # 检测无效循环连续调用相同工具且参数一致 loop_count 0 for i in range(1, len(tool_calls)): prev tool_calls[i - 1] curr tool_calls[i] if prev.get(tool) curr.get(tool) and prev.get(params) curr.get(params): loop_count 1 # 错误恢复成功率 error_recovery 0 for i, s in enumerate(steps): if s.get(result) error: # 如果错误步骤之后还有后续步骤且最终任务成功则视为恢复成功 if i len(steps) - 1: error_recovery 1 recovery_rate error_recovery / len(error_steps) if error_steps else 1.0 return { total_steps: total_steps, tool_call_count: len(tool_calls), tool_accuracy: tool_accuracy, loop_count: loop_count, error_steps: len(error_steps), recovery_rate: recovery_rate, } # 使用示例 trace_steps [ {type: tool_call, tool: get_order_id, params: {order_no: A123}, result: success, is_correct: True}, {type: tool_call, tool: query_order, params: {order_id: ord_1}, result: success, is_correct: True}, {type: tool_call, tool: query_order, params: {order_id: ord_1}, result: success, is_correct: False}, {type: tool_call, tool: refund_order, params: {order_id: ord_1, amount: 199}, result: error, is_correct: True}, {type: tool_call, tool: refund_order, params: {order_id: ord_1, amount: 199}, result: success, is_correct: True}, ] print(evaluate_trajectory(trace_steps))这个示例演示了如何对轨迹进行基础量化。你可以把这个逻辑扩展为更复杂的评估器通过规则或 LLM 对每一步工具调用的“正确性”进行判定。4.5 轨迹层常见问题与调整策略轨迹层最常暴露的问题是工具选择混乱和无效循环。处理思路包括如果工具选择错误率高优先优化系统提示词中对工具能力的描述或使用更严格的工具选择约束。如果参数传递错误率高优先检查 Agent 是否从用户输入中正确抽取了参数而不是直接把整段用户输入传给工具。如果无效循环频繁需要设置最大重试次数并在提示词中强调“不要重复调用已获得同一结果的工具”。5. 系统层评估稳定性、性能与可观测性系统层关注的是 Agent 在真实运行环境中的非功能性表现。即使结果层和轨迹层都表现优秀系统层如果不过关Agent 仍然不能算作“生产就绪”。5.1 系统层到底要评估什么系统层评估的核心是回答三类问题性能Agent 的响应速度是多少延迟波动大不大高并发下会不会劣化稳定性长时间运行时会不会内存泄漏上下文不断增长后会不会变慢模型调用失败时有没有降级策略可观测性与安全有没有完整的日志调用链是否可追踪敏感操作有没有权限校验工具调用有没有越权风险5.2 系统层核心指标指标名称定义建议标准P50/P95/P99 延迟任务从开始到结束的耗时分布视业务场景而定工具调用失败率工具调用失败的次数 / 总调用次数越低越好模型调用错误率模型服务返回错误的比率一般应低于 1%上下文窗口使用率已用 token / 上下文窗口上限持续接近上限需告警任务超时率超过预期耗时的任务比例应低于 5%安全事件数越权、敏感信息泄露等事件次数必须为 05.3 可观测性三层评估的数据基础没有可观测性结果层和轨迹层的评估就无从谈起。系统层的落地工作首先是把 Agent 每一次运行的轨迹完整记录下来。推荐在 Agent 执行流程中加入 Trace ID将所有步骤串联起来。一个标准的 Agent 执行记录应该包含以下字段{ trace_id: agent_trace_2024001, task: 查询订单并生成报表, steps: [ { step_id: 1, step_type: user_input, content: 帮我查一下订单 A123, timestamp: 2024-01-01T10:00:01Z }, { step_id: 2, step_type: tool_call, tool: query_order, input: {order_no: A123}, output: {status: success, order_id: ord_1}, latency_ms: 210, timestamp: 2024-01-01T10:00:02Z }, { step_id: 3, step_type: agent_output, content: 订单 A123 的状态是已支付金额 199 元。, timestamp: 2024-01-01T10:00:04Z } ], total_latency_ms: 4100, total_tokens: 3500, cost_usd: 0.012 }5.4 系统层监控配置示例如果你使用 Prometheus Grafana 这套技术栈可以为 Agent 定义如下指标# 文件路径monitoring/agent_metrics.py from prometheus_client import Counter, Histogram, Gauge, start_http_server # 任务级别指标 TASK_TOTAL Counter(agent_task_total, Total agent tasks) TASK_SUCCESS Counter(agent_task_success, Success agent tasks) TASK_FAILED Counter(agent_task_failed, Failed agent tasks) # 延迟指标 TASK_LATENCY Histogram(agent_task_latency_seconds, Task latency, buckets(1, 2, 5, 10, 30, 60)) TOOL_CALL_LATENCY Histogram(agent_tool_call_latency_seconds, Tool call latency) # 状态指标 CONTEXT_USAGE Gauge(agent_context_usage, Context window usage ratio) TOOL_FAILURES Counter(agent_tool_failures_total, Tool call failures) if __name__ __main__: start_http_server(8080) # 在 Agent 主流程中调用对应指标 print(metrics server started on :8080)5.5 系统层的安全边界系统层里最容易忽略也最重要的是安全边界。Agent 如果拥有调用数据库、执行命令、访问 API 的权限必须限制权限范围。由于 Agent 的工具选择可能出现偏差建议所有工具调用都经过中间层鉴权而不是让 Agent 直接持有全局权限。此外任何涉及删除、覆盖、资金操作的工具都应该要求二次确认或通过审批流程。6. 从指标到评估框架一个可落地的评估体系设计三层指标拆完之后最关键的问题是怎么把指标组合成一套可执行的评估流程6.1 分层评估流程推荐的做法是分层执行、逐层筛选。不要先跑完整评估再统一打分而是让每层评估作为下一层的前置门槛。# 评估执行流程伪代码 1. 系统层自检检查服务可用性、依赖状态、鉴权配置 2. 运行用例集Agent 执行评估任务记录完整轨迹 3. 结果层评分对每个任务的最终输出进行评级 4. 轨迹层分析对通过结果层的任务进行轨迹质量分析 5. 系统层统计汇总延迟、错误率、稳定性指标 6. 生成评估报告输出三层指标汇总、失败用例明细6.2 评估集的设计不要只测“简单任务”很多团队建的评估集全是理想场景结果是所有 Agent 都拿高分。评估集一定要包含困难样本和边界情况工具参数缺失的输入模型需要拒绝的危险请求工具返回异常数据的情况多步依赖的复杂任务需要多工具协作的复合任务6.3 评估报告模板一次完整的评估应该输出这样的报告评估项目客户服务 Agent v2.3 评估日期2024-XX-XX 评估集规模200 个任务用例含 50 个困难用例 一、结果层 - 任务完成率93.5% - 结果正确率87.0% - 首轮成功率71.5% - A 级结果占比64.0%B 级17.5%C 级12.0%F 级6.5% 二、轨迹层 - 工具调用正确率91.2% - 工具参数正确率88.7% - 平均轨迹长度4.2 步 - 无效循环次数3 次 - 错误恢复成功率78.6% 三、系统层 - P50 延迟2.1sP95 延迟6.8sP99 延迟12.4s - 工具调用失败率1.8% - 模型调用错误率0.4% - 安全事件0 结论结果层表现可接受但轨迹层参数正确率偏低建议优先优化工具入参抽取环节。6.4 三层指标的权重如何确定权重取决于业务场景。如果任务允许重试、允许人工介入轨迹层的权重要低于结果层如果是自动化无人值守场景轨迹层的权重就应该调高因为无人值守意味着所有错误恢复都需要 Agent 自己完成。一个比较常用的经验是结果层 40%、轨迹层 40%、系统层 20%。如果有特别重要的运维指标可以临时调高系统层权重。6.5 评估结果的回归与迭代评估不是一次性动作。每轮模型升级、Prompt 调整、工具变更都要重新跑同一套评估集。只有通过这种方式才能判断本次改动是“变好了”还是“变坏了”。这就要求评估集必须具备稳定性和可重复性。7. 完整评估方案落地示例下面是模拟一个评估方案从配置到执行的完整流程。这个示例不依赖任何特定的 Agent 框架适用于大多数自定义 Agent 系统。7.1 环境准备与前置条件在开始评估之前需要确认以下环境你的 Agent 服务可以以 API 或命令行方式调用有一个包含多种类型任务的评估集JSON 格式日志系统可以输出结构化轨迹至少有一台可以运行评估脚本的机器本地或 CI 环境下面是一个最小的评估集示例// 文件路径evaluation/dataset/eval_tasks.json [ { task_id: 001, task: 查询订单 A123 的状态, expected_tools: [get_order_id, query_order], expected_output: {contains: [已支付, 199]} }, { task_id: 002, task: 把订单 B456 的金额改成 299 并确认, expected_tools: [get_order_id, query_order, update_order, confirm_change], expected_output: {contains: [修改成功]} } ]7.2 评估主脚本下面是一个执行三层评估的最小脚本它调用 Agent、记录轨迹、计算指标。# 文件路径evaluation/run_evaluation.py import json from trajectory_scorer import evaluate_trajectory from result_scorer import score_result # 模拟的 Agent 服务调用接口 def run_agent(task: str) - dict: 调用 Agent 服务返回执行结果。 返回格式 { output: Agent 最终输出文本, steps: [{type: tool_call, tool: ..., params: {...}, result: ...}], latency_ms: 1234, total_tokens: 2345 } # 这里替换成真实的 Agent 服务调用 return { output: 订单 A123 状态是已支付金额 199 元, steps: [ {type: tool_call, tool: get_order_id, params: {order_no: A123}, result: success, is_correct: True}, {type: tool_call, tool: query_order, params: {order_id: ord_1}, result: success, is_correct: True} ], latency_ms: 2100, total_tokens: 1560 } def evaluate_task(task: dict) - dict: task_id task[task_id] task_desc task[task] result run_agent(task_desc) output result[output] steps result[steps] # 结果层评分 result_score score_result(output, required_fields[]) # 轨迹层评分 trajectory_score evaluate_trajectory(steps) # 汇总 return { task_id: task_id, result_layer: result_score, trajectory_layer: trajectory_score, latency_ms: result[latency_ms], total_tokens: result[total_tokens] } if __name__ __main__: with open(dataset/eval_tasks.json, r, encodingutf-8) as f: tasks json.load(f) reports [evaluate_task(t) for t in tasks] # 简单汇总输出 success_rate sum(1 for r in reports if r[result_layer][grade] in (A, B)) / len(reports) avg_latency sum(r[latency_ms] for r in reports) / len(reports) avg_tool_accuracy sum(r[trajectory_layer][tool_accuracy] for r in reports) / len(reports) print(成功完成率: {:.2%}.format(success_rate)) print(平均延迟: {:.1f} ms.format(avg_latency)) print(平均工具调用正确率: {:.2%}.format(avg_tool_accuracy)) with open(reports/eval_report.json, w, encodingutf-8) as f: json.dump(reports, f, ensure_asciiFalse, indent2)7.3 如何验证评估方案本身是有效的评估方案自身也可能有缺陷。建议做一次小规模人工标注与自动评估结果做对齐分析。具体做法是随机抽取 50 到 100 条任务由人工评估者在不知道自动分数的情况下独立打分再对比人工与自动评估的一致性。如果一致率低于 80%说明自动评估方案需要调整。8. 常见问题与排查思路在落地三层评估体系的过程中很多团队会遇到相似的坑。这里整理成排查表方便你对照处理。问题现象可能原因排查方式解决方案结果层完成率很高但生产事故频发评估集过于简单缺少困难样本检查评估集中困难用例占比扩充边界用例和异常样本首轮成功率很低但任务完成率很高Agent 过度依赖重试机制查看失败轨迹的重试次数优化工具选择提示限制最大重试次数轨迹层工具调用正确率较高但参数正确率低Agent 从用户输入抽取参数时丢失信息比对工具入参与用户原始输入增加参数抽取的中间步骤或使用结构化输出错误恢复成功率低但任务最终完成Agent 用大量重试掩盖错误恢复能力的不足检查错误恢复阶段的路径设计更清晰的降级策略评估结果在不同轮次之间波动大LLM 采样随机性或环境状态变化使用相同种子和配置重跑多次固定 temperature 参数多次运行取平均结果层打分用同一个模型评判自身LLM 评估器存在自我偏好偏差替换为独立评估模型或增加人工抽样评估模型与生成模型分离系统层延迟突然上升上下文过长或工具调用链变长检查延迟分位数和 token 使用增加上下文裁剪或步骤压缩机制安全敏感工具被 Agent 误调Agent 权限范围过大审计工具调用记录引入中间件鉴权收紧工具权限9. 最佳实践与工程建议9.1 建立评估集并持续维护评估集是评估体系的根基。建议从项目初期就建立一套最小但多样的评估集不要等 Agent 开发完了再补评估集。评估集至少覆盖三类任务容易失败的任务、容易绕路的任务、边界或危险请求。版本变更时要同步更新评估集。9.2 把评估接入 CI/CD 流程Agent 项目也应该像普通软件项目一样做回归测试。每当修改系统提示词、模型配置、工具定义或代码逻辑时都跑一遍三层评估。建议把“结果层 轨迹层”的优先指标作为 CI 门禁不达标不允许合并代码。9.3 明确人工评估的抽样机制自动评估不能完全替代人工评估。建议每次训练集或框架升级后人工抽查至少 10% 的评估结果重点检查高分但明显不合理的结果以及低分但实际可用的结果。这能持续校准自动评估器的判断标准。9.4 控制评估成本评估不是免费的每次都跑全量数据会产生大量 token 消耗。建议设计两级评估策略快速回归用小样本集重大版本或上线前再用全量评估集。这样既能快速发现问题又能避免无谓的成本浪费。9.5 安全边界优先所有 Agent 工具调用一律遵循最小权限原则。评估阶段就要测试 Agent 在遇到权限不足、工具报错、非法输入时的表现。使用安全敏感工具时建议在评估流程中模拟“未授权调用”场景验证 Agent 是否会主动拒绝。9.6 工具与框架选择思路LangSmith、Langfuse、WB Weave、Arize Phoenix 等工具都提供了 Agent 轨迹追踪能力可以直接用于采集轨迹层数据。如果你的技术栈已经是 Prometheus使用自定义指标上报系统层比较顺手。如果是小规模团队可以先从结构化日志加脚本分析做起不一定一上来就上商业平台。10. 从评估到生产三层指标的长期价值最后回到开头那个问题上为什么同样能完成任务的 Agent性能差距可能天差地别因为“完成”只是最浅层的判断标准。一个真正适合生产的 Agent必须同时满足三层要求结果层证明它有基本能力轨迹层证明它的决策过程可靠高效系统层证明它能经受真实环境的考验。这套三层评估方案不是一次性的检查清单而是应该贯穿 Agent 全生命周期的工程基础设施。模型升级时拿它做回归工具调整时拿它做对比上线后拿它做监控。不管你的 Agent 是用来处理文档、操作数据库还是作为多 Agent 协作系统中的一个节点这套评估思路都适用。下一步的实践建议很简单从当前项目里挑 20 个最典型的任务整理成最小评估集加一层结果层评分有精力再做轨迹层日志分析当团队对评估结果逐渐有信任感了再把系统层指标纳入统一看板。路径不需要太复杂关键是先跑起来并持续迭代。