写清任务合同
输入是什么、要改哪些文件、不能碰什么、什么结果才算完成。它是给执行者和检查者共用的说明书。
从零开始 · 可复查的 Agent 工作流
Harness 不是
更多工具，是闭环
模型负责生成和执行。Harness 负责告诉它边界、在危险动作前拦一下、在完成后留下能重跑的证据。没有它，Agent 只是“看起来做完了”。
先说清这次要交付什么
再拦住不该发生的动作
最后证明结果能被复查
先做一个最小闭环
别先堆工具。先让一件小事能被证明。
例如，让 Agent 修改一个配置文件。你需要的不是十个 MCP，而是下面四步。四步都走通，才有资格扩展。
给危险动作留拦截点
删除、强制推送、写外部平台这类动作，不只写在提示词里。把它们接到 Hook 或安全门上。
准备一条会失败的测试
不仅验证“正确配置能通过”，也验证“错误配置会被拦住”。只跑正例，不能说明保护真的有效。
由独立角色复查
执行 Agent 不能给自己判完成。检查者重跑命令、看退出码，并把仍需人工确认的地方单独列出来。
一句话记住：规则要能触发，结果要能重跑，边界要能被看见。
把规则接到动作上
文档负责解释，机制负责执行。
CLAUDE.md、Skill 和任务说明告诉 Agent 应该怎么做。Hook、安全门和脚本则在关键时刻真正执行规则。两者缺一个都不完整。
写给人和 Agent 的规则
用具体动作表达：何时允许写、何时必须询问、完成时要带什么证据。避免“注意安全”这类无法判断对错的话。
CLAUDE.md · Skills · Task Contract写给机器的拦截
危险命令、敏感文件、外部写入在工具调用前检查。模型忘了规则时，机制还能把它拦下来。
Hook · Safety Gate · Exit Code一个常见误会“配置文件存在”不等于“规则已触发”。要同时看安全路径、危险路径和真实宿主里的烟测结果。
完成不是一句口头报告
把“做完了”拆成三类证据。
Harness Check 不给一个掩盖细节的总分。它把自动化、人工确认和未决风险分开，因为它们不是同一种结论。
自动化命令、正反例、退出码证明在本地或 CI 中，这条检查可以重复执行。可重跑
独立复查Evaluator 重跑并解释结果执行者之外的人，按任务合同检查产物、范围和遗漏。可追问
人工边界真实宿主、视觉、发布与外部副作用自动化没有覆盖的部分明确标为待确认，不能写成通过。不假装
30 分钟上手
今天只做第一轮，不求把系统一次做全。
- 01
选一个高频、低风险任务
例如改一份配置或生成一个固定格式的文件。不要从发布、付费或生产删除开始。
- 02
为它写一个任务合同和一个反例
先让错误路径能失败，再谈自动化通过。
- 03
运行工作区检查
bash .harness/scripts/verify.sh --working-tree
- 04
记录一次真实失败
它为什么发生、以后由规则、Hook 还是测试防住、怎样回归验证。这个记录就是失败台账的起点。
走完第一轮以后再加入长任务状态、Context Reset、Sprint Contract、权限分级和 CI 模式。它们解决的是规模变大后的问题，不是起步门槛。