sanguo_moziplus_v2/docs/research/v2.6-research-01-ai-decision-experience.md

# 调研报告：AI 决策者参与 + 经验沉淀闭环

> 调研时间：2026-05-15
> 调研范围：Hermes v0.13、Claude Code Agent Teams、GSD Wave Execution、OpenAI Agent SDK Guardrails、MetaGPT、nuwa-skill、claude-mem 等

---

## 课题 1：AI 决策者有效参与

### 1.1 已有经验（知识库/wiki）

知识库中无直接相关的实践经验。知识库主要包含 OpenClaw Agent 模板（awesome-openclaw-agents），其中涉及 coordinator 模式的有：
- `family-coordinator/SOUL.md`：家庭协调员模式，但偏向任务调度而非质量门控
- `incident-responder/README.md`：事件响应模式，有升级机制但非实时决策参与

**结论**：需要从业界实践中提炼适合 moziplus Blackboard 架构的决策者参与机制。

### 1.2 业界优秀实践对比表

| 项目 | 架构模式 | 决策者角色 | 防偏离机制 | 防蔓延机制 | 故障处理 | 介入时机 |
|------|----------|-----------|-----------|-----------|---------|---------|
| **Hermes v0.13** | Kanban Board（持久多 Agent 看板） | 无显式 coordinator，靠系统级保护 | 幻觉门控（Hallucination Gate）：验证完成声明才关闭任务 | Per-task retry budget 限制单任务重试次数 | 僵尸检测 + 自动回收 + 不完整退出自动阻塞 | 心跳超时 → 回收；幻觉检测 → 阻塞关闭 |
| **Claude Code Agent Teams** | Lead + Teammates（coordinator 模式） | Lead Agent 负责：分解任务、分配、监控输出、解决冲突 | Lead 监控每个 subagent 输出，解决依赖冲突 | Task decomposition 即为范围限定，subagent 只拿相关 context | Subagent 失败由 Lead 感知并处理 | 每个 subagent 完成时介入审查 |
| **GSD (get-shit-done)** | Planner → Executor → Verifier 三角色 | Planner 做分解和验证计划；Verifier 做独立验收 | must_haves（前置条件）+ goal-backward verification（目标回溯验证） | 每个 task 有原子 commit，可独立 revert | Verifier 独立 context 验收，不通过则生成 fix plan | Executor 完成后 Verifier 独立审查 |
| **OpenAI Agent SDK** | Guardrails 模式 | 无显式 coordinator，靠 input/output guardrails | Input guardrail：并行执行输入检查，快速失败 | Output guardrail：验证 agent 输出合规性 | Tripwire 机制：检测到违规立即中断 | 每次 agent 输入/输出时并行检查 |
| **MetaGPT** | SOP 编码 + Role-based | Engineer Agent 作为隐式 supervisor，每个 role 按 SOP 产出 | 共享消息池（Message Pool），Agent 监控环境观察 | SOP 编码为 prompt 序列，严格定义每步产出 | 每个 Agent 发布消息到共享池，下游 Agent 可拒绝不符合规范的输入 | 每个角色产出时，下游消费者隐式审查 |

### 1.3 关键机制深度分析

#### 1.3.1 Hermes v0.13 — 系统级韧性（不依赖 coordinator）

Hermes v0.13 的核心创新是"不信任 Agent 的完成声明"，通过多层系统级保护确保任务完整性：

- **心跳检测（Heartbeat）**：Agent 领取任务后必须定期发送心跳，超时未发送则标记为"可能停滞"
- **僵尸检测（Zombie Detection）**：检测已分配但长时间无进展的任务，自动标记
- **回收机制（Reclaim）**：僵尸任务被回收回看板，可被其他 Agent 重新领取
- **幻觉门控（Hallucination Gate）**：Agent 声称"完成"时，系统验证实际产出（如补丁是否真正落地），验证通过才关闭任务
- **Per-task Retry Budget**：每个任务有独立重试预算，防止单任务无限循环
- **不完整退出自动阻塞（Auto-block）**：Agent 异常退出时自动阻塞该任务，不会静默失败

**适用场景**：适合 moziplus Daemon 层面的保护机制——Daemon 不做决策，但做系统级保护。

#### 1.3.2 Claude Code Agent Teams — Lead 主动协调

Claude Code 的 Agent Teams 模式采用显式 Lead（coordinator）：

- **Lead Agent** 职责：
  1. 接收用户需求并分解为子任务
  2. Spawn teammates，每个 teammate 拿到特定 context
  3. 监控各 teammate 输出
  4. 解决 teammate 间的依赖冲突
  5. 合成最终结果
- **关键约束**：Lead 通过 `Agent(agent_type)` 语法限制可 spawn 的 subagent 类型
- **Context 隔离**：每个 subagent 只拿到相关 context，防止信息泄露和范围蔓延
- **配置示例**：
  ```yaml
  --- 
  name: coordinator
  description: Coordinates work across specialized agents
  tools: Agent(worker, researcher), Read, Bash
  ---
  ```

**适用场景**：适合 moziplus 中庞统作为 coordinator 的角色定义。

#### 1.3.3 GSD Wave Execution — 三角色流水线

GSD 的核心是 Planner → Executor → Verifier 的严格流水线：

- **Planner**：
  - 输出 PLAN.md（含 must_haves 前置条件）
  - 依赖分析 + wave 分组（同 wave 并行执行）
  - goal-backward verification（从目标回推验证计划完整性）
- **Executor**：
  - 每个 task 获得独立 200k token context
  - 原子 commit（每个 task 独立提交）
  - 不读其他 executor 的 context
- **Verifier**：
  - 独立 context 审查
  - 读取 SUMMARY + must_haves 验证
  - 不通过则输出 fix plan，可直接重执行

**适用场景**：适合 moziplus 的"分阶段编排"模式，特别是需要质量门控的场景。

#### 1.3.4 OpenAI Agent SDK Guardrails — 并行验证层

OpenAI 的 Guardrails 不依赖特定角色，而是通过 input/output 两层验证：

- **Input Guardrail**：在 agent 执行前并行检查输入（如注入检测、范围校验）
- **Output Guardrail**：在 agent 输出后验证合规性
- **Tripwire**：检测到严重违规时立即中断执行
- **关键原则**：验证逻辑放在产生副作用的地方，而非仅靠 agent 级别的 input/output guardrail
- **并行执行**：guardrail 与 agent 执行并行，不阻塞正常流程

**适用场景**：适合 moziplus 黑板上的"观察者"模式——在黑板写入时并行验证。

### 1.4 推荐方案（结合 AI Native 目标）

基于以上分析，推荐采用 **"系统保护层 + Coordinator 主动介入" 双轨制**：

#### 方案架构

```
┌─────────────────────────────────────────────────┐
│                Blackboard (黑板)                  │
│  observations | decisions | tasks | experiences  │
└──────────┬──────────────────────────┬───────────┘
           │                          │
  ┌────────▼────────┐      ┌────────▼────────┐
  │  Daemon 保护层    │      │ Coordinator 层   │
  │  (系统级，不决策)  │      │ (庞统，主动决策)  │
  │                  │      │                  │
  │ • 心跳检测        │      │ • 任务分解验证    │
  │ • 僵尸回收        │      │ • 输出质量审查    │
  │ • 幻觉门控        │      │ • 冲突调解        │
  │ • Retry budget   │      │ • 范围仲裁        │
  └─────────────────┘      └─────────────────┘
```

#### 具体机制设计

**第一层：Daemon 系统保护（类似 Hermes）**

| 机制 | 触发条件 | 行为 |
|------|---------|------|
| 心跳检测 | Agent 领取节点后 N 分钟无更新 | 标记为"停滞" |
| 僵尸回收 | 停滞超过阈值 | 回收任务到待分配池 |
| 幻觉门控 | Agent 提交完成声明 | 验证 output.md 是否存在且非空，验证结论 JSON 格式正确 |
| Retry Budget | 单节点重试超过 N 次 | 标记为失败，通知 coordinator |

**第二层：Coordinator 主动介入（类似 Claude Code Lead + GSD Verifier）**

| 介入时机 | 介入方式 | 说明 |
|---------|---------|------|
| 任务创建时 | 分解验证 + must_haves 定义 | 确保每个节点任务有明确的成功标准 |
| 节点产出时 | 输出审查 + 范围校验 | 检查是否偏离原始需求 |
| 依赖冲突时 | 仲裁 + 调解 | 解决 Agent 间的矛盾输出 |
| 节点失败时 | 根因分析 + 重规划 | 决定是重试、降级还是放弃 |
| 任务完成时 | 整体验收 + 经验提取 | 运行 Verifier 角色，提取经验写入黑板 |

**第三层：Guardrails（类似 OpenAI Agent SDK）**

在黑板写入时并行验证：
- **范围守卫**：Agent 写入 decisions 时，检查是否超出任务 scope
- **格式守卫**：验证写入数据的格式和完整性
- **冲突守卫**：检测与已有 decisions 的矛盾

#### 防偏离策略

1. **must_haves 继承**：每个节点任务从父任务继承 must_haves，coordinator 在创建时定义
2. **目标回溯验证**：任务完成后，从最终目标回溯验证每个节点的贡献
3. **范围声明**：每个 Agent 在开始工作前必须声明"我计划做什么"，coordinator 确认后才开始

#### 防蔓延策略

1. **原子任务**：每个节点任务有明确的输入/输出契约
2. **Context 隔离**：Agent 只能读取被授权的黑板区域
3. **单次写入**：Agent 只能写入自己负责的 decisions 条目
4. **超时机制**：每个节点有预估工时，超时自动升级到 coordinator

#### 故障处理策略

| 故障类型 | 检测方式 | 处理方式 |
|---------|---------|---------|
| Agent 崩溃 | 心跳超时 | 自动回收 + 重新分配 |
| Agent 幻觉 | 幻觉门控 | 阻塞关闭 + 要求补充验证 |
| 产出质量差 | Coordinator 审查 | 打回重做 + 给出改进方向 |
| 需求偏离 | 范围守卫 | 暂停 + coordinator 仲裁 |
| 依赖阻塞 | 超时检测 | coordinator 重新编排依赖 |

---

## 课题 6：经验沉淀闭环

### 2.1 已有经验（知识库/wiki）

知识库中无直接相关的经验沉淀实践。但 OpenClaw 体系中已有：
- **MEMORY.md**：每个 agent 的记忆文件（四类记忆法：user/feedback/project/reference）
- **知识库**：`~/.openclaw/knowledge_base/` 目录，但目前只存基础数据

### 2.2 业界优秀实践对比表

| 项目 | 闭环模型 | 信息源 | 蒸馏过程 | 经验载体 | 反哺机制 |
|------|---------|-------|---------|---------|---------|
| **Claude Code Memory** | 四类记忆法 | Agent 工作过程中的自动观察 | Agent 自行判断何为值得记录的 → 写入 MEMORY.md | Markdown（MEMORY.md，按 user/feedback/project/reference 分类） | 每次 session 启动时自动加载到 context |
| **Hermes Learning Loop** | 闭环学习（五层） | 任务执行过程、对话历史 | 复杂任务完成 → 自动创建 SKILL.md；使用中自改进；FTS5 跨 session 搜索 + LLM 摘要 | SKILL.md（步骤化菜谱）+ Honcho dialectic model（12 层用户建模） | 新任务自动检索相关 SKILL；periodic nudges 主动推送遗忘的知识 |
| **nuwa-skill** | 五阶段蒸馏管线 | 公开数据源（文章、演讲、推文） | Phase 1 实体发现 → Phase 2 数据采集 → Phase 3 心智模型提取（3-7个 + 5-10条决策启发式 + 表达DNA + 反模式 + 诚实边界） → Phase 4 验证（3 个已知问题 + 1 个未知问题） → Phase 5 双 Agent 精炼 | SKILL.md（心智操作系统） | 生成的 Skill 可被 Agent 直接加载使用；Darwin.skill 持续进化（八维评估 + 棘轮机制） |
| **claude-mem** | 三层工作流 | Agent session 全程捕获 | 捕获 → AI 压缩 → 相关性注入 | 结构化 memory 文件 + FTS 索引 | 4 个 MCP 工具按需检索注入 context |
| **GSD** | Spec-driven | Plan → Execute → Verify 流水线 | Planner 的经验沉淀为更好的 plan template | PLAN.md 模板 + must_haves 模式 | 每个 phase 的 plan 模板可复用 |

### 2.3 关键机制深度分析

#### 2.3.1 Claude Code Memory — 四类记忆法

Claude Code 的记忆体系分为四个类别：

1. **User Memory**：用户角色和偏好（"用户喜欢用 TypeScript"）
2. **Feedback Memory**：用户纠正 Agent 错误的记录（"不要用 var，用 let/const"）
3. **Project Memory**：项目关键决策和架构选择（"我们用 monorepo"）
4. **Reference Memory**：文件位置和结构（"配置在 src/config/"）

**关键设计决策**：
- Agent **自行判断**什么值得记录（不是什么都记）
- 写入门槛高：只记录不能从代码推导的信息
- Auto memory 机制：Agent 在工作时自动积累，无需用户手动维护
- Subagent 也可以维护自己的 auto memory

**局限**：
- 无显式蒸馏过程（只记录不蒸馏）
- 无跨项目经验迁移
- 无质量验证机制（可能记录错误的"经验"）

#### 2.3.2 Hermes Learning Loop — 五层闭环

Hermes 是目前最完整的 Agent 学习闭环实现，包含五个层次：

1. **Agent-curated Memory + Periodic Nudges**
   - Agent 自主管理记忆
   - 定期"轻推"自己回忆可能遗忘的知识
   - 避免长 session 中上下文退化

2. **Autonomous Skill Creation**
   - 完成复杂任务后，自动将解决步骤写入 SKILL.md
   - 本质是"做过的事变成可复用的菜谱"

3. **Skill Self-improvement During Use**
   - 使用 Skill 时，根据实际效果自动改进
   - 类似"边用边学"

4. **FTS5 Cross-session Recall + LLM Summarization**
   - 全文搜索（FTS5）索引所有历史 session
   - LLM 自动摘要，提取跨 session 可复用的知识
   - 新任务可搜索历史相似场景

5. **Honcho Dialectic User Modeling**
   - 可选的用户建模层
   - 通过 12 个身份层建模用户偏好
   - "辩证法"建模：同时建模用户和 Agent 的关系

**关键洞察**：Hermes 的闭环核心是"记忆 → Skill → 搜索 → 改进"的持续循环。

#### 2.3.3 nuwa-skill — 五阶段蒸馏管线

nuwa-skill 的蒸馏管线从原始数据到可复用 Skill 经过五个阶段：

**Phase 1：Entity Discovery（实体发现）**
- 输入：一个名字
- 处理：通过搜索发现该人物的存在维度、领域、公开数据源
- 产出：候选数据源列表

**Phase 2：Data Collection（数据采集）**
- 输入：数据源列表
- 处理：采集文章、演讲、推文、访谈等原始材料
- 产出：原始语料库

**Phase 3：Cognitive DNA Extraction（认知 DNA 提取）**
- 输入：原始语料
- 处理：提取心智模型（3-7个）、决策启发式（5-10条）、表达 DNA、价值观与反模式、诚实边界
- 方法论：三重验证（跨域存在性 + 预测力 + 排他性）
- 产出：SKILL.md 草稿

**Phase 4：Quality Verification（质量验证）**
- 输入：SKILL.md 草稿
- 处理：用 3 个该人物公开回答过的问题测试（方向一致性）；用 1 个未讨论过的问题测试（适度不确定性）
- 产出：验证通过的 SKILL.md

**Phase 5：Dual-Agent Refinement（双 Agent 精炼）**
- 输入：验证通过的 SKILL.md
- 处理：一个 Agent 扮演该人物使用 Skill，另一个 Agent 评估表现
- 结合 Darwin.skill 的八维评估 + 棘轮机制（只保留改进，自动回退退化）
- 产出：最终 SKILL.md

**关键创新**：
- "蒸馏的是思维方式，不是行为模仿"
- 三重验证确保提取的心智模型是真实的
- 诚实边界：明确声明 Skill 的局限

### 2.4 推荐方案（结合 AI Native 目标）

基于以上分析，推荐采用 **"DISCOVER → DISTILL → VERIFY → APPLY → IMPROVE" 五阶段闭环**：

#### 闭环架构

```
     ┌──────────────────────────────────────────────┐
     │                                              │
     ▼                                              │
 DISCOVER ──→ DISTILL ──→ VERIFY ──→ APPLY ──→ IMPROVE
    │              │           │          │           │
    │ 黑板         │ 蒸馏器    │ 验证器   │ 执行器    │ 进化器
    │ observations │           │          │           │
    │ decisions    │           │          │           │
    │ task_outputs │           │          │           │
    └──────────────┘           │          │           │
                               ▼          ▼           ▼
                          Skill Store  下次任务    Skill 自改进
```

#### 阶段一：DISCOVER（信息发现）

**信息源**（按价值排序）：

| 信息源 | 采集方式 | 价值 |
|-------|---------|------|
| 黑板 decisions | 自动记录 Agent 决策过程和理由 | 高 |
| 节点 output.md | 任务完成后的产出文件 | 高 |
| Coordinator 审查记录 | 庞统审查时的问题和修正 | 高 |
| 错误与修正 | 幻觉门控拦截、Coordinator 打回重做 | 极高 |
| Agent 间协作 | 黑板 observations 中的交互记录 | 中 |
| 重试历史 | Retry budget 消耗记录 | 中 |

**写入黑板 experiences 表**：
```json
{
  "experience_id": "exp-001",
  "source": "node_output",
  "task_id": "task-123",
  "node_id": "coding",
  "timestamp": "2026-05-15T10:00:00Z",
  "raw_data": { ... },
  "tags": ["error-handling", "vnpy-strategy", "backtest"],
  "status": "discovered"
}
```

#### 阶段二：DISTILL（蒸馏）

蒸馏过程分为两级：

**一级蒸馏（实时，每个任务完成后）**：
- **执行者**：完成任务后的 Agent 自动触发
- **过程**：
  1. 从 output.md 提取关键决策和理由
  2. 从错误修正中提取"教训"
  3. 压缩为结构化经验条目（200-500 字）
- **产出**：经验条目写入黑板 experiences 表，status = "distilled"

**二级蒸馏（周期性，由 Coordinator 触发）**：
- **执行者**：Coordinator（庞统）或专用蒸馏 Agent
- **过程**（参考 nuwa-skill 三重验证）：
  1. 聚合同类经验（按 tag 聚合）
  2. 提取心智模型（这类问题的通用解决模式）
  3. 提取决策启发式（遇到 X 情况，优先考虑 Y）
  4. 提取反模式（遇到 X 情况，千万不要 Z）
  5. 标注诚实边界（这些经验的适用范围）
- **产出**：Skill 草稿或 Rule 更新

**蒸馏格式**（参考 nuwa-skill SKILL.md 结构）：

```markdown
# Skill: [名称]
## 心智模型
- [模型1]: [描述]
- [模型2]: [描述]

## 决策启发式
- [情况X] → 优先考虑 [Y]
- [情况A] → 避免使用 [B]

## 反模式
- ❌ [错误做法]: [为什么错]

## 诚实边界
- 本 Skill 适用于 [场景]
- 不适用于 [场景]
```

#### 阶段三：VERIFY（验证）

**验证方式**（参考 nuwa-skill Phase 4 + Hermes 幻觉门控）：

1. **已知场景回测**：用 3 个历史类似任务测试 Skill 是否给出正确建议
2. **未知场景测试**：用 1 个新场景测试 Skill 是否表现出适度不确定性
3. **Coordinator 审核**：庞统审查 Skill 的逻辑合理性
4. **自动格式验证**：JSON Schema 校验 Skill 结构完整性

**验证通过** → status = "verified"，写入 Skill Store
**验证失败** → 回到 DISTILL 重新蒸馏或丢弃

#### 阶段四：APPLY（应用）

**反哺机制**：

| 应用方式 | 触发时机 | 机制 |
|---------|---------|------|
| Context 注入 | Agent 接受节点任务时 | 在任务 prompt 中注入相关 Skill 的摘要 |
| FTS5 搜索 | Agent 遇到困难时 | Agent 可主动搜索历史经验 |
| Planner 参考 | Coordinator 分解任务时 | 参考历史类似任务的经验 |
| Guardrail 规则 | 黑板写入时 | 经验转化为 guardrail 规则 |

**关键设计**：
- 不是所有经验都注入 context（token 成本）
- 按相关性排序，只注入 top-K 相关经验
- 经验注入是建议性的，不强制 Agent 遵循

#### 阶段五：IMPROVE（进化）

**进化机制**（参考 Hermes skill self-improvement + nuwa-skill Darwin 棘轮机制）：

1. **使用反馈收集**：Skill 被引用时，记录 Agent 是否采纳了建议
2. **效果追踪**：采纳 Skill 建议的任务 vs 未采纳的任务，成功率对比
3. **定期回顾**：Coordinator 定期审查 Skill Store，淘汰低效 Skill
4. **棘轮机制**：Skill 只能进化为更好的版本，改进才保留，退化自动回退

**Skill 生命周期**：
```
discovered → distilled → verified → active → deprecated
                                     ↑          │
                                     └── improved ┘
```

#### 黑板 experiences 表设计

```json
{
  "table": "experiences",
  "schema": {
    "experience_id": "string (uuid)",
    "source": "enum(node_output, coordinator_review, error_correction, collaboration)",
    "task_id": "string (foreign key to tasks)",
    "node_id": "string",
    "timestamp": "datetime",
    "tags": "string[]",
    "raw_summary": "text (一级蒸馏结果)",
    "skill_id": "string|null (关联的 Skill)",
    "status": "enum(discovered, distilled, verified, active, deprecated)",
    "usage_count": "integer (被引用次数)",
    "effectiveness_score": "float|null (效果评分 0-1)",
    "verified_at": "datetime|null",
    "verified_by": "string|null"
  }
}
```

### 2.5 实施优先级

| 优先级 | 机制 | 复杂度 | 价值 |
|-------|------|-------|------|
| P0 | 一级蒸馏（任务完成自动提取） | 低 | 高 |
| P0 | experiences 表写入 | 低 | 高 |
| P1 | 幻觉门控 + 心跳检测（系统保护） | 中 | 高 |
| P1 | Coordinator must_haves 定义 | 低 | 高 |
| P2 | 二级蒸馏（周期性 Skill 生成） | 高 | 高 |
| P2 | FTS5 搜索 + Context 注入 | 中 | 中 |
| P3 | Skill 进化 + 棘轮机制 | 高 | 中 |
| P3 | Guardrails 自动生成 | 高 | 中 |

---

## 附录：项目参考链接

| 项目 | 链接 | 核心价值 |
|------|------|---------|
| Hermes v0.13 | https://github.com/NousResearch/hermes-agent | 系统级韧性机制（心跳/僵尸/幻觉门控）+ 闭环学习 |
| Claude Code Agent Teams | https://code.claude.com/docs/en/agent-teams | Lead coordinator 模式 + subagent 编排 |
| Claude Code Memory | https://code.claude.com/docs/en/memory | 四类记忆法 |
| Claude Code Subagents | https://code.claude.com/docs/en/sub-agents | 自定义 subagent + coordinator 定义 |
| GSD (get-shit-done) | https://github.com/gsd-build/get-shit-done | Wave Execution + Planner/Executor/Verifier |
| OpenAI Agent SDK Guardrails | https://openai.github.io/openai-agents-python/guardrails/ | Input/Output guardrails + tripwire |
| MetaGPT | https://github.com/FoundationAgents/MetaGPT | SOP 编码 + 角色协作 |
| nuwa-skill | https://github.com/alchaincyf/nuwa-skill | 五阶段蒸馏管线 + Cognitive DNA |
| claude-mem | https://github.com/thedotmack/claude-mem | 持久记忆 + 三层检索 |