AI 写了99%代码后,谁来测试?一套能够自我修复的Agent Harness-夜雨聆风

AI 写了99%代码后,谁来测试?一套能够自我修复的Agent Harness

注：本文作者为Peter Pang，creao.ai的联合创始人。creao.ai类似manus.

不要陷入追逐”科学正确性”的陷阱。我见过很多有研究背景的人陷入关于基于 Agent 的评估是否在方法论上足够严谨的争论。对于创业公司来说，这种争论是一种你负担不起的奢侈。它忽略了重点。基于 Agent 的评审器的目的不是为了给模型排名写论文，而是快速识别我们产品中反复出现的问题。一个今天能触发修复的足够好的信号，胜过下个季度才能发布的完美可辩护的基准测试。

那个循环——评审、分诊、修复、验证、发布门控——就是我们所说的 Agent Harness。

1 核心论点：评估和 QA 是同一个循环

在传统 SaaS 公司，这两件事通常在不同地方：

模型评估

问的是：模型在真实流量上给好答案了吗？这归 ML 或数据科学团队管，他们做仪表盘。
QA

问的是：产品在生产环境正常运行吗？这归工程团队管，他们提 Bug、修 Bug、发版本。

对于 AI Agent 平台，这两个是同一个问题。一个差的 Agent 回复既是需要绘图的指标，也是需要分诊和修复的 Bug。而这个 Bug 可能来自几乎任何地方：

模型推理差或产生了幻觉
一个集成返回了 500 错误，过期的 token 或格式错误的数据，Agent 把错误结果重复了一遍
基础设施抖动。Cloudflare 超时了，Postgres 副本延迟了，ECS 任务在中途内存耗尽了
工具契约漂移了。上游的 schema 变了，Agent 的参数悄悄不再匹配
Prompt 或上下文管道坏了。系统 Prompt 被截断了，RAG 返回了错误的片段，记忆加载失败了
一次部署回归悄悄地降级了单个用户请求背后众多小组件中的一个

对用户来说，所有这些看起来都一样：得到了一个糟糕的答案。对评审器来说，它们看起来也一样：在 messageId X 上得到了一个低分。这正是我们为什么要建这套 Harness 的原因。评分时我们不需要知道根本原因，只需要快速捕获失败。然后我们的分诊系统可以从信号出发逆向追溯。

一次失败的工具调用应该表现为一次质量下降，这个质量下降应该阻止下一次部署。评估管道不在一旁闲着，它直接喂养工程团队。每一次生产故障都经过同一个漏斗。

那个漏斗就是 Agent Harness。

它在一个自我修复循环中运行三个组件，本文接下来逐一展开：

评审器：一个三裁判组，给每一条真实 Agent 回复打分（取代人工 QA 审核和离线基准评估）
工程管道：六个每日任务，把低分变成 Linear 工单、草案 PR 和已验证的修复（取代人工 Bug 分诊、冲刺规划和回归测试）
桥接层：AI 门控的灰度发布，评审器的分值决定新代码是否发布（取代预发布环境和发布审批）

当 AI 把构建时间从数月缩短到数小时，每个下游阶段都成了瓶颈。分开管理的评估和 QA 都是那个瓶颈。跟上 AI 速度的唯一方法是把它们合并。

下图展示了过去 7 天在 CREAO 平台上收集的采样评估和平均分。

2 组件一：评审器——真实流量上的三裁判组

评估 AI 产品最难的部分不是检查代码能不能编译，而是判断 Agent 是否给出了一个好的、符合逻辑的答案。

过去这意味着人读对话记录。我们用一个异步评审端点取代了它，在每次助手回复后触发，完全在 band 之外。它从不在用户面向的延迟上增加一毫秒。

这是 Harness 的眼睛。下游的一切都依赖这些分值的可信度。

关于意图的说明：

我们非常关心准确性和公平性，但我们不是在建排行榜，也不是在给模型排名。评审器的存在是为了暴露 Agent 系统中的问题：差的 Prompt、坏掉的工具契约、漂移的集成、基础设施抖动、我们自己部署带来的回归。各个模型的分值只是调试信号，不是基准测试。如果两个裁判对同一个 messageId 都给了差评，我们知道的不是哪个模型比哪个更好——我们只知道我们管道里有什么东西产生了一个坏答案，我们需要修复它。

2.1 触发与采样

每条 Agent 回复都会向我们的内部评审端点发送 POST 请求，带上 messageId、threadId 和降级后实际服务的模型。

采样是按模型来的，不是按流量平摊的：

主导生产模型（Sonnet 4.6）采样 10%。它处理大约 24 倍于平台上其他任何模型的流量，所以平摊采样会让其他模型被淹没
所有少数或实验模型：Opus、GPT、Gemini 等，采样 100%

这是让少数模型在数小时内而非数周内达到统计显著性来门控发布决策的唯一方法。

2.2 任务 0：分类路由器

在裁判看到对话记录之前，一个轻量级分类器（任务 0）把交互映射到我们 12 个核心领域之一：编码、研究、数据分析、任务自动化、Agent 构建、工件构建、传统应用构建、规划、写作、创意工作、对话和错误恢复。

我们在评分之前做这个，这样每个裁判看到的是类别条件化的评分规则。一条好的编码答案和一条好的研究答案会用不同的红旗标准来评判。

2.3 三个裁判，三种角色

我们并行运行来自不同模型家族的三名裁判：Anthropic、OpenAI 和 Google。这有助于减少模型评自己工作时可能出现的自我偏好偏差。我们通过 AI 网关同时调用这三名裁判，所以单个裁判的慢或失败不会让判决落空——它只是降低该行的仲裁人数。

但我们不会因为裁判团意见一致就信任它。我们仍然采样一小部分判决结果回到人工进行定期校准。如果在裁判团共识和人工审核之间出现了持续的差距，我们把它当作评分规则中的 Bug，而不是可容忍的错误率。

每个裁判必须通过 schema 锁定的工具调用（submit_evaluation）返回结构化输出。该工具要求五个字段：reasoning（2 到 3 句话的逐步推理）、category（被评分的领域）、quality（excellent、good、acceptable、poor）、issues（从 9 项分类中抽取：不完整、幻觉、工具滥用、上下文遗漏等）和 confidence（0 到 1 的浮点数）。

2.4 分类评分规则

每个裁判看到同一份对话记录，但根据类别特定约束来评估：

2.5 数学共识

我们将 quality 映射到 1-4 分制，对存活的裁判取平均而不是投票。这把一个粗粒度的四分制变成了一个连续指标（3.33 对比 2.66），并且使得每个模型的趋势在比多数投票小得多的样本量下就能显现出来。

如果 Sonnet 给 Sonnet 评分，分值可能膨胀约 0.3。然而，当 OpenAI 和 Google 裁判——各自在不同的专家角色下运行——标记了同一个问题时，偏差会被仲裁人数冲掉。我们把每个裁判的判决与平均值一起持久化（sonnet_quality、gpt_quality、gemini_quality、judge_count），这样工程师可以事后审计分歧，并在任何一个裁判开始漂移时重新加权。

评审器的输出很简单：一连串带类别标签的、裁判平均化的分值，绑定到产生它们的准确 messageId。这条数据流喂养着接下来的一切。

下图展示了我们服务中可用选定模型的回复质量。

3 组件二：工程管道——从分值到修复的六个任务

大量论文证明自主 Bug 修复是可能的。但学术基准测试不会在生产环境中运行。如果 AI 在静态基准测试上幻觉出一个修复，你得到的是一个坏分数。如果它在你的活跃代码库中幻觉出一个修复，你得到的是一次故障。

工程管道接收评审器的分值，把它们变成已发布的代码。来自组件一的低分就是一份 Bug 报告。从那里，六个任务把这份 Bug 报告一直加工到已验证的修复。这取代了人工 QA：分诊、调查、修复、回归测试、审批。

每日工作流运行六个顺序任务：

3.1 任务 1：检测与分诊

一个 Agent 从评审器拉取低质量判决并对它们进行聚类。它在一个 9 维度严重性引擎上给每个聚类评分：用户影响、速度、持续时间、告警关联、资源压力、延迟、4xx 比率、爆炸半径、业务关键性。任何超过紧急阈值的都会向前推进。其余的进入日志用于趋势追踪。

3.2 任务 2：调查

对于排名前三的聚类，一个 Agent 顺着栈追踪穿过我们的 monorepo，拉取 CloudWatch 日志，检查最近部署，查询数据库副本。它分配一个根本原因，并把工单连同完整证据包路由给人类。

3.3 任务 3：自动修复

对于高置信度、紧急的问题，系统拉分支、改代码，写修复、验证，然后提交一份草案 PR 到 GitHub。野心之上的护栏：

每次运行最多 3 个 PR。审核者有上限。Bot 洪水会让它枯竭。
任何触碰 .env、.github/ 或 IAM 策略的 diff 都会自动关闭。
类型错误阻止提交。测试失败阻止提交。

我们在这里不是要修复深层架构债务。我们的目标是快速修复明显的 Bug，让人类能专注于深度工作。

3.4 任务 4：验证

对于”审核中”的工单，系统查询过去 6 小时的 CloudWatch。零发生？它把遥测证据粘贴到评论里，然后关闭工单。还在失败？它用新的错误计数更新工单，然后再次循环。客观证据证明修复有效，零人工回归测试。

3.5 任务 5：重新评审

评审器在接下来 24 小时内以 100% 采样率对已关闭的聚类重新评审。当问题再次出现时系统重新触发修复。

3.6 任务 6：报告

一份每日夜间摘要出现在 Linear 和团队频道里：检测到的聚类、发布的 PR、撤销的 PR、每个类别的分值变化以及每个模型的排行榜。仪表盘不是目的，它只是已经发生的事情的记录。

4 组件三：桥接层——AI 门控的灰度发布

前两个组件关闭了已上线 Bug 的循环。第三个关闭了即将上线 Bug 的循环。

自我修复管道处理小问题很有效。但当你替换一个基础模型、重写一个核心系统 Prompt、或授予一个 Agent 大量新工具访问权限时会发生什么？行为风险陡增。你不能把一个重大更新推向 100% 的生产环境然后祈祷。

桥接层是评审器和工程管道交汇的地方。我们用评审器的分值作为发布门控之一（还有许多其他的，但这里我们聚焦于评审器的分值）。没有预发布环境。没有人工审批。没有在 PR 评论里说”我觉得可以”。

当一个重大 Agent 变更合并时，我们把一小部分真实流量——通常是 10%——路由到新变体。评审器实时给它和当前生产基线打对比分。

晋升阶梯自动运行：

失败。

如果裁判团的平均分相对基线下降 0.15 或以上（p < 0.05，窗口至少 200 次交互），或者我们的确定性 Bug 猎人在那 10% 人群中检测到新错误聚类的激增，管道会中止发布，把流量切回稳定版本，并打开一个附有回归人群的 Linear 工单。那张工单作为任务 1 的输入进入组件二。循环关闭。
维持或改善。

人群扩展：5% → 20% → 50% → 100%。每一步都通过对新窗口的相同统计检验来门控。

模型在真实用户流量上证明自己的安全性，爆炸半径由人群规模控制。

5 关于运行 Harness 的几个残酷真相

如果你正在转向 AI 优先的工程工作流，把这些记下来。

看结果，不看路径。 早期，我们会因为 Agent 做了”不必要”的工具调用而惩罚它。这没有持续多久。我们很快学到了最近的 Agent 研究已经证明的事情：AI 通常会发现非常有效的、非线性的解决方案，这些方案在人类看来很奇怪但实际效果极好。评判 Agent 产出的东西比微观管理它怎么到达那里要稳健得多。

按模型采样，而不是按流量采样。 平摊采样会让主导模型看起来像是唯一的模型。你会对其他模型投入不足。

没有工单的分值是没人看的仪表盘。 没有工程管道在后面支撑，评审器毫无价值。没有评审器喂给它，工程管道毫无价值。两个都要建，或者两个都不建。

6 新标准

自我修复系统不是单一功能。它是一个循环：评审、分诊、修复、验证。每个组件都运行在模型自己的输出上。评审器取代了主观的人工审核。工程管道取代了人工 Bug 分诊和回归测试。桥接层取代了大爆炸发布带来的焦虑。

大多数创始人仍然在把 Copilot 这样的工具绑定到同样的老工作流上。他们跑着标准 CI/CD 加标准人工 QA。他们用 AI 在数小时写代码，然后用数天测试。他们是 AI 辅助的。他们不是 AI 优先（AI-FIRST）的。

竞争优势属于那些停止把评估和 QA 当作独立功能、而是构建融合两者的 Harness 的团队。