Skip to content
← 全部章节

章 05

代码仓库原型

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

DWP 识别两种原型。绝大多数代码仓库属于第一种；第二种则为需要协调多个仓库的团队而存在。

单一代码仓库

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

特征：

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

编排枢纽

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

特征：

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

归类判定法则

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

当代理发现多个嵌套的 git 仓库或子模块、一份所管理仓库的登记表或清单，或指向外部仓库的配置时，就应当把该仓库归类为编排枢纽。在缺乏这些信号的情况下，它会把该仓库当作单一代码仓库来对待——这是安全的默认选择，因为将计划的范围扩展到并不存在的边界之外，比在一个真实存在的边界内工作要糟糕得多。

接入有何不同

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

方面 单一 编排
范围 本仓库 多个仓库
接入 仓库结构 枢纽登记表
计划目标 本地文件 子计划
状态 本地 .dwp/ 跨仓库 .dwp/

其实际效果是：单一仓库代理会对一个代码库进行端到端的推理，而编排代理则对协调本身进行推理——哪个子仓库负责哪部分工作，以及跨仓库的状态如何保持一致。

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