Agent 评测工程 2026:三层堆栈与持续校准的工程范式

一、问题的提出：为什么 Agent 评测是一道独立的工程难题

传统软件的单元测试与集成测试建立在「确定性函数 + 固定输入 → 固定输出」的范式之上。Agent 系统打破了这一范式：LLM 的采样温度非零、工具调用的副作用受外部状态影响、多智能体协作的状态机空间随步骤指数增长、同一 prompt 在不同模型版本下行为可能漂移。这意味着把传统测试方法照搬到 Agent 上，会得到三种失败模式：要么测试本身通过率波动剧烈无法作为发布门禁，要么覆盖率指标虚高但线上真实缺陷依然外溢，要么回归测试能复现却无法定位根因。

2026 年中，主流 Agent 框架的工程团队普遍意识到：评测不是一个 QA 阶段，而是 Agent 系统全生命周期的基础设施。从开发期的工具选型到上线期的灰度发布再到运行期的 A/B 实验，每一步都需要可被工程化的评测体系支撑。

本文聚焦 Agent 评测工程中的实战问题：如何构建可重复执行的评测集、如何设计同时覆盖单元、集成、端到端的三层堆栈、如何把 LLM 作为裁判引入而不引入新的偏倚、如何在 CI 流水线里把 Agent 测试做到秒级反馈、如何让评测基线随模型迭代持续校准。我们刻意避开「评测理论」的纯学术讨论，把笔墨放在工程实现与踩坑教训上。需要强调的是，本文的全部建议都来自 2026 年中真实生产环境的工程实践，而非来自评测理论文献，因为评测工程的工程化路径在过去十二个月里才真正稳定下来，文献综述往往滞后于工程现实。

二、形式化：三层评测堆栈

Agent 评测体系可以分解为三层：单元层（Unit）评测单个组件的契约，集成层（Integration）评测组件协作的协议，端到端层（E2E）评测用户可见的任务完成度。三层之间通过评测产物链联通，每一层的输出作为下一层的输入。单元层产物是组件契约的可执行断言，集成层产物是协议交互的可重放脚本，E2E 层产物是用户任务的语义评分与可解释的归因记录。三层产物的工程含义完全不同：单元层产物应当可以在本地秒级跑完，集成层产物应当在 CI 上分钟级完成，E2E 层产物应当每日定时批量产出。三层时间预算的差异决定了它们的实现技术与触发策略。

形式化地，记 Agent 系统为五元组 $\mathcal{A} = (M, T, S, \pi, R)$：$M$ 为 LLM 推理入口，$T$ 为工具集合，$S$ 为状态存储，$\pi$ 为编排策略，$R$ 为奖励函数。评测的目标是为每一元组构造可量化的度量 $Q(x) \to [0, 1]$，并使得度量在不同运行间具备可比的统计性质。

三层评测堆栈的工程意义在于：单元层评测速度快、可定位到具体组件；集成层评测覆盖组件协作的协议契约；E2E 层评测反映用户感知。任何一层缺失都会形成评测盲区，单层独大则会陷入"过度拟合单层指标"的陷阱。实践中常见的失衡是 E2E 层独大，单元层与集成层薄弱，导致线上缺陷无法在开发期被拦截，全部依赖发布前 E2E 兜底，这种模式在迭代节奏上不可持续。

三、单元层：组件契约的工程化

单元层评测的核心是组件契约（component contract）。对 LLM 推理入口 $M$，契约是输入 prompt 格式、输出 JSON schema、token 上限、重试语义。对工具 $t \in T$，契约是入参 schema、出参 schema、副作用范围、超时与降级路径。对状态存储 $S$，契约是读写接口的一致性保证、并发安全、过期策略。一个常见的反模式是把契约只写在文档里而不进入代码契约，导致 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 项目的评测工作，建议按以下顺序推进：

1. 录制基础设施：先把所有 LLM 调用、工具副作用的录制链路打通，录制文件进 Git LFS。这一步投入最大但收益最长，录制质量决定了后续所有测试的可重复性。
2. 单元层契约：把每个组件的契约写明确，输入输出 schema + 副作用范围 + 超时降级。单元测试覆盖率目标 80%，重点覆盖边界与错误路径。
3. 集成层协议：重点测超时、并发、重试、降级。集成测试覆盖核心 10-20 个场景，每一个对应一个具体的协议契约。
4. E2E 评测集：用生产日志 + 合成任务构造 200 条 E2E 评测，三层判官组合。样本按 60/30/10 比例分布高频 / 长尾 / 敏感任务。
5. 持续校准：评测运行记录完整元数据，每周做基线回归。评测数据集用语义版本号管理。
6. 风险驱动门禁：把 PR 分类与评测强度绑定，避免一刀切。门禁策略本身每季度审视一次。
7. 私有评测集：保留 50-100 条私有评测集对开发者保密，做最终验收。私有集的比例与评测可信度成正比。

评测工程是 Agent 系统从「能跑」到「能稳」的关键基础设施。投入在评测上的工程时间，最终会以缺陷率与迭代速度的双重改善回报给整个团队。同时也要记住评测工程的边界：评测能告诉你 Agent 在已知的任务上表现如何，但不能告诉你 Agent 在未知的真实用户需求上表现如何。最终决定 Agent 品质的，永远是真实用户场景中的反复迭代与持续校准，而不是任何一套精心构造的离线评测集。

一句话摘要：Agent 评测工程不是 QA 阶段，而是覆盖单元、集成、E2E 三层的全生命周期基础设施，其核心是用录制回放保证可重复、用 LLM-as-judge 三件套保证语义质量、用风险驱动门禁保证迭代速度。

参考文献

1. Anthropic. Building Effective Agents. 2024.
2. LangChain. LangGraph: Multi-Agent Workflows Documentation. 2025.
3. OpenAI. Evaluation Best Practices for LLM Applications. 2024.
4. Microsoft. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. 2024.
5. CrewAI Inc. CrewAI Production Engineering Guide. 2025.
6. Anthropic. Claude Agent SDK Engineering Reference. 2025.
7. OpenAI. OpenAI Agents SDK Production Patterns. 2025.
8. Google Research. ADK: Agent Development Kit Best Practices. 2025.
9. AWS. Bedrock AgentCore Evaluation Framework. 2025.
10. LangChain. LangSmith Evaluation Suite Documentation. 2025.
11. Hugging Face. Agent Evaluation Toolkit. 2025.
12. Replit. Agent Reliability Engineering at Scale. 2025.
13. Shopify. Sidekick Agent Quality Engineering. 2025.
14. Cloudflare. Workers AI Agent Observability Guide. 2025.