Use single-agent workflow
This commit is contained in:
+12
-21
@@ -1,13 +1,13 @@
|
||||
# 任务文件(一任务一文件 · 默认任务管理方式)
|
||||
|
||||
> 本目录是项目任务的**默认存放位置**:每个任务一个文件 `docs/tasks/T-<编号>.md`,单 agent 与多 agent 并发通用。
|
||||
> 本目录是项目任务的**默认存放位置**:每个任务一个文件 `docs/tasks/T-<编号>.md`。当前项目使用单 Agent 串行执行。
|
||||
> 阶段划分、里程碑和待办池见路线图 [`../06-tasks.md`](../06-tasks.md);路线图只读,不跟踪单任务状态。
|
||||
|
||||
## 为什么默认一任务一文件
|
||||
|
||||
- **单 agent**:领任务只读一个文件就拿到完整上下文(背景、方案、验收、执行记录),不用在看板、进度流水、快照三个共享文件之间跳转同步;执行记录和任务绑定,审查时 `git log -p` 一个文件即可回放全程。
|
||||
- **多 agent 并发**:单个大看板 + 多写者 = **编辑竞争**(读到旧版本、反复重读)、**ID 撞号**(全局递增号是共享计数器)、**合并冲突**(相邻行改动)。一任务一文件后:改哪个任务只动哪个文件,agent 之间互不抢占;ID 撞号在**新建文件时当场暴露**(文件已存在就换号)。
|
||||
- **零迁移**:项目从单 agent 长到多 agent,无需切换任何约定。
|
||||
- **低上下文成本**:一任务一文件让单 Agent 只读取当前任务规格和执行记录,减少跨文件同步与重复检索。
|
||||
- **保留扩展性**:如果未来由用户明确重新启用多 Agent,现有任务文件仍可作为写路径和依赖边界;重新启用前必须先更新并提交协作规则。
|
||||
|
||||
## 文件命名与 ID
|
||||
|
||||
@@ -46,28 +46,19 @@ write_paths: # 允许修改的仓库相对路径
|
||||
|
||||
## 领取 / 完成流程
|
||||
|
||||
- 状态:`TODO` · `DOING` · `DONE` · `BLOCKED`。每个 agent 同时最多一个活跃任务;项目可以并行多个写路径互不重叠的任务。
|
||||
- 每个 agent 一次只领一个 `status: TODO` 且依赖全 `DONE` 的任务,取编号最靠前的;若本目录暂无可领任务,先按路线图把下一个建议任务落成任务文件,再领取。
|
||||
- `write_paths` 必须在动手前写清。两个活跃任务路径相同,或一条是另一条的目录前缀,均视为冲突,不能并行。
|
||||
- 状态:`TODO` · `DOING` · `DONE` · `BLOCKED`。项目同一时间只保留一个活跃任务。
|
||||
- 单 Agent 一次只领一个 `status: TODO` 且依赖全 `DONE` 的任务,取编号最靠前的;若本目录暂无可领任务,先按路线图把下一个建议任务落成任务文件,再领取。
|
||||
- `write_paths` 必须在动手前写清,用于约束本任务允许修改和提交的路径。
|
||||
- 做完自测、按「passing 需证据」把验证命令与结果写清、改 `status: DONE`。
|
||||
- **执行记录写进本任务文件的 `## 执行记录` 一节**(改了什么、跑了什么验证、结果、决策)——不逐任务追加共享的 `progress.md`(可选历史归档)、也不逐任务覆盖 `current-state.md`(项目级快照,只在启动/验证路径、目录结构或 blocker 变化时更新)。
|
||||
- **只改自己那个任务文件**;不要编辑别人正在做的任务文件。
|
||||
- **只改当前任务文件**;不要顺带修改其他任务的状态或执行记录。
|
||||
|
||||
### 同一任务的多 Agent 模式
|
||||
### 当前单 Agent 模式
|
||||
|
||||
当任务本身不能安全拆成互不依赖的写路径时,使用“单写入者 + 多只读审查者”:
|
||||
|
||||
1. coordinator 先落成任务文件并提交,明确唯一写入 Agent、只读测试 Agent、只读安全/架构 Agent。
|
||||
2. 写入 Agent 独占任务 `write_paths`;只读 Agent 不调用文件编辑、`git add`、`git commit` 或会改变仓库状态的命令。
|
||||
3. 只读 Agent 返回可复现的测试矩阵、风险和审查意见;coordinator 决定是否采纳并由唯一写入者或 coordinator 修改。
|
||||
4. 所有意见合并后由 coordinator 跑任务完整闸门、更新执行记录并创建唯一任务提交。
|
||||
|
||||
若要让多个 Agent 并行写代码,必须先:
|
||||
|
||||
- 拆成带后缀的独立任务文件(如 `T-301a.md` / `T-301b.md`)。
|
||||
- 先完成并提交共享接口/协议冻结任务。
|
||||
- 确保依赖均 DONE,且 `write_paths` 互不重叠、没有目录前缀包含关系。
|
||||
- 每个子任务独立状态、验证证据和 Git 提交;最后另设串行集成任务。
|
||||
1. 当前 Agent 负责从任务落文档到最终提交的完整生命周期,不启动或委派子 Agent。
|
||||
2. 测试设计、安全检查、代码审查和提交前复核由当前 Agent 分阶段执行,结果统一写入任务执行记录。
|
||||
3. 前一个任务达到 `DONE`、完整验证通过并提交后,才正式落成或领取下一个依赖任务。
|
||||
4. 若用户以后明确恢复多 Agent,必须先修改并提交 `AGENTS.md`、本文和当前任务的协作约束;在该文档提交之前不得启动子 Agent。
|
||||
|
||||
未启用 Gitea 时,在独立分支 / worktree 中把任务文件从 `TODO` 改为 `DOING` 即可。启用 Gitea 时,必须先按 [`../gitea-collaboration.md`](../gitea-collaboration.md) 由 dispatcher 串行分配并创建 `claims/T-<编号>` 防御性标记;assignee、标签、读回和普通 create-branch API 都不能单独提供并发互斥。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user