第 9 章：Harness Engineering 十条原则
出处
来源：原网页 · 状态：已读 · PDF：book1-claude-code.pdf p.72–74
一句话
Harness Engineering 关心的是：在模型并不可靠的前提下，系统仍然能表现出工程系统应有的行为。 模型不可靠，但系统仍然可以可靠——前提是别把可靠性寄托在模型身上，而要把它做进 harness。Harness 比激情重要，制度比聪明重要，验证比自信重要。
核心概念
团队真正带得走的，往往是若干能反复使用的原则，而不是某个版本的函数名。十条不是格言，来自 Claude Code 源码与工程结构里的工作判断。
- 把模型当不稳定部件，不要当同事。 同事可以被信任地承担职责，模型不能。它也许能像同事一样说话，但不会自动获得同事那种稳定性、责任感和持续判断力。越早承认这一点，系统就越早开始补上权限、恢复、验证和回滚。
- Prompt 是控制面的一部分。 System prompt 用来定义行为协议，和 runtime、tool schema、memory、hook 一起组成控制平面。把 prompt 当人格设定，最后会得到一个很会表演、但不受约束的系统。
- Query loop 才是代理系统的心跳。 真正的 agent 依赖一段持续的执行循环。输入治理、流式消费、工具调度、恢复分支、停止条件，都是这个心跳的一部分。没有 query loop 的系统也许能做 demo，但还谈不上运行时。
- 工具是受管执行接口。 一旦模型开始碰 shell、文件系统、Git 和网络，问题就从「它会不会说」变成「它会不会留下后果」。工具必须被调度、被授权、被中断、被补账。越危险的工具，越不能按普通能力对待。
- 上下文是工作内存。 能塞进上下文，不等于应该塞进去。长期规则、持久记忆、会话连续性和临时对话应该分层治理。Compact 的目标是保住继续工作的语义底座。好的上下文管理，标准不是「够多」，而是「可治理」。
- 错误路径就是主路径。 Prompt too long、max output tokens、中断、hook 回环、compact 自身失败，都是长会话代理迟早要面对的日常天气。恢复、熔断、限次、防死循环，必须在设计时就存在，而不是出问题以后再补。
- 恢复的目标是继续工作。 截断之后最好的动作通常是续写；压缩失败时最重要的是先让系统恢复呼吸。工程系统真正的礼貌，在于别把用户困在失败态里。
- 多代理的意义，是把不确定性分区。 把研究、实现、验证、综合放进不同职责容器。隔离状态，分离角色，最后由 coordinator 收束理解。并行真正带来的价值不是更快，而是让职责边界更清楚。
- 验证必须独立，不能让系统自己给自己打分。 实现者天然倾向于相信自己的改动「差不多行了」，模型更是如此。凡是重要任务，验证都应该成为独立阶段，最好还有独立角色。否则所谓「完成」很快就会退化成「已经写完并且我觉得没问题」。
- 团队制度比个人技巧重要。 一个高手可以靠经验把代理驯服，一个团队不行。团队需要：分层 CLAUDE.md、明确 approval、可执行 skill、生命周期 hook、可追踪 transcript、统一验证定义。只有把个人经验制度化，代理系统才可能成为组织能力，而不是个人把戏。
关键洞察
Claude Code 的源码真正教人的，是这种克制：它始终把不稳定性当已知前提，再围着这个前提设计 prompt、loop、tools、memory、compact、recovery、verification 和 team workflow。也正因为如此，它值得被当作设计样本。
难的从来不在把原则说出来，而在愿不愿意承认那三句：Harness 比激情重要，制度比聪明重要，验证比自信重要。
封面那句和这十条是同一件事：一个系统是否可靠，不在它会不会说，而在它出了岔子以后，谁来收拾残局。
个人思考
十条几乎可以当本仓库 Harness 系列的索引：1–3 对应序言到 Query Loop，4 对应工具权限，5 对应上下文治理，6–7 对应错误恢复，8–9 对应多代理与验证，10 对应团队落地。读完 Book 1 之后，Book 2 对照 Claude Code 与 Codex，看的就是这十条在另一套 harness 里换了哪些器官、留下了哪些判断。