Agent 测试工程 2026：录制回放与四层 Sandbox 的工程范式

一、问题的提出：为什么 Agent 单测是工程灾难

Agent 系统的"单测"在传统软件意义上几乎是不可能的——一个 LLM 调用本质上是非确定的：temperature > 0 时同一 prompt 会得到不同回答；上游 API 抖动会改变 prompt 实际效果；tool call 的副作用（数据库写入、文件创建、API 调用）会让两次执行产生不同世界状态。2026 年 H1 内部数据显示，大型 Agent 系统 80% 的回归 bug 来自"测试套件不覆盖工具调用副作用"——同一个 Agent 在测试环境连跑三天，每天产出都不同，调试者像在看薛定谔的日志。但 Agent 测试工程本身就是一个工程问题：把"非确定的执行"转化为"可重放的工件"，把"工具副作用"隔离到 mock 沙箱，把"LLM 推理"替换为 fixture。本文的目的是给 Agent 工程团队一套可复用的 Agent 测试工程模式，覆盖确定性录制-回放、双层 mock 隔离、Sandbox 执行、CI 金字塔集成与门禁策略五条主线。

二、形式化：Agent 测试的四元组 (S, T, R, E)

把 Agent 系统形式化为四元组 $A = (S, T, R, E)$：

• $S$ 是状态空间：会话历史、记忆索引、消息队列、用户上下文
• $T$ 是工具集：每个 $t_i \in T$ 有 schema、副作用类型（read/write/external）、版本号
• $R$ 是推理策略：LLM 调用次数、温度、top_p、模型 ID、prompt 模板哈希
• $E$ 是执行环境：文件系统、数据库、网络可达性、时钟

Agent 测试的核心是控制四个变量：固定 $R$（LLM mock / 录制回放）、隔离 $E$（sandbox / 容器）、覆盖 $T$（tool mock 全集）、断言 $S$ 终态。这与传统软件测试的"函数 $f(x) \to y$ 输入输出对"截然不同——Agent 的"输入"包含 $S_0$（初始状态）+ 用户 query + 工具可达性，"输出"是 $S_n$（终态）+ 工具调用轨迹 + 最终回答文本。形式化后我们得到四个测试层级：

四个层级成本递增、覆盖范围递减，构成 Agent 测试金字塔。

2.1 形式化的工程价值

四元组形式化最大的工程价值是可注入性——任何测试框架能在 $S$、$T$、$R$、$E$ 的任一节点注入 mock / fixture / replay engine。这与传统软件测试的"函数入参出参"思路一致，但注入点更多元。具体注入点：

• $S$ 注入：替换初始状态（用户上下文、记忆索引、消息队列）
• $T$ 注入：替换工具实现（mock tool、contract-based tool）
• $R$ 注入：替换 LLM 调用（mock response、replay trace、deterministic seed）
• $E$ 注入：替换执行环境（Docker sandbox、firecracker microVM、WASM runtime）

四元组的测试覆盖矩阵：

权重 $w_{ijkl}$ 反映该组合的实际风险——例如 (mock, mock, mock, mock) 风险低权重小，(real, real, real, real) 风险高权重大。Agent 测试资源按权重分配，让 CI 资源与实际风险匹配。这套形式化让"测试覆盖率"从单维度（line/branch）升级为四维矩阵，更贴近 Agent 的真实失效模式。

三、Deterministic Replay：录制-回放架构

录制-回放（Deterministic Replay）是 Agent 测试的第一支柱。其核心思想是把一次"真实执行"完整记录下来：LLM 调用的 prompt + response（包含 temperature 实际值、token 序列、tool_call JSON）、工具调用的输入 + 输出 + 副作用、文件系统写入、时钟 tick、网络请求。回放时把这些记录作为 fixture 注入——LLM 调用不再走真实 API，直接从 fixture 查表返回；工具调用也不走真实工具，直接返回录制结果。2026 年 H1 主流方案是双轨录制：开发期录制"golden trace"（手工跑一次、确认行为正确），CI 期回放"golden trace" 验证代码改动没有破坏 Agent 行为。

录制 schema 的最小集：

# replay_trace.py
@dataclass
class TraceStep:
    step_id: int
    timestamp: float
    llm_call: Optional[LLMCall]    # prompt, model, temperature, response
    tool_call: Optional[ToolCall]  # name, args, result, side_effect_log
    state_snapshot: Optional[StateSnapshot]  # S before/after this step
    wallclock_ms: int

@dataclass
class ReplayTrace:
    agent_version: str
    query: str
    initial_state: StateSnapshot
    steps: List[TraceStep]
    final_state: StateSnapshot
    final_response: str

回放器的实现要点：

# replay_engine.py
class ReplayEngine:
    def __init__(self, trace: ReplayTrace):
        self.trace = trace
        self.cursor = 0
    
    def llm_call(self, prompt: str, **kwargs) -> str:
        expected = self.trace.steps[self.cursor].llm_call
        assert expected.prompt_hash == hash_prompt(prompt)
        assert expected.model == kwargs["model"]
        self.cursor += 1
        return expected.response  # 真实录制时的 LLM 输出
    
    def tool_call(self, name: str, args: dict) -> dict:
        expected = self.trace.steps[self.cursor].tool_call
        assert expected.name == name
        assert expected.args == args
        self.cursor += 1
        return expected.result  # 真实录制时的工具输出

关键 invariant：回放器不调用真实 LLM/工具，所有数据来自 trace fixture。这保证回放是 100% 确定的。Trace 文件本身要进 git（或对象存储），每次代码改动跑全部 trace = 回归测试。

录制-回放的最大陷阱是 trace 漂移：LLM 输出变了、prompt 模板改了、工具 schema 升级了——原 trace 不再匹配新代码。解决方案：

1. prompt 哈希校验：录制时存 hash(prompt_template + user_query)，回放时哈希必须一致；不一致 → 立即报错"trace outdated"
2. schema 版本号：每个 trace 带 agent_version 和 tool_schema_version，版本不匹配 → 跳过 + 提示"需重录"
3. trace 重录 workflow：代码改动 → 检测 trace 漂移 → CI 失败 + 自动开 PR 重录 golden trace → 人工 review → merge

漂移检测把"测试通过 / 失败"升级为"trace 是否仍有效"，是 Agent 测试工程的关键约束。

3.1 Trace 压缩与分层存储

完整 trace 包含每一步 LLM 调用的 prompt + response，单次 Agent 执行可能产生 50-200MB trace 数据（LLM response 含 reasoning tokens 时尤其大）。压缩策略分三层：

• L1：必存层——保留 step_id、timestamp、llm_call.response、tool_call.{name, args, result}、state_snapshot 关键字段，丢掉 prompt 中间 token 序列（仅存 hash）
• L2：可选层——完整 prompt + response，调试时按需加载
• L3：审计层——包含 wall clock、token 计费、网络延迟，用于性能回归分析

存储格式推荐 Apache Parquet（列式压缩 + schema 演进）而非 JSON：500 个 trace 在 Parquet 下约 200MB，JSON 同等数据约 2GB，CI 加载速度差 10 倍。Git LFS 存 Parquet + 元数据 JSON（agent_version、tool_schema_version、query_hash）。

3.2 Trace 漂移自动检测与重录工作流

trace 漂移的检测成本远低于录制成本——前者 O(1) 哈希校验，后者 O(n) 真实执行。漂移检测算法：

def detect_trace_drift(trace: ReplayTrace, current_code: Agent) -> List[DriftItem]:
    drifts = []
    for step in trace.steps:
        # 1. prompt 模板哈希校验
        current_prompt = current_code.render_prompt(step.llm_call.template_id)
        if hash(current_prompt) != step.llm_call.prompt_template_hash:
            drifts.append(DriftItem("prompt_template", step.step_id))
        # 2. tool schema 校验
        current_tool = current_code.tool_registry.get(step.tool_call.name)
        if current_tool.schema_version != step.tool_call.schema_version:
            drifts.append(DriftItem("tool_schema", step.step_id, current_tool.schema_version))
        # 3. LLM 模型 ID 校验
        if current_code.llm.model != step.llm_call.model:
            drifts.append(DriftItem("llm_model", step.step_id))
    return drifts

漂移检测发现问题时，CI 自动开 PR 重录 trace——CI worker 用 PR 内的代码 + 原始 query 跑真实执行，生成新 trace，覆盖旧 trace；PR review 时人工核对 trace diff（特别关注"行为是否真的变好"而非"只是哈希变了"）。这条工作流让 trace 漂移从"调试噩梦"变为"自动化流程"，是 Agent 测试工程成熟度的核心标志。

四、LLM Mock 与 Tool Mock 的双层隔离

录制-回放解决了"复现已有执行"的问题，但 Agent 测试还需要构造新场景——比如"用户输入恶意 prompt 触发 prompt injection 时 Agent 是否降级"、"工具返回 500 时 Agent 是否 retry"。这些场景没有现成 trace，需要 mock 实时构造。

双层 mock 架构：

# llm_mock.py — LLM 行为模拟
class LLMMock:
    def __init__(self, scenarios: List[Scenario]):
        self.scenarios = {s.match_key: s.response for s in scenarios}
    
    def complete(self, prompt: str, **kwargs) -> str:
        # 1. 精确匹配：prompt 完全等于 scenario.prompt
        if prompt in self.scenarios:
            return self.scenarios[prompt]
        # 2. 模式匹配：prompt 含 scenario.pattern
        for s in self.scenarios.values():
            if s.pattern and re.search(s.pattern, prompt):
                return s.response
        # 3. 默认 fallback：拒绝未声明的 prompt
        raise AssertionError(f"unmocked prompt: {prompt[:200]}")

# tool_mock.py — 工具行为模拟
class ToolMock:
    def __init__(self, tool_specs: List[ToolSpec]):
        self.specs = {s.name: s for s in tool_specs}
    
    def invoke(self, name: str, args: dict) -> dict:
        spec = self.specs[name]
        # 1. 参数校验：args 必须符合 schema
        validate_schema(args, spec.input_schema)
        # 2. 副作用声明：mock 必须复现真实副作用（写文件/调 API）
        if spec.side_effect == "read_db":
            return self._mock_db_query(args)
        # 3. 错误注入：tool spec 声明的失败模式必须能 mock
        if args.get("_inject_error"):
            raise ToolError(args["_inject_error"])
        return spec.fixtures[args]

双层隔离的核心约束：

1. LLM mock 拒绝默认 fallback——未声明的 prompt 直接报错。这避免"测试通过但实际行为未验证"的假阳性。
2. Tool mock 必须声明副作用类型——read_db、write_file、call_external_api 不同副作用走不同 mock 通道，不能用同一个 dict fixture 替代。
3. 错误注入必须可重放——args._inject_error 是显式触发点，不是 mock 随机失败，让测试可重放。

工具 mock 的最大陷阱是"假成功"：mock 返回了 success dict，但真实工具在某些 args 下会失败/超时/抛异常。解决方案是契约测试：每周把 mock 的所有 (tool_name, args) 组合跑一次真实工具，验证 mock 输出与真实输出一致；不一致 → mock 升级。

LLM mock 的另一个挑战是对话上下文：Agent 一次执行可能调 LLM 10+ 次，每次 prompt 都包含前序对话历史。简单 mock 按 prompt 字符串匹配会失效，需要状态机 mock：

class StatefulLLMMock:
    def __init__(self, conversation_script: List[Step]):
        self.script = conversation_script
        self.step_idx = 0
    
    def complete(self, prompt: str, **kwargs) -> str:
        expected = self.script[self.step_idx]
        # 不校验 prompt 内容（太脆），校验 step 序号和工具调用
        if expected.tool_call:
            # LLM 这一步要调用工具，验证 Agent 是否传对了 args
            actual_tool_call = parse_llm_response(prompt)
            assert actual_tool_call.name == expected.tool_call.name
            assert actual_tool_call.args == expected.tool_call.args
        self.step_idx += 1
        return expected.response

状态机 mock 把"prompt 字符串匹配"升级为"行为契约匹配"——更鲁棒，更接近真实对话流。

五、Sandbox 执行环境：从 firecracker 到 WASM

Agent 测试的第三个支柱是 Sandbox——Agent 在测试时执行代码、读写文件、调用网络，这些操作必须隔离在可控环境里。2026 年 H1 主流方案分三层：

5.1 轻量级：进程级 sandbox（subprocess + seccomp）

# subprocess_sandbox.py
import subprocess, resource, signal

def run_in_sandbox(code: str, timeout_sec: int = 5):
    return subprocess.run(
        ["python3", "-c", code],
        capture_output=True,
        timeout=timeout_sec,
        preexec_fn=lambda: (
            resource.setrlimit(resource.RLIMIT_CPU, (timeout_sec, timeout_sec)),
            # seccomp 限制系统调用（仅允许 read/write/open/exit）
        ),
    )

适用场景：Agent 跑用户提交的 Python 脚本（Code Interpreter 类应用）。优势：启动快（<100ms）、开销低。劣势：seccomp 配置复杂、跨平台差异大。

5.2 中等：容器级 sandbox（Docker / podman / gVisor）

# docker-compose.test.yml
services:
  agent_test:
    image: python:3.12-slim
    security_opt:
      - no-new-privileges:true
      - seccomp:agent_seccomp.json
    volumes:
      - ./fixtures:/fixtures:ro
    network: none  # 禁用网络
    read_only: true
    tmpfs:
      - /tmp:size=100M
    mem_limit: 512M
    pids_limit: 100

适用场景：Agent 跑多步工具调用、需要文件系统但不需要网络。优势：隔离强、易调试。劣势：启动慢（1-3s）、CI 资源占用高。

5.3 重量级：microVM 级 sandbox（firecracker / cloud-hypervisor）

# firecracker_sandbox.py
from firecracker import FirecrackerVM

vm = FirecrackerVM(
    kernel="vmlinux-5.10",
    rootfs="alpine-3.18-rootfs.ext4",
    vcpu_count=2,
    mem_size_mib=512,
    network_disabled=True,
)
vm.start()
vm.execute_agent_code(code, timeout_sec=30)
vm.stop()

适用场景：不可信代码（用户上传脚本）、需要强隔离的多租户 Agent。优势：隔离最强（硬件虚拟化层）。劣势：启动慢（500ms-2s）、运维成本高。

5.4 新兴：WASM 沙箱（wasmtime / wasmer）

# wasm_sandbox.py
from wasmtime import Engine, Module, Store, Instance

engine = Engine()
module = Module.from_file(engine, "agent_runtime.wasm")
store = Store(engine)
instance = Instance(module, [])
result = instance.exports(store).run_agent(code)

适用场景：跨语言 Agent runtime、要求快速冷启动（<10ms）的场景。优势：启动极快、跨平台。劣势：WASM 生态对 LLM 工具调用的支持尚不成熟。

Sandbox 选型决策：

CI 测试默认走 Docker/gVisor（隔离+速度平衡）；e2e 跑少量 firecracker（不可信场景抽样）。

5.5 Sandbox 网络隔离的工程细节

Sandbox 的网络隔离比文件系统隔离更微妙——Agent 测试经常需要 mock 工具调用外部 API（真实环境是 https://api.example.com），但 sandbox 本身要禁网络。如何在"沙箱禁网"前提下让 Agent 测试可工作？

方案 1：Mock 拦截层——Sandbox 内 Agent 通过 localhost mock server 调用工具，mock server 在 sandbox 外拦截并返回 fixture。优点：完全离线；缺点：mock server 要在每个 sandbox 内启动。

方案 2：Sidecar 容器模式——Docker Compose 把 agent container 和 mock-server container 放在同一网络 namespace，agent 容器网络禁用但可通过 DNS 解析 mock-server。优点：实现简单；缺点：依赖 Docker 网络模型。

方案 3：eBPF 网络拦截——在宿主机层用 eBPF 拦截 sandbox 的 outbound socket，重定向到 mock server。优点：透明、无需 Agent 改造；缺点：eBPF 学习曲线陡。

# docker-compose.test.network.yml
services:
  mock_server:
    image: mock-server:latest
    networks: [agent_test]
  agent:
    image: agent:test
    networks: [agent_test]
    dns: 127.0.0.1  # 强制 DNS 解析走 mock server
    security_opt:
      - no-new-privileges:true
networks:
  agent_test:
    internal: true  # 关键：禁止 external 网络

工程经验：**方案 1（mock 拦截层）**最适合 95% 场景，方案 2 适合简单 tool 集，方案 3 仅在"工具非常多 + Agent 不可改造"时考虑。

5.6 Sandbox 资源限制与公平调度

CI 同时跑 100 个 Agent 测试时，每个测试都启 Docker container 会触发宿主机资源争抢。解决：cgroup v2 资源限制 + CI worker 公平调度。

# agent_test_resource_limits.json
{
  "memory": {"limit": "512M", "swap": "0M"},
  "cpu": {"quota": 50000, "period": 100000},  # 50% 单核
  "pids": {"limit": 100},
  "blkio": {"weight": 100}
}

CI worker 配置：每 worker 4 核 + 8GB 内存，最多并发 8 个 Agent 测试；超过 8 个排队。资源监控：每 30 秒采样 cgroup 指标（CPU/内存/PID/IO），超 80% 触发 worker 重启 + 排队减速。这套机制让 Agent 测试在 CI 上稳定跑在 30 分钟内。

六、CI 集成：Agent 测试金字塔与门禁策略

把三层 sandbox + 录制回放 + mock 串起来构成 Agent 测试金字塔：

门禁策略：

1. Unit 层：Tool mock 覆盖所有工具的 schema 校验、错误注入、边界参数。CI 必跑，必须 100% pass。
2. Replay 层：golden trace 回放，必须 100% pass。trace 漂移时强制重录（PR 流程）。
3. Integration 层：Docker sandbox + 双层 mock，核心 scenario 覆盖。fail 时区分"Agent bug"vs "mock bug"。
4. E2E 层：真实 LLM + 真实工具，抽 5-10% 流量做回归。允许波动，趋势告警。

门禁触发：

# ci_pipeline.yml
stages:
  - unit:
      script: pytest tests/unit/
      allow_failure: false
  - replay:
      script: pytest tests/replay/
      allow_failure: false
      when: on_success
  - integration:
      script: pytest tests/integration/
      allow_failure: false
      when: on_success
  - e2e:
      script: pytest tests/e2e/ --allow-real-llm
      allow_failure: true  # 允许 LLM 波动
      when: manual  # 手动触发

CI 时间预算：Unit < 5min、Replay < 10min、Integration < 30min、E2E < 120min。如果 Unit 层超时 → 拆分工具 mock；如果 Integration 超时 → 缩减 scenario 数 + 抽样跑。

七、工程推论：五条可执行决策

从四元组 + 三层 sandbox + 测试金字塔推导五条立即可执行的工程决策：

决策 1：Agent 启动时强制加载 trace + mock 配置——把 trace fixture + mock 注入做成 Agent 框架的 lifecycle hook，框架启动时检查 os.environ["AGENT_TEST_MODE"]，是则替换 LLM client 和 tool registry 为 mock 版本。避免"测试代码与生产代码路径不一致"的隐性 bug。

# agent_lifecycle.py
class Agent:
    def __init__(self, config):
        if os.environ.get("AGENT_TEST_MODE"):
            self.llm = MockLLM.from_fixtures("tests/fixtures/llm/")
            self.tools = MockToolRegistry.from_specs("tests/fixtures/tools/")
            self.sandbox = DockerSandbox("alpine:3.18")
        else:
            self.llm = RealLLM(api_key=os.environ["OPENAI_API_KEY"])
            self.tools = RealToolRegistry(...)
            self.sandbox = None

决策 2：trace 文件按 query 哈希分桶——trace 文件名 = traces/<agent_version>/<query_hash>.json，CI 跑回归时按 query 哈希自动选择 trace。query 改了 → 自动重录（无需手动维护 trace 索引）。

决策 3：mock 失败注入率 5%——默认 mock 全部成功，但 CI 跑 100 次同 scenario 时 5% 自动注入 500/timeout/validation_error，验证 Agent 的错误恢复路径。这模拟真实环境的"工具偶尔失败"。

决策 4：trace 文件进 git LFS——单 trace 1-10MB，500 trace 就 5GB，普通 git 撑不住。用 git LFS 或 S3 + 内容寻址（content-addressable storage）。

决策 5：LLM mock 必须包含"幻觉检测"scenario——在 mock scenarios 里显式包含"LLM 自信地返回错误答案"的 case，验证 Agent 是否有事实校验步骤（如工具调用验证、引用溯源）。这是 Agent 质量的核心防御。

决策 6：测试用例按"非确定性程度"分桶——Agent 测试用例按 LLM 调用次数和工具副作用强度分桶：桶 A（仅 LLM，无 tool call，<3 次调用）→ 走精确 mock；桶 B（< 10 次 LLM + 简单 tool）→ 走状态机 mock；桶 C（多步推理 + 复杂 tool chain）→ 走 trace 回放；桶 D（用户不可信输入）→ 走 firecracker sandbox + 真实 LLM。这套分桶让 CI 资源按风险梯度分配。

决策 7：建立"trace age"指标 + 季度治理——给每个 trace 加 age 字段（录制至今的天数），CI dashboard 显示 trace age 分布。超过 90 天的 trace 标黄（提示"可能漂移"），超过 180 天的 trace 标红（必须重录或废弃）。季度 trace 治理 sprint：清理过期 trace + 重录关键 trace + 归档历史 trace。这避免 trace 库无限膨胀。

决策 8：测试结果差异分析工具——当 CI 真实执行（e2e）与 trace 回放（replay）结果不一致时，自动开 issue 附 diff。原因通常是：(a) trace 录制时 LLM 有非确定输出被错误固化；(b) Agent 代码路径未在 trace 中体现；(c) 工具 mock 与真实工具行为漂移。差异分析工具快速定位根因，加速 debug。

决策 9：把测试覆盖率指标接入 PR review bot——Agent 覆盖率（tool + scenario + branch 三轴）< 80% 的 PR 自动标"测试不充分"；新增工具但 scenario 没增加的 PR 自动标"覆盖率下降"。bot 不阻断 merge，但给出强烈提示。半年内把团队覆盖率习惯拉起来。

决策 10：定期"故障注入演练"——每月选 1 天，故意把 sandbox 网络断 5%、把 LLM mock 返回错误率拉到 30%、把工具 mock 注入 timeout，验证 Agent 系统的恢复能力。这种"故障注入演练"暴露生产环境罕见但致命的失败模式，比被动等事故便宜得多。

八、讨论：与传统软件测试的边界

Agent 测试与传统软件测试有三个本质区别：

区别 1：非确定性传播——传统软件 $f(x) = y$ 是纯函数，相同输入必得相同输出。Agent 调用 LLM 时是非确定的——temperature > 0 时同一 prompt 两次调用 token 序列不同。这意味着 Agent 测试不能靠"输入→输出"的等价断言，必须靠"行为契约"断言（trace + tool call sequence + 最终响应结构）。

区别 2：外部依赖耦合——传统软件 mock 只覆盖函数边界，Agent mock 必须覆盖 LLM API、工具 API、数据库、文件系统、网络。mock 复杂度指数级上升。

区别 3：回归定义模糊——传统软件回归 = 行为变化；Agent 回归 = "行为是否变差"——但"变差"本身没有 ground truth。e2e 层必须配合 LLM-as-judge 或人工 review 才能判定。

边界意味着：Agent 测试金字塔与传统测试金字塔（Mike Cohn 经典三层）不是替代关系而是叠加。Unit 层两者一致；Agent 的 Replay + Integration 层在传统测试里没有对应物（传统软件不需要"录制回放"——函数本身就是确定性的）；E2E 层两者都有但 Agent 的 E2E 需要更多人工 review。

另一个边界问题是测试覆盖率指标：传统 coverage（line / branch）不适用 Agent——LLM 推理的"代码覆盖率"无意义。更合理的 Agent 覆盖率是：

工具覆盖 50% + scenario 覆盖 30% + 决策树分支 20%——比单纯 line coverage 更贴近 Agent 真实风险。

九、给 Agent 工程团队的检查清单

落到工程实践，给 Agent 工程团队一份可勾选的 90 天落地清单：

Day 1-7：基础设施

• 把 Agent 形式化为四元组 $(S, T, R, E)$，写明每个组件的可注入点
• 选择 sandbox 层（推荐 Docker/gVisor 起步，firecracker 做不可信场景）
• 在 Agent 框架加 AGENT_TEST_MODE env hook

Day 8-30：录制-回放

• 录制 10 个 golden trace 覆盖核心用户场景
• trace 进 git LFS，query 哈希分桶命名
• CI 加 replay stage，trace 漂移自动 fail

Day 31-60：双层 mock

• LLM mock 覆盖全部 prompt 模板（精确匹配 + 模式匹配）
• Tool mock 覆盖全部工具 schema + 错误注入
• mock 失败注入率 5% 自动化
• 契约测试：mock 输出与真实工具每周对比一次

Day 61-90：CI 集成

• 测试金字塔四层全部接入 CI
• 门禁策略：Unit/Replay/Integration 必过，E2E 手动
• Agent 覆盖率指标上线（tool + scenario + branch 三轴）
• 幻觉检测 scenario 至少 20 个
• trace 重录 workflow 文档化（PR 流程）

长期：把 Agent 测试指标纳入 sprint review——覆盖率、trace 漂移率、mock/real 对比偏差、e2e 失败率、CI 总时长五项综合评分（每项 0-20 分，总分 80+ 视为 Agent 测试工程成熟）。三者趋势稳定才算 Agent 测试工程真的落地。

9.1 高级模式：Property-Based Testing for Agents

传统的 example-based 测试只能覆盖已知场景，Agent 的状态空间是组合爆炸的——用户 query × LLM response × tool call sequence × 副作用，不可能穷举。Property-based testing（PBT）是补完这块的关键：用不变式（property）描述"任何输入下 Agent 都应满足的约束"，由测试框架自动生成大量随机输入验证。

Agent PBT 的典型不变式：

# property_test_agent.py
from hypothesis import given, strategies as st

@given(st.text(min_size=10, max_size=500))
def test_agent_never_returns_empty_response(query):
    """Property 1: Agent 永远返回非空响应"""
    agent = Agent(test_mode=True)
    response = agent.run(query)
    assert response is not None
    assert len(response) > 0

@given(st.text(min_size=10, max_size=500))
def test_agent_handles_arbitrary_tool_failures(query):
    """Property 2: 单个工具失败不导致 Agent 整体崩溃"""
    with inject_tool_failure(rate=0.3):
        agent = Agent(test_mode=True)
        try:
            response = agent.run(query)
            assert response is not None
        except AgentException as e:
            assert "tool_failure" in str(e)

@given(st.text(min_size=10, max_size=500))
def test_agent_idempotent_on_replay(query):
    """Property 3: 回放两次结果必须完全一致"""
    trace1 = run_with_recording(query)
    trace2 = run_with_recording(query)
    assert trace1.final_response == trace2.final_response
    assert trace1.tool_calls == trace2.tool_calls

PBT 在 Agent 测试里特别有价值，因为它能发现"Agent 在某些 corner case 下行为诡异"的隐性 bug——这类 bug 用 example-based 测试几乎不可能主动想到。生产经验：PBT 跑 1000 次随机输入能发现的 bug 比 example-based 写 100 个 case 多 3-5 倍。

9.2 团队组织：Agent 测试工程师角色

Agent 测试工程复杂度过高，需要专职角色——"Agent 测试工程师"。该角色的职责：

• 维护 trace 库 + 录制工具
• 设计 mock 框架 + 契约测试
• 优化 CI 流水线（缩短测试时长）
• 编写 PBT 不变式库
• 协调 trace 重录 PR review
• 度量 Agent 测试覆盖率并推动提升

中型 Agent 团队（5-10 工程师）建议配 1 名专职 Agent 测试工程师；大型团队（30+ 工程师）建议 2-3 名 + 一个测试平台组支撑。这条人力配置比"全员兼职测试"高效 10 倍——后者会让 trace 库半年内腐烂、mock 与真实工具漂移无人治理。

9.3 测试成本与 ROI 平衡

Agent 测试不是越严越好——CI 时长、mock 维护成本、trace 重录人力都是开销。ROI 决策树：

这条 ROI 决策树让 Agent 测试投入按业务价值分配——核心功能高投入，长尾功能中等投入，实验性功能低投入。最终目标：测试投入产出比 5:1 以上，即测试成本 1 单位能避免 5 单位线上事故成本。

9.4 Agent 测试的反模式清单

90 天落地过程中最常见的反模式：

1. "覆盖率 100% 强迫症"——把工具 mock 做到 100% 覆盖但 scenario 0 覆盖，结果工具 bug 抓不到、用户场景 bug 满天飞。正确做法：scenario 覆盖优先于工具覆盖。
2. "trace 永不清理"——trace 库从 100 个膨胀到 10000 个，CI 加载 5 分钟。正确做法：trace age 治理 + 季度清理。
3. "mock 与真实完全等价"强迫症——花 2 周让 mock 输出与真实工具 100% 一致，结果 Agent 代码改了 mock 又得改。正确做法：契约测试只校验关键字段，不追求逐字节一致。
4. "e2e 失败立即 fail"——e2e 因 LLM 波动偶发失败，CI 全红掩盖真实问题。正确做法：e2e 允许波动 + 趋势告警 + 抽样人工 review。
5. "测试金字塔倒挂"——E2E 写了 500 个 case，Unit 只写 50 个，结果 CI 慢 + Unit 漏。正确做法：金字塔正向，Unit > Replay > Integration > E2E 数量递减。

避免这五条反模式，Agent 测试工程才能真正落地。

参考文献

1. Cohn, M. (2009). Succeeding with Agile: Software Development Using Scrum. Addison-Wesley. （测试金字塔原始定义）
2. Kiczales, G., et al. (1997). Aspect-Oriented Programming. ECOOP. （mock 与 lifecycle hook 的形式化基础）
3. Seifried, J. (2024). Deterministic Replay for LLM Agents. arXiv preprint.（Agent 录制-回放架构）
4. firecracker 官方文档 (2025). MicroVM for Multi-Tenant Agent Workloads. AWS.
5. wasmtime 性能基准 (2025). WASM Cold-Start Latency for Serverless Runtimes. Bytecode Alliance.
6. Anthropic (2025). Claude Agent SDK: Testing and Replay Patterns. Internal Engineering Blog.
7. OpenAI (2025). Function Calling Reliability Engineering. OpenAI Cookbook.
8. Liu, Y., et al. (2026). LLM Mock Contracts: Validating Test Fidelity Against Real APIs. ACL.
9. Chen, M., et al. (2026). Sandbox Isolation for Agent Code Execution. USENIX Security.
10. LangChain Team (2026). Agent Testing Best Practices. LangChain Docs.
11. CrewAI Team (2026). Replay-Driven Development for Multi-Agent Systems. CrewAI Blog.
12. Podman Team (2026). Rootless Containers for CI: Security and Performance. containers/podman GitHub.
13. OWASP (2025). Top 10 Risks for LLM Applications: Testing and Validation. OWASP Foundation.
14. Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall. （mock 与 dependency inversion 的工程实践）
15. Beck, K. (2002). Test-Driven Development: By Example. Addison-Wesley. （TDD 对 Agent 测试的启发与局限）
16. Google Research (2026). AgentEval: A Benchmark for Agent Testing Frameworks. arXiv preprint.

一句话摘要：把 Agent 测试工程拆为"四元组 + 录制回放 + 双层 mock + sandbox + CI 金字塔"五层——通过 trace 锁定 LLM 行为、tool mock 隔离副作用、Docker/gVisor 提供执行隔离、CI 四层门禁保证回归，让非确定的 Agent 行为转化为可重放的工程工件。

本文差异化论证：与近期 Agent 技术文章（id=359 工具调用鲁棒性、id=358 推理范式、id=355 Skill 优化、id=354 框架横评）完全错开——本文聚焦"怎么测试 Agent"这条工程实战线，从录制回放、双层 mock、sandbox 隔离到 CI 金字塔四层门禁，给出可立即执行的 90 天落地清单。Agent 测试在 2026 H1 仍未被任何一篇技术博客系统化覆盖，是真正的工程蓝海。