docs: 明确子代理无新证据停止条件

2026-07-16 09:38:38 +02:00
parent 7f32a33938
commit e1787fbd24
2 changed files with 7 additions and 1 deletions
@@ -86,6 +86,11 @@ description: UniDesk 主代理调度子代理的必读技能。用户提到子
  - 用户允许子代理实施、要求并行或启用多轮审查，不等于允许调度审核子代理；
  - 只有用户明确要求子代理审核、独立审核代理或多代理交叉审核时，才允许派发审核型子代理；
  - 主代理发现问题后，直接形成纠偏要求；实现返工默认派给新的 task/session，不新增审核代理，也不把返工 send 给原执行 session。
+- 子代理执行必须遵守停止条件：
+  - 只有每次定位、修复或复测都产生新证据，且所依赖基础设施保持可靠时，才继续小闭环；
+  - 同一失败连续重复且没有新证据时，停止继续试错、叠加补丁或拆更深任务；
+  - 发现派单、构建、测试、部署或观测基础设施不可靠时，停止业务任务并报告已验证证据、影响范围和恢复条件，不得用人工补跑伪造成功；
+  - 停止后由主代理判断是等待基础设施恢复、建立独立基础设施 issue，还是在用户新增授权后改走其他路径。
 - 管理性、决策性文档由主代理直接完成，不把决策权或治理写入外包给子代理：
  - 主代理负责 `AGENTS.md`、skill 核心规则、长期 reference 规范、架构决策、主 issue anchor/closeout，以及 MDTODO FILE 的领域划分、ITEM 结构和状态治理；
  - 子代理可以在已明确的 issue、MDTODO ITEM 和验收边界内独立调研，并编写对应任务报告、验证记录、实现说明和证据附件；
@@ -105,7 +110,7 @@ description: UniDesk 主代理调度子代理的必读技能。用户提到子
 - 每个子代理 prompt 必须写清 repo、目标分支、独立 worktree、issue/PR、禁止触碰范围、验收命令、证据字段和是否允许部署；不要让多个子代理共享同一可写 worktree。
 - 用户指定模型时，Artificer 通过正式 model/reasoning 调度参数显式覆盖；原生子代理才在任务描述或原生调度参数中遵守。两类调度都不得用 prompt 约定 API credential。
 - 用户要求或授权“按任务难度分配模型”时，主代理必须按复杂度选择模型与 reasoning effort，并在 prompt 中写明选择理由；默认继承主模型，只有任务难度、风险或延迟收益明确时才显式覆盖。
- 执行型子代理必须能在自己负责的边界内完成“单步验证 -> 定位 -> 最小修复 -> 复测 -> PR/issue 证据”的闭环；这里的“单步验证”必须是可独立触发、独立执行、独立复测的入口，不是在端到端大循环中被动观察某个阶段。子代理不应停留在解释历史数据或等待主代理逐步批准；在授权边界内应自主真实触发目标侧独立单步 gate 做小闭环调优，测不通就继续细分/修复/复测，直到该单步通过或遇到明确越界阻塞。除非遇到架构边界、权限缺失或需要主代理合并/取舍，不要把每个单步验证都退回主代理通过 issue 大回环推进。
+- 执行型子代理必须能在自己负责的边界内完成“单步验证 -> 定位 -> 最小修复 -> 复测 -> PR/issue 证据”的闭环；这里的“单步验证”必须是可独立触发、独立执行、独立复测的入口，不是在端到端大循环中被动观察某个阶段。子代理不应停留在解释历史数据或等待主代理逐步批准；在授权边界内应自主真实触发目标侧独立单步 gate 做小闭环调优。只有每轮产生新证据且基础设施可靠时才继续；同一失败重复无新证据、基础设施不可靠、架构边界、权限缺失或需要主代理合并/取舍时立即停止并报告，不把每个单步验证退回主代理做无界大回环。
 - 需要提交 PR 的子代理必须在 PR 前自行用相关独立单步跑通目标运行面验证并保存 bounded 证据；测不通就继续定位和修改，直到该单步在目标侧通过。只有权限、外部依赖、架构取舍或明确越界时才写 issue 阻塞/缺口，不得先提交 PR 让主代理或自动 follower 替自己联调。
 - 主代理 review 子代理 PR 时直接信任子代理对运行结果、target-side gate 和 evidence 的描述；主代理只审核 diff、架构边界、受控入口、YAML-first、职责拆分和是否违反长期规则。除非描述自相矛盾、缺失关键字段或涉及安全/生产高风险，不要重复拉运行面证据或替子代理重跑 gate。
 - 子代理完成后必须留下可审查工件：PR、issue comment、commit、验证输出摘要、部署/observer/trace 证据或阻塞说明；主代理不能只凭口头结论合并。
@@ -11,6 +11,7 @@
 - 只有低耦合任务才并行：不同 worktree、不同模块或不同 issue，产物可以独立 review，失败不会阻塞其他任务继续产出证据。
 - 高耦合任务先串行定锚：公共类型/契约、source-of-truth、请求治理 authority、共享 runtime policy、同一大文件或同一状态机的修改，应先由主代理或一个子代理形成基线，其他子代理基于基线继续。
 - 任务要按成功率分层：调查、工具增强、业务修复、验证、PR review、上线 closeout 可以并行，但“修同一个根因的两套实现”通常不应并行。
+- 同一验证或修复连续重复失败且没有新证据时，子代理必须停止继续试错；派单、构建、测试、部署或观测基础设施不可靠时也必须停止，并在子 issue 留下已验证证据、影响范围和恢复条件，不得以人工补跑或更深任务层级掩盖阻塞。
 - 主代理需要持续调度，而不是把多个子任务排队串行执行。用户明确要求并行且任务在不同 worktree 时，应同时派发能并行的子任务，并通过 issue/PR 状态汇总。
 - 主代理必须维护可安全并发窗口：
  - 从原始任务建立依赖图，区分串行定锚、已就绪任务和等待依赖任务；