企业官网建设流程全解析

目录

一、Agent 评测已经从“答案打分”进入“行为系统验证”

（一）传统 LLM 评测为什么不够

1、一个正确答案，可能来自一条错误路径

2、Agent 的失败具有级联性

（二）从三个常用指标扩展为四层质量模型

1、第一层：结果质量——任务到底完成了吗

2、第二层：动作质量——工具是否选对、参数是否正确

3、第三层：推理质量——计划是否合理、执行是否遵循

4、第四层：运行约束——效率、安全、成本与权限

二、先把最小评测跑起来，但不要停在 Hello World

（一）最小闭环的意义，是验证评测基础设施

1、第一条测试不应该追求“指标齐全”

2. 写一个确定性更强的工具契约测试

（二）版本锁定比“代码能运行一次”更重要

1、评测框架本身也在快速变化

2. 不要把默认 Judge 模型当成永久配置

三、Trace-first：Agent 评测真正的工程分水岭

（一）为什么 Trace 是 Agent 评测的“数据底座”

1、没有 Trace，评测只能看到结果，不能解释结果

2、端到端与组件级不是二选一，而是上下两层

（二）用 Trace 把测试从“文本样例”升级为“执行样例”

1、Trace 中应该保存哪些最小信息

2、不要把敏感原始数据无限制写入 Trace

四、指标体系：不要堆指标，要建立职责分工

（一）TaskCompletionMetric：用“是否达成目标”做北极星指标

1、它衡量的是 Outcome，而不是文案质量

2、Task Completion 不能替代全部指标

（二）ToolCorrectnessMetric：把动作层变成可测试契约

1、工具名正确只是最低要求

2、确定性规则优先于 LLM Judge

（三）PlanQualityMetric 与 PlanAdherenceMetric：分别评“想得对”和“做得像”

1、Plan Quality 解决“第一步就想错了”

2、Plan Adherence 解决“计划很好但中途跑偏”

没有显式计划时，计划指标可能产生“虚假的好成绩”

（四）StepEfficiencyMetric：让 Agent 不仅成功，还要少走弯路

（五）GEval：把业务标准写进评测，但必须可操作

五、LLM-as-Judge 不是“自动真理”，而是一套需要校准的测量系统

（一）为什么强 Judge 仍然会不稳定

1、Judge 会受到顺序、长度与自我偏好影响

2、评判器与被评测对象必须一起版本化

（二）构建 Judge 信任度的五步法

1、先用小规模人工标注建立校准集

2、对边界样例做重复评测

3、优先让规则承担客观判断

4、对关键指标设置“灰区”而不是单一阈值

5、定期用人工复核检查 Judge 漂移

六、评测数据集才是长期壁垒：从样例集合走向失败模式资产

（一）为什么手写 20 条测试永远不够

（二）建议把数据集拆成四类

1、Golden Set：稳定验证核心能力

2、Regression Set：每次线上事故都“买一张永久门票”

3、Edge Set：专门打边界条件

4、Adversarial Set：验证提示注入与越权风险

（三）数据集版本化比不断加样例更重要

七、CI/CD 质量门禁：评测必须参与“能不能合并”的决策

（一）不要把全部评测都塞进每个 PR

（二）夜间回归承担“广覆盖”

（三）生产评测承担“真实分布监控”

离线数据集无法永久代表线上流量

（四）质量门禁应关注“绝对阈值 + 相对退化”

八、一个更可靠的 Agent 评测金字塔

（一）第一层：确定性 Contract Tests

（二）第二层：语义 Evals

（三）第三层：场景回放与端到端集成测试

（四）第四层：生产在线评测与人工复核

九、企业级落地示例：退款客服 Agent 应该怎么评

（一）先定义失败模式，再选指标

（二）一个推荐的 4 指标组合

（三）测试代码应该和 Agent 一起演进

十、DeepEval 的真正价值：不是替你决定“什么叫好”，而是把标准工程化

（一）评测框架解决的是执行问题，不是业务定义问题

（二）一个成熟评测体系的标志，是“失败可以推动下一步行动”

十一、落地路线图：从 1 天试跑到 4 周形成工程闭环

（一）第 1 天：建立最小可运行评测

（二）第 1 周：把 Agent 运行变成可观察 Trace

（三）第 2 周：建立指标职责与 Judge 校准

（四）第 3 周：建立数据集飞轮

（五）第 4 周：形成三层质量门禁

十二、结语：把 Agent 评测当成软件工程，而不是模型打分

可参考文章与资料

干货分享，感谢您的阅读！

Agent 评测真正困难的地方，不是“给回答打一个分”，而是验证一个会规划、会调用工具、会访问外部系统、会多步执行的自治流程是否完成了正确目标、采取了正确动作、遵守了必要约束，并且能够在版本迭代后稳定复现质量。

我们以 DeepEval 为工程抓手，从最小可运行测试出发，进一步构建 Trace-first 的评测架构、分层指标体系、LLM-as-Judge 校准机制、数据集飞轮与 CI/CD 质量门禁。重点不是“多用几个指标”，而是把评测变成 Agent 软件交付过程中的基础设施。

同时按 DeepEval 当前官方文档重新核对 API 与指标命名。较早实践中常见的AgentGoalCompletionMetric思路，在当前官方 Agentic Metrics 体系中应优先对照TaskCompletionMetric；官方当前还将ArgumentCorrectnessMetric、StepEfficiencyMetric、PlanQualityMetric等列入 Agent 核心指标。实际项目必须以锁定版本的文档与测试结果为准，而不是复制历史代码片段。

一、Agent 评测已经从“答案打分”进入“行为系统验证”

（一）传统 LLM 评测为什么不够

1、一个正确答案，可能来自一条错误路径

普通问答模型通常可以被抽象为“输入 → 输出”。因此，相关性、事实性、完整性、风格等指标往往足够描述主要质量问题。但 Agent 不是单一生成器，它更接近一个由模型驱动的动态工作流：模型会拆解任务、选择工具、生成参数、读取工具返回、更新状态、决定下一步，最后才形成对用户的回复。

这会带来一个关键差异：最终输出正确，不代表执行过程可靠。

例如，一个退款 Agent 最终告诉用户“退款申请已提交”，但它可能根本没有调用退款接口；一个采购 Agent 给出正确价格，却读取了无权限的数据源；一个旅行 Agent 完成了机票预订，却先进行了三次无意义搜索并产生额外费用。若评测只检查最后一句话，这些失败都会被“正确答案”掩盖。

2、Agent 的失败具有级联性

Agent 的每个中间步骤都可能改变后续状态。一次工具选择错误，可能导致错误上下文进入下一轮推理；一次参数偏差，可能让工具返回合法但错误的数据；一个糟糕计划，即使后续每个步骤都严格执行，也可能稳定地产生错误结果。

所以 Agent 质量不应被理解为某个单点分数，而应被理解为一条链：

目标理解 → 计划形成 → 动作选择 → 参数构造 → 工具执行 → 状态更新 → 结果生成 → 用户目标达成。

只要链上的关键节点不可观察，评测就很难从“发现失败”进一步走到“定位失败”。

（二）从三个常用指标扩展为四层质量模型

1、第一层：结果质量——任务到底完成了吗

这一层回答的是最根本的问题：用户目标有没有被实质完成。当前 DeepEval 的TaskCompletionMetric以完整 Trace 为基础，从任务与结果之间的对齐程度进行判断。它适合做 Agent 的端到端主指标，因为它关心的是“任务结果”，而不是仅看文本表面是否漂亮。

2、第二层：动作质量——工具是否选对、参数是否正确

ToolCorrectnessMetric适合检查 Agent 是否调用了预期工具，并可进一步考虑参数、输出与调用顺序。对于交易、客服、运维、数据查询类 Agent，这一层通常比回答风格更重要，因为真正改变业务状态的是工具调用，而不是语言描述。

3、第三层：推理质量——计划是否合理、执行是否遵循

PlanQualityMetric与PlanAdherenceMetric可以分别回答两个不同问题：

• 计划本身是否足以完成任务；

• Agent 后续是否按自己的计划执行。

把二者分开非常重要。一个 Agent 可能“计划很好但执行跑偏”，也可能“计划本来就错但执行得非常忠实”。两种故障的修复方向完全不同。

4、第四层：运行约束——效率、安全、成本与权限

生产级 Agent 还必须考虑步骤效率、调用成本、时延、权限边界和风险动作。DeepEval 当前提供StepEfficiencyMetric等 Agent 指标；而在企业系统里，成本、P95/P99 时延、工具权限、重试次数、外部 API 错误率等往往需要与评测框架之外的可观测性数据结合。

一个可用的 Agent，不仅要“做成事”，还要“用正确方式、在合理成本和权限内做成事”。

二、先把最小评测跑起来，但不要停在 Hello World

（一）最小闭环的意义，是验证评测基础设施

1、第一条测试不应该追求“指标齐全”

初次接入时，最重要的是确认四件事：

1. 测试用例能被稳定构造；

2. 指标能正常执行并给出分数/原因；

3. 测试失败能让进程返回非零状态；

4. 结果可以进入本地报告或团队平台。

DeepEval 延续了 Pytest 风格的工程体验：把评测写成测试，使用assert_test或测试运行命令执行。在团队工程里，这个设计的价值不是“语法熟悉”，而是可以直接复用现有的软件测试工作流。

2. 写一个确定性更强的工具契约测试

下面这个例子不依赖复杂 Agent Trace，先验证“预期工具是否被正确调用”。它非常适合作为第一条 CI 测试：

from deepeval import assert_test from deepeval.metrics import ToolCorrectnessMetric from deepeval.test_case import LLMTestCase, ToolCall def test_refund_tool_contract(): case = LLMTestCase( input="用户要求取消订单并退款", actual_output="退款申请已提交。", tools_called=[ ToolCall(name="QueryOrder"), ToolCall(name="SubmitRefund"), ], expected_tools=[ ToolCall(name="QueryOrder"), ToolCall(name="SubmitRefund"), ], ) metric = ToolCorrectnessMetric( threshold=1.0, should_consider_ordering=True, should_exact_match=True, ) assert_test(case, [metric])

这个测试的工程价值在于：它先把“行为契约”固定下来。当模型、Prompt 或工具描述变化后，只要 Agent 不再按预期路径调用关键工具，PR 就会直接失败。

（二）版本锁定比“代码能运行一次”更重要

1、评测框架本身也在快速变化

Agent 评测库仍处在高频演进阶段。指标命名、默认 Judge 模型、Trace API、框架集成方式都可能变化。因此，在真实项目中建议：

• 锁定deepeval版本；

• 在仓库中记录评测框架升级日志；

• 把“评测指标变化”视为测试基础设施变更，而不是普通依赖升级；

• 升级后先重跑固定基线集，再决定是否调整阈值。

2. 不要把默认 Judge 模型当成永久配置

当前 DeepEval 文档对部分 Agentic Metrics 给出了默认 Judge 模型，但这类默认值会随框架版本更新。生产项目应显式配置 Judge，并在实验元数据中记录 Judge 名称、版本、Prompt/模板与运行时间。否则，同一个 Agent 在两个月后的“同一套测试”里，可能因为评判器变化而出现不可解释的分数漂移。

三、Trace-first：Agent 评测真正的工程分水岭

Trace 对应一次完整 Agent 运行，Span 对应检索、LLM、工具或子 Agent 等组件。端到端指标与组件级指标应放在不同层级。

（一）为什么 Trace 是 Agent 评测的“数据底座”

1、没有 Trace，评测只能看到结果，不能解释结果

DeepEval 当前的 Agent Quickstart 把 Agent 评测建立在 tracing 上：一次完整运行形成 Trace，内部每个组件形成 Span。这个抽象非常关键，因为它把“黑盒输出”变成了“可审计执行轨迹”。

一旦 Trace 完整，你可以回答更多工程问题：

• 哪一步选择了错误工具？

• 哪个参数导致业务 API 返回异常？

• 检索阶段是否已经丢失关键信息？

• 计划是否在中途发生不必要偏移？

• 哪个子 Agent 贡献了主要时延？

2、端到端与组件级不是二选一，而是上下两层

端到端评测负责告诉你“整件事是否成功”，组件级评测负责告诉你“失败发生在哪里”。

端到端指标适合做质量门禁；组件级指标适合做故障定位。

如果只做组件级，你可能得到“每个局部都不错，但最终任务没完成”的假象；如果只做端到端，你只知道失败，却不知道修哪个模块。

（二）用 Trace 把测试从“文本样例”升级为“执行样例”

1、Trace 中应该保存哪些最小信息

对于工具型 Agent，建议至少保留：

• 用户原始输入；

• 最终输出；

• 工具名；

• 工具输入参数；

• 工具输出摘要；

• 关键中间状态；

• 子 Agent/子流程边界；

• 错误、重试、超时；

• 总时延与主要 Span 时延。

2、不要把敏感原始数据无限制写入 Trace

评测可观测性越强，数据治理要求越高。订单号、身份证号、账户余额、医疗信息、密钥、内部文档内容等不应该因为“方便调试”就无条件进入日志。生产 Trace 需要脱敏、分级授权、留存期限和审计策略。

四、指标体系：不要堆指标，要建立职责分工

指标应围绕失败模式选择，而不是追求数量。一个场景通常用 3-5 个互补指标即可形成有效信号。

（一）TaskCompletionMetric：用“是否达成目标”做北极星指标

1、它衡量的是 Outcome，而不是文案质量

TaskCompletionMetric的核心价值在于评判“任务与结果是否对齐”。对于执行型 Agent，这比传统“回答相关性”更接近真实业务目标。

例如，用户要求“把下周一 10 点的会议改到 11 点，并通知参与者”。如果 Agent 只是回复“好的，已为您处理”，但实际上没有更新日历，文本可能很流畅，任务却没有完成。

2、Task Completion 不能替代全部指标

一个 Agent 可以完成目标，但过程依然存在问题：

• 多调用了昂贵工具；

• 使用了错误权限；

• 进行了无关搜索；

• 计划偏离后碰巧得到正确结果。

因此 Task Completion 最适合作为“结果层主指标”，而不是唯一指标。

（二）ToolCorrectnessMetric：把动作层变成可测试契约

1、工具名正确只是最低要求

当前 DeepEval 的ToolCorrectnessMetric可以从工具名扩展到输入参数、输出以及调用顺序。工程上建议按风险分级：

• 低风险查询：检查工具名即可；

• 有状态写操作：必须检查参数；

• 严格工作流：检查顺序；

• 金融、审批、退款等关键流程：尽量使用严格匹配与额外业务断言。

2、确定性规则优先于 LLM Judge

如果一个条件能用代码明确判断，就不要首先交给 LLM 判断。例如：

• 是否调用了SubmitRefund；

• 退款金额是否小于订单实付金额；

• 是否禁止调用DeleteAccount；

• 参数中的币种是否符合账户币种；

• 是否在写操作前完成鉴权。

确定性规则成本低、可重复、可解释，是最适合做 CI Gate 的指标。LLM Judge 更适合处理语义层和开放式质量标准。

（三）PlanQualityMetric 与 PlanAdherenceMetric：分别评“想得对”和“做得像”

1、Plan Quality 解决“第一步就想错了”

如果 Agent 的任务需要多步规划，计划质量会决定后续执行上限。一个包含错误依赖关系的计划，即使工具调用百分之百正确，也无法得到可靠结果。

2、Plan Adherence 解决“计划很好但中途跑偏”

计划遵循度更像执行纪律。它帮助发现 Agent 在长链任务中临时偏航、跳步、重复、绕路等问题。

没有显式计划时，计划指标可能产生“虚假的好成绩”

DeepEval 当前文档说明，若 Trace 中无法识别明确计划，部分计划类指标会默认通过。这意味着一个“全是 1.0”的计划分数未必是好消息，也可能意味着你的 Trace 根本没有暴露可评估的计划信息。

所以在使用计划指标之前，先确认两个问题：

• Agent 是否真的有可观察的规划阶段？

• 记录的 reasoning/thinking 是否足以支撑评测，而不只是最终结果？

（四）StepEfficiencyMetric：让 Agent 不仅成功，还要少走弯路

Agent 经常出现一种“看起来没错”的退化：最终任务仍能完成，但步骤越来越多、工具调用次数越来越高、成本越来越贵、响应越来越慢。

StepEfficiencyMetric可以把这种退化从“用户感觉变慢了”提前变成可观测信号。企业场景还应配合确定性指标：平均工具调用次数、Token 使用、外部 API 成本、P95 时延、重试率等。

（五）GEval：把业务标准写进评测，但必须可操作

GEval 适合表达难以完全代码化的业务标准，例如：

• 客服回复是否明确说明处理状态与预计时间；

• 合规助手是否区分事实、判断与建议；

• 数据分析 Agent 是否明确说明数据口径和不确定性；

• 销售 Agent 是否避免未经证实的承诺。

但“回答是否优秀”“是否专业”这样的标准太宽泛。评测标准越抽象，Judge 波动越大，失败后也越难定位。

一个更好的原则是：每个自定义指标只负责一种可以描述、复核、修复的质量属性。

五、LLM-as-Judge 不是“自动真理”，而是一套需要校准的测量系统

（一）为什么强 Judge 仍然会不稳定

1、Judge 会受到顺序、长度与自我偏好影响

LLM-as-Judge 让开放式质量评测变得可规模化，但研究已经反复提示其偏差问题，包括位置偏差、冗长偏好、自我增强偏差等。因此，“换一个更强模型做 Judge”是必要条件之一，却不是完整解决方案。

2、评判器与被评测对象必须一起版本化

建议把以下信息记录为一次评测运行的不可缺省元数据：

• 被测 Agent 版本；

• 系统 Prompt / 工具描述版本；

• Judge 模型与版本；

• 指标 Prompt / 模板版本；

• 数据集版本；

• 阈值配置；

• 运行日期与环境。

如果这些信息没有版本化，所谓“回归测试”就缺少可比性。

（二）构建 Judge 信任度的五步法

1、先用小规模人工标注建立校准集

从核心业务场景中抽取 50-200 条样例，由领域专家给出“通过/失败”或分级评分。这个小集合不追求覆盖全部场景，而用于判断自动 Judge 是否与人类标准基本一致。

2、对边界样例做重复评测

对靠近阈值的样例重复运行若干次，观察评分方差。若同一个案例在 0.55 与 0.85 间反复跳动，说明当前指标不适合直接作为硬门禁。

3、优先让规则承担客观判断

格式、数值、权限、工具调用、参数范围、禁止动作等规则尽量用代码判断，把 Judge 留给语义正确性、完整性、解释质量等更适合模型的领域。

4、对关键指标设置“灰区”而不是单一阈值

例如：

• ≥0.85：通过；

• 0.70-0.85：需要二次评判或人工抽检；

• <0.70：失败。

这比把 0.79 与 0.80 视为本质不同更符合概率性评测的特点。

5、定期用人工复核检查 Judge 漂移

当 Judge 模型升级、指标模板变化或业务规范变化后，应重新计算人机一致性。否则评测基础设施可能在团队不知情的情况下“改了尺子”。

六、评测数据集才是长期壁垒：从样例集合走向失败模式资产

生产失败应被沉淀为回归样例，形成“日志 → 归因 → Golden → CI → 生产”的持续学习闭环。

（一）为什么手写 20 条测试永远不够

Agent 最危险的问题往往不是标准路径，而是组合边界：模糊指令、冲突要求、缺失信息、异常工具返回、权限不足、上下文过长、连续追问、跨语言表达、恶意提示等。

手写测试适合建立初始骨架，但真正高价值的数据往往来自生产失败。

（二）建议把数据集拆成四类

1、Golden Set：稳定验证核心能力

覆盖最重要、最常见、业务价值最高的标准路径。数量不一定大，但每条样例都应有明确预期。

2、Regression Set：每次线上事故都“买一张永久门票”

只要生产中出现过有代表性的失败，就应该在修复后加入回归集。这样团队不会在几个月后重新踩同一个坑。

3、Edge Set：专门打边界条件

包括参数缺失、工具超时、重复请求、权限不足、时区问题、单位换算、并发状态变化等。

4、Adversarial Set：验证提示注入与越权风险

对于能读取外部内容或执行写操作的 Agent，必须覆盖提示注入、工具诱导、越权访问、数据外泄等安全场景。安全失败通常不适合用“平均分”稀释，而应使用硬失败门禁。

（三）数据集版本化比不断加样例更重要

建议给测试样例附加元数据：

• scenario：业务场景；

• risk_level：风险等级；

• source：人工设计 / 生产日志 / 事故复盘；

• failure_mode：工具错误 / 规划错误 / 幻觉 / 越权等；

• created_at；

• owner；

• expected_tools或关键断言。

这样数据集不再是一堆 JSON，而是一张可以分析质量债务的“失败模式地图”。

七、CI/CD 质量门禁：评测必须参与“能不能合并”的决策

PR 阶段运行快速硬门禁，夜间运行更完整的语义回归，生产阶段进行异步抽样评测。三层不应使用完全相同的成本策略。

（一）不要把全部评测都塞进每个 PR

PR 阶段建议优先运行：

• 关键工具契约；

• 权限与安全规则；

• 核心 Golden 子集；

• 少量高稳定性语义指标；

• 失败即阻止合并的 P0/P1 场景。

如果每次提交都运行几千条 LLM Judge 评测，研发会因为等待时间和成本绕过测试。

（二）夜间回归承担“广覆盖”

夜间评测可以覆盖：

• 完整 Regression Set；

• 多模型对比；

• 多次重复测量；

• 更强 Judge；

• 成本、时延、步骤效率趋势；

• 失败样例自动聚类。

（三）生产评测承担“真实分布监控”

离线数据集无法永久代表线上流量

用户行为、外部工具、知识库与模型都在变化，因此上线后仍需要对 Trace 进行采样评测。生产评测更适合异步执行，避免把 Judge 时延叠加到用户请求上。

（四）质量门禁应关注“绝对阈值 + 相对退化”

如果主版本 Task Completion 长期为 0.93，新 PR 跑出 0.85，即使仍高于 0.80，也可能是明显回归。因此建议同时判断：

• 是否低于最低阈值；

• 是否相对基线下降超过容忍区间；

• P0/P1 场景是否出现新增失败；

• 成本或时延是否显著上升。

八、一个更可靠的 Agent 评测金字塔

（一）第一层：确定性 Contract Tests

便宜、快速、适合每次提交：检查工具、参数、权限、格式、数值范围、状态机约束。这一层越扎实，越不需要用昂贵 Judge 处理本可以写成assert的问题。

（二）第二层：语义 Evals

用 LLM Judge 判断“规则无法完全表达”的质量：Task Completion、GEval、Plan Quality 等放在这一层。它们提供了更强的语义覆盖，但需要校准和成本治理。

（三）第三层：场景回放与端到端集成测试

让 Agent 在尽量真实的工具与环境里执行：Mock 可以验证逻辑，但无法暴露真实 API 变化、数据质量、权限配置、网络失败等问题。高风险场景应在隔离环境中做真实或半真实回放。

（四）第四层：生产在线评测与人工复核

自动评测不能完全替代真实用户反馈：上线后的真实分布、事故、投诉与人工质检应持续回流。真正成熟的体系不是“自动化率 100%”，而是知道哪些问题适合机器判断、哪些问题必须由人承担最终责任。

九、企业级落地示例：退款客服 Agent 应该怎么评

（一）先定义失败模式，再选指标

假设退款 Agent 的主要风险是：

• 没查订单就直接退款；

• 调错工具；

• 退款金额错误；

• 不满足政策仍执行；

• 最终回复没有说明处理状态；

• 遇到工具失败后重复提交；

• 虽完成退款，但路径过长、成本失控。

对应的测试设计可以是：

（二）一个推荐的 4 指标组合

对于这类工具型 Agent，可采用：

1. ToolCorrectnessMetric：关键工具及顺序；

2. TaskCompletionMetric：用户目标是否真正达成；

3. 一个业务GEval：回复是否包含处理状态、后续步骤与时间预期；

4. 一个确定性业务指标：金额/权限/重复提交等。

必要时再加入StepEfficiencyMetric，但不建议一开始就堆到十几个分数。DeepEval 官方 FAQ 当前仍建议总指标数不要过多，典型上限是 5 个左右，原因正是为了让结果可解释、可行动。

（三）测试代码应该和 Agent 一起演进

Agent 研发中，“只是改了几句话”并不等于低风险。系统 Prompt、工具描述、路由条件、输出格式都会改变模型行为。建议把以下规则写进团队开发流程：

• Prompt / 工具描述变更必须触发 Agent Eval；

• 新工具上线必须新增工具契约测试；

• 线上事故修复必须新增 Regression Case；

• Judge 或评测框架升级必须重跑基线集；

• 质量门禁调整必须有历史数据支撑。

十、DeepEval 的真正价值：不是替你决定“什么叫好”，而是把标准工程化

（一）评测框架解决的是执行问题，不是业务定义问题

DeepEval 可以提供 Trace、指标、Judge 接口、Pytest 集成、数据集与运行机制，但它无法替团队回答：

• 什么错误是不能接受的？

• 哪些场景比平均分更重要？

• 一次错误退款和一次语气不够礼貌是否应该同权？

• 什么样的成本上涨值得阻止上线？

• 哪些样例必须人工复核？

这些问题必须由产品、工程、业务、风险与运营共同定义。

（二）一个成熟评测体系的标志，是“失败可以推动下一步行动”

如果一个评测失败后，团队只能得到“0.67，不通过”，这个指标价值有限。好的评测应该能够回答：

• 失败发生在哪个 Trace / Span；

• 是结果、工具、参数、计划还是数据问题；

• 是否为历史已知失败模式；

• 是单点失败还是系统性退化；

• 应该改 Prompt、模型、工具描述、业务规则还是数据集。

评测的终点不是排行榜，而是缩短“发现问题 → 定位问题 → 修复问题 → 防止复发”的时间。

十一、落地路线图：从 1 天试跑到 4 周形成工程闭环

（一）第 1 天：建立最小可运行评测

目标是跑通而不是完美，需要完成：

• 安装并锁定 DeepEval 版本；

• 写 5-10 条核心 Golden；

• 接入一个工具契约指标；

• 接入一个端到端任务完成指标；

• 在本地与 CI 都能执行。

（二）第 1 周：把 Agent 运行变成可观察 Trace

优先补齐高风险组件，基本完成：

• Agent、工具、检索、子 Agent 的 Span；

• 错误与重试记录；

• 关键工具参数脱敏后的 Trace；

• 失败样例能够定位到具体步骤。

（三）第 2 周：建立指标职责与 Judge 校准

从“能打分”升级为“分数可信”，具体完成：

• 3-5 个核心指标；

• 50-200 条人工校准集；

• Judge 与人工的一致性检查；

• 灰区和人工复核策略；

• 基线版本冻结。

（四）第 3 周：建立数据集飞轮

把线上失败变成永久测试资产，完成：

• Golden / Regression / Edge / Adversarial 分层；

• 测试样例元数据；

• 线上失败自动进入候选池；

• 每周复盘新增失败模式。

（五）第 4 周：形成三层质量门禁

PR、Nightly、Production 分工运行，完成：

• PR 快速门禁；

• 夜间完整回归；

• 生产 Trace 异步抽样；

• 质量趋势、成本趋势与失败聚类；

• 明确责任人和回滚条件。

十二、结语：把 Agent 评测当成软件工程，而不是模型打分

Agent 评测最容易掉进两个极端：一种是完全依赖人工体验，“感觉新版本更聪明”；另一种是堆满自动指标，最后团队面对几十个分数却不知道该改什么。

更有效的道路在二者之间：

用确定性规则守住不可违反的底线，用 Trace 让过程可观察，用少量互补指标描述主要失败模式，用 LLM Judge 处理语义判断，用数据集记录历史教训，再把这些能力嵌入 CI/CD 和生产监控。

DeepEval 的意义恰恰在这里：它降低了把评测写进工程流程的门槛。但真正让 Agent 从 Demo 走向可靠产品的，不是某一个 Metric，而是团队是否建立了持续、可解释、可回归、可治理的质量体系。

当每一次线上失败都能沉淀为新的测试，当每一次 Prompt 或工具修改都能在合并前得到质量证据，当每一次分数下降都能定位到具体 Trace 和失败模式，Agent 评测才从“实验报告”变成了真正的软件工程能力。

可参考文章与资料

1. DeepEval - AI Agent Evaluation Quickstart —— 当前官方 Agent 评测快速入门，重点是 Trace 与组件级/端到端评测。

2. DeepEval - LLM Tracing —— Trace、Span 与组件级评测的官方说明。

3. DeepEval - Tool Correctness —— 工具名、参数、输出、顺序与严格匹配的当前文档。

4. DeepEval - Task Completion —— 当前 Agent 端到端任务完成指标。

5. DeepEval - AI Agent Evaluation Metrics —— Plan Quality、Plan Adherence、Tool Correctness 等指标组合建议。

6. DeepEval - Metrics FAQ —— 指标数量、GEval/DAG 等常见实践建议。

7. DeepEval GitHub —— 项目 README、版本与集成能力。

8. G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment —— LLM-as-Judge / G-Eval 的经典研究。

9. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena —— 讨论 LLM Judge 的可用性与位置、冗长、自我增强等偏差。

10. Judging the Judges: A Systematic Study of Position Bias in LLM-as-a-Judge —— 对 LLM Judge 位置偏差进行系统研究。

11. AgentBench: Evaluating LLMs as Agents —— 从多环境、多步交互角度理解 Agent 评测的复杂性。