auto-sync: 2026-06-04 22:03:57

docs/design/architecture-v3.0.md

@@ -1916,3 +1916,73 @@ PRAGMA busy_timeout=5000       # 写锁等待 5s
 | 16 | per-provider 冷却 | C6 | T8 |
 | — | Gateway 内部 session lock 竞争 | C7 | T2 (02 架构改造) |
 | — | TOCTOU 竞态 | C8 | T2 (02 架构改造) |
+
+---
+
+## §22. Pipeline 强工作流设计（TODO）
+
+> 2026-06-04 新增。基于 #12 Pipeline 设计专题讨论确认的方向。本节所有内容均为 **待实现**，标注 TODO。
+
+### 22.1 设计方向（2026-06-04 #12 讨论确认）
+
+#### 两种模式
+
+**自由模式（AI native）**：
+- 不指定 task_type → 广播认领
+- Agent 自主判断、自主认领、自主决定执行方式
+- Agent 是决策主体
+- 当前已实现
+
+**Pipeline 强工作流（TODO）**：
+- 指定 task_type → 确定性路由 + 状态机约束
+- 系统控制流程、指定执行者、规定步骤顺序
+- Agent 是执行主体，不是决策主体
+- 不走 claim，直接 assign
+- 引擎提示词需严格约束 Agent 行为边界，防止不可预料分支
+
+#### Pipeline 灵活流转
+
+- **顺序（sequence）**：A → B → C
+- **条件分支（branch）**：review 通过 → done，review 拒绝 → working
+- **退回（rollback）**：review 失败退回上一个 stage
+- **循环重试（loop）**：max_retries 控制
+
+#### 已确认的设计决策
+
+| # | 决策 | 内容 |
+|---|------|------|
+| D1 | Pipeline vs 自由模式二选一 | task_type 决定走哪条路 |
+| D2 | Pipeline 是强工作流，不可偏离 | Agent 必须按流程走 |
+| D3 | @mention 在 Pipeline 模式下只做通知不改变执行者 | 流程控制权在系统 |
+| D4 | task_type 默认 None（不指定 = 自由模式） | 向后兼容 |
+| D5 | 前端下拉 + Chat 入口 | 用户选择 Pipeline 模式 |
+
+#### 待深入设计的问题
+
+1. **提示词约束**：强工作流下提示词模板如何约束 Agent 不产生不可预料分支
+2. **模式共存**：自由模式和强工作流模式如何共存（同一系统、不同任务）
+3. **差异化需求**：两种模式对 Spawner/Ticker/Router 的差异化需求
+4. **排队处理**：Pipeline 任务直接 assign 后 Agent 忙时的处理（Spawner 排队 vs 升级）
+5. **错误处理**：强工作流下的错误处理（Agent 失败是流程回退，不是自主重试）
+
+#### 相关设计文档
+
+| 文档 | 说明 |
+|------|------|
+| `docs/design/12-pipeline-design.md` | Pipeline 设计专题 v2.1（已 approved） |
+| `docs/design/08-classify-outcome-optimization.md` | Classify Outcome v3.1 |
+| `docs/design/09-rebuttal-and-goal-gate.md` | Rebuttal 流程 |
+
+### 22.2 与现有架构的关系
+
+- **Router（§8.1）**：当前只有确定性路由 + 广播认领两种模式。Pipeline 需要新增按 task_type 匹配 Pipeline 定义的路由模式
+- **Ticker（§6.1）**：Pipeline 任务不走 `_broadcast_claim()`，走直接 assign + 状态机流转
+- **Spawner（§6.3）**：Pipeline 任务的 spawn prompt 需严格约束行为边界，防止 Agent 偏离流程
+- **状态机（§5.2）**：Pipeline 流转的 branch/rollback/loop 需要状态机支持更丰富的转换规则
+
+### 22.3 实施建议
+
+- 优先级：P2（核心架构增强，但不阻塞 T2 持续指挥）
+- 前置条件：T2 完成后再启动（避免与 Daemon 退化方向冲突）
+- 建议阶段：T4 审查体系完善之后，或独立为 T4.5
+- 里程碑：先实现单一顺序 Pipeline（A→B→C），再扩展条件分支