Files
sanguo_moziplus_v2/docs/research/v2.6-research-01-ai-decision-experience.md
T
2026-05-15 09:31:37 +08:00

22 KiB
Raw Blame History

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

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


课题 1AI 决策者有效参与

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 + Teammatescoordinator 模式) 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 GateAgent 声称"完成"时,系统验证实际产出(如补丁是否真正落地),验证通过才关闭任务
  • Per-task Retry Budget:每个任务有独立重试预算,防止单任务无限循环
  • 不完整退出自动阻塞(Auto-block):Agent 异常退出时自动阻塞该任务,不会静默失败

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

1.3.2 Claude Code Agent Teams — Lead 主动协调

Claude Code 的 Agent Teams 模式采用显式 Leadcoordinator):

  • Lead Agent 职责:
    1. 接收用户需求并分解为子任务
    2. Spawn teammates,每个 teammate 拿到特定 context
    3. 监控各 teammate 输出
    4. 解决 teammate 间的依赖冲突
    5. 合成最终结果
  • 关键约束Lead 通过 Agent(agent_type) 语法限制可 spawn 的 subagent 类型
  • Context 隔离:每个 subagent 只拿到相关 context,防止信息泄露和范围蔓延
  • 配置示例
    --- 
    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_havescoordinator 在创建时定义
  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 MarkdownMEMORY.md,按 user/feedback/project/reference 分类) 每次 session 启动时自动加载到 context
Hermes Learning Loop 闭环学习(五层) 任务执行过程、对话历史 复杂任务完成 → 自动创建 SKILL.md;使用中自改进;FTS5 跨 session 搜索 + LLM 摘要 SKILL.md(步骤化菜谱)+ Honcho dialectic model12 层用户建模) 新任务自动检索相关 SKILLperiodic 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 1Entity Discovery(实体发现)

  • 输入:一个名字
  • 处理:通过搜索发现该人物的存在维度、领域、公开数据源
  • 产出:候选数据源列表

Phase 2Data Collection(数据采集)

  • 输入:数据源列表
  • 处理:采集文章、演讲、推文、访谈等原始材料
  • 产出:原始语料库

Phase 3Cognitive DNA Extraction(认知 DNA 提取)

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

Phase 4Quality Verification(质量验证)

  • 输入:SKILL.md 草稿
  • 处理:用 3 个该人物公开回答过的问题测试(方向一致性);用 1 个未讨论过的问题测试(适度不确定性)
  • 产出:验证通过的 SKILL.md

Phase 5Dual-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 表

{
  "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 结构):

# 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 表设计

{
  "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 持久记忆 + 三层检索