## 一个奇怪的场景
我最近写深度科普的方式，越来越不像"写作"了。
打开电脑，进到一个叫 `Creator/` 的文件夹。里面有十几个子目录和配置文件，没有一个是文章本身——都是规则、模板、契约、状态机协议。我启动 Claude Code，让它读 `STARTUP.md`，然后根据当前任务状态进入对应的阶段。
第一个阶段叫 planning。AI 先扮演一个叫 `AudienceAnalyst` 的角色，定义这篇文章的目标读者；然后切换成 `PoliticalTheorist`，把我模糊的想法转成可研究的社会科学问题并匹配理论框架；再切换成 `ResearchAnalyst`，做系统性深度研究，产出注释书目和带字数预算的详细大纲。每个阶段都产出一份结构化文档保存在任务目录里，我逐份审阅，通过了才能推进到下一个。
然后是 writing。先 `NarrativeStrategist` 把研究大纲改造成叙事蓝图，确定每章的钩子、转场、证据锚点；再 `ContentWriter` **按章节接力写作**——一次调用只写一章，严格遵守该章的字数预算和证据要求；整篇拼接完成后由 `VoiceAndStyle` 做整体文风塑造。
再之后是 review。**三个独立视角并行工作**：`RedTeam` 找逻辑谬误和隐藏假设，`FactChecker` 做外部交叉验证并输出事实核查报告，`PeerReviewer` 以期刊审稿人立场做学术评估。三份报告产出后，一个叫 `ReviewSynthesizer` 的角色把它们聚合成结构化的决策面板，把冲突的建议显式标出来给我选择。
整个过程里，我没在"写"——至少不是传统意义上的、对着空白文档敲字的那种写。AI 也没在"写"——它只是在一套严格的契约里执行被约束好的工作。
**真正在工作的东西，是那套结构本身。**
这种工作方式有个名字，但这个名字几个月前才刚被创造出来。有意思的是，这个名字当前几乎只在程序员的世界里流通。而我在这里想说的是：它其实更属于我们——属于所有做非虚构深度写作的人。
## 这套方法叫 harness engineering
"Harness"这个词在英文里有几个意思。套在马身上的缰绳和挽具，是最字面的那个。工程领域里它引申为"测试用的固定装置"——"test harness"是跑自动化测试时把被测对象固定住的一整套脚手架。
2026 年初，HashiCorp 的创始人 Mitchell Hashimoto 在一篇博客里提到一个习惯：每次 AI agent 犯错，他就在 agent 的运行环境里修一个永久性的结构性补丁，而不是去调教这一次的具体输出。他把这个做法叫做 "engineering the harness"——工程化那个套在 AI 外面的挽具。
几周之内，OpenAI 和 Anthropic 相继发文扩展这个概念。Martin Fowler 在 4 月的长文中做了定性：**harness engineering 是"围绕 AI 模型的一切，除了模型本身"**——上下文管理、工具编排、沙箱执行、持久化状态、权限范围、错误恢复、可观测性。一个可以被写出来的公式：
> **Agent = Model + Harness**
Fowler 把 harness 组件分成两类：**guides**（前馈控制，在 agent 行动前引导它）和 **sensors**（反馈控制，在 agent 行动后观察并触发自我修正）。LangChain 的工程师进一步给出了五个原语：文件系统（作为持久状态和协作界面）、代码执行（让 agent 自主解决问题）、沙箱（隔离和验证）、记忆（跨会话持久化）、上下文管理（对抗"上下文腐烂"）。
这套框架被迅速接受，因为它命名了一个大家都在做但缺乏共同语言的事。
在进入写作场景之前，需要先把一个概念区分讲清楚——它是理解整套系统的入口。
## Harness 不是 skill，也不是 workflow
熟悉 AI 工具的读者这时候可能会问：**这和 prompt、和 skill、和工作流有什么本质区别？**
**Prompt engineering** 优化的是单次对话的输入——给模型什么指令能得到更好的输出。它是 harness 的一个组件，但不等于 harness。Fowler 的比喻很准：如果 prompt engineering 是"告诉司机向右转"，harness engineering 是"道路、护栏、交通标志、信号灯共同构成的让十辆车安全导航的系统"。
**Skill**（比如 Claude 的 skill 机制）封装的是**能力**——一个特定任务 agent 可以加载的便携工具包。它适合"这件事偶尔做一下、需要时加载"的场景：格式转换、特定 API 调用规范、领域术语处理。skill 是 agent 工具箱里的零件，由 agent 自己判断何时使用。
**Harness** 封装的是**约束环境**——它定义 agent 在什么边界内工作、产物如何被校验、哪些节点需要人工确认、状态如何跨会话持续。主动权不在 agent，而在你。Skill 问的是"agent 需要什么能力"，harness 问的是"agent 应该在什么约束下工作"。
还有第三个需要区分的东西：**workflow（工作流）**。
这个区分是理解本文系统的关键，但它经常被忽略。Harness 和 workflow 是两个不同的层次：
- **Harness 是静态的**——契约 schema、校验脚本、权限 gate、记忆系统。它定义了约束，但不规定执行顺序。
- **Workflow 是动态的**——谁调用谁、什么顺序、输入输出是什么。它在 harness 提供的约束里运行。
类比：harness 是交通法规和道路基础设施，workflow 是你从 A 开到 B 的具体路线。路线需要法规才安全；法规本身不是路线。
本文描述的系统**同时包含两个层次**：harness 层决定这个系统可不可信，workflow 层决定文章怎么写出来。搞清楚这两层，才能理解为什么写作——尤其是深度非虚构写作——对 harness 的需求比 coding 更迫切。
## 为什么写作更需要 harness
这么说不是为了赶时髦，它是有理由的。
**第一，代码有天然的 sensors，写作没有。**
Fowler 的 sensor 概念——那些能在 agent 行动之后自动校验输出质量的反馈机制——在 coding 领域几乎是免费的。编译器会告诉你语法错了；单元测试会告诉你行为变了；linter 会告诉你风格偏了；类型检查器会告诉你接口不兼容了。这些 sensor 不需要你特意建造，它们是几十年软件工程积累下来的基础设施。一个哪怕设计得很粗糙的 coding harness，光靠接上这些现成的 sensor，就能获得相当可观的质量反馈回路。
写作没有这些东西。没有编译器会告诉你这段话"逻辑跳跃了"，没有单元测试会告诉你这个比喻"不贴切"，没有 linter 会告诉你这个段落"正确但平庸"。这意味着：coding harness 可以靠复用既有 sensor 跑得挺远；**写作 harness 必须从零设计质量反馈机制**，否则就会退化成"AI 写完你看一眼"的粗糙流水线。
坦白讲：这个问题还没有完全得到解决。本文后面会描述的三个审查角色（RedTeam、FactChecker、PeerReviewer），本质上也是 AI agent——它们是高质量的 guides（前馈引导），不是机械的 sensors（客观反馈）。整套系统里真正意义上的 sensor，只有字数校验脚本这类机械检查。写作 harness 与 coding harness 之间的 sensor 差距，至今仍未弥合。这是领域层面尚待解决的问题，不是本文能回答的。
**第二，写作的质量判断更依赖契约，因为它不能依赖运行时验证。**
代码不确定写得好不好？跑一下。测试过了就大概率没事，性能不够就 profile 一下。写作不能"跑一下"。一篇文章"好不好"的判断，发生在读者脑子里——那是 harness 无法企及的黑箱。
这逼着写作 harness 必须在**事前**把质量要求转化成可检查的契约，而不是**事后**靠运行验证。这种"契约先行"的设计，在 coding 里也有（类型系统、接口定义），但在写作里它是**唯一的质量保障机制**，所以必须做得更严密、更显性。
**第三，写作的选题本身就可能是个错误，代码几乎不会。**
没有人会花三天写一段"根本不值得写的代码"——你要写的代码通常由业务需求驱动，值不值得写在任务启动前就已经决定了。但写作不同：**最大的浪费不是写得不好，而是选题本身不值得写**。信息密度不够、已有大量优质存量内容、无法在目标篇幅内讲清楚、或者你的视角其实并不独特——任何一条都可能让一篇认真写出来的文章从一开始就注定平庸。
这意味着写作 harness 必须包含一个 coding harness 通常不需要的东西：**选题质量门**。在 planning 之后、writing 之前，必须有显式的 go/no-go 检查点，让选题和框架在开始写作之前就能立住。
## 写作 harness 的五个层面
说了这么多抽象原则，具体看一眼结构更直观。先看 harness 层——那套静态的约束环境。这是我的 `Creator/` 目录里属于 harness 的部分：
```
Creator/
├── CLAUDE.md / GEMINI.md # 约束规则层：协调器行为边界
├── STARTUP.md # 状态控制层：任务启动与阶段调度协议
├── knowledge/
│ ├── templates/ # 契约 schema 层：结构化输入输出强制
│ │ ├── subagent_call_contract.md
│ │ ├── subagent_response_template.md
│ │ ├── workflow_state_template.md
│ │ ├── revision_decision_template.md
│ │ └── evidence_map_template.md
│ └── memory/ # 记忆层：跨任务全局知识
│ ├── style_guidelines.md
│ ├── verified_sources.md
│ └── topic_map.md
└── scripts/ # 机械校验层：客观可验证的质量检查
└── check_word_budget.py
```
workflow 的执行产物（每篇文章的 `run/` 目录、草稿、审查报告）不在这里——它们是 harness 运行时生成的状态，不是 harness 本身。
这五个层面各司其职：
### 约束规则层：定义边界
`CLAUDE.md`（或 `GEMINI.md`——换 AI 工具时读不同文件，内容一致）里写着协调器的行为边界。其中有一条关键的非协商规则：
> **主动提问权**：只有你可以向用户提问。子代理（或你代行时）只能返回文件、摘要、待确认问题、假设和阻塞原因。
这是 harness 层面的权限范围约束，不是 prompt 层面的"建议"。它强制了信息流的拓扑结构：用户 ↔ 协调器 → 子代理，单向且清晰。多 agent 系统最容易犯的错误是 agent 各自和用户对话，信息分散、状态不一致。这条规则在结构层面杜绝了这个问题。
`CLAUDE.md` 里还有一条踩坑后加的警告：
> 本工作区已完全包含了专栏创作的完整流程。在此工作区内，严禁调用 `activate_skill` 工具去激活全局的 `substack` 技能，以免造成规则重复和上下文污染。
这条警告值得诚实说明：它不是设计原则，是一个当前的架构限制。harness 和 skill 系统在上下文里相遇时会产生规则冲突，目前的解法是隔离使用。理想的设计应该让两者可组合——这是这套系统尚未解决的问题。
### 契约 schema 层：结构化强制
子代理被调度时，不是收到一段自由文字的指令，而是一个完整的**调用包**（subagent call packet）。契约模板规定了必填字段：
```text
阶段: writing
agent: ContentWriter
执行方式: 子代理委派
任务目录: runs/2026-03-13-example-topic
输入文件:
- argument_structure.md
- detailed_outline.md
- annotated_bibliography.md
输出文件:
- sections/03-case-study.md
目标总字数:
- 7000-10000 汉字
章节预算:
- 03 核心案例：1000-1400 汉字
本轮目标:
- 完成第 03 章初稿，聚焦核心案例与机制解释
边界:
- 只写本章
- 不得覆写 draft_v1.md
- 不得向用户提问
证据规则:
- 保留来源键
- 证据不足时使用 [待核实]
```
返回也是结构化的：
```text
状态: 成功 | 阻塞 | 失败
已生成文件: <相对任务目录的路径>
摘要: <100-200 字>
待确认问题: - ...
默认假设: - ...
建议回滚步骤: - 无 / 步骤 N + 原因
风险或阻塞: - ...
```
这是 schema 级别的强制，不是建议性规则。`已生成文件` 列出的路径必须真实存在，`状态: 阻塞` 必须配 `风险或阻塞` 字段说明原因。协调器在推进下一步之前做结构校验，不符合契约就打回重做——**agent 的工作结果因此是可机械校验的**。
### 机械校验层：唯一真正的 sensor
整套系统里最接近 coding harness sensor 的东西，是 `check_word_budget.py`。它做的事很简单：验证整篇和每章的字数是否都在 min-max 区间内。这是客观的、不依赖 AI 判断的质量检查——这才是真正意义上的 sensor。
三个审查 agent 的报告是高质量的 guides，不是 sensors。这个差别在写作 harness 的设计里必须被认清。
### 状态控制层：把人工介入变成结构强制
在状态机里，显式标注哪些状态转换是 `human_gate: true`。比如 `planning_done → writing_start` 必须人工确认，agent 看到 gate 就停下来等我输入，不能擅自推进。
这个设计把"人应该在哪里介入"从自觉变成了强制——既防止我自己偷懒，也防止 agent 漂移。这是 harness 层面权限控制的核心体现。
### 记忆层：跨任务的全局知识
`knowledge/memory/` 下的三个文件由 `ReflectionAgent` 维护：
- `style_guidelines.md`：具有全局指导意义的文风准则
- `verified_sources.md`：经过外部交叉验证的高价值文献
- `topic_map.md`：专栏已覆盖的议题版图
关键设计：**ReflectionAgent 不直接修改记忆文件，只产出 `memory_update_proposal.md`**。人批示之后才追加进去。这样记忆库的演化速度取决于我的批示节奏，避免了"AI 擅自把不合适的规则沉淀下来"的污染风险。
记忆层让 harness 具备了自我进化能力。更让我意外的是，`ReflectionAgent` 还会额外产出关于 harness 本身运行的观察——比如报告 `check_word_budget.py` 的 ASCII 词条算法会导致来源键剥离后总字数下降幅度小于直觉预期，建议在契约里显式说明。这部分进入 harness changelog，把系统从"静态工具"变成**观察自身运行低效点的自反思系统**。
## 在这个 harness 上跑的 workflow
harness 定义了约束环境，workflow 在约束里执行。我的写作 workflow 是一条 11 个 agent 的流水线，分四个阶段：
```
Planning: AudienceAnalyst → PoliticalTheorist → ResearchAnalyst
Writing: NarrativeStrategist → ContentWriter（按章循环）→ VoiceAndStyle
Review: RedTeam ∥ FactChecker ∥ PeerReviewer → ReviewSynthesizer
Publishing/Reflection: ...→ ReflectionAgent
```
workflow 的具体设计和 harness 是独立的——换一套写作类型（财经分析、文化评论），workflow 里的 agent 角色和顺序都会变，但 harness 的五个层面基本不动。这是两层分离的实际价值：harness 是可迁移的方法论基础设施，workflow 是领域特定的执行策略。
workflow 里有几个设计决定值得单独说明，因为它们和 harness 的约束密切相关。
**字数预算作为贯穿全流程的硬约束。**
字数预算在这套系统里不是"写完看一眼"的指标，而是贯穿整条流水线的强制：ResearchAnalyst 产出大纲时锁定每章预算，ContentWriter 写作时以预算为硬边界，reviewer 的建议必须标注预期字数影响，revision decision 阶段每项采纳都要算预算冲突，最终由 `check_word_budget.py` 机械验证。
为什么字数预算这么重要？因为**它是对"证据密度"和"论证饱和度"的代理度量**。每章的硬边界意味着 agent 不能靠空话凑字，也不能靠删减偷工。如果某章证据不足以支撑其预算，必须在大纲的"证据缺口"字段里显式登记——不得把问题留给写作阶段临时发挥。在写作 harness 里，字数预算扮演的角色类似于 coding harness 里的测试覆盖率——它不是直接度量质量，而是**约束出质量的容器**。
**三份审查报告并行，然后由 Synthesizer 聚合。**
Review 阶段的设计出发点是：事实核查要怀疑主义，红队要敌意和攻击性，学术审稿要宏观视野。这三种思维模式是互相冲突的，让一个 reviewer 承担全部维度会让每个维度都做得平庸。
让三个独立视角并行工作，再由 `ReviewSynthesizer` 做三件事：**去重**（指向同一问题的报告合并为一个 Action Item）、**冲突显式化**（不同报告对同一问题给出不同建议时，标记为冲突而不是偷偷选一个）、**分支化**（每个 Action Item 给出多个选项，标注预期影响，推荐默认选项但不替用户决策）。
最终产出是 `review_action_items.md`，按"已吸收 / 高优 / 中优 / 低优 / 冲突"分类。多 agent 审查最大的认知负担不是读报告，而是消化三份报告之间的冲突和重叠——把这个消化动作从我这里转移到 Synthesizer 那里，我的决策时间缩短了几倍。
## 真正的设计哲学：人 in the loop，不是人 on the loop
OpenAI 那个"五个月零手写代码"的实验展示的，是一种**人 on the loop** 的理想——人类退到外围，通过设计和维护 harness 来间接引导 agent 工作，具体的执行完全由 agent 完成。这套理想在 coding 领域是合理的：代码的质量有客观标准（能跑、正确、高性能），人类的具体介入不一定比精心设计的自动化流程更有价值。
但如果你把这套理想照搬到深度写作上，会得到一个在流程上无懈可击、在内容上毫无灵气的产物。
原因很简单：**深度非虚构写作的核心竞争力是独特视角和对复杂性的驾驭**。这两样东西没法被流程保证——流程只能保证下限，保证不了上限。agent 的默认品味是所有训练数据的平均值，而平均值恰好是最没有个性的地方。
所以写作 harness 必须坚持的是**人 in the loop**：人不是在外面监督，而是在里面做关键判断。Harness 的正确使命不是"让人越来越不用参与"，而是"**让人只在最有价值的地方参与**"。
具体到我的这套系统，人必须介入的节点包括：
**选题决策点（planning 阶段的三次 gate）。** AudienceAnalyst 产出读者画像后我看一遍，PoliticalTheorist 产出理论框架后我看一遍，ResearchAnalyst 产出大纲和字数预算后我再看一遍。这三个 gate 里任何一个不过，后面全是白做——选题错了，写得再漂亮也只是一篇错文章。
**叙事骨架点（writing 早期）。** NarrativeStrategist 产出 `argument_structure.md` 后我审阅。大纲不是章节列表，是"想让读者经历什么认知旅程"。AI 擅长填充、扩写、查证，但不擅长判断"哪个比喻真的能说明问题"、"哪里该留白"。我在骨架上画两笔，后面 writing 的质量天花板就完全不同了。
**审稿的价值判断（review 阶段）。** 事实核查可以机械化，但"这段虽然准确但很平庸"、"这里逻辑对但读者会走神"这种判断必须由我做。三份独立报告 + Synthesizer 聚合之后，我拿到的是一个分层的决策面板，我只做"采纳 / 拒绝 / 折中"的选择题。
**记忆沉淀的批示（reflection 阶段）。** ReflectionAgent 提议新增文风准则，我决定采纳哪几条进全局记忆。这一步决定了我的"专栏潜意识"如何演化。
对应地，agent 的舒适区是：草稿、查证、格式、一致性检查、字数控制、重复段落检测、引用规范、结构化报告产出、跨报告去重。让它做好这些，我就能把注意力集中在品味和判断上，而不是被琐碎耗竭。
## 过度工程化的三个陷阱
我必须在这里指出这一点，因为它是 harness 最大的风险。
**第一，harness 的维护成本可能超过它的收益。**
这套系统适合"需要稳定产出、有一定批量"的场景——如果你一年要写 50 篇深度文章，harness 几乎一定是值得的。但如果你一个月才写一两篇，每次写作前对着 harness 调一调提示词、改一改模板、修一修脚本的时间，可能已经超过你直接手写那一两篇的时间。
一个自检问题：**上次你改 harness 花的时间，如果直接用来手写文章，是不是产出更高？** 如果答案连续几次都是"是"，说明你在享受建造工具而不是享受产出内容。
**第二，harness 容易变成"安全毯"。**
流程越规整，越容易产生"按流程走完 = 作品合格"的错觉。你会开始迁就流程——因为某个 agent 不擅长处理某类选题，就避开那类选题；因为某个模板不支持某种叙事结构，就不用那种结构。这时候 harness 不是在服务你，是在塑造你。
判断信号：如果你发现自己产出的文章都"挺规范但没什么记忆点"，那就是 harness 在压制而不是放大你的判断力。这时候应该把 harness 用得更轻，只保留事实校验、证据政策、字数控制这些机械性部分，把选题视角、叙事结构、语言节奏这些创造性部分交还给人。
**第三，harness 规则会和模型能力产生版本错位。**
这是 harness 特有的风险，前两个是通用的过度工程化风险。
你为今天的模型设计的约束——"不得靠同义反复凑字"、"证据不足时使用 [待核实]"——是在应对今天模型的具体缺陷。模型能力提升后，这些约束可能变成无意义的噪声，甚至限制输出质量。harness 需要被定期对着当前模型能力重新校准：这条规则是在对抗一个已经不存在的问题吗？
这不只是"定期重构"，而是一种更具体的维护工作——让 harness 的约束边界随模型能力的演进而移动。
Harness 的正确使用姿势不是"越完整越好"，而是**识别出哪些环节适合流程化、哪些必须保留人的判断**——而且这个识别是动态的。
## 为什么现在应该开始
**第一，你沉淀下来的是写作方法论，不是对某个 AI 工具的熟练度。**
harness 里的程序化部分（契约 schema、校验脚本、gate 机制）对 agent 是完全无关的。指令性部分（CLAUDE.md / GEMINI.md）需要针对不同模型做校准，但迁移成本远低于从头重建。今天你用 Claude Code、明天换别的——只要新 agent 能读 markdown 指令、能访问文件系统、能执行脚本，harness 的核心约束就能继续有效。
**第二，模型会越来越强，但你的品味是稀缺品。**
很多人担心"把流程做得这么精细，将来模型能力上去了不就白做了？"这个担心搞反了方向。模型越来越强意味着能跟它协作的人越来越多，同质化也会越来越严重——每个人都能用 AI 产出"还不错"的内容，意味着"还不错"已经不构成任何竞争力。真正稀缺的是**你独特的判断力**——什么选题值得做、什么角度有张力、什么段落该删、什么比喻能击中人。Harness 是把这种判断力固化、复用、放大的载体。模型越强，harness 放大出来的判断力价值越高。
## 结尾：一门属于创作者的新手艺
目前，Harness engineering 被定义为一门工程框架，主流讨论也确实在工程语境里进行。但这个框架的出发点——**让 AI 在一套精心设计的约束中做有价值的工作，让人只在最需要判断的地方出现**——这个哲学本身和工程无关，和创作的关系反而更深。
写作者一直在做类似的事：我们用写作指南约束自己的语言，用风格手册保持出版物的一致性，用审稿流程拦住质量下限，用编辑对话发现自己看不见的盲点。这些都是 harness，只是以前它们是人和人之间的协作结构。现在有了 AI，这些结构的一部分可以被形式化、版本化、自动化，并且和一个不会疲倦的执行者对接。
但 harness 的灵魂不是自动化。是**你作为创作者的方法论变得可被审视、可被迭代、可被持续改进**。这件事在 AI 出现之前就有价值，现在只是有了一个更强的载体。
所以如果你是一个认真对待写作的人，不要把 harness engineering 当成程序员的小玩具。它是一门**属于所有需要在复杂性中保持判断力的创作者**的新手艺。
从哪里开始？从你下一篇文章开始。别搭一个宏大的结构——搭最小的那个：一个 `writing.md` 写清楚你的写作原则，一个 `checklist.md` 列出你审稿时检查的维度，一个 `runs/` 目录存中间稿。就这三样，你已经有一个 harness 了。
剩下的，随着你写的每一篇文章生长出来。
---
*本文描述的 harness 会择时开源，敬请关注。*