Harness值不值，先看纠错收益

同一个接口开发任务，加上行为 Harness 后，GPT-6 Luna 从十次只交对三次，变成十次全交对；GPT-6 Sol 两边都全对。这是 Naresh Jain 的公开实验。多做检查的收益，明显取决于谁在写代码。

Harness值得付费的地方，是把遗漏及时变成可修复的失败信号。已经稳定交对的任务，重点是保留独立验收；经常漏边界的任务，才值得让检查更早进入开发循环。

这里的 Harness，指围绕业务行为搭起的指导和反馈环境。它让 Agent 看见要求、执行检查、根据结果修复。要理解钱花在哪里，可以盯住一个小动作：创建请求超时后，系统究竟有没有把它接下去。

超时之后，谁接住这笔请求

实验要求构建一个产品服务的 BFF，即面向客户端的接口层。产品数据归下游 Order API 管，BFF负责转发、校验和恢复。

创建操作经由 POST /products 进入。正常路径拿到下游创建结果后返回201。下游超时后，BFF把请求记入内部监视存储，交给后台线程池继续处理，返回202，并在 Link 响应头给出监视地址。

后台线程池每隔1秒重试，最多10次。同一逻辑请求沿用同一个UUID幂等键，避免重复创建。成功后，BFF把下游响应写回监视记录，客户端查询时便能同时读到请求与结果。

这条链处理的是下游超时。任务说明把监视存储和重试线程池留给BFF内部实现，没有规定持久化介质或进程退出后的接管机制。例如，内存记录随进程退出而丢失，就超出了这条链已说明的恢复能力。RFC 9110中的202只表达已受理，完成证据要从后续状态里找。

因此，测试只看202会漏掉最关键的一段。监视地址可以存在，后台任务却没有启动；后台任务可以执行，结果却没有写回。接口看起来齐全，时间上的接续仍然断着。

有价值的检查要跟着同一笔请求走：先让下游超时，再观察后台调用，最后让下游恢复，确认监视结果更新。示意记录：首次调用的UUID键记作A，后台重试却换成B。报告应列出“预期A、实际B”对应的完整键值，把缺陷指向请求身份的保存和传递。

重试耗尽也是一道边界。迁移到业务系统时，接口双方应先约定终止状态和后续处理方式。后台停止发送以后，客户端还得知道这笔请求接下来怎么办。

把遗漏变成下一次修改的输入

理解行为 Harness，可以分清两类东西。指南在动作前提供要求；检查在动作后给出差异。前者告诉 Agent 要保留什么，后者指出当前实现漏了什么。在这次实验里，OpenAPI接口规格和示例承担指南职责，Specmatic提供契约检查及依赖模拟能力。

原报告的“The inner loop”说明，示例包含超时与重试序列，检查会断言HTTP响应及下游模拟调用。外部验收还观察到原幂等键重试和监视结果回写。前面的键值差异报告、后面的故意改错，则是本文设计的验证办法；读者可以对照这些行为，不能把它们当成公开测试文件里的原始用例。

Agent写完一段实现，调用项目测试命令。工具启动应用和模拟依赖，驱动请求，检查响应与下游调用，再返回失败报告。模拟依赖能按预设制造超时并恢复，使修复前后有可比结果。Agent据报告改实现，重跑失败场景，再跑完整检查。

决定下一次改哪里的是 Agent。判断某个响应是否符合预期的是确定性检查。两个职责分开，报告就有机会成为修复输入，而非又一次模型之间的意见交换。

原实验要求 Agent保留契约和验证输入；这是行为指令。落到团队仓库，可再限制验收材料的写权限。模型修复实现，团队控制“怎样才算交对”。

开发结束后，两组服务都接受同一套178项外部检查。它自行控制下游测试数据与消息捕获，不调用应用的开发期测试；开发Harness也拿不到这套验收的答案。两套检查依据同一份业务要求，独立的是执行与验收材料，不是另换业务标准。

还要分清两个循环：运行中的BFF重试业务请求；开发中的Agent根据报告改代码。后者修复程序，前者推进业务状态。把两者都叫“自动恢复”，会掩盖真正的责任边界。

▲ 业务重试与开发纠错的双循环及测试反馈方向

有了契约，还缺时间上的接续

已有契约测试的团队，可以从现成资产开始。Pact就是一个有用的对照：消费方测试产生交互契约，提供方验证把请求发给服务，再比较响应。

Pact把各个交互视为独立测试。需要已有数据时，用 provider states，也就是提供方前置状态，先安排好条件。这样能清楚地检查双方对消息的理解是否一致。

但独立安排“创建已完成”，再验证监视接口，绕开了后台任务真正完成创建的过程。创建接口通过、监视接口通过，只能说明两个状态下的响应成立。

我们还需要回答：是谁把系统从前一个状态推进到后一个状态？中途用的是同一笔请求吗？这正是流程检查要补的证据。

所以，接入 Harness 时，优先寻找现有检查之间的空白。保留契约测试，再补一个跨状态的恢复场景，通常比让 Agent重写一整套“自己的测试”更容易审查。投入用在可观察的业务承诺上，资产也能继续服务人工开发。

单次便宜，离回本还差一笔固定投入

Jain记录的每次运行平均API等价估算中，Luna加 Harness 后从0.086美元升至0.273美元；Sol从0.406美元升至2.679美元，验收仍是两边十次全通过。检查增加了费用，能否换来纠错收益，要看任务和模型。

换一种模型组合，账才出现变化：带 Harness 的Luna每次0.273美元，不带它的Sol每次0.406美元。两组都十次全通过，差额是0.133美元，约为后者的33%。

但时间走向相反：前者平均35分钟，后者6分51秒。若任务在阻塞联调或等待人工评审，机器多跑的时间也会占住交付窗口。价格和等待，应当分开看。

按同类任务1000次、新增 Harness 建设与维护固定投入100美元计算。沿用上面的单次估价，基准路线花406美元；Harness路线花273美元，再加固定投入100美元，共373美元。

账面余额只剩33美元。固定投入需要约752次同类任务才能摊平，计算就是100除以0.133，再向上取整。

人工修复、运行资源和等待的机会成本，还要另计。哪条路线省下更多返工，哪条路线就可能重新占优。单次模型调用的折扣，只覆盖总账里的一部分。

运行频率同样影响总账。即使检查程序跑得很快，Agent读取报告、定位问题和重新生成代码仍然要消耗时间。测试的执行成本，与模型消化测试结果的成本，是两笔钱。

在自己的接口上，只改反馈时机

实验边界集中看：它研究的是一个需求详细的新建Java服务，每条件十次运行，以启动并通过178项外部检查为验收。原实验把指南和检查一起加入；要判断反馈时机的收益，需要下面这组同规格对照。

对照时固定同一个模型、推理设置、任务、初始代码和外部验收。两路拿到相同的规格与示例，只改变检查反馈的时机。一路允许Agent在开发中获得反馈；另一路只在完成时检查，若失败再进入修复。两路都算到交付可接受结果为止，保留失败尝试的费用与人工接管时间。

为避免无限修复，事先设定本次尝试的时间或费用上限。到限后由工程师查看失败报告，决定修代码、修运行环境，还是澄清要求。一次失败的去向要清楚，才能比较真正的交付成本。

启动对照前，还可以先故意改错一次：让后台重试生成新的幂等键。如果检查仍然全绿，先补检查；如果它能指出哪一次调用偏离，再把这份反馈交给Agent。这是在验证传感器是否看得见缺陷。

架构师要买到的是纠错收益：把关键业务承诺变成可执行预期，再选反馈时机。对重复、边界清楚的任务，早点纠错有机会扩大可用模型的选择；接口约定还在频繁变化时，先把预期说清，比让检查跑得更勤更划算。

IT架构师联盟

面向架构师与工程同行，解析AI Agent、系统架构与可靠性，讲清技术机制、工程边界和实践方法。