cfdaily
204 lines
10 KiB
Markdown
204 lines
10 KiB
Markdown
# 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 安全红线）和前端集成是最紧迫的待讨论项。
|