原型

版本 1.1。 DWP 识别三种原型。原型决定了代理如何接入、计划如何界定范围，以及机器可读状态层是否为必要条件。

v1.1 新增（可向后兼容）。 代理工作区（§3）作为第三种原型加入：自主代理的长期驻地。Git 从假定存在变为 RECOMMENDED。v1.0 的两种原型不变。

单一代码仓库

一个自成一体的代码库——一个应用、一个库或一个服务。计划直接作用于代码。

特征：

• 单一、连贯的代码库。
• 计划修改本仓库中的文件。
• .dwp/ 工作区位于仓库根目录。

编排枢纽

一个管理多个子仓库的协调型仓库。计划可以在子仓库中派生出子计划。

特征：

• 协调多个子仓库。
• 计划可以委派给子计划。
• 维护一份所管理仓库的登记表。
• 位于枢纽根目录的 .dwp/ 工作区追踪跨仓库的状态。

代理工作区

代理工作区是自主代理的长期工作驻地——OpenClaw 工作区、Hermes 服务目录、个人助理守护进程的数据目录或云端代理的持久化卷。它是一个工作区，不一定是 git 代码仓库，其主要产物是代理正在进行的工作，而非某个代码库。

使这种原型成为可能的洞察：harness 是一个工作区，而非特定意义上的代码仓库。 该方法论为代码仓库定义的每个 harness 元素都有一个直接的工作区等价物：

代理工作区 MUST 在工作区根目录提供 AGENTS.md、.agents/ 与 .dwp/。

Git 为 RECOMMENDED，非 REQUIRED。 在没有 git 的情况下，每份计划 MUST 携带机器可读状态层：state.json 的检查点、关卡记录与逐任务时间戳，承担了 git 日志在代码仓库中所承担的恢复信息职责。

代理工作区中的计划通常以无人值守方式运行：计划中的心跳或 cron 轮次通过 DWP 恢复协议恢复未完成的计划，执行下一个原子任务，更新状态层，然后让出。计划——而非会话——是连续性的单元。

归类判定法则

Repository

? Multiple nested repos or a hub registry?

No

Individual repository

• single codebase
• plans modify local files
• .dwp/ at repo root

Yes

Orchestrator hub

• coordinates sub-repos
• plans delegate to child plans
• cross-repo .dwp/ state

当目标是自主代理平台的工作目录时，优先归类为代理工作区——信号：平台标识文件（如 OpenClaw 的 SOUL.md 或 HEARTBEAT.md）、无主要应用技术栈，以及内容主要为代理自身的状态。任意一个强平台信号即可。

否则，当以下大多数情形成立时，归类为编排枢纽：多个嵌套的 git 仓库或子模块；一份所管理仓库的登记表或清单；指向外部仓库的配置。否则归类为单一代码仓库——这是安全的默认选择。

当信号模糊时，代理 MUST 向用户呈现其判断与依据，并在继续之前请求确认。

接入差异