序言：Harness、终端与工程约束
出处
来源：原网页 · 状态：已读 · PDF：book1-claude-code.pdf p.8–11（含导读）
一句话
Prompt 决定它怎么说话，Harness 决定它怎么做事。 模型进入终端、仓库和 Git 之后，可靠性不取决于它会不会说，而取决于出了岔子以后谁来收拾残局。
导读（阅读前提）
这本书不问「模型会不会写代码」，而问：会写代码的模型被放进终端、仓库和团队流程以后，怎样才不会把系统带偏。不是源码注释，也不是功能清单。结构是七块：控制面、主循环、工具权限、上下文治理、恢复路径、多代理验证、团队制度。
三个前提：
- 重点不在模型能力，而在 harness 如何组织约束与执行
- 重点不在函数逐条解释，而在运行时结构为什么必须长成这样
- 重点不在个人技巧，而在这些结构怎样变成团队能复用的制度
想先看总判断，可跳第 9 章。
核心概念
- Harness Engineering：一组持续生效的控制结构，用来划定模型在工程环境里的行为边界。没有约束的能力只会扩大事故半径。
- 文本错误 vs 执行错误：只会吐文本的模型，出错主要是理解成本；能跑命令、改文件、联网、动 Git 的模型，出错留下的是执行痕迹——目录变了、进程断了、配置坏了、历史难追。
- 模型是不稳定部件：工程不能靠乐观叙事撑着。部件本质不稳，系统就要按这个事实设计。Agent = 整套约束结构；模型只是其中最会说话、也最不稳的那个部件。
- Claude Code 当样本，不当时装：价值不在复制同一套 CLI，而在展示面向真实工程的代理如何走向更严的约束结构。本书不附源码（版权边界），只从结构提炼原则。
Claude Code 的工程克制（它不假定什么，所以做了什么）：
| 它不假定…… | 所以它做了…… |
|---|---|
| 模型会持续正确 | query loop 管状态 |
| 工具调用天然安全 | 权限 + 调度卡住工具 |
| 上下文越多越好 | memory、CLAUDE.md、compact、session memory |
| 错误是偶发事件 | prompt too long、max output tokens、中断、hook 回环都有恢复 |
| 多代理 = 更强 | synthesis 和 verification 拆开，避免自我背书 |
关键洞察
书要做两件事：
- 讲清真正决定可靠性的结构——为什么上下文治理必须走主路径、多代理解决的是职责分区、团队制度为什么要嵌进生命周期——而不是罗列「有 compact / subagent / hook」。
- 把判断提炼成更一般的原则。代码、函数名、产品形态会变；只要还把不稳的模型接进真实工作流，这些判断就可能还有效：
- 错误路径要按主路径设计
- 验证必须进入完成定义
- 权限是系统器官，不是附属功能
- 上下文是资源，不是垃圾桶
- 多代理靠角色分离，不靠人海战术
- 团队制度比个人技巧重要
更直白：这本书不讨论如何包装「像工程师」的幻觉，而讨论在模型不具备工程师级稳定性时，如何仍做出可运行的工程系统。回滚、审批、权限、验证、compact、清理孤儿进程都不显眼，但长期稳定往往取决于它们。过度追求「像人一样自然」，常见结果是学到了人类式失误，却没有承担后果的能力。
封面口号：SYSTEM FIRST / MODEL SECOND。先有规矩再谈聪明。
文末日期 2026.04.01，作者加了一句「Claude Code 源码泄漏的愚人节」——当玩笑读，不影响论点。
个人思考
和仓库里已有判断对得上：Anthropic 的 AI-native SDLC 说代码不再是瓶颈、人守闸门、循环自己转；Warp 说 agent 变好靠现场反馈沉淀进 skill。序言把这些收成一句更硬的话——没有 harness，能力只是事故半径。后面九章都是在展开这套约束如何形成、为什么必须这样安排。