规约：让意图能被并行分发

🚧 本章正在开发中。本文是章节开篇，子节内容陆续补充。

卷一回顾的画面是一份 spec、一个 Agent、一个人。意图从人脑子里出来，经过分层和维度的整理变成 spec，Agent 读 spec 执行，人验收并发起下一轮。规约章的方法论让这条路径走得稳，但也是因为这条路径只有一个人在走。

卷二的画面不一样。多个 Agent 同时在不同的子空间里跑。可能是几个 agent 真的并行，也可能是一个 agent 在长程任务里跨多个 context window 跑。本质都是多个并行的对齐流。

人物理上做不到逐条介入每条流的每一步。一天能盯三四条已经到极限，但子空间数量动辄十几条。人没法继续担任 orchestrator。

orchestrator 不会消失

问题不是要不要 orchestrator，而是它由谁来扮演。orchestrator 这个角色一旦消失，每条线程会各自漂移，产出合不到一起。

不能再是人。那就是 harness 自己。卷二里 harness 的本质就是意图对齐的 orchestrator。它把一份顶层意图切分，分发到多个子空间，并保证每个子空间的执行都和原始意图对齐。

orchestrator 不能取代人的所有判断。顶层决策仍然必须留给人：项目方向的取舍、关键设计的权衡、产品形态的判断，这类决策的杠杆覆盖整个项目，一旦错了，后面的自动化只是在为错误的目标加速。orchestrator 的职责是把人保留下来的少量顶层决策准确传达到每个子空间，并把子空间内的局部决策 offload 给 AI。前者保证子空间不漂移，后者解放人的注意力。

这一章回答 orchestrator 在切分和传达上的具体做法。

一份 spec 不够分发

卷一规约的核心思想是把意图结构化、显式化、可执行化。这套思想在多线程下没变。变的是它要被切成多份，于是出现三个新问题。

切分的边界要按决策来划，不是按代码模块。代码模块是工程组织上的产物，模块边界和模块之间的关键决策落在哪里没有必然对应。两个 agent 各做一个模块，模块之间的关键决策没人负责，合起来时矛盾就暴露在边界处。决策边界和模块边界是两件事。

切完之后每个子空间必须自包含。多线程下子空间里的 agent 没办法回头查上层文档，卷一里靠分层省字、人去查上层的做法不再适用。每个子空间的 spec 必须把它需要的上层关键决策依据装在自己里面。这违反传统软件工程的 DRY 原则。DRY 服务的是文档维护成本，自包含服务的是分发后的对齐准确性。两者的优化目标不同。

拆分粒度由 attention 机制决定，不是经验感觉。一份 spec 长到一定程度，Agent 会开头结尾认真读、中间跳读。规约章的拆分不是为了好管，是为了让每一块 attend 得住。

这一章怎么展开

下面四节回答上面三个问题，最后用一个项目把答案串起来。

下一节讲决策边界。判断标准是杠杆，不是难度。把架构选型抛给非架构师等于没做这个决策，把每个函数命名拉来开会等于浪费杠杆。决策边界要识别两件事：哪些决策值得人参与，以及人有能力参与哪些决策。两个判定一起，才能定义出有效的人机分工。

之后讲自包含怎么具体落地。一个子空间的 spec 哪些信息必须装、哪些可以省、自包含和分层之间的张力怎么平衡。

再之后讲拆分粒度。把拆分这件事从感觉的工艺变成可量化的工程指标：每一块的内容能被 Agent 一次完整 attend，这是上限。

最后用一个具体项目走通从顶层意图到子空间执行的完整路径，把三个原则在一条流上串起来。

Harness Engineering Playbook · AgentsZone Community