auto-sync: 2026-05-28 08:12:08

docs/design/architecture-v3.0.md

@@ -148,10 +148,13 @@ v2.0 的核心是 **DAG 引擎 + 状态机 + 邮件通信**，本质是给 AI
 
 | 方面 | PRD 目标 | 实际状态 |
 |------|---------|---------|
-| 苏格拉底式对话 | 需求探索的核心入口 | ❌ 未实现 — 无独立的"需求探索"阶段，任务直接创建 |
-| 多轮需求澄清 | 庞统通过对话帮用户梳理需求 | ⚠️ Agent 对话中可实现，但无专门机制 |
+| 苏格拉底式对话 | 需求探索的核心入口 | ✅ 已有 skill — `requirement-clarification`（加权模糊度评分 + 节奏守卫 + 停止守卫） |
+| 多轮需求澄清 | 庞统通过对话帮用户梳理需求 | ✅ 已有 skill — `requirements-analysis`（需求规格化 + 假设标注 + 交付物定义） |
+| 需求探索自动触发 | PRD Phase 1 自动启动 | ❌ 未实现 — Skill 存在但无 Daemon 自动触发机制 |
 
-**差距**: PRD 描述的四相循环（需求探索→动态规划→自主执行→主动汇报）中，Phase 1 需求探索完全依赖 Agent 对话能力，平台没有提供专门的需求探索 Skill 或流程。
+**现状**: Skill 层面完备（`requirement-clarification` + `requirements-analysis` 覆盖需求澄清全流程），但编排层面缺少自动触发。当前依赖 Agent 手动加载 Skill 或用户显式触发。
+
+**差距**: 需要一个"需求探索"入口，当用户提一个模糊方向时，自动触发苏格拉底式对话。可在庞统主 session 通过 Skill 匹配实现，或在 Dashboard 新建任务时自动引导。
 
 ### 3.2 B2: 编排层是 AI 指挥官 ✅
 
@@ -508,9 +511,9 @@ Ticker.tick()
 
 | 设计文档 | 实际代码 | 状态 |
 |---------|---------|------|
-| 广播认领 (v3.0-router-refactor) | Router 模糊场景直接 delegate 庞统 | 🔀 广播认领设计未实现，改为确定性路由 + delegate |
+| 广播认领 (v3.0-router-refactor) | 认领基础设施完整，`_broadcast_claim()` 未实现 | ⚠️ 待探讨实施时机 |
 | Session 存档清理 | spawner 有 `_sessions` 注册表但清理逻辑未完整集成 | ⚠️ |
-| L2 Subagent spawn | `AgentSpawner` 注释了 Subagent 但未实现 | ❌ 只有 Full Agent spawn |
+| L2 Subagent spawn | `spawner.spawn_subagent()` 存在但标注 TODO: F17 | ⚠️ 骨架已有 |
 | `_parse_stdout_json` P0 修复 | 代码已修正为 `data["response"]["meta"]` 路径 | ✅ 已修复 |
 
 ---
@@ -549,7 +552,7 @@ Ticker.tick()
 }
 ```
 
-**Title 自动生成** ✅: 调用 zhipu GLM-4-flash 生成简短标题。
+**Title 自动生成** 👻 BUG: `blackboard_routes._generate_title()` 直接用 OpenAI client 调 zhipu API 生成标题（不走 Gateway），绕过了 Gateway 统一路由 + 计费。与 v3.0 删除 LLMDriver 的目标矛盾。应改为走 Gateway API 或前端传 title（当前前端已支持）。
 
 ### 7.2 CLI 工具 ✅
 
@@ -635,15 +638,19 @@ route(task_info, action_type):
 - `set_cooldown(agent_id, seconds=120)`: API 429 后冷却
 - `is_cooling_down(agent_id)`: 检查冷却状态
 
-### 8.3 广播认领 ❌
+### 8.3 广播认领 ⚠️（待进一步探讨）
 
-**设计文档 (v3.0-router-refactor)**:
-- 广播所有空闲 Agent → 自主 claim → 续杯兜底
+**设计文档 (v3.0-router-refactor §3.3)**:
+- 确定性路径：已知下一步谁做 → 直接 spawn
+- 广播认领路径：不确定 → spawn 所有空闲 Agent → 自主 claim
+- 无人认领 → claim_timeout (5min) → pending → 再广播 → 庞统兜底
 
 **实际代码**:
-- ❌ `_broadcast_claim` 未实现
-- ✅ 模糊场景直接 delegate 庞统
-- 🔀 设计要求"Agent 自主领活"，实际是"Router 决定 + delegate"
+- ✅ 认领基础设施完整：claim API (CAS 原子操作) + claim_task() + claim_timeout
+- ❌ `_broadcast_claim()` 调度逻辑未实现
+- ✅ 模糊场景直接 delegate 庞统（临时替代方案）
+
+**方向**: 广播认领是 v3.0 的设计目标，待进一步探讨实施时机和方案。
 
 ---
 
@@ -681,10 +688,10 @@ route(task_info, action_type):
 **实现状态**:
 - ✅ ReviewPipeline 验证链
 - ✅ reviews 表 + verdict 字段 (approved/rejected/needs_revision)
-- ❌ 方案审查 (plan_review) 协议未集成到 Daemon 流程
-- ❌ 反驳权 (Rebuttal Phase) 未自动化
-- ❌ 审查协议注册表 (review_protocols/) 未集成
-- ❌ 对抗辩论模式未实现
+- ⚠️ 方案审查 (plan_review) — reviews 表支持 plan_review 类型 (db.py REVIEW_TYPES)，但 Daemon 流程未自动触发方案审查
+- ✅ 反驳权 — RebuttalManager (review.py) + 8 种 comment_type 含 rebuttal/debate 系列 + 前端 UI 支持
+- ❌ 审查协议注册表 (review_protocols/) 未实现 — bootstrap.py 有 `_load_review_protocols` 但 review_protocols/ 目录不存在
+- ❌ 对抗辩论模式未实现 — 无自动 spawn 正反方辩论
 
 ### 9.3 Guardrail 安全红线 ✅
 
@@ -810,11 +817,11 @@ route(task_info, action_type):
 - ✅ Mail spawn 时系统自动标 working
 - ✅ Mail 续杯专用 prompt (不含状态转换指令)
 
-### 12.2 与 v2.6 设计的关系 🔀
+### 12.2 与 v2.6 设计的关系 ✅（已澄清）
 
-**v2.6**: "Mail 完全退役，黑板替代所有功能"
+**v2.6 原文**: "Mail 完全退役，黑板替代所有功能" — 这里的 Mail 指的是 **sanguo_mail**（旧邮件系统），已被 v2.0 黑板完全替代。
 
-**实际**: Mail 作为 `_mail` 虚拟项目保留，功能完整。这是正确的工程决策——Mail 提供了 Agent 间的异步通信能力，黑板更适合任务级协作。
+**当前 Mail Tab**: 是 moziplus v2 内置的飞鸽传书功能（`_mail` 虚拟项目），是全新的实现，与 sanguo_mail 无关。两者不是同一个系统。
 
 ---
 
@@ -906,11 +913,11 @@ CREATE TABLE experiences (
 
 **实际**: ❌ 未实现。tasks 表无 `verification_commands` 字段。
 
-### 14.3 Runaway Guard ❌
+### 14.3 Runaway Guard ⚠️
 
 **设计 (v2.6.9 借鉴3)**: 每个任务最大 tick 上限 (max_ticks=100)，超限暂停 + 告警。
 
-**实际**: ❌ 未实现。tasks 表无 `tick_count` / `max_ticks` 字段。
+**实际**: ⚠️ 部分实现。Ticker 有 `max_ticks` 参数（当前用于测试，限制 Ticker 自身运行次数），但不是 per-task 的 Runaway Guard。tasks 表无 `tick_count` / `max_ticks` 字段。需要扩展为 per-task 粒度。
 
 ---