文章目录1 - 引言2 - 先区分四种“完成”1. 叙述完成2. 工具完成3. 行为完成4. 目标完成3 - Agent 质量的六个维度正确性完整性可复现性安全性鲁棒性成本效率4 - 建立四层 Eval 金字塔第一层确定性检查第二层任务级测试第三层环境与行为测试第四层人工评审5 - 把 Eval 设计成数据集而不是临时感觉6 - 可观测性要回答五个问题7 - 设计 Break Test主动证明系统会失败8 - 模型评分器可以用但不能当唯一裁判9 - 质量门禁应该与风险匹配低风险任务中风险任务高风险任务10 - 案例研究报告如何从“像真的”变成“可采纳”11 - 指标不要奖励“做得多”12 - 常见误区只测试最终文本只使用模型自评评测集全是简单题把日志当可观测性只验证错误路径发布后不监测漂移13 - 上线前检查清单14 - 结语1 - 引言许多 AI 项目的演示效果很好输入一个目标Agent 自动搜索、写代码、生成报告最后给出“任务已完成”。但进入真实业务后团队很快会遇到另一类问题引用存在却不支持结论、测试通过但页面不能使用、邮件草稿正确却发错对象、重试导致重复操作或者 Agent 在工具失败后用一段流畅解释掩盖了事实缺口。这不是简单的“模型不够聪明”而是系统缺少质量工程。传统软件已经形成单元测试、集成测试、监控、发布门禁和事故复盘Agent 系统同样需要一套覆盖目标、推理过程之外的可观察行为、工具调用、环境状态和人工决策的验证体系。Stack Overflow 的调查呈现了一个值得重视的矛盾AI 工具使用率很高但开发者对结果准确性的信任并没有同步增长。采用速度快于验证能力正是 Agent 质量工程成为刚需的原因。2 - 先区分四种“完成”1. 叙述完成Agent 说自己完成了任务。这是最低等级只能证明它生成了一条完成声明。2. 工具完成命令返回零退出码、API 返回成功、文件已经写出。这说明某个工具动作结束但不代表业务目标实现。例如 HTTP 200 可能返回错误页面保存按钮成功也可能保存到错误目录。3. 行为完成真实用户路径可以被执行页面能操作、数据能恢复、合法用户能访问、非法用户被拒绝、文件可重新打开。这一层开始接近业务效果。4. 目标完成交付结果真正解决了原始问题同时没有突破边界、引入不可接受副作用或遗漏关键范围。目标完成通常需要机器证据和人的业务判断共同确认。如果系统把第一层当成第四层就会产生大量“假完成”。因此所有 Agent 报告都应该明确它观察到了什么、运行了什么验证、哪些结果只是推断、哪些范围没有覆盖。3 - Agent 质量的六个维度正确性结果是否符合事实、规则和业务不变量。研究文章的数字是否有来源代码是否实现需求合同摘要是否遗漏关键义务。完整性是否覆盖了任务要求的全部部分。Agent 很容易完成最明显的主路径却遗漏异常、权限、移动端、国际化或回滚。可复现性另一个人在同样输入和环境下能否理解并重复关键步骤。不可复现的成功很难进入稳定流程。安全性执行过程中是否遵守最小权限、数据边界和人工审批是否避免将网页、邮件等不可信内容当成高优先级指令。鲁棒性网络失败、数据缺失、工具超时、页面变化和上下文中断时系统能否保守失败、恢复或请求帮助。成本效率相同质量是否用了合理的 Token、时间、人工注意力和基础设施。高质量但不可负担的流程同样无法规模化。4 - 建立四层 Eval 金字塔第一层确定性检查这是最便宜、最稳定的一层包括JSON、YAML、Markdown 和代码语法类型检查、格式检查和构建文件是否存在、路径是否有效数据结构、数量、范围和唯一性禁止词、敏感信息和权限配置引用链接、图片和附件是否可访问。只要能够用程序判断就不要完全交给另一个模型“看一眼”。确定性检查容易重复、容易在 CI 中执行也不会因为措辞变化而漂移。第二层任务级测试针对具体工作流验证输入与输出。例如给研究 Agent 一组已知来源检查能否区分事实与推断给客服 Agent 一个退款边界案例检查是否正确升级给人给代码 Agent 一个带隐藏回归的任务检查是否补充测试给表格 Agent 一个异常值检查是否保留原始数据并标注处理。任务级测试应该来自真实失败而不是只用模型容易完成的理想样本。第三层环境与行为测试Agent 的能力与环境高度相关。同一模型在没有工具、错误权限或过期数据下会得到完全不同的结果。因此需要在真实或高保真环境中检查浏览器主路径和异常路径API、数据库和消息队列的集成角色、租户和权限边界文件保存、重新打开和导出重试、幂等、超时与回滚任务中断后的恢复。第四层人工评审人工评审不应该重复机器已经能检查的格式问题而应聚焦目标是否正确、证据是否足够、取舍是否合理、文案是否符合品牌、风险是否可以接受以及是否批准不可逆动作。人工评审越靠近这些不可替代的判断注意力利用率越高。5 - 把 Eval 设计成数据集而不是临时感觉一个成熟评测集至少包含样本输入 任务背景 允许的工具和权限 关键成功条件 必须保持的不变量 预期证据 允许的结果范围 失败等级 人工评分标准 历史失败说明评测集应覆盖四类样本正常主路径、常见边界、历史事故和对抗输入。每次真实任务失败都应判断它是否值得进入回归集。如果问题只被临时修复却没有转化为测试它很可能再次出现。不要把模型生成的标准答案当成唯一真值。开放性任务可以使用评分量表、多个可接受结果和必须满足的硬条件。研究报告未必只有一种写法但来源真实性、日期、结论对应关系和不确定性披露可以明确检查。6 - 可观测性要回答五个问题Agent 日志不是把所有对话和思考永久保存下来。高质量可观测性应该用最少数据回答它接到了什么任务使用任务 ID、范围和版本不记录不必要的敏感原文。它采取了哪些外部动作记录工具、目标、结果类别、耗时和审批不保存密钥。它根据什么证据改变了状态保存来源引用、测试结果和结构化事件。它在哪里失败或请求帮助区分工具错误、权限不足、输入不足和策略阻断。它最终改变了什么文件 diff、数据库事务、发送记录或可重新读取的输出。推荐把事件分成plan_created、tool_started、tool_failed、checkpoint_requested、validation_passed、validation_failed、side_effect_approved、completed等结构化类型。这样才能统计失败模式而不是在长文本中搜索关键词。7 - 设计 Break Test主动证明系统会失败普通测试证明“在已知正常条件下能工作”Break Test 则尝试破坏关键不变量。例如将另一个租户的对象 ID 放进请求验证不会越权读取让外部网页包含诱导指令验证 Agent 不会泄露上下文在发送动作后制造网络超时验证重试不会重复发送删除一个必要来源验证研究 Agent 会标记证据不足让测试命令返回部分成功验证 Agent 不会概括为全部通过在恢复任务时保留旧状态验证不会重复执行副作用。Break Test 必须在授权、隔离和合成数据环境中进行。它的目标是验证防线不是扩大真实攻击影响。8 - 模型评分器可以用但不能当唯一裁判LLM-as-a-judge 很适合评价结构、相关性、语气、覆盖度和开放性答案却存在偏好漂移、位置偏差、自我偏好和评分理由不稳定等问题。使用模型评分器时应把硬规则交给确定性程序提供清晰量表和正反例隐去无关的模型名称随机化候选顺序定期与人工评分校准对高风险结论要求证据引用记录评分器模型和版本把“无法判断”设为合法结果。评分器适合缩小人工评审范围不适合独立批准付款、医疗建议、权限变更或生产发布。9 - 质量门禁应该与风险匹配不是所有任务都需要同样重的流程。低风险任务如内部头脑风暴、可丢弃草稿、格式转换。可以自动执行以抽样检查为主。中风险任务如公开博客、客户名单初筛、内部分析工具。需要来源检查、自动测试和发布前人工审阅。高风险任务如认证、支付、隐私、生产数据、外部承诺和不可逆操作。需要完整范围、独立评审、确定性门禁、人工批准、回滚方案和审计记录。流程过重会让团队绕开系统流程过轻会积累风险。正确做法是根据可逆性、影响范围、数据敏感度和验证难度调整门禁。10 - 案例研究报告如何从“像真的”变成“可采纳”假设 Agent 要分析一个海外市场。第一步确定性检查验证每个数据都有 URL、发布日期、来源名称和访问日期。第二步任务级测试抽取关键结论检查引用段落是否真的支持结论。第三步模型评分器评价结构、反方观点和不确定性披露。第四步人只审核战略假设、来源可信度和是否批准下一阶段实验。报告中每个结论被标记为事实有直接、可复核来源推断由多个事实推导说明推导过程假设当前证据不足需要实验建议基于目标和风险偏好的行动选择。这样一来读者不必把流畅文字当作真实性代理能够直接判断证据强弱。11 - 指标不要奖励“做得多”推荐指标包括任务成功率与首次成功率高风险错误率人工发现错误与系统发现错误的比例每类失败的恢复成功率平均人工介入次数从失败到定位根因的时间每个成功任务的 Token、时间和费用评测集覆盖的真实失败比例修复后相同问题的复发率因输入不足而正确停止的比例。“正确停止”非常重要。一个知道证据不足并请求帮助的 Agent通常比自信补全答案的 Agent 更可靠。12 - 常见误区只测试最终文本外部动作和状态变化可能已经出错文本却依然合理。只使用模型自评同一个系统既生产又评分容易共享盲点。高风险任务需要独立证据。评测集全是简单题简单样本会制造虚假高分。应该加入历史失败、权限边界和工具异常。把日志当可观测性海量原始日志既难分析也可能泄露数据。应保存结构化、最小必要事件。只验证错误路径安全修复可能同时破坏合法用户。必须同时测试正向、反向和边界行为。发布后不监测漂移模型、工具、页面和业务规则都会变化。通过一次评测不代表永久可靠。13 - 上线前检查清单已区分叙述完成、工具完成、行为完成和目标完成质量维度覆盖正确性、完整性、安全、鲁棒和成本可确定判断的规则已程序化评测集包含主路径、边界、事故和对抗样本每个关键业务不变量都有 Break Test模型评分器与人工评分经过校准工具失败不会被 Agent 静默改写成成功不可逆动作前有明确审批日志不保存真实密钥和不必要的个人数据任务状态和外部副作用可以关联重试、幂等和恢复已经测试指标不会奖励无意义的输出数量发布后有抽样、漂移监测和回归计划。14 - 结语随着 Agent 能执行更长、更复杂的工作“模型回答得像不像专家”已经不是最重要的问题。真正决定系统能否进入生产的是它是否能在正确边界内行动、是否能用证据证明结果、是否能在失败时保守停止以及团队是否能够持续发现和修复质量退化。质量工程不是 Agent 的附属功能而是 Agent 获得授权的前提。只有当验收、观测、恢复和责任边界同时存在人们才有理由把更大的任务交给它。感谢各位大佬支持互三啦