# moziplus v2.6 需求-设计一致性验证报告

**版本**: v1.0
**日期**: 2026-05-15
**作者**: 庞统（副军师）
**状态**: ✅ 验证完成，发现问题已记录
**范围**: PRD v1.0 + requirements-v3.md ↔ architecture-v2.6.md + technical-design-v2.6.md

---

## 0. 验证方法

1. 逐条比对 PRD 功能需求（F1-F12）与架构/技术设计的覆盖情况
2. 逐条比对铁律（IR-1~IR-4）的落地情况
3. 对照 MEMORY.md 中 v2.0 AI Native 共识，评估设计是否达标
4. 识别缺口、提出待讨论项和优化建议

---

## 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 轮上限）<br>❌ 无结构化评审结果（PRD 定义了 review_result JSON）<br>❌ 无 round/max_rounds 概念 |
| **F3 灵活编排** | Agent 可自主 claim 任务 | ❌ "庞统根据任务类型动态匹配参与者和流程"——智能拆解机制没有设计<br>❌ "动态扩展——发现需要谁就动态加入谁"——没有设计<br>❌ 协作模式表（串行/并行/讨论/协商/动态加入）没有对应设计 |
| **F6 自动化流转** | Daemon tick 有基本的 mention/blocked 处理 | ❌ "需求确认→自动拆解→自动分配→自动流转→自动挑战→自动汇总"链不完整<br>❌ 自动检查点（scope reduction detection）没有设计 |
| **IR-1 做加挑战** | 有 review 状态可触发司马懿 spawn | ❌ 没有强制"每个节点必须过挑战"的机制保障<br>❌ 挑战者池（PRD: 按任务类型匹配）未设计，只有固定司马懿 |
| **IR-2 Plan→Execute→Validate** | 只有一个 working 状态 | ❌ 没有设计任务内部的 plan/execute/validate 三阶段<br>❌ 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）：

```sql
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 安全红线）和前端集成是最紧迫的待讨论项。