From ba40bbefe5ef6a9fa5141008441a1c63f3713ce9 Mon Sep 17 00:00:00 2001 From: cfdaily Date: Thu, 28 May 2026 08:12:08 +0800 Subject: [PATCH] auto-sync: 2026-05-28 08:12:08 --- docs/design/architecture-v3.0.md | 49 ++++++++++++++++++-------------- 1 file changed, 28 insertions(+), 21 deletions(-) diff --git a/docs/design/architecture-v3.0.md b/docs/design/architecture-v3.0.md index 685d1fa..d5a9975 100644 --- a/docs/design/architecture-v3.0.md +++ b/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 粒度。 ---