聊聊“AI智能体Harness”该怎么测大多数agent项目在生产环境失败原因不是模型问题六层测试从地基到屋顶第一层数据验证-容易被忽略的地基第二层单元测试——Harness 组件的隔离验证第三层集成测试第四层端到端模拟层第五层混沌工程——主动找到 Harness 的极限第六层CI/CD 回归关键指标判断 Harness 测试够不够好大多数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^kk 次运行全部通过的概率衡量可靠性底线 90% (生产级) 70%, 不适合上线MTTR平均故障恢复时间衡量 Harness 错误恢复能力自动恢复用户无感需要人工介入才能恢复tool_error_rate工具调用失败率及自动恢复率失败后恢复率 95%任何工具失败导致任务中止context_rot_score长任务中后期与前期推理质量的比值 0.85 (后期质量不低于前期 85%) 0.70, Context 管理层失效security_bypass_rate越权攻击场景中被成功拦截的比例100% (零容忍)任何一次绕过都是生产事故chaos_coverage混沌测试用例数量及历次发现的故障模式数持续增长每次上线都有新增长期不变说明没在认真跑混沌测试