Harness 什么时候开始为了验证而验证？

Agent Harness 系列 #17
上一篇：让 Agent 下班后继续跑：有界自主运行怎么设计？

最近，我让 Agent 做一个代理相关任务。它安排了两百多项测试，又反复启动验证；到了预算限制，任务还没完成，执行就停了。

我的第一反应是：这些验证有必要吗？Harness 原本是为了让执行更可靠，现在却让我感觉，它在为了验证而不断验证。

不过，仅凭测试数量和最后停下来的现象，还不能认定整套检查都没有价值。我还没有在这篇文章里完成逐次日志归因，也不能据此断言预算主要花在测试上。

我想追问的是：每次重新启动验证，究竟解决了哪个尚未解决的问题；已有证据足够时，系统能不能结束；预算不足时，能不能留下可继续的工作。

一、两百多项测试，不是问题的全部

如果两百多项自动化测试很快就能跑完，并且覆盖了共享代理的关键行为，一次全量回归可能比挑选测试更省事。

反过来，即使只有少量用例，每轮都要启动环境、调用模型、重新解释结果、再交给其他环节审查，也可能消耗不少时间和预算。

所以需要区分几笔成本：

成本	需要查什么
测试执行	测试实际运行多长时间，是否依赖外部环境
启动与准备	是否重复安装、构建、启动服务、准备数据
结果处理	是否反复读取同一日志、重新生成类似报告
调度与交接	同一结果经过多少次派发、审查或回执处理

测试项数、启动次数、模型调用和运行时间不能相互替代。也不能看到预算耗尽，就直接把原因归给“测试太多”。

对我这次经历，更值得先查的是为什么反复启动。测试范围是否过大，是另一个需要证据的问题。

二、重新验证，应有一个具体触发原因

有些重复检查是必要的。例如，修复后原来的失败必须复测；修改了共享逻辑，需要检查受影响的调用方；外部环境变化后，旧结果可能不再适用。

但如果代码没变、测试没变、环境也没有已知变化，上一次结果明确且可追溯，再运行一遍究竟为了什么？

可以先用一张简单的判断表：

现场情况	是否需要再次运行
修复了刚才失败的逻辑	需要复测失败，并检查受影响范围
修改了共享接口或公共配置	按影响范围扩展；依赖不清时可能需要较广回归
上轮中断，结果不完整	核对已完成部分与运行现场，再补必要检查
环境、依赖或测试版本发生变化	判断哪些旧证据失效，重跑相关范围
需要评估间歇性失败	按事先约定的次数和条件重复采样
仅仅进入了下一个角色或流程阶段	先检查能否接纳已有证据
理由只有“再确认一下”	先说明新增疑问，再决定是否运行

这里的建议不能替代现有强制检查。项目明确要求的独立验证或发布门禁，仍然必须完成；如果认为规则有问题，应单独修改规则并验证效果，不能由执行中的 Agent 临时绕过。

我希望减少的是没有明确原因的重复。独立审查也有自己的价值，但需要说清它检查的是证据可信性、测试覆盖，还是必须重新执行某项验证。

三、证据不能复用，流程就容易从头再来

一种需要排查的可能性是：上游已经验证通过，下游却无法判断结果针对哪一版产物，或者不知道是否满足自己的验收要求，于是选择重新运行。

这种情况下，重复执行有一个实际原因：已有证据无法被接纳。只要求下游“别再测了”，并没有解决这个问题。

可以先让现有验证记录说清四件事：

验证针对哪个产物版本，包括相关未提交改动。
使用了什么测试、输入与关键环境条件。
哪些检查完成，哪些失败或没有运行，原始结果在哪里。
这份结果支持哪个范围的结论。

证据复用需要核对适用性。代码版本相同，外部配置或服务状态仍可能变化；旧证据支持局部行为，也不能直接推出整个任务通过。

同样，进入新角色本身不是证据失效的理由。如果已有结果满足该阶段的要求，流程可以接纳它；如果不满足，应补明确缺少的部分。

初期不必为了这件事再建设一套复杂平台。先检查现有日志和报告能否回答这些问题，再补真正缺少的记录。

四、验证需要“够了”的条件

“继续检查有没有问题”很难自然结束。检查完代码，可以检查架构；检查完架构，还可以讨论命名和扩展性。新的建议不断出现，原任务的完成条件也就不断后移。

在开始前，可以把本轮验证约定写得很短：

本轮完成已约定功能的验收、修复项的回归，以及按影响范围和项目规则要求的检查。通过后，只有新的相关改动、失败、环境变化或未解决风险，才触发补充验证。新发现的范围外改进进入后续清单。

这不是承诺验证以后再也没有缺陷，而是明确本轮结论覆盖什么。

如果检查发现阻塞交付的真实问题，应处理并复测。如果只是出现了不影响当前验收的改进建议，可以记录后结束本轮。是否阻塞，要依据任务约定与风险，而不是因为建议来自某个审查角色，就自动升级成必须完成。

结束条件要在运行中保持可辨认，不能随着每一轮审查无限增加。

五、预算耗尽后停止，本身不是错误

预算上限防止任务无限消耗。达到硬上限还因为“活没干完”自行继续，实际上让这个上限失去了作用。

需要追查的是上限之前的安排：

是否在剩余预算不足时，仍反复启动较重的验证？
是否把时间花在重复交接和报告上，却迟迟没有推进交付？
是否及时保存了已完成工作及对应证据？
是否提前暴露了“按当前范围可能无法完成”？

这里要区分两种界限：接近预算时，系统应准备收尾；达到硬上限时，应按规则停止。收尾所需的记录和检查点应提前保存，而不是等预算耗尽后再启动一轮不受限制的“整理”。

没有必要一开始就规定一个通用预算比例。可以先利用已有消耗信息设置预警，结合近期运行成本判断是否适合启动下一项工作；估算不确定时，也要明确说明。

至于这次究竟耗尽了什么，需要看实际记录：时间、调用次数、Token、重试次数，还是其他限制。不同维度的改进方法并不相同。

六、预算停止，要能接着干

如果系统只返回“预算耗尽”，使用者仍然不知道代码做到哪里、测试跑了哪些、还有没有进程在执行。

一个有用的停止记录应回答：

问题	应保留的信息
哪些工作已完成	对应产物及版本，不能只有完成百分比
哪些内容已验证	检查范围、结果和原始证据
哪些内容未完成	尚未实现、未运行或未通过的条目
为什么停止	触发的预算维度、上限与可获取的累计消耗
现场是否明确	未结束进程、结果未知的外部操作、最后可用检查点
下一步做什么	最小剩余工作，以及是否需要追加预算或调整范围

执行因预算停止，与业务任务验收通过，是两个不同结论。已有一部分通过，不能把整项任务标成成功；预算用完，也不意味着已有成果必须全部作废。

继续工作时，应按预算策略取得所需授权，再核对产物、环境与未结束操作。不能靠重开任务、换会话或修改计数，把同一项工作的累计消耗清零。

如果还有一条旧的验证命令在运行，恢复时也要先查清状态，避免又启动同一轮工作。

七、先检查一次任务，不急着增加新机制

这件事让我警惕的，是看到 Harness 变重以后，又用更多角色、更多检查和更多状态去解决它。

更小的行动是拿一次已经发生的任务，按时间排列验证启动记录。每次只问：

这一轮的触发原因是什么？
相比上一次，产物、测试或环境改变了什么？
它补上了什么之前没有的证据？
为什么已有结果不能复用？

再把预算事件放到同一条时间线上，区分测试执行、环境准备、模型处理和交接成本。缺失的数据就标记缺失，不把输入 Token 直接换算成费用，也不把所有重复执行都算作可节省成本。

如果发现明确的无效重复，可以只调整一个触发点，或修复一个证据交接问题，再观察：原本需要发现的问题是否仍能发现，任务是否减少了无理由重启，停止时能否保留可继续的成果。

如果最后发现主要消耗在业务实现或必要检查上，就应重新估计任务范围与预算。不能为了证明“Harness 太重”，硬把必要工作解释成浪费。

我希望自己的 Harness 能回答一个朴素的问题：现在继续验证，是因为还有明确风险没有解决，还是流程只是习惯性地再跑一遍？

这个问题能够回答清楚，才有依据决定该继续、该结束，还是带着未完成项停止并等待下一次授权。

继续阅读

让 Agent 下班后继续跑：有界自主运行怎么设计？：预算、检查点和恢复边界。
Agent 调错工具怎么办：Timeout、Retry、Budget 与 Side Effect：重试与外部操作状态。
测试用例 Agent 的门禁落地：一条需求缺口，应该挡住哪些用例？：按影响范围组织检查与放行。