cfdaily
10 KiB
moziplus v2.6 需求-设计一致性验证报告
版本: v1.0 日期: 2026-05-15 作者: 庞统（副军师） 状态: ✅ 验证完成，发现问题已记录 范围: PRD v1.0 + requirements-v3.md ↔ architecture-v2.6.md + technical-design-v2.6.md
0. 验证方法
- 逐条比对 PRD 功能需求（F1-F12）与架构/技术设计的覆盖情况
- 逐条比对铁律（IR-1~IR-4）的落地情况
- 对照 MEMORY.md 中 v2.0 AI Native 共识，评估设计是否达标
- 识别缺口、提出待讨论项和优化建议
1. 需求与设计一致性分析
1.1 ✅ 覆盖良好的需求
| PRD 需求 | 设计覆盖 | 说明 |
|---|---|---|
| F1 任务主页 | 黑板 7 表（tasks/comments/outputs/decisions/observations/events/agents） | 完整，黑板即 Single Source of Truth |
| F5 结构化IO | CLI 操作全部结构化参数 | 完整，产出写入 outputs 表 |
| F11 消息传递 | 黑板评论 + @mention 完全替代 Mail | 比原来更好 |
| F12 编排引擎分离 | Daemon 是基础设施，庞统是 Agent 层 | 核心架构正确 |
| IR-3 全局视野 | Agent 读黑板了解全局 | 正确 |
| P1 传话游戏 | 黑板共享空间根治 | 核心痛点已解决 |
1.2 ⚠️ 部分覆盖但有缺口
| PRD 需求 | 现状 | 缺口 |
|---|---|---|
| F2 质量门禁 | 有 review 状态 + 司马懿 spawn 流程 | ❌ 无协商轮次追踪（PRD 要求 3 轮上限） ❌ 无结构化评审结果（PRD 定义了 review_result JSON） ❌ 无 round/max_rounds 概念 |
| F3 灵活编排 | Agent 可自主 claim 任务 | ❌ "庞统根据任务类型动态匹配参与者和流程"——智能拆解机制没有设计 ❌ "动态扩展——发现需要谁就动态加入谁"——没有设计 ❌ 协作模式表（串行/并行/讨论/协商/动态加入）没有对应设计 |
| F6 自动化流转 | Daemon tick 有基本的 mention/blocked 处理 | ❌ "需求确认→自动拆解→自动分配→自动流转→自动挑战→自动汇总"链不完整 ❌ 自动检查点（scope reduction detection）没有设计 |
| IR-1 做加挑战 | 有 review 状态可触发司马懿 spawn | ❌ 没有强制"每个节点必须过挑战"的机制保障 ❌ 挑战者池（PRD: 按任务类型匹配）未设计，只有固定司马懿 |
| IR-2 Plan→Execute→Validate | 只有一个 working 状态 | ❌ 没有设计任务内部的 plan/execute/validate 三阶段 ❌ PRD 铁律"每个节点都走三步"无法在状态机中体现 |
1.3 ❌ 完全未覆盖的需求
| PRD 需求 | 重要程度 | 说明 |
|---|---|---|
| F4 Dashboard 可视化 | 🔴 核心需求 | 架构文档完全没涉及前端。frontend-design-v3.md 单独存在但与 v2.6 架构没有集成设计 |
| F7 全生命周期覆盖 | 🟡 重要 | PRD 要求 需求→设计→编码→测试→部署→运维，当前只有通用 pending→done 状态，无生命周期阶段映射 |
| F8 工具链自动化 | 🟡 重要 | lint/test/build/deploy 自动化完全没涉及，这是"不只是个任务流转工具"的关键差异 |
| F9 Skill 生态 | 🟠 改善 | 架构只提 Phase 3 未来做，无最小规范设计 |
| F10 Web 前端平台 | 🟡 重要 | 无 |
| IR-4 安全红线 | 🔴 铁律 | 无危险操作检测、无审批流程、无三层模型实现 |
| 并行执行（F3/N6） | 🟡 重要 | 依赖解析和并行 spawn 没有详细设计 |
| 上下文管理 | 🔴 PRD §11 高风险 | PRD 明确标注"Agent 上下文膨胀"为高风险项，架构无 L1/L2/L3 三层记忆方案 |
1.4 覆盖率汇总
| 类别 | 覆盖良好 | 部分覆盖 | 未覆盖 | 覆盖率 |
|---|---|---|---|---|
| 功能需求 (F1-F12) | 4 | 3 | 5 | 33% 完全覆盖 / 58% 部分覆盖 |
| 铁律 (IR1-IR4) | 1 | 2 | 1 | 25% 完全覆盖 / 75% 部分覆盖 |
| 痛点 (P1-P8) | 1 | 4 | 3 | — |
2. AI Native 程度评估
评分：6/10
v2.6 相比 v2.0 有本质进步——从"给 AI 团队做 ERP"进化到"黑板 + Agent 自主决策"。但离真正的 AI Native 还有明显差距。
2.1 ✅ 做对的（AI Native 部分）
| 点 | 说明 |
|---|---|
| 黑板模式 | Agent 读黑板、想、做、写回。这是 AI Native 的核心范式 |
| Daemon 是投递员不是决策者 | 决策在 Agent 层，Daemon 只执行。这个分离完全正确 |
| Session 隔离 | 每次任务 spawn 新 session，避免上下文膨胀。解决了 v1 的核心痛点 |
| 评论线程协作 | Agent 间通过自然语言讨论 + @mention，比邮件更原生 |
| Agent 自主领活 | claim 机制让 Agent 主动选择，不是被动分配 |
2.2 ❌ 不够 AI Native 的
问题 1：编排层没有 AI 参与
MEMORY.md v2.0 共识："不只是执行节点里有 AI，编排/路由/渲染/异常处理/经验沉淀都要有 AI 参与"
当前 Daemon tick 是纯机械逻辑：检查 mention → spawn。没有任何 AI 参与：不判断任务优先级调整、不判断任务是否需要重新拆解、不判断 Agent 是否适合当前任务、不做异常根因分析。
问题 2：没有 Plan→Execute→Validate 纪律
PRD 铁律 IR-2 "每个节点都走三步"是 v2.0 的核心创新。当前设计只有 working 一个大状态，没有纪律约束 Agent 必须先 plan 再 execute。
问题 3：庞统的智能拆解没有机制保障
PRD 要求"庞统根据任务类型动态匹配参与者和流程"。当前设计只是"庞统创建 tasks"，但怎么保证庞统能做好拆解？靠提示词不够。
问题 4：质量门控不够结构化
PRD 定义了详细的 review_result JSON（severity/issues/suggestion），但架构只有"司马懿写评论通过/不通过"。挑战应产生结构化评审结果。
问题 5：没有经验沉淀闭环
PRD F9 和 MEMORY.md 都强调 DISCOVER→DISTILL→APPLY→IMPROVE 闭环。当前黑板的 observations/decisions 表只记录不蒸馏。
问题 6：人机交互不是 AI Native 的
PRD §8 的交互设计是用户主动看 Dashboard。AI Native 的方向应该是 v2.0 共识的 Phase 4 "主动汇报"——AI 推送关键信息，不等人查。
3. 待讨论问题清单
🔴 必须讨论（影响核心架构）
| # | 问题 | 说明 | 影响 |
|---|---|---|---|
| D1 | IR-2 Plan→Execute→Validate 如何落地？ | 铁律。改状态机加 sub_status？拆成子任务？完全靠 Agent Skill？每个方案开发量差异很大 | 状态机 + Agent 行为 |
| D2 | IR-4 安全红线如何实现？ | 铁律。需要至少：危险命令正则拦截 + 部署类任务审批暂停。最小实现方案？ | Daemon + 前端 |
| D3 | 挑战协商轮次如何追踪？ | PRD 要求 3 轮上限。tasks 表加 review_round 字段？用 events 日志算？ | 黑板 schema |
| D4 | 前端（Dashboard）与 v2.6 如何集成？ | v2.6 有独立 HTTP API（端口 8083），前端如何对接？改现有 v1 前端还是从零做？ | 前端架构 |
🟡 建议讨论（影响质量）
| # | 问题 | 说明 |
|---|---|---|
| D5 | Daemon tick 中是否引入 AI 决策？ | 纯机械 tick 够用还是需要 AI 判断？影响架构复杂度 |
| D6 | 60s tick 间隔是否太长？ | Agent 协作场景下，等 1 分钟才知道被 @。是否需要事件驱动（如 Redis pub/sub）？ |
| D7 | 庞统智能拆解的保障机制？ | 怎么确保庞统拆解质量？拆解本身是否过挑战？ |
| D8 | 上下文管理策略？ | Agent spawn 时传多少黑板信息？全传爆 context，只传摘要可能丢关键信息。PRD L1/L2/L3 方案何时落地？ |
| D9 | v1 前端（8082）如何过渡到 v2？ | v1 前端已有任务看板/详情/干预能力，v2 是否可以复用？ |
🟢 可以后讨论
| # | 问题 |
|---|---|
| D10 | 工具链自动化（F8）Phase 规划 |
| D11 | Skill 生态（F9）最小规范 |
| D12 | 经验沉淀闭环设计 |
| D13 | 全生命周期阶段映射（F7） |
4. 优化建议
4.1 状态机粒度增强
当前 8 个状态太粗，建议扩展以支持 IR-2：
pending → claimed → planning → plan_review → executing → exec_review → validating → done
↑ │ ↑ │
└──────────────┘ └──────────────┘
(plan被打回) (exec被打回)
这样铁律 IR-2 直接在状态机中强制执行。
4.2 评审结果结构化
黑板的 reviews 表应独立（不只是靠 comments）：
CREATE TABLE reviews (
id INTEGER PRIMARY KEY,
task_id TEXT,
reviewer TEXT,
round INTEGER,
verdict TEXT, -- approved/needs_revision/rejected
issues TEXT, -- JSON array
created_at TEXT
);
4.3 依赖推进机制
当前 depends_on 字段存在但没有设计自动推进逻辑。Daemon tick 需要检查：task-001 done → task-002 的 depends_on 全部 done → spawn task-002 的 assignee。
4.4 用户主动通知
最简方案：Daemon tick 检测到关键事件（任务 blocked、挑战 3 轮未通过、Agent 无响应），通过 OpenClaw cron 发消息给用户。
4.5 Phase 规划调整建议
当前 Phase 规划缺少前端和安全两个关键维度，建议调整为：
- Phase 1：黑板 + Daemon + CLI（当前设计 ✅）
- Phase 2：IR-2/IR-4 落地 + 评审结构化 + 依赖推进 + 前端 API
- Phase 3：前端 Dashboard（复用 v1 或新建）+ 用户通知
- Phase 4：AI 增强（Daemon AI 决策、智能拆解、经验沉淀）
5. 总结
| 维度 | 评分 | 说明 |
|---|---|---|
| 需求覆盖率 | 55% | F1/F5/F11/F12/IR-3 覆盖良好；F4/F7/F8/F9/F10/IR-2/IR-4 未覆盖 |
| AI Native 程度 | 6/10 | 黑板模式 + Agent 自主决策方向正确；但编排层无 AI、无纪律约束、无经验闭环 |
| 可落地性 | 7/10 | 技术方案扎实（已验证可行），Phase 1 开发量合理（~11h） |
| 主要风险 | — | 两项铁律（IR-2、IR-4）未落地；前端与 v2.6 集成方案未定 |
核心结论：v2.6 架构方向完全正确，从 DAG 状态机到黑板模式是质的飞跃。但当前设计更像是"黑板基础设施的技术方案"，还不是"moziplus v2.0 的完整设计"。两块铁律（IR-2 Plan-Execute-Validate、IR-4 安全红线）和前端集成是最紧迫的待讨论项。