22 KiB
调研报告: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 职责:
- 接收用户需求并分解为子任务
- Spawn teammates,每个 teammate 拿到特定 context
- 监控各 teammate 输出
- 解决 teammate 间的依赖冲突
- 合成最终结果
- 关键约束: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 的矛盾
防偏离策略
- must_haves 继承:每个节点任务从父任务继承 must_haves,coordinator 在创建时定义
- 目标回溯验证:任务完成后,从最终目标回溯验证每个节点的贡献
- 范围声明:每个 Agent 在开始工作前必须声明"我计划做什么",coordinator 确认后才开始
防蔓延策略
- 原子任务:每个节点任务有明确的输入/输出契约
- Context 隔离:Agent 只能读取被授权的黑板区域
- 单次写入:Agent 只能写入自己负责的 decisions 条目
- 超时机制:每个节点有预估工时,超时自动升级到 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 的记忆体系分为四个类别:
- User Memory:用户角色和偏好("用户喜欢用 TypeScript")
- Feedback Memory:用户纠正 Agent 错误的记录("不要用 var,用 let/const")
- Project Memory:项目关键决策和架构选择("我们用 monorepo")
- Reference Memory:文件位置和结构("配置在 src/config/")
关键设计决策:
- Agent 自行判断什么值得记录(不是什么都记)
- 写入门槛高:只记录不能从代码推导的信息
- Auto memory 机制:Agent 在工作时自动积累,无需用户手动维护
- Subagent 也可以维护自己的 auto memory
局限:
- 无显式蒸馏过程(只记录不蒸馏)
- 无跨项目经验迁移
- 无质量验证机制(可能记录错误的"经验")
2.3.2 Hermes Learning Loop — 五层闭环
Hermes 是目前最完整的 Agent 学习闭环实现,包含五个层次:
-
Agent-curated Memory + Periodic Nudges
- Agent 自主管理记忆
- 定期"轻推"自己回忆可能遗忘的知识
- 避免长 session 中上下文退化
-
Autonomous Skill Creation
- 完成复杂任务后,自动将解决步骤写入 SKILL.md
- 本质是"做过的事变成可复用的菜谱"
-
Skill Self-improvement During Use
- 使用 Skill 时,根据实际效果自动改进
- 类似"边用边学"
-
FTS5 Cross-session Recall + LLM Summarization
- 全文搜索(FTS5)索引所有历史 session
- LLM 自动摘要,提取跨 session 可复用的知识
- 新任务可搜索历史相似场景
-
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 表:
{
"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 自动触发
- 过程:
- 从 output.md 提取关键决策和理由
- 从错误修正中提取"教训"
- 压缩为结构化经验条目(200-500 字)
- 产出:经验条目写入黑板 experiences 表,status = "distilled"
二级蒸馏(周期性,由 Coordinator 触发):
- 执行者:Coordinator(庞统)或专用蒸馏 Agent
- 过程(参考 nuwa-skill 三重验证):
- 聚合同类经验(按 tag 聚合)
- 提取心智模型(这类问题的通用解决模式)
- 提取决策启发式(遇到 X 情况,优先考虑 Y)
- 提取反模式(遇到 X 情况,千万不要 Z)
- 标注诚实边界(这些经验的适用范围)
- 产出:Skill 草稿或 Rule 更新
蒸馏格式(参考 nuwa-skill SKILL.md 结构):
# Skill: [名称]
## 心智模型
- [模型1]: [描述]
- [模型2]: [描述]
## 决策启发式
- [情况X] → 优先考虑 [Y]
- [情况A] → 避免使用 [B]
## 反模式
- ❌ [错误做法]: [为什么错]
## 诚实边界
- 本 Skill 适用于 [场景]
- 不适用于 [场景]
阶段三:VERIFY(验证)
验证方式(参考 nuwa-skill Phase 4 + Hermes 幻觉门控):
- 已知场景回测:用 3 个历史类似任务测试 Skill 是否给出正确建议
- 未知场景测试:用 1 个新场景测试 Skill 是否表现出适度不确定性
- Coordinator 审核:庞统审查 Skill 的逻辑合理性
- 自动格式验证: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 棘轮机制):
- 使用反馈收集:Skill 被引用时,记录 Agent 是否采纳了建议
- 效果追踪:采纳 Skill 建议的任务 vs 未采纳的任务,成功率对比
- 定期回顾:Coordinator 定期审查 Skill Store,淘汰低效 Skill
- 棘轮机制: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 | 持久记忆 + 三层检索 |