Harness 能稳定处理结构信号，却不能直接理解“任务是否完成”。Agent 可靠性的关键不是让 Harness 模拟模型的语义判断，而是尽可能把目标转换为退出码、产物校验、状态变化和评分标准。
Harness 执行每一次工具调用，因此天然掌握命令结果、文件变化和调用次数。它缺少的不是数据，而是“这些数据是否意味着目标已经达成”的定义。
停滞不是简单重复
同一测试连续运行可能是正常轮询，不同命令也可能只是在重复同一个失败思路。更准确的停滞定义是：资源持续消耗，但可观察目标没有进展。
检测可以从低成本信号逐层增加：
| 信号 | 能说明什么 |
|---|---|
| 相同调用得到相同结果 | 可能正在重复 |
| 同一错误签名反复出现 | 解决路径没有改变 |
| 文件、测试或待办状态不变 | 客观进展接近于零 |
| 独立评审判断转录 | 开放任务可能缺乏结构指标 |
检测之后不应立即终止。先把“连续三次得到同样错误”作为显式信息放入下一轮，仍无进展时再回到早期 Checkpoint、启用干净上下文或请求人工介入。最大轮数只负责限制最坏损失，不能代替停滞判断。
“完成”必须转换为可检验条件
模型停止或声明完成，只是一项建议。Harness 若没有验收条件，就无法区分真实完成与过早结束。
可靠性从高到低可以分为三层：
- 机器可验证：测试通过、编译成功、文件存在且结构合法；
- 独立评分：事先定义检查项，由独立上下文评审产出；
- 人工确认：目标只存在于用户判断中时，整理证据并交还用户。
代码任务往往比开放式写作稳定，不一定是模型更擅长代码，而是代码天然拥有测试、编译器和静态检查。目标越容易转换为确定性信号，Harness 越能可靠批准完成。
Harness 应在执行中和结束时各检查一次
流中检查用于判断进展。例如失败测试从 12 个降到 5 个，虽然尚未完成，但不应被判为停滞；连续多轮维持 5 个，才需要干预。
终局检查则在模型声明完成后重新执行验证，不依赖它提供的文字总结：
模型声明完成→ Harness 独立运行验证→ 通过则结束→ 失败则把真实结果送回 Agent工具层错误也应作为结果交给模型，而不是由 Harness 无条件重试。网络超时可以在满足幂等条件时退避重试；文件不存在或命令失败通常需要模型改变方法；任务级停滞则必须改变上下文、计划或参与者。
我的选择：先设计验收，再设计 Agent
我会在任务进入 Agent Loop 前定义可验证的完成条件，并同时记录过程指标和终局验证结果。写不成测试时，就写成明确评分表；两者都无法定义时，任务必须保留人工确认。
这会增加验证器和状态采集成本，也可能限制开放任务的自由度。但如果目标无法被任何独立证据确认，就不应把“自动完成”作为系统承诺。下一篇进一步讨论如何判断系统改动是否整体变好：评估集的定位是防回归，而不是证明质量。