代码仓库原型

在代理改动任何一行代码之前，它会先做出一个决定，而这个决定将影响此后的一切：**这是什么类型的代码仓库？**它所推断出的原型，界定了它在整个协作过程中的推理边界——它如何接入、计划的覆盖范围有多大，以及状态保存在哪里。判断错误，代理就会把工作范围限定到错误的对象上，这是长周期任务中最常见的漂移根源。判断正确，它就能自主运转数小时，因为计划、接入与状态都与代码的真实形态保持一致。

DWP 识别三种原型。绝大多数代码仓库属于第一种；第二种则为需要协调多个仓库的团队而存在；第三种涵盖自主代理的长期工作区。

独立仓库

一个自包含的代码库

编排中枢

协调子仓库

单一代码仓库

最常见的情形：一个自成一体的代码库——一个应用、一个库或一个服务。只有一个连贯的对象面需要推理，因此计划直接作用于仓库中的代码，接入则读取仓库自身的结构与约定。代理将整个代码库作为其上下文，并对其进行端到端的处理。

特征：

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

编排枢纽

协调型场景：一个以管理其他代码仓库为职责的仓库。此时的工作单元不是文件，而是子仓库——计划可以在子仓库中派生出子计划，接入则读取枢纽中所管理仓库的登记表，而非单一代码库。代理推理的是边界与交接——哪个仓库负责哪部分工作，以及它们的状态如何保持一致。

特征：

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

代理工作区

第三种原型，在 v2.2 中新增，描述的是一种先于代码仓库存在的工作区：自主代理的长期驻地。OpenClaw 工作区、Hermes 服务目录、个人助理守护进程的数据目录、云端代理的持久化卷——每一个都有要执行的计划、要使用的工具和要维护的记忆，但不一定有需要交付的代码库。

关键洞察是：harness 是一个工作区，而非特定意义上的代码仓库。 DWP 安装进代码仓库的每个元素——AGENTS.md、docs/、.agents/、.dwp/——都有一个直接的工作区等价物。该方法论的层面对应得非常清晰：常态上下文文件取代根目录的 AGENTS.md，平台技能目录取代 .agents/，工作区根目录下的 .dwp/ 文件夹保持不变。发生变化的是 git 的角色。在代码仓库中，git 日志承载状态，使计划可跨会话恢复。在没有 git 的工作区中，state.json 承担这一职责——这也是为何机器可读状态层对代理工作区是必要条件。

实际收益是夜间无人值守计划。在 OpenClaw 类平台上，心跳或 cron 轮次唤醒代理，运行 DWP 恢复协议，执行下一个原子任务，更新 state.json，然后让出。计划——而非会话——是连续性的单元。多日计划历经重启、模型更换与会话边界而仍能存续，因为下一轮次所需的一切都在计划文件中：目标、已勾选的进展、关卡记录，以及当前任务内的确切检查点。

特征：

• 自主代理平台的工作目录。
• 工作区根目录提供 AGENTS.md、.agents/ 与 .dwp/。
• Git 为 RECOMMENDED，非 REQUIRED。
• 在没有 git 时 state.json 为必要条件，任何无人值守运行亦然。
• 计划通常以无人值守方式运行，由计划中的心跳或 cron 驱动。

归类判定法则

三种原型在磁盘上呈现出不同的面貌，代理根据它能够核实的信号在三者之间做出判断——而非被告知的标签。下方的决策树展示了判断路径；简而言之，当存在平台标识信号时归类为代理工作区，仅在证据确凿时才归类为编排枢纽，否则一律视为单一代码仓库。

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 仓库或子模块、一份所管理仓库的登记表或清单，或指向外部仓库的配置。在两者均缺失的情况下，将目标视为单一代码仓库——这是安全的默认选择，因为将计划的范围扩展到并不存在的边界之外，比在一个真实存在的边界内工作要糟糕得多。

接入有何不同

原型并非装饰性的标签；它改变了代理读取的内容、计划可以触及的范围，以及状态的记录位置。

其实际效果是：单一仓库代理会对一个代码库进行端到端的推理，编排代理对跨代码仓库的协调进行推理，而代理工作区代理则对跨会话的连续性进行推理——规划了什么、运行了什么、阻塞在哪里，以及接下来是什么。

这正是让代理得以在无人监督下自主工作数小时的关键所在：通过首先确定原型，它把计划、接入与状态界定到正确的边界上，于是代理从第一项任务到最后一项都在正确的对象面上运作。