Agent 测试工程 2026：从确定性到金字塔

一、问题的提出：Agent 测试的"非确定性诅咒"与本篇立场

Agent 系统在 2026 年已经从"概念验证"走进"生产常态"。LangGraph 仓库截至 2026-07-30 在 GitHub 拿到 38,518 颗星、6,490 个 fork，最近一次提交就在当日 19:19 UTC；CrewAI 同日拿到 56,397 颗星、8,020 个 fork；微软的 AutoGen 仓库停留在 60,117 颗星与 2026-04-15 的最后一次提交，已经连续三个多月没有合入主线分支；OpenAI Agents Python SDK 则在 28,297 颗星、4,407 个 fork 的体量上保持着 2026-07-30 的活跃节奏。这四个数字并不是简单的"竞品热度排行榜"——它们折射出一个更深层的事实：Agent 框架的工程重心已经从"能不能跑"转向"能不能测"。一个能在 demo notebook 里跑通的 ReAct 循环，把它放到 CI 流水线里放进版本门禁放进灰度发布放进 SLA 监控，立刻就会撞上一面名为"非确定性"的墙。

传统单元测试的根基是：给定相同的输入，得到相同的输出。这个根基在大模型调用面前是缺位的。同一个 prompt 喂给同一个模型，温度参数即便设为 0，不同时间窗口的推理也可能因为推理引擎的 prefix cache 命中率、KV 复用的批处理对齐、CUDA kernel 的非完全确定性浮点累加等隐性因素产生微小但累积的差异；温度参数一旦开到 0.7 之上，整段轨迹就开始发散；多智能体编排里一个 agent 的输出是另一个 agent 的输入，第一步的发散会被指数级放大。所有这些让"测试通过 / 测试失败"这个二值信号变得几乎不可信。开发者写完一段 agent 代码，按下 CI 按钮，看到红叉，会本能地怀疑是代码 bug 还是模型 bug；看到绿勾，又会本能地怀疑这次是不是运气好。一个团队如果不能在 30 秒内回答"这次失败到底是不是回归"，整个工程节奏都会被拖垮。

本篇要解决的就是这个问题。我们不打算重复讨论"为什么 LLM 不可复现"这种已经被讲烂的话题，也不打算站在哲学层面争论"非确定性系统的可测性是否可能"这种二阶问题。本篇的目标更工程化、更有用：给读者一套 2026 年能在 CI 里真正跑起来的 Agent 测试工程范式——从 deterministic mock、LLM stub、replay 录制回放、tool stub、环境隔离到层级测试金字塔，每一层都给出具体的代码骨架、库选型对比、踩坑诊断与可观测性闭环。我们会刻意避开"理论上很美但 CI 跑不起来"的方案（比如把所有测试都接真实 LLM API），也刻意避开"完全 mock 掉一切等于不测"的方案（比如把整个 agent 替换成一个返回固定字符串的假函数）。前者烧钱且不稳定，后者等于在用单元测试的仪式感掩盖集成测试的缺失。

我们的立场可以一句话概括：Agent 测试不是一个工具，是一个工程学科。它的可信度由四个互相制约的维度共同决定——determinism（确定性）、fidelity（保真度）、coverage（覆盖率）、cost（成本）——任何一项极端追求都会破坏其余三项。我们接下来的篇幅就是围绕这四个维度，给读者一个可以复制、可以度量、可以 CI 化的工程蓝图。

二、形式化：测试可信度的四元组 (D × F × C × K)

我们形式化定义 Agent 测试的"四元组可信度"：D 代表 determinism，是测试在重复运行下输出 bit-identical 程度的度量；F 代表 fidelity，是被测系统与生产系统行为相似度的度量；C 代表 coverage，是测试对状态空间、工具路径、错误分支的触达比例；K 代表 cost，是单次完整测试的金钱、token、wall-clock 与算力四要素的合计。这四个维度构成一个不可同时最大化的 trade-off 四面体——这是我们整个测试工程的根约束。增加 determinism 通常需要引入 mock 或固定 seed，这会降低 fidelity；增加 fidelity 又意味着放弃 mock、改接真实 API，cost 立刻指数级上升；想同时拉高 coverage 又会把测试用例数量推到一个 CI 跑不完的量级。

形式化表达上，我们可以把每一次测试运行看成一次从被测系统状态空间 S 到观察空间 O 的映射 τ: S → O；测试集 T 是多个 τ 的集合。Agent 系统的 S 通常是高维的（消息历史、工具缓存、外部 API 响应、token 计数、时间戳、随机数生成器状态），τ 也不是确定函数。在传统软件测试里，我们可以用 property-based testing 把 τ 抽象成纯函数；Agent 测试里 τ 本质是 sampling——这意味着我们对"测试通过"的语义必须重新定义：不是"τ(s) = expected_output"，而是"P(τ(s) ∈ AcceptableRegion) ≥ 1 - ε"，其中 ε 是团队可接受的失败概率。

这个概率视角引出一个关键操作：对 acceptance 的可接受区域要做拓扑描述，而不是点描述。比如某段 agent 代码期望最终输出包含"订单号：ORD-12345"，传统的断言会写成 assert "ORD-12345" in final_message，但这等价于把可接受区域缩小到一个点——任何 LLM 的微小偏差都会让测试闪烁。工程化的写法是接受一个区域："消息必须包含一个形如 订单号：ORD-\d{5} 的正则匹配"。更进一步，可以接受"消息中必须出现以下三个语义槽位中的任意两个：订单号、收件人、预计送达日"——这种"槽位存在性 + 语义等价"的断言模式才是 Agent 测试的合理形态。

这个形式化还引出一个推论：determinism 不应该是测试的目标，应该是测试的属性。在 CI 里强行追求 bit-identical 复现，会让团队陷入"为了确定性牺牲一切保真度"的陷阱，把 mock 写到不能反映任何生产行为的程度。一个成熟的测试体系应该明确标注每个测试在哪条 trade-off 边上：单元级 LLM stub 测试是高 D 低 F 低 C 低 K；端到端真实 API 测试是低 D 高 F 中 C 高 K；replay 测试落在中间；tool stub + 真实 LLM 组合又是一种变种。测试金字塔的本质就是这四个维度在不同层级上的不同组合——后面 §6 我们会展开层级金字塔的具体架构。

三、deterministic mock 与 LLM stub 的工程真相

deterministic mock 是 Agent 测试金字塔的最底层，也是最被滥用的一层。原则很简单：把所有外部依赖替换成确定性返回值。落地时有三种模式：第一种是完全替换——把 LLM 调用替换成 return "fake response" 这种字符串字面量；第二种是录制回放式——先在生产环境记录一次真实的 LLM 响应，下游测试直接 replay；第三种是模型级 stub——用一个比生产模型小几个数量级的模型（比如 0.5B 参数的蒸馏模型）来模拟主模型的行为，但保留一定的语义随机性。这三种模式分别对应 D×F×C×K 四面体的不同投影，工程上各有适配场景。

完全替换式 mock 的代表是 LangChain 生态里的 FakeListLLM、LangGraph 里的 FakeChatModel，以及 pytest 生态里通用的 unittest.mock.MagicMock。它们接受一个字符串列表，按调用顺序逐次返回，CI 跑起来毫秒级，确定性极高。但它们的 fidelity 是零——被测 agent 拿到的永远是"hi there, I'm a fake model"这种无意义字符串，所有 LLM 依赖的判断逻辑都被绕过。这种 mock 只适合结构性测试：测试 ReAct 循环能不能进入正确的 tool 调用分支、测试消息路由能不能正确分发给不同的子 agent、测试状态机的 transition 在外部事件触发下能不能正确推进。任何涉及"模型到底会不会判断对"的语义测试都会被这种 mock 完全掩盖。

录制回放式 stub 的代表是 VCR.py（在 Python 生态里最有代表性的 HTTP 录制库）、LangSmith 的 Dataset Replay、LangGraph 的 Memory Store Replay。它的工作流是：先用真实 API 跑一次生产路径，把所有 HTTP 请求-响应对序列化到 cassette 文件；后续测试把这个 cassette 当成 fixture 加载，对每个 LLM API 调用做精确匹配。fidelity 比完全替换高得多，因为录制的响应包含了真实模型的语义；D 仍然是 1，因为 cassette 是不可变的；C 由录制时的路径覆盖决定；K 几乎为零，毫秒级完成。踩坑点是 cassette 漂移：生产 prompt 模板改了一行、cassette 就失效，必须重新录制。这套模式适合集成测试层——验证 agent 与真实工具、真实 RAG 检索、真实数据库 schema 的交互是否正确。

模型级 stub 的代表是 HuggingFace Transformers 里的小模型加载、SGLang 的 deterministic mode、vLLM 的 --seed 参数。它在保留 LLM 的语义随机性的同时通过固定 random seed 把发散控制在一个可接受范围内。这种模式适合回归测试层：你想知道某个 prompt 模板改动会不会让输出质量下降，但又不希望接入 OpenAI API 烧钱。这种模式的 fidelity 介于前两者之间——输出仍然是 LLM 风格的自然语言，但不一定反映生产模型的真实能力。一个工程化的折中是跑两套：单元层用完全替换 mock 验结构、回归层用模型级 stub 验语义。CI 里完全替换 mock 跑 1000 个用例毫秒级、模型级 stub 跑 100 个用例分钟级、真实 API 跑 10 个用例十分钟级——这是工业界 2026 年的标准配比。

四、replay 录制回放与 trace 重放

replay 是 Agent 测试里最容易被低估但工程回报最大的一层。它的核心思想来自分布式系统的"故障重放"传统——把生产环境真实发生的一段 trace 完整记录下来，包括 LLM 调用、工具调用、状态转移、消息路由，然后让被测系统在受控环境下重新执行这段 trace，验证输出是否仍然合理。LangSmith、LangGraph Studio、OpenAI Agents SDK 的 Tracing 模块、Anthropic Claude Agent SDK 的 trace inspector 都原生支持这一范式。replay 在工程上有三个独特价值：它把生产真实行为变成可重放的测试输入、它把"这次为什么错了"这种事后分析变成可重跑的测试用例、它让模型升级验证有了真实的对照基准。

replay 的工程骨架通常由四部分组成：trace recorder（生产侧采集）、trace serializer（持久化到对象存储）、trace loader（测试侧回放）、assertion engine（断言 trace 的最终状态或关键中间节点）。trace recorder 通常基于 OpenTelemetry 的 span 模型扩展，每个 span 包含 prompt 模板 + 模型名 + temperature + seed + 输入 token + 输出 token + 工具调用 + 延迟 + cost + 元数据。trace serializer 通常用 Parquet 或 JSONL，每个 trace 一个文件，文件名包含 trace_id、agent_version、production_timestamp。这种格式让 trace 既可读又可索引，工程师可以用 DuckDB 在 100ms 内筛选出"过去 24 小时所有 temperature > 0.8 的失败 trace"。assertion engine 是 replay 测试的差异化能力——它不只比较"最终输出文本"，还可以比较"中间 reasoning 步骤是否符合预期"、"tool 调用顺序是否与生产一致"、"cost 是否在预算内"、"latency 是否在 SLA 内"。这种多维断言让 replay 测试的覆盖率远超传统单元测试。

工程踩坑点有三个。第一，trace 漂移：生产模型升级会让 replay 失败，因为同一个 prompt 在新模型下产生不同输出。这不是 bug 而是版本变化的合理信号——测试系统应该自动检测"trace 输入 + agent 版本"是否与历史匹配，匹配才跑，否则跳过并标注"stale trace"。第二，PII 泄漏：replay 文件经常包含真实用户数据，必须在 serializer 层做脱敏——masking 掉邮箱、电话、地址，但保留 prompt 的语义结构。一个常见的反模式是直接用生产 trace 做 replay，导致测试日志里出现客户姓名。第三，环境依赖：replay 通常假设外部 API、数据库、外部文件状态在录制时刻和回放时刻是相同的。如果 trace 包含"读取 /tmp/foo.json"这种本地路径操作，回放时这个文件可能不存在。解法是在 trace 里把这类外部依赖也序列化下来，或者在回放前用 deterministic filesystem（fakefs、in-memory FS）整体替换。

五、tool stub 与环境隔离（firecracker / gVisor / Docker）

tool stub 解决的是 Agent 测试金字塔里"工具调用"那一层的问题。Agent 系统里有两类工具：一类是只读工具（搜索、查询、读取文件），一类是写操作工具（修改数据库、发邮件、执行 shell）。前者可以用纯函数 stub 替换，后者必须考虑副作用隔离。工程上有三种模式：纯函数 stub、文件系统 stub、进程级 sandbox。纯函数 stub 的代表是 pytest 的 monkeypatch.setattr、unittest.mock.patch，适合 HTTP 客户端、SDK 调用；文件系统 stub 用 pyfakefs、mock-fs 替换整个文件系统层；进程级 sandbox 用 bubblewrap、nsjail、firecracker、gVisor、Docker 启动一个轻量级隔离进程执行写操作。

生产环境的 Agent 经常需要执行 shell 命令、运行 Python 代码、调用 git 操作。如果这些操作没有隔离直接跑在测试机或者 CI runner 上，轻则污染测试环境，重则引发安全事故。firecracker 是 AWS 开源的 microVM，1.5 秒冷启动、内存开销小于 5MB，2026 年已经成为 CI sandbox 的事实标准；gVisor 是 Google 的 user-space kernel，拦截所有 syscall，性能开销比 firecracker 略高但兼容性更好；Docker + gVisor 组合是 GitHub Actions、GitLab CI 的默认 sandbox。三者的选型逻辑可以简化为：firecracker 用于性能敏感的代码执行 sandbox（比如让 Agent 跑一段 Python 验证算法正确性）、gVisor 用于需要丰富 syscall 兼容性的工具调用 sandbox（比如 npm install 这种重度 fs 操作的场景）、Docker 用于普通 CI 步骤隔离。

工程骨架上，tool stub 通常包装成一个 @sandbox_tool 装饰器或者 SandboxExecutor 类。生产代码里写 result = await agent.invoke_tool("git_commit", {"msg": "fix"})，测试代码里写 result = await stub.invoke_tool("git_commit", {"msg": "fix"}, return_value="commit_sha_12345") 或者 result = await sandbox.invoke_tool("git_commit", {"msg": "fix"}, sandbox="firecracker")。这种抽象让工具调用从"直接调函数"变成"通过 stub 调度"，测试侧可以自由切换 stub、sandbox、生产三种后端。一个成熟的 Agent 框架应该把这层抽象固化在 SDK 里——LangGraph 的 ToolNode、CrewAI 的 Tool、AutoGen 的 FunctionCall 都内置了类似的能力，但深度差异很大。LangGraph 的 ToolNode 把 tool stub 与 replay 集成得最好，CrewAI 的 tool 抽象更偏向业务语义，AutoGen 的 FunctionCall 更接近底层。

tool stub 还有一层隐藏价值：它把测试金字塔里"工具层"的 fidelity 与 determinism 解耦。我们可以让 LLM 用真实 API（高 F），同时让 tool 调用走 stub（高 D），整体测试仍然是确定性可重放的。这种"分层 mock"是 Agent 测试工程的核心技巧之一——完全 mock 掉一切会失去测试意义，完全不 mock 又跑不起来，分层 mock 是唯一的工程化折中。

六、统一视角：CI 中 agent 测试的层级金字塔

把前面四节的内容整合起来，我们得到 Agent 测试的层级金字塔。自下而上分为五层，每层对应 D×F×C×K 四面体的一个特定投影。

第一层：纯结构单元测试（High D / Low F / Low C / Low K）——完全替换式 mock，验证消息路由、状态转移、tool 分发、错误处理分支。毫秒级，跑数千用例。代表工具：pytest、unittest.mock、LangChain FakeListLLM。

第二层：录制回放集成测试（High D / Medium F / Medium C / Low K）——VCR.py + cassette fixture，验证 agent 与真实外部 API 的交互模式。秒级，跑数百用例。代表工具：VCR.py、responses、betamax、vcrpy。

第三层：模型级 stub 回归测试（Medium D / Medium-High F / Medium C / Medium K）——固定 seed 的小模型或同模型低温度，验证 prompt 模板改动的语义影响。分钟级，跑数十用例。代表工具：transformers + seed、SGLang deterministic、vLLM --seed。

第四层：tool stub + 真实 LLM 集成测试（Low-Medium D / High F / Medium C / Medium-High K）——LLM 走真实 API，工具走 stub 或 sandbox。验证"模型 + 工具"的协同是否正确。十分钟级，跑十到数十用例。代表工具：自定义 SandboxExecutor + OpenAI API / Anthropic API。

第五层：端到端 + replay 验证（Low D / Very High F / High C / Very High K）——真实 LLM + 真实工具 + 生产 trace replay，验证真实用户场景。小时级，跑数用例，通常 nightly。代表工具：LangSmith Dataset Replay + LangGraph Studio + 生产 trace store。

金字塔的关键是每层之间存在晋升机制：第一层 PASS 是 PR 合并的硬门禁；第二层 PASS 是 nightly 发布的必要条件；第三层 PASS 是模型升级前的必跑门禁；第四层 PASS 是月度发布的硬条件；第五层 PASS 触发线上灰度发布。这种分层让 CI 时间预算可控——PR 反馈循环保持在 5 分钟内，nightly 控制在 1 小时内，月度发布控制在 12 小时内。没有分层的 Agent 测试体系一定会撞墙：要么把端到端测试塞进 PR 检查让开发者 1 小时看不到反馈，要么把单元测试当作唯一门禁让生产事故不断。

跨层的关键工程能力是trace continuity：第一层 mock 返回的 fake response 必须能在第二层 cassette 里复现；第四层真实 LLM 输出必须能被第五层 replay trace 捕获并再次验证。LangGraph 的 Memory Store 与 Checkpointer 在 2025-2026 年的演进就是围绕这个能力——它把每次 agent 执行的完整状态序列化下来，让任何一层测试都能拿到上一层的中间产物。这种"全栈 trace"是 Agent 测试金字塔能够真正落地的基础设施，也是 Agent 工程与传统软件测试最大的差异点。

七、对工程实践的推论：六条落地清单

基于前面六节的形式化与层级分析，我们给读者六条具体的工程落地建议。每条都给出可操作的工程动作、推荐的工具栈与常见的失败模式。

1. 立即为项目划分测试金字塔层级——不要等"测试崩了"才分层。在 tests/ 目录下建立 unit/、integration/、regression/、e2e/ 四个子目录，每个目录的测试文件命名严格遵循层级约定（test_unit_*.py、test_integration_*.py 等）。CI 配置文件里按层级分别设置超时、并行度、重试策略。失败模式：所有测试混在一起，CI 时间膨胀到小时级，开发者开始 --no-verify 绕过门禁。

2. 录制至少 100 条生产 trace 作为 e2e 测试基线——这是从"无测试"过渡到"有测试"最快的路径。让 Agent 在生产环境开启 trace 录制一周，把 trace 自动归类（成功 / 失败 / 异常终止 / 用户中途打断），每个分类至少保留 20 条作为 golden trace。失败模式：trace 文件太大（每条上百 MB），必须做采样 + 字段裁剪，只保留 prompt、response、tool_call、tool_response、final_message、cost、latency 这七个核心字段。

3. 引入 deterministic seed 管理工具——不要在代码里硬编码 random.seed(42)，用一个 SeedManager 类集中管理 seed pool。生产环境关闭 seed 注入以保留随机性，测试环境从 seed pool 取 seed 让 trace 可复现。推荐 pyngus、deterministic-py、numpy + torch + transformers 的 seed 联合设置。失败模式：只设了 Python 层 seed 没设 PyTorch 层 seed，导致模型输出仍然发散。

4. 强制执行分层 mock 纪律——LLM 调用必须可切换（mock / stub / real），工具调用必须可切换（mock / stub / sandbox）。在 SDK 层封装 LLMClient 与 ToolExecutor 两个抽象类，测试时注入不同的实现。失败模式：业务代码直接 import openai 并调用 openai.chat.completions.create，测试时改不动，必须 monkeypatch 全局，这种代码永远写不出干净的集成测试。

5. 把 sandbox 纳入 CI 基础设施——不要等安全团队来推动才上 sandbox。在 CI runner 上预装 firecracker 或者 gVisor，提供统一的 sandbox API（SandboxExecutor.run(code, lang, timeout)），所有写操作类工具的测试默认走 sandbox。失败模式：Agent 测试在 CI 里跑得好好的，部署到生产环境的某个特殊输入触发了一个 shell 命令，把生产数据库删了——这种新闻每年都有。

6. 建立测试 cost 仪表盘——每次测试运行记录 token、wall-clock、money 三个 cost 维度，按层级、按模型、按测试文件聚合。如果某次 PR 让 e2e 层 cost 翻倍，立刻报警。失败模式：CI 跑了 3 个月，账单从每月 100 美元涨到每月 5000 美元没人发现——这种 cost 失控在 Agent 测试场景非常常见，因为真实 LLM API 调用的 cost 不是传统 CI 能见到的。

八、讨论：测试金字塔的边界与"反测试"哲学

金字塔不是银弹。有三类场景它天然不擅长，需要读者保持工程判断力。

第一类是高度创造性的 Agent——比如营销文案生成器、开放式对话 Agent。这类 Agent 的输出空间近乎无限，"acceptance region"的拓扑描述本身就很模糊，硬套金字塔会让测试变成"什么也不测"。对这类系统，更有效的是 pairwise A/B 框架 + 人类评估——让生产流量分流到新旧两个 agent 版本，让用户行为（点赞、采纳、停留时长）作为评价信号。pytest 和 VCR.py 在这里派不上用场，要切换到 Statsig、LaunchDarkly、Eppo 这类 feature flag + 实验平台。

第二类是多智能体协作系统——5 个以上 agent 互相调用，整体行为呈现混沌系统特征。这种系统的 trace 长度爆炸（金字塔第四层的一次运行可能产生 200 个 span），单点断言失效，整体断言又太粗糙。工程化的解法是 behavioral fingerprinting：用一组低维向量（平均消息长度、tool 调用分布、终止时间分布、cost 分布）描述一次 agent run 的"行为指纹"，把指纹的 KL 散度作为相似度度量。两次运行的指纹 KL 散度 < 0.1 视为行为一致。这套方法借鉴于推荐系统的 user embedding 工程，比逐 token 断言稳定得多。

第三类是 Agent 与外部物理世界交互的场景——机器人 Agent、IoT 控制 Agent、自动驾驶决策 Agent。这类系统的真实测试只能在仿真环境或真实环境里跑，金字塔的 mock 与 stub 失效，因为"行为正确"的判定本身就需要物理反馈。工程上转向 digital twin + sim-to-real gap 度量：先在仿真器里跑百万次验证算法正确性，再在小规模真实环境里跑数十次验证 sim-to-real 偏差，最后再上线。这条路线属于 robotics 测试工程学的范畴，与 Agent 软件测试在哲学层面已经分叉。

还有一种"反测试"哲学值得提一句：有些团队认为 Agent 系统的核心价值是"不可预测的创造性"，测试得越死板，这种价值就被压制得越多。这种观点在产品早期是对的——你需要的不是测试，是快速迭代 + 真实用户反馈。但在产品进入生产、用户量超过 1000 之后，"反测试"会让每一次回归事故都演变成 P0 级事故。测试金字塔的存在不是为了压制创造性，而是为了让创造性的迭代不被回归事故反复打断。它给的是一层防护网，不是天花板。

九、给 SRE 与研究者：可观测性 + 评估基座的反哺

最后我们给两个具体读者一些收尾建议。

给 SRE：可观测性与测试是同一件事的两面。生产 trace 不只是给 on-call 看的，它应该自动喂回 e2e 测试集形成"测试自循环"——生产出现的新失败 case 自动转成 regression test，新版本发布前自动重跑一遍 production trace。这套闭环的核心是 trace-to-test pipeline，可以基于 OpenTelemetry Collector + Kafka + 一套 transformer 实现。LangSmith、LangGraph Studio 在 2026 年已经把这个能力产品化。SRE 的工作里 30% 是处理 agent 异常 case，把这些 case 自动转成测试是这个工作最有效的减负手段。

给研究者：测试工程里仍然有几个开放问题值得严肃探索。一是acceptance region 的自动发现——目前需要人类专家手工标注可接受区域，自动化方法尚未成熟；diff-based testing、property-based testing 在 LLM 场景下的推广可能是一条路。二是non-deterministic system 的 coverage 度量——传统 line coverage / branch coverage 在 Agent 系统里几乎没意义，新的 coverage 度量需要定义什么叫"agent 系统的状态被覆盖"。三是cost-aware testing——如何在固定预算下最大化测试的边际信息量，这是一个组合优化问题，可能借鉴 active learning 的 query strategy。

我们这篇的立场不是给这些问题答案，而是把这些问题摆到工程师面前。Agent 测试不是银弹、不是科学、不是哲学——它是工程。它由几十个小决策、几个层级判断、一套工具栈、一个金字塔纪律组成。每个决策都平凡，但每个决策累积起来，决定了一个团队的 Agent 系统能不能从 demo 走向生产，从生产走向规模化，从规模化走向可持续。我们的目标就是把这套工程实践讲清楚，让读者在自己的团队里能动手实践、能持续改进、能与同行交流。

参考文献

1. Vaswani A, et al. Attention Is All You Need. NeurIPS 2017.
2. Wei J, et al. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. NeurIPS 2022.
3. Yao S, et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023.
4. Park J S, et al. Generative Agents: Interactive Simulacra of Human Behavior. UIST 2023.
5. Schick T, et al. Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS 2023.
6. LangChain. LangGraph Documentation. GitHub langchain-ai/langgraph, 38,518★, 2026-07-30.
7. CrewAI Inc. CrewAI Framework. GitHub crewAIInc/crewAI, 56,397★, 2026-07-30.
8. Microsoft. AutoGen Framework. GitHub microsoft/autogen, 60,117★, last commit 2026-04-15.
9. OpenAI. OpenAI Agents Python SDK. GitHub openai/openai-agents-python, 28,297★, 2026-07-30.
10. OpenTelemetry SIG. OpenTelemetry GenAI Semantic Conventions. CNCF, 2025.
11. VCR.py Project. VCR.py Documentation. GitHub vcr/vcrpy, 2024.
12. LangSmith. LangSmith Platform Documentation. LangChain, 2026.
13. AWS. Firecracker MicroVM Documentation. GitHub firecracker-microvm/firecracker, 2026.
14. Google. gVisor User-Space Kernel. GitHub google/gvisor, 2026.
15. Anthropic. Claude Agent SDK Documentation. Anthropic, 2026.

一句话摘要：Agent 测试是一个工程学科，由四元组（D × F × C × K）trade-off、五层金字塔（unit / cassette / stub / sandbox / replay）纪律与六条落地清单组成；它是 demo 走向生产的必经之路，也是规模化可持续的护城河。