Agent 写完不等于完成：AI 质量工程实战

文章目录

• 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 日志不是把所有对话和思考永久保存下来。高质量可观测性应该用最少数据回答：

推荐把事件分成 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 获得授权的前提。只有当验收、观测、恢复和责任边界同时存在，人们才有理由把更大的任务交给它。

感谢各位大佬支持！！！

互三啦！！！