Agent 评测工程 2026:三层堆栈与持续校准的工程范式
把 Agent 评测拆成单元、集成、E2E 三层堆栈,用录制回放保证可重复、用 LLM-as-judge 三件套保证语义质量、用风险驱动门禁保证迭代速度,把 Agent 系统从能跑推到能稳的工程基础设施。
约 23 分钟阅读6,753 字7 次阅读博主
把 Agent 评测拆成单元、集成、E2E 三层堆栈,用录制回放保证可重复、用 LLM-as-judge 三件套保证语义质量、用风险驱动门禁保证迭代速度,把 Agent 系统从能跑推到能稳的工程基础设施。
传统软件的单元测试与集成测试建立在「确定性函数 + 固定输入 → 固定输出」的范式之上。Agent 系统打破了这一范式：LLM 的采样温度非零、工具调用的副作用受外部状态影响、多智能体协作的状态机空间随步骤指数增长、同一 prompt 在不同模型版本下行为可能漂移。这意味着把传统测试方法照搬到 Agent 上，会得到三种失败模式：要么测试本身通过率波动剧烈无法作为发布门禁，要么覆盖率指标虚高但线上真实缺陷依然外溢，要么回归测试能复现却无法定位根因。
2026 年中，主流 Agent 框架的工程团队普遍意识到：评测不是一个 QA 阶段，而是 Agent 系统全生命周期的基础设施。从开发期的工具选型到上线期的灰度发布再到运行期的 A/B 实验，每一步都需要可被工程化的评测体系支撑。
本文聚焦 Agent 评测工程中的实战问题：如何构建可重复执行的评测集、如何设计同时覆盖单元、集成、端到端的三层堆栈、如何把 LLM 作为裁判引入而不引入新的偏倚、如何在 CI 流水线里把 Agent 测试做到秒级反馈、如何让评测基线随模型迭代持续校准。我们刻意避开「评测理论」的纯学术讨论，把笔墨放在工程实现与踩坑教训上。需要强调的是，本文的全部建议都来自 2026 年中真实生产环境的工程实践，而非来自评测理论文献，因为评测工程的工程化路径在过去十二个月里才真正稳定下来，文献综述往往滞后于工程现实。
Agent 评测体系可以分解为三层：单元层（Unit）评测单个组件的契约，集成层（Integration）评测组件协作的协议，端到端层（E2E）评测用户可见的任务完成度。三层之间通过评测产物链联通，每一层的输出作为下一层的输入。单元层产物是组件契约的可执行断言，集成层产物是协议交互的可重放脚本，E2E 层产物是用户任务的语义评分与可解释的归因记录。三层产物的工程含义完全不同：单元层产物应当可以在本地秒级跑完，集成层产物应当在 CI 上分钟级完成，E2E 层产物应当每日定时批量产出。三层时间预算的差异决定了它们的实现技术与触发策略。
形式化地，记 Agent 系统为五元组 ： 为 LLM 推理入口， 为工具集合， 为状态存储， 为编排策略， 为奖励函数。评测的目标是为每一元组构造可量化的度量 ，并使得度量在不同运行间具备可比的统计性质。
三层评测堆栈的工程意义在于：单元层评测速度快、可定位到具体组件；集成层评测覆盖组件协作的协议契约；E2E 层评测反映用户感知。任何一层缺失都会形成评测盲区，单层独大则会陷入"过度拟合单层指标"的陷阱。实践中常见的失衡是 E2E 层独大，单元层与集成层薄弱，导致线上缺陷无法在开发期被拦截，全部依赖发布前 E2E 兜底，这种模式在迭代节奏上不可持续。
单元层评测的核心是组件契约（component contract）。对 LLM 推理入口 ，契约是输入 prompt 格式、输出 JSON schema、token 上限、重试语义。对工具 ，契约是入参 schema、出参 schema、副作用范围、超时与降级路径。对状态存储 ，契约是读写接口的一致性保证、并发安全、过期策略。一个常见的反模式是把契约只写在文档里而不进入代码契约，导致 Agent 组件在迭代过程中悄悄偏离了原始设计意图。工程化的稳定做法是契约进 schema，schema 进 CI，CI 失败阻塞合并。
工程实践里，单元层评测的稳定形态是「快照断言 + Mock 边界」。对 LLM 部分用录制的真实模型响应做 replay，避免每次评测都消耗模型调用成本；对工具调用部分用 in-memory mock 替换外部副作用，保证幂等；对状态存储用 SQLite 内存库或事务回滚机制隔离测试态。三类测试对象在工程上有三个差异点：LLM 部分的录制文件往往体积大（一次对话可能数十 KB），适合用 Git LFS 或对象存储；工具 mock 的难点是副作用的语义回放，例如「删除文件」操作的 mock 必须真的能在文件系统上可观察，否则后续代码路径会偏离；状态存储的测试隔离需要认真考虑事务边界，否则并行测试会相互污染。
# 示例：Agent 单元测试中用 mock LLM + mock 工具的伪代码
def test_search_agent_contract():
agent = SearchAgent(llm=MockLLM(replay="search_v2.json"), tools=MockToolRegistry())
result = agent.run("查找 2026 LLM 网关基准")
assert result.status == "ok"
assert result.citations # 至少 1 条引用
assert len(result.tokens) < 4000 # token 上限契约
单元层评测的常见踩坑是把 mock 写得过于智能，导致 mock 本身在维护真实组件的语义，违背了「mock 应当是被动应答」的工程原则。正确做法是 mock 只回放录制响应，不做语义推断。LLM 侧的 replay 录制应当覆盖典型路径、边界情况、错误路径三大类，至少各 3-5 条样本。
集成层评测关注组件之间的协议正确性。Agent 系统的典型协议包括：工具调用与响应的时序约束、多智能体之间的消息路由、状态机的转移合法性、并发场景下的资源竞争。集成层评测比单元层更难自动化，因为协议涉及时间维度与外部状态。一个常见的工程误区是把集成层测试写成单元层测试的简单叠加，导致集成层测试既没有覆盖真正的协议交互，又失去了单元层测试的速度优势。集成层的价值正在于它能捕获单元层看不到的协议 bug。
工程上，集成层评测通常采用「确定性编排 + LLM stub」混合策略。编排器（orchestrator）的状态转移用确定性实现，方便录制与回放；LLM 调用替换为 stub，stub 在每次录制时记录真实响应，运行时按录制顺序回放。这样既保证了协议层的可重复性，又保留了真实 LLM 行为的语义。这种策略的工程难点在于 stub 的边界划分：哪些 LLM 行为用 stub 回放，哪些保留真实调用，需要根据测试目标动态决定。经验做法是 80/20 规则：80% 的协议 bug 可以通过 stub 捕获，剩余 20% 必须真实调用才能暴露，应当把后者隔离到「集成冒烟」测试集中。
集成层评测的第二个关键是时间维度。Agent 系统的 timeout、retry、backoff、circuit breaker 都是时间敏感的协议特性。常见的测试场景包括：工具响应延迟超过 timeout 时的降级路径、网络抖动触发 retry 但避免 retry storm、circuit breaker 打开后的快速失败而非长尾等待。这些场景的评测需要可控的时间注入，例如 fake clock 或 mock 计时器。
# 示例：集成层测试超时降级路径的伪代码
def test_tool_timeout_fallback():
clock = FakeClock(start=0)
agent = SearchAgent(
llm=MockLLM(replay="search_v2.json"),
tools=MockToolRegistry(latency={"web_search": 30}), # 30 秒延迟
clock=clock,
tool_timeout=5, # 5 秒超时
)
result = agent.run("超时场景")
clock.advance(6)
assert result.status == "fallback"
assert "工具超时" in result.message
assert result.used_cache # 命中降级缓存
端到端层评测是 Agent 评测工程里难度最高的部分。E2E 评测的目标是回答「用户拿这个 Agent 完成真实任务时，体验是否达到预期」。这一层直接面对三个挑战：评测样本的真实性、评测判官的可靠性、评测成本的可控性。三个挑战相互制约：提高样本真实性的代价是隐私与数据合规成本，提高判官可靠性的代价是引入偏倚漂移的风险，提高评测覆盖度的代价是 token 成本指数级上升。工程化的稳定做法是把三者解耦，分别构造基础设施，再在调度层做组合优化。
评测样本必须覆盖真实用户场景的分布。生产环境的对话日志是金矿，但涉及隐私合规。常见做法是对日志做去标识化、按任务类型分层采样、构造合成但贴近真实分布的种子场景。一个 Agent 评测集通常包含 200-500 条 E2E 任务，每条任务附带期望完成度评分、关键检查点、可接受的偏离范围。样本分层是核心工程动作：高频任务全量覆盖、长尾任务聚类采样、敏感任务人工标注。三层之间按 60/30/10 比例分布，可以平衡评测广度与深度。
评测判官（judge）是 E2E 评测的另一核心组件。最稳定的形态是「LLM-as-judge + 规则校验 + 人工抽样复核」三层组合。LLM-as-judge 用一个强模型对 Agent 输出打分，规则校验确保硬性约束（如引用数量、token 上限），人工抽样复核用于监控 LLM 判官的偏倚漂移。纯 LLM-as-judge 是危险的，纯规则校验覆盖不了语义质量，纯人工成本不可持续。
E2E 评测的成本控制是工程化的硬约束。一次完整 E2E 评测涉及一次或多次 LLM 调用 + 多次工具调用 + 判官模型调用，单任务成本可能是单元层评测的 100-1000 倍。常见做法是分级评测：核心任务全量评测（200 条）、长尾任务采样评测（每类 10-20 条）、冒烟测试每日一次（10-15 条代表任务）。
把三层评测堆栈放入持续集成 / 持续部署（CI/CD）流水线时，会浮现出评测本身的工程规律。最重要的规律是评测基线随模型迭代必须持续校准。LLM 提供商发布新版本时，旧评测集的得分可能漂移；Agent 框架升级时，旧工具的语义可能变化；评测判官升级时，旧判官的偏倚可能改变。任何一项改变都可能让历史评测记录失去可比性。持续校准的目标不是消除漂移，而是把漂移变成可观察、可归因、可决策的工程事件。
持续校准的工程实现是「评测集的版本化 + 评测运行的元数据」。评测集存为 Git LFS 或对象存储，每次评测运行记录 commit hash、模型版本、框架版本、判官版本、时间戳。回溯任意一次评测时，可以复现当时的完整环境。一个常被忽略的工程细节是评测数据集本身的语义版本：评测集不只是「文件哈希变化」，更应当用语义版本号（v1.0, v1.1, v2.0）记录「意图变更」。一次意图变更是增加一类任务、删除一类任务、还是修改评分标准，对评测可比性的影响完全不同。
第二个统一视角是评测与可观测性的边界。可观测性回答「线上发生了什么」，评测回答「是否达到预期」。两者的交集是 A/B 实验：用可观测性指标做评测判官，把评测推理过程做可观测性埋点。一个成熟的 Agent 工程团队会让评测平台与可观测性平台共享数据 schema，避免重复埋点。
第三个统一视角是评测的成本-收益曲线。评测覆盖越广，成本越高，迭代越慢。工程上的最优解不是「全量评测」，而是「风险驱动评测」：高风险改动触发全量评测，低风险改动走冒烟测试 + 抽样评测。风险评分来自改动 diff、历史缺陷密度、用户影响面三个信号。
基于三层评测堆栈与持续校准的统一视角，可以推导出五条可执行的工程实践：
第一，录制与回放优先。所有 LLM 调用、工具副作用、状态变更在测试环境下都应当可录制、可回放。录制文件进 Git LFS，回放时按录制顺序 deterministic 执行，避免测试 flaky。推论：所有涉及外部副作用的代码路径必须有录制接口。
第二，mock 不做语义推断。mock 只回放录制响应，不理解业务语义。这样保证 mock 维护成本与真实组件独立，不会因为真实组件升级导致 mock 失效。推论：评测代码不应当有 if mock_response: return real_response() 这种分支。
第三，LLM-as-judge 三件套。判官模型 + 规则校验 + 人工抽样同时存在，缺一不可。判官模型用最强可用模型，规则校验用 SQL-like 查询或 DSL，人工抽样每周 5-10 条。推论：纯 LLM-as-judge 是债务，纯规则是覆盖不足，纯人工是成本不可持续。
第四，风险驱动评测门禁。不是所有 PR 都触发全量 E2E，而是按改动 diff 自动评估风险等级。低风险走单元 + 冒烟，中风险加集成层，高风险加全量 E2E。推论：门禁策略本身需要随历史缺陷数据校准，每季度审视一次。
第五，评测基线持续校准。每次 LLM 提供商版本升级、Agent 框架升级、判官模型升级都触发一次基线回归。基线回归结果不通过则阻塞升级。推论：评测平台必须记录完整的运行元数据，否则无法回溯历史可比性。基线回归的频率应当与外部依赖的发布频率对齐：主流 LLM 提供商每月发布新版本，对应的基线回归频率应当不低于每月一次；自托管的 Agent 框架升级更频繁，基线回归可能需要每周甚至每日触发。
第六，评测与监控的统一 schema。评测推理过程埋点与线上监控埋点应当使用相同的字段命名、相同的时间粒度、相同的 trace ID 关联方式。这样 A/B 实验的判官可以直接复用监控数据，反过来线上报警的回放也能进入评测集。推论：评测平台与可观测性平台应当共享数据 schema 的同一份规范文档。
第七，评测成本的工程预算。一次全量 E2E 评测的 token 成本可能等于一个工程师一天的工资。推论：评测预算应当按季度规划，明确高频触发（每日冒烟）、中频触发（每周回归）、低频触发（发布前全量）三类预算分配，并把每次评测的成本写入元数据以便后续成本审计。
Agent 评测工程当前仍未解决的几个核心问题：长程任务的评测一致性（>20 步的 Agent 输出在不同运行间波动可能 >30%）；多智能体协作的因果归因（一个 E2E 失败很难定位到具体智能体）；评测集本身的分布漂移（用户真实任务分布随时间漂移，评测集需要定期刷新）。这三大问题在 2026 年的工程实践中仍然只能缓解而无法根治：长程一致性靠重试 + 多次取均值缓解，因果归因靠 trace ID + 细粒度埋点缓解，分布漂移靠定期采样 + 评测集滚动更新缓解。
更隐蔽的问题是评测对 Agent 行为的反作用。Agent 开发者会针对评测集做过度优化（Goodhart's Law），让评测得分虚高但实际能力下降。规避策略是评测集的持续更新 + 评测集对开发者保密 + 保留一定比例的私有评测集做最终验收。此外还存在评测成本与评测速度的尖锐矛盾：评测集越全面、E2E 覆盖越广，单次评测的成本越高，反过来拖慢迭代节奏。规避策略是分层评测与按需触发，把全量评测限定在发布门禁节点，日常迭代只跑代表性子集。
如果你刚接手一个 Agent 项目的评测工作，建议按以下顺序推进：
评测工程是 Agent 系统从「能跑」到「能稳」的关键基础设施。投入在评测上的工程时间，最终会以缺陷率与迭代速度的双重改善回报给整个团队。同时也要记住评测工程的边界：评测能告诉你 Agent 在已知的任务上表现如何，但不能告诉你 Agent 在未知的真实用户需求上表现如何。最终决定 Agent 品质的，永远是真实用户场景中的反复迭代与持续校准，而不是任何一套精心构造的离线评测集。
一句话摘要：Agent 评测工程不是 QA 阶段，而是覆盖单元、集成、E2E 三层的全生命周期基础设施，其核心是用录制回放保证可重复、用 LLM-as-judge 三件套保证语义质量、用风险驱动门禁保证迭代速度。
Conversation
0 条