harness-constrain-verify

name	harness-constrain-verify
description	当你要实现 Harness 的约束（限定能做什么）、验证（检查做得对不对）、纠正（做错怎么补救）三层保障机制时使用；当 Agent"能做事"但"不做错事"没保障时使用。不适用于编排模式选择（见 orchestration）或故障恢复（见 fault-recovery）。

约束、验证、纠正（Constrain / Verify / Correct）

角色与读者

面向生产级 Agent 的开发者。本 Skill 服务的目标：把 Harness 的保障机制落地——上下文与工具让 Agent"能做事"，约束/验证/纠正让 Agent"不做错事"。核心认识：生产级系统中 Harness 绝大部分代码都在实现这三层保障，而非上下文与工具本身。

核心原则（配正例/反例）

1. 约束（Constrain）：故障安全默认值，所有能力默认关闭，必须显式开放

   • 类似手机 App 权限管理。Claude Code 每个工具默认需用户授权才能执行。
   • 约束的是动作而非结果（防过程性错误/reward hacking）：删库重建"修复"了故障但数据没了，删失败测试"通过"了但没解决问题。

2. 验证（Verify）：只看结构化数据，不看模型自由文本

   • 安全检查只看工具返回的 JSON 字段，不看模型自由生成的文本（可能已被提示注入操纵）。
   • 正例：Linter 检查、类型系统、工具调用结果校验；write_file 后自动跑 linter 返回结构化错误列表。
   • 验证要自动化，反馈越快越结构化越好（错误信息越接近错误发生时刻，纠正效率越高）。

3. 纠正（Correct）：发现问题自动修正或回退，确认无法恢复前不暴露中间态

   • 工具调用失败先静默重试，不把半成品给用户；连续失败回退到人工判断（熔断）。
   • 正例：静默重试、接续生成、连续失败熔断。

4. 约束优先于指导：能用代码强制的就不要用文档建议

   • Linter 规则、类型约束、CI 检查是"做不了"；提示词"请遵循…"是"建议别做"。
   • 正例：业务规则编码进校验器/Linter/CI；"付款前不能预订"由代码强制。

5. 验证作为独立视角（提议者-审核者 / Sidecar）

   • 事前审批：异源模型双签（不同家族相似能力）；事后验证：模态切换（渲染截图/沙盒运行）。
   • Sidecar：只读结构化字段，与主模型流式输出并行，危险操作放行前不执行。

执行流程（SOP 检查清单）

1. 盘点五要素：上下文、工具、约束、验证、纠正。
2. 约束：所有能力默认关闭，显式开放；对危险动作设专门检查（语义解析）。
3. 验证：自动化（linter/测试/类型检查），只看结构化数据，加 Sidecar 独立审查。
4. 纠正：静默重试 → 降级接续 → 暴露给用户；每条路径熔断上限。
5. 回退可靠（Git 分支/沙盒/快照）。

禁止清单（写清合法例外）

• 禁止把业务规则只写在文档/提示词里（应编码进 Linter/CI/校验器）。例外：自然语言版本放提示词供解释，代码化校验做守门员。
• 禁止验证依赖模型自由文本（只看结构化 JSON 字段）。例外：Sidecar 判断简单分类问题可用轻量模型看结构化字段。
• 禁止确认无法恢复前暴露中间态。例外：所有自动手段用尽后才呈现错误。
• 禁止约束只约束结果不约束动作（防 reward hacking）。例外：对危险动作设专门检查+审批。
• 禁止无限重试。例外：每条恢复路径熔断上限，阈值来自生产数据。

参考资料

• 本书第 1.2 节《Harness 工程》+ 第 5.1.4 节《Harness 工程在 Coding Agent 中的实践》。
• 笔记 01-AI-Agent入门.md 第 1.6 节、05-Coding-Agent与通用Agent.md 第 5.1.4 节。