让多个 Agent 协作完成一个长程任务——跨越多轮对话、多个文件、好几个小时——最大的敌人往往不是模型能力，而是上下文漂移：每个 Agent 看到的信息不一致，目标随着对话越走越偏，返工和误解随迭代不断累积。

规范驱动开发（Spec-Driven Development，SDD）给出的答案很直接：用一份可版本化的规范（spec）作为所有 Agent 的共享事实来源，把易失的对话上下文沉淀为持久、可引用的协议。本文给出一条可以今天就上手的最短路径。

为什么长程任务需要规范

长程任务天然和大语言模型的工作方式相冲突：

• 上下文窗口有限。任务一长，对话必然经历压缩与遗忘，早期的关键约定容易丢失。
• 并行的 Agent 互相看不见。多个 Agent 同时推进时，谁也看不到对方的中间决策。
• 没有共享事实来源，误解会复利。每一轮的小偏差叠加起来，最终偏离原始意图。

规范把”要做什么、为什么、边界在哪”写成结构化文本，放进仓库，让每个 Agent 在开工前先读、收工后回写。对话是易失的，规范是持久的——这就是长程协作的地基。

规范长什么样

规范是对系统需求与行为的自然语言描述，应当被版本管理，并与代码保持”最终一致”。它不需要笨重的工具，一个清晰、可预期的句式就够了。我们推荐用 GEARS 句式来写每一条规范：

[Where <静态前提>] [While <运行时状态>] [When <触发事件>] The <主体> shall <行为>。

例如：

When 用户提交表单，The 系统 shall 校验所有必填字段并返回首个错误。

需要记住三点：规范是迭代式的（与代码一起逐次成长，不是回归瀑布）；规范可以由 AI 起草（人给意图，AI 补细节）；规范与代码保持最终一致（先有意图，落地后回写）。

五步快速开始

1. 从一句话意图开始。 由人来写意图，先别急着写实现。一句”我想要什么、为什么”就足以启动。
2. 让 Agent 把意图起草成规范。 用 GEARS 句式输出条目，必要时配上决策记录（DR）与迭代记录（IR）。你只负责评审，而不是逐字撰写。
3. 拆成”一次提交大小”的任务。 把规范切成彼此独立、可单独提交的小任务，并标注依赖关系。颗粒越小，越好并行、越好回滚。
4. 多 Agent 分工执行。 每个 Agent 领一个任务，开工的第一个动作是读相关规范，把规范当作协议来执行，而不是自由发挥。
5. 收口并回写。 评审产物 → 把变更回写进规范以保持最终一致 → 更新索引（如 map.md），方便下一轮检索。

让多 Agent 不跑偏的几个实践

• 单一事实来源。 规范放在仓库里，而不是某一次对话里。
• 条目自包含。 每条规范不依赖别处的隐含上下文，需要引用时显式写明链接。
• 小步快跑。 任务切到一次提交大小，并行和回滚都更轻。
• 显式交接。 Agent 之间通过规范与 PR 交接，而不是把一长串对话原样转述给下一个 Agent。
• 先读后写。 每个 Agent 的第一个动作是读规范，最后一个动作是回写规范。

一个最小骨架

不必一上来就建一套庞大的体系。一个能跑起来的 specs/ 目录可以很小：

specs/
  decisions/   # 决策记录（DR）
  iterations/  # 迭代记录（IR）
  user/        # 面向用户可见行为的条目
  dev/         # 面向内部实现的条目
  map.md       # 索引，便于检索

从一条规范、一个迭代开始，让它随代码一起长大。

结语

规范不是额外负担，而是让”长程”成为可能的基础设施。当 AI 负责起草、人类负责评审时，写规范的成本-收益比已经发生反转：你用很低的代价换来一份所有 Agent 都能对齐的协议。

想更深入了解我们使用的规范句式，可以阅读 《GEARS：面向 AI 的规范语法》。