大多数agent项目在生产环境失败，原因不是模型问题

目前常见的测试流程，做的其实是「模型评测」，而不是「Agent 系统评测」。

一个常见的测试流程是这样的：准备 50 个测试问题，跑模型，看输出质量，打分，迭代提示词。这个流程看起来完整，但它只在测一件事：模型在给定输入下的推理质量。

它完全没有测到：工具调用失败时 Harness 能不能恢复；状态丢失时任务会不会重复执行；上下文腐烂后推理质量会不会系统性下降；高危操作是否真的被拦截；整个执行链路在异常情况下的行为。

你测的只是模型，但 Agent 系统的失缺点，80% 在 Harness。你没有测到真正重要的东西。

解决这个问题需要一套专门针对 Agent Harness 的测试体系。

六层测试：从地基到屋顶

第一层：数据验证-容易被忽略的地基

数据认证不是 QA 的事，也不是 ETL 的事——在 Agent 测试里，它是一切测试的前提条件。 在跑任何 eval 或者集成测试之前，你需要先回答这些问题：

• 格式一致性
  所有数据源的字段格式、类型、单位是否统一？有没有隐藏的空值、截断、乱码？
• 时效性验证
  向量数据库里的 embedding 是否及时更新？有没有过期数据被当成最新数据用？
• 权限边界验证
  Agent 能访问哪些数据？有没有意外的越权通路？沙箱环境和生产环境数据是否隔离？
• 覆盖度检查
  测试数据集是否覆盖了生产中真实会出现的分布？有没有明显的缺失场景？

第二层：单元测试——Harness 组件的隔离验证

Harness 的每个组件都是可以独立测试的代码单元：工具的重试逻辑、状态持久化的读写接口、上下文压缩算法、权限拦截逻辑。把模型 Mock 掉，专注测试 Harness 本身的行为正确性。

这层的核心原则是：不要让模型参与 Harness 组件的单元测试。 模型的输出是概率性的，会干扰 Harness 逻辑的确定性验证。

Harness 组件	单元测试重点	关键断言
工具执行层	重试逻辑、超时、输出 Schema 校验	重试次数、最终成功/失败状态、输出格式
状态持久化层	读写接口、并发安全、数据完整性	写入后读取一致、并发写入不丢数据
权限拦截层	白名单过滤、审批门触发	越权调用必须被拦截，合法调用必须通过
上下文管理层	摘要算法、Token 计数、窗口截断	压缩后关键信息保留、Token 不超预算

第三层：集成测试

单元测试验证了每个组件的独立正确性。集成测试要验证它们组合在一起工作时，有没有新的问题出现——这是经典的「集成地狱」：每个组件单独测都没问题，组合起来就出错了。

• 工具输出 → 上下文注入
  工具返回的数据经过格式化后，是否能被 Context 层正确处理，不引入噪声？

• 状态变更 → 持久化同步
  Agent 执行完一步后，状态更新是否及时写入持久层？下一步读到的状态是否正确？

• 权限拦截 → 任务恢复
  权限层拦截了一个操作之后，任务能否正确暂停等待审批，而不是直接崩溃？

• 错误传播路径
  某一层的错误是否被正确隔离？有没有错误级联传播，把局部失败变成全局崩溃？

第四层：端到端模拟层

这一层让真实的模型参与进来——但要做一个关键设置：将模型温度（Temperature）设为 0。

温度设为 0 意味着模型的输出接近确定性——相同输入会给出相同输出。这让端到端测试的结果可以重复，可以作为回归基准。如果温度是 0.7，你永远不知道失败是偶发的还是系统性的。

端到端模拟要覆盖的不只是 Happy Path，而是所有你能想到的边界场景：

场景类型	测试内容	通过标准
正常流程	标准任务从头到尾完整执行	结果正确，状态机终态是 DONE
工具失败恢复	模拟工具中途失败，验证恢复路径	任务最终完成，不丢失已完成步骤
上下文边界	人为触发 Context 窗口接近上限	摘要机制生效，推理质量不明显下降
长任务稳定性	连续执行超过 20 步的复杂任务	不出现循环调用、不出现状态遗忘
并发安全	同时启动多个 Agent 实例操作共享状态	状态不出现竞争写入错误

第五层：混沌工程——主动找到 Harness 的极限

前几层测的是「正常情况下 Harness 能不能跑」。混沌工程测的是「异常情况下 Harness 会不会优雅失败，还是灾难性崩溃」。

核心思路是：在受控的测试环境里，主动向系统注入各种故障，观察 Harness 的响应。这比等生产环境出问题要好得多——在测试里崩溃，你可以选择时间和地点；在生产里崩溃，你没得选。

• 故障注入类
  让工具随机返回 500 错误、返回格式错误的 JSON、连接超时、返回空响应。验证 Harness 的错误恢复是否真的生效。
• 越权攻击类
  构造让 Agent 尝试调用未授权工具、访问越权数据、绕过审批门的场景。验证安全层的拦截是否可靠。
• 无限循环类
  构造会让 Agent 陷入循环推理的场景，验证最大推理步骤数的熔断机制是否按预期触发停止。
• 状态损坏类
  在任务执行中途人为损坏持久化状态，验证 Harness 能否检测到状态异常并优雅处理，而不是带着脏数据继续执行。
• 网络分区类
  模拟外部服务突然不可达、DNS 解析失败、网络抖动。验证 Harness 是否有适当的重连策略和超时降级。

第六层：CI/CD 回归

前几层建好之后，需要让它们自动运行。每次 Harness 代码变更、提示词变更、工具升级、模型版本更新，都应该自动触发完整的测试套件。

这里有一个 Agent CI/CD 特有的挑战：不同层次的测试，运行成本和时间差异巨大。单元测试秒级完成，E2E 模拟可能要几分钟，混沌工程测试套件可能要几十分钟。需要根据变更类型，分层触发不同的测试：

质量门控制节点是关键设计——不通过就阻断发布，不讨价还价。这跟传统 CI/CD 的质量门控思路完全一致，只是应用到了 Agent 的变更管理里。

关键指标：判断 Harness 测试够不够好

指标	含义	健康值	危险信号
pass^k	k 次运行全部通过的概率，衡量可靠性底线	> 90% (生产级)	< 70%, 不适合上线
MTTR	平均故障恢复时间，衡量 Harness 错误恢复能力	自动恢复，用户无感	需要人工介入才能恢复
tool_error_rate	工具调用失败率及自动恢复率	失败后恢复率 > 95%	任何工具失败导致任务中止
context_rot_score	长任务中后期与前期推理质量的比值	> 0.85 (后期质量不低于前期 85%)	< 0.70, Context 管理层失效
security_bypass_rate	越权攻击场景中被成功拦截的比例	100% (零容忍)	任何一次绕过都是生产事故
chaos_coverage	混沌测试用例数量及历次发现的故障模式数	持续增长，每次上线都有新增	长期不变，说明没在认真跑混沌测试