docs: 共享意识空间调研报告 v1.0 - 综合 wiki + 学术 + 生产实践

docs/research/shared-consciousness-research.md

@@ -0,0 +1,416 @@
+# 共享意识空间（Shared Consciousness）调研报告
+
+**版本**: v1.0
+**日期**: 2026-05-14
+**作者**: 庞统（副军师）
+**目的**: 为 moziplus v2.0 AI 原生架构设计共享意识空间，综合 wiki 已有经验 + 前沿学术 + 生产实践
+
+---
+
+## 第一部分：Wiki 已有经验（知识库检索）
+
+> ⚠️ 以下内容来自 wiki-vault practices/，是之前项目调研中已经蒸馏的结构化知识。
+
+### 1. AI Native 多Agent架构实践
+
+**来源**: `practices/ai-native-multi-agent-architecture`
+
+#### 编排混合模式
+- 业界共识：不纯 DAG 也不纯 ReAct，而是"可预测骨架 + LLM 动态填充"
+- LangGraph：图定义结构，条件边动态路由
+- OpenAI Agent SDK：Handoff 显式转交 + 对话历史传递
+- Google ADK：层级树 + LLM 做委派决策
+- **实践**：保留确定性引擎做底层保障（状态追踪、超时保护），在决策点插入 LLM 判断
+
+#### 通信四模式（按 AI native 程度递进）
+1. **点对点异步消息**（Sanguo Mail）：有损、延迟、缺上下文——最基础
+2. **共享工作区 + 结构化产出**（Claude Code）：文件系统 + JSON 接口——简单有效
+3. **对话历史传递**（OpenAI Handoff）：转交时携带完整上下文——"surprisingly effective"
+4. **Blackboard 广播**（学术前沿）：全局黑板 + LLM 控制单元路由——最强但最复杂
+
+#### Skill 三层组合
+- Execution Layer + Enhancement Layer + Guarantee Layer
+- 从工具层→行为层→认知层演进
+
+#### 经验沉淀：Memory → Skills → Rules 三层压缩
+- Memory：原始执行 trace 存档
+- Skills：从多次经验中抽象的可复用操作序列
+- Rules：高度压缩的启发式规则/偏好
+
+#### 对 v2.0 的具体借鉴
+| 方向 | 做法 | 来源 |
+|------|------|------|
+| 编排动态化 | Goal-first + Coordinator 动态分解 | open-multi-agent |
+| 质量门禁 | 三方共识（Planner+Architect+Critic） | oh-my-claudecode |
+| 并行安全 | propose→validate→commit 原子写入 | Network-AI |
+| 防偷懒 | Scope Reduction Detection | get-shit-done |
+| 紧急中断 | Steer 优先级消息 | wanman |
+| 经验沉淀 | 任务完成后 nudge 持久化 | hermes |
+| 上下文隔离 | Wave Execution 独立上下文 | get-shit-done |
+| 运维保障 | 心跳+reclaim+幻觉门控+per-task retry | Hermes v0.13 |
+| 跨Agent传递 | Canonical IR + Fidelity 三档 | Opal-Bridge |
+
+### 2. 多Agent协作模式
+
+**来源**: `practices/multi-agent-collaboration-patterns`
+
+#### 四种编排模式
+| 模式 | 结构 | 适用场景 |
+|------|------|----------|
+| 线性流水线 | A→B→C→D | 明确先后顺序 |
+| 并行扇出 | A→[B,C,D]→Merge | 子任务独立可并行 |
+| 主从模式 | Supervisor→Workers | 有明确协调者 |
+| 网状协作 | Agent互调 | 需要灵活路由（谨慎） |
+
+#### 三种通信协议
+| 协议 | 优点 | 缺点 | 适用场景 |
+|------|------|------|----------|
+| 文件通信 | 简单可靠可追溯 | 慢需轮询 | 大文件、持久化 |
+| 消息队列 | 异步解耦可扩展 | 复杂需基础设施 | 高并发 |
+| RPC/API | 快同步类型安全 | 耦合紧 | 实时通信 |
+
+#### 冲突解决策略
+- 写冲突：锁定+排队（try_acquire + release）
+- 逻辑冲突：优先级+仲裁（Supervisor 决策）
+- 资源冲突：队列+限流
+
+### 3. Network-AI 原子黑板
+
+**来源**: `practices/network-ai-practices`
+
+#### 核心机制
+- **propose→validate→commit** 三阶段原子写入，消除 split-brain
+- **Priority-Wins** 优先级抢占：0-3级（low/normal/high/critical），高优先级可抢占低优先级
+- **FileLock** 文件系统互斥锁：零外部依赖，wx标志保证原子性
+- **FederatedBudget** 联邦预算追踪：全局上限 + per-Agent 上限
+
+#### 启示
+- 风控Agent（关羽）应该是最高优先级
+- 数据验证Agent（赵云）的校验结果也应高优先级
+- NAS上的共享数据文件写入需要锁机制防并发损坏
+
+### 4. Opal-Bridge 跨Agent Session 翻译
+
+**来源**: `practices/opal-bridge-practices`
+
+#### 五大核心机制
+1. **Canonical IR 中间表示**：N个Agent只需2N个adapter，结构对称不偏袒
+2. **Moments 原子事件**：13种事件类型，时间戳单调递增，source_ref可追溯
+3. **Fidelity 三档**：无损（Mode A）/ LLM摘要（Mode B）/ 混合保留最近N条（Mode C）
+4. **Subagent 策略**：inline（拼入主线）/ split（独立文件）/ drop（只保留结果）
+5. **覆盖保护**：翻译器永远不修改用户原始数据
+
+### 5. ClawTeam OpenClaw 多Agent协作
+
+**来源**: `practices/clawteam-openclaw-practices`
+
+#### 关键实践（28条中的精选）
+
+| # | 实践 | 核心思路 | v2.0 借鉴点 |
+|---|------|----------|------------|
+| 1 | Git Worktree 隔离 | 每个Agent独立分支，零合并冲突 | 并行编码隔离 |
+| 2 | fcntl文件锁+原子rename | 无数据库并发安全 | 黑板写入安全 |
+| 3 | Inbox文件消息系统 | JSON文件即消息，claim→ack模式 | Agent间通信 |
+| 4 | 任务依赖链+自动解除 | blocked_by字段+DFS环检测+自动流转 | 动态计划 |
+| 5 | Boids群体智能规则 | Separation/Alignment/Cohesion/Boundary | Agent行为注入 |
+| 6 | 任务锁机制 | locked_by+死锁回收 | 防止任务重复执行 |
+| 7 | Agent生命周期感知 | tmux pane存活检测+任务自动回收 | 僵尸检测 |
+| 8 | 元认知自评 | [confidence: 0.X] 置信度标注 | 产出质量信号 |
+| 10 | Auftragstaktik任务式指挥 | Intent→End State→Constraints | 任务分配方式 |
+| 11 | 成本追踪 | Agent自报Token消耗+增量汇总 | Token治理 |
+| 12 | Agent数量限制 | 默认max=4，有学术依据 | 并行度控制 |
+| 14 | Plan审批工作流 | Worker提交计划→Leader审批→执行 | 复杂任务门控 |
+| 15 | Dead Letter隔离 | 格式错误消息不阻塞队列 | 消息处理韧性 |
+| 19 | 不可变事件日志 | inbox消息消费删除+事件日志永久保留 | 审计追溯 |
+| 20 | on-exit钩子 | trap EXIT自动清理+通知 | Agent崩溃恢复 |
+| 27 | 共享记忆作用域 | team级memory scope | 团队知识共享 |
+
+### 6. Hermes v0.13 Kanban 运维保障
+
+**来源**: `practices/hermes-kanban-v0.13-practices`
+
+| 机制 | 做法 | v2.0 借鉴 |
+|------|------|----------|
+| 心跳+Reclaim | 定期心跳，超时自动回收任务 | Worker生命周期管理 |
+| 幻觉门控 | Agent声称完成时验证产出是否存在 | "不验证不算完" |
+| Per-Task重试 | 每个任务独立max_retries | 灵活重试策略 |
+| Worker自动Block | 异常Worker不再接新活 | 防止坏Agent继续接活 |
+| /goal Ralph Loop | 持久目标跨turn保持 | "持续指挥官"原语 |
+
+### 7. 知识管理体系
+
+**来源**: `practices/knowledge-management-system`
+
+#### 闭环学习（DISCOVER→DISTILL→APPLY→IMPROVE）
+- 只记录不应用的知识是浪费
+- 只应用不沉淀的知识是重复劳动
+- 闭环必须完整
+
+#### 四层金字塔
+- L0 记忆层（MEMORY.md）→ L1 经验层 → L2 知识层（wiki） → L3 体系层（设计文档）
+
+#### 五路径增长
+- 调研驱动 / 问题驱动 / 外部注入 / 反向触发 / 交叉碰撞
+
+---
+
+## 第二部分：前沿学术与生产实践（Web 调研）
+
+### 8. bMAS（Blackboard LLM Multi-Agent System）
+
+**来源**: *"Exploring Advanced LLM Multi-Agent Systems Based on Blackboard Architecture"* (arXiv:2507.01701, 2025.07)
+
+#### 三大核心组件
+1. **Control Unit**：LLM驱动，根据黑板内容动态选择下一轮该哪个Agent行动
+2. **Blackboard**：全局共享信息空间，所有Agent读写，是唯一的记忆和消息传递中枢
+3. **Agent Group**：不同专业角色的LLM Agent
+
+#### 关键机制
+- **动态选择**：不是固定DAG，Control Unit根据黑板当前内容决定下一步
+- **迭代收敛**：Agent轮流行动→更新黑板→Control Unit判断→直到黑板达成共识
+- **全息可见**：所有Agent能看到黑板上的所有信息
+
+#### 实验结果
+- bMAS在常识推理和数学任务上**匹配甚至超过**静态编排和动态编排系统
+- **token效率更高**（因为Control Unit做智能路由，不浪费在不相关的Agent上）
+
+### 9. Global Workspace Theory（GWT）与AI意识
+
+**来源**: Bernard Baars 认知科学理论 + ACM CENs 论文 (2025)
+
+#### 核心循环
+```
+竞争（各模块提交信息）→ 选择（Control Unit选出胜出者）→ 广播（胜出信息共享给所有模块）→ 下一轮
+```
+
+#### 对共享意识空间的映射
+- GWT的"专业模块" = 我们的各个Agent
+- GWT的"全局工作空间" = 我们的Blackboard
+- GWT的"竞争→选择→广播" = 我们的Control Unit路由机制
+- **Serial bottleneck is a feature, not a bug**：串行瓶颈确保信息不冲突
+
+### 10. KVCOMM（NeurIPS 2025）—— 共享 KV Cache
+
+**来源**: *"KVCOMM: Online Cross-context KV-cache Communication for Efficient LLM-based Multi-agent Systems"*
+
+#### 关键洞察
+- 多个Agent共享前缀文本时，可复用KV Cache
+- 5个Agent场景下 **7.8× 加速**，TTFT从~430ms降到~55ms
+- **70%+ KV-cache reuse** in five-agent settings
+
+#### 启示
+- 共享意识空间不需要每个Agent都重新"理解"全部上下文
+- 公共部分可以缓存和复用（这是模型层面的优化，我们暂不实现，但未来方向）
+
+### 11. PSMAS（Phase-Scheduled Multi-Agent Systems）
+
+**来源**: arXiv:2604.17400, 2026.04
+
+#### 关键思路
+- 把Agent激活看作**连续控制**而非离散RPC
+- 在共享注意力空间（circular manifold）上调度Agent
+- **34.8% token reduction**
+
+### 12. O'Reilly 模式总结（2026.02）
+
+**来源**: *"Designing Effective Multi-Agent Architectures"* (O'Reilly Radar)
+
+#### 关键洞察
+- **共享产出物（shared artifacts）比共享消息更重要**
+- **Blackboard + shared memory > manager routing every thought**
+- 2026存活下来的协作系统共同特征：**Phase gates + shared artifacts + final supervisor**
+- **纯 Open Mesh（无结构自由协作）是失败模式**
+
+### 13. Meta 生产实践
+
+**来源**: Multi-Agent in Production 2026 总结
+
+- Meta's tribal-knowledge engine: **critics, fixers, upgraders, testers** over **shared artifacts inside one session**
+- 关键：**在一个session内围绕共享artifacts协作**，不同角色轮流在同一空间工作
+- Spotify's Ads AI: decomposes media planning into specialized agents working in parallel
+
+### 14. LangGraph 共享状态模式
+
+**来源**: LangGraph 文档 + 生产案例
+
+- 每个Agent是一个节点，接受和返回**共享状态**（TypedDict）
+- Supervisor节点负责路由决策
+- **Postgres-backed checkpointers** 做长期持久化
+- 关键：**状态是 reducer 模式**——多个Agent可并发写入同一个key，通过reducer合并
+
+### 15. OpenClaw RFC #35203
+
+**来源**: github.com/openclaw/openclaw/issues/35203
+
+OpenClaw官方已提出RFC：**Capability Profiling + Shared Blackboard + Layered Memory + Token Cost Governance**
+- 每个Agent的capability profiling（能力画像）
+- 共享黑板机制
+- 分层记忆边界
+- Token成本治理
+
+---
+
+## 第三部分：综合分析与方案设计
+
+### 设计原则（从调研中提炼）
+
+1. **黑板是唯一真相源**：所有Agent通过黑板共享信息，没有私下通信
+2. **Control Unit是AI驱动的**：不是规则路由，而是LLM根据当前黑板状态动态决策
+3. **写入保护**：不是谁都能随意改任何字段，需要propose→validate→commit
+4. **信息分级**：不是所有Agent都看全量信息，Fidelity三档按需路由
+5. **产出物>消息**：共享产出物比共享消息更重要
+6. **验证才算完**：Agent声称完成时必须验证产出是否真实存在
+7. **结构对称**：不把任何一个Agent当"主"——Canonical IR原则
+8. **有界并行**：默认max=4个并行Agent，有学术依据
+9. **任务式指挥**：Intent→End State→Constraints，Agent自主决定怎么做
+10. **闭环学习**：执行→经验沉淀→下次改进
+
+### 共享意识空间架构
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                       用户（自然语言入口）                         │
+└──────────────────────────┬──────────────────────────────────────┘
+                           │
+┌──────────────────────────▼──────────────────────────────────────┐
+│                 庞统（指挥官 + Control Unit）                     │
+│                                                                 │
+│  四相循环:                                                       │
+│  Phase 1: 苏格拉底对话 → 理解需求                                │
+│  Phase 2: 动态规划 → 生成/调整计划                               │
+│  Phase 3: 持续指挥 → 调度Agent + 监控 + 异常处理                 │
+│  Phase 4: 主动汇报 → 推送进展 + 验收                             │
+│                                                                 │
+│  ┌───────────────────────────────────────────────────────────┐  │
+│  │              Blackboard（全局共享黑板）                      │  │
+│  │                                                           │  │
+│  │  ┌────────────┐ ┌────────────┐ ┌────────────┐            │  │
+│  │  │ TaskCtx    │ │ Moments    │ │ Artifacts  │            │  │
+│  │  │ 任务上下文  │ │ 原子事件流  │ │ 产出物索引  │            │  │
+│  │  └────────────┘ └────────────┘ └────────────┘            │  │
+│  │  ┌────────────┐ ┌────────────┐ ┌────────────┐            │  │
+│  │  │ PlanGraph  │ │ AgentStates│ │ Experience │            │  │
+│  │  │ 动态计划    │ │ Agent状态  │ │ 经验记忆   │            │  │
+│  │  └────────────┘ └────────────┘ └────────────┘            │  │
+│  │  ┌────────────┐                                          │  │
+│  │  │ EventLog   │ ← 不可变事件日志（审计追溯）              │  │
+│  │  └────────────┘                                          │  │
+│  └───────────────────────────────────────────────────────────┘  │
+└─────────────────────────────────────────────────────────────────┘
+                           │ Fidelity三档读写
+        ┌──────────────────┼──────────────────┐
+        │                  │                  │
+   ┌────▼────┐        ┌────▼────┐        ┌────▼────┐
+   │  张飞   │        │  关羽   │        │  赵云   │ ...
+   │  编码   │        │  风控   │        │  数据   │
+   └─────────┘        └─────────┘        └─────────┘
+```
+
+### 七大核心机制
+
+#### 1. Blackboard 物理结构（文件系统 + 结构化JSON）
+
+```
+consciousness/
+├── tasks/{task-id}/
+│   ├── context.json           # 任务上下文
+│   ├── moments.jsonl          # 原子事件流（追加写入）
+│   ├── artifacts/             # 产出物
+│   ├── decisions.jsonl        # 决策记录
+│   ├── plan.json              # 动态计划图谱
+│   └── agents/{agent-id}.json # Agent当前状态
+├── global/
+│   ├── agent-registry.json    # Agent能力画像
+│   ├── experience/            # 跨任务经验
+│   └── templates/             # 任务模板
+├── events/                    # 不可变事件日志
+│   └── evt-{ts}-{uuid}.json
+└── inbox/                     # 用户需求入口
+```
+
+#### 2. Control Unit（庞统）
+
+- 苏格拉底对话理解需求
+- 根据黑板状态动态规划
+- 根据能力画像选择Agent
+- 监控Agent状态、检测异常
+- Fidelity分档信息路由
+
+#### 3. Moments 原子事件流（借鉴 Opal-Bridge）
+
+13+ 种事件类型，追加写入JSONL，时间戳单调递增。
+
+#### 4. Fidelity 三档信息路由
+
+| 档位 | 内容 | 对象 |
+|------|------|------|
+| Full | 完整moments + 全部artifacts | 庞统 |
+| Summary | AI压缩关键节点 + 相关artifacts | 协作伙伴 |
+| Signal | 只传需行动通知 + 最终结论 | 外围Agent |
+
+#### 5. Agent 能力画像（借鉴 RFC #35203）
+
+capabilities / tools / performance_history / current_load
+
+#### 6. 动态计划图谱（替代固定DAG）
+
+计划可在执行中动态调整——庞统发现需额外步骤可直接插入。
+
+#### 7. 写入保护（借鉴 Network-AI）
+
+propose→validate→commit 三阶段，配合文件锁。
+
+### 额外借鉴的设计元素
+
+从 wiki 调研中发现的、之前方案未覆盖的重要设计：
+
+| # | 来源 | 设计元素 | v2.0应用 |
+|---|------|----------|----------|
+| A | ClawTeam #5 | **Boids群体智能规则** | 在Agent prompt中注入 Separation/Alignment/Cohesion/Boundary 四条协作规则 |
+| B | ClawTeam #8 | **元认知自评 [confidence: 0.X]** | Agent产出自带质量信号，指挥官据此决定是否需人工介入 |
+| C | ClawTeam #10 | **Auftragstaktik任务式指挥** | 任务分配用 Intent→End State→Constraints 三元组，不指定步骤 |
+| D | ClawTeam #14 | **Plan审批工作流** | 复杂任务Agent先提交计划，指挥官审批后执行 |
+| E | ClawTeam #19 | **不可变事件日志** | Blackboard事件消费语义 + 事件溯源的审计能力 |
+| F | ClawTeam #27 | **共享记忆作用域** | team级memory scope实现跨Agent知识共享 |
+| G | Hermes #5 | **/goal Ralph Loop** | 持久目标跨turn保持——"持续指挥官"的原语 |
+| H | Hermes #2 | **幻觉门控** | Agent声称完成时验证产出是否真实存在 |
+| I | Network-AI | **优先级抢占** | 风控Agent（关羽）最高优先级，能抢占其他Agent写入 |
+| J | 知识管理 | **闭环学习循环** | DISCOVER→DISTILL→APPLY→IMPROVE |
+| K | 学术 bMAS | **迭代收敛到共识** | Agent轮流行动直到黑板达成consensus |
+| L | O'Reilly | **Phase gates** | 阶段门控确保质量，不是无结构自由协作 |
+| M | OpenClaw RFC | **Token成本治理** | 全局上限 + per-Agent上限 |
+
+---
+
+## 第四部分：待深入问题
+
+1. **物理载体**：文件系统 vs 数据库？——倾向文件系统（与OpenClaw天然兼容、可git追踪）
+2. **庞统运行方式**：persistent session vs 事件驱动唤醒？
+3. **与v1.0 Agent的兼容**：v2.0的Agent是否复用三国团队，还是重新定义？
+4. **信息过载防御**：当任务量大时，黑板上的Moments流如何保持可管理？
+5. **共识机制**：bMAS的"迭代收敛到共识"具体怎么实现？简单投票？LLM仲裁？
+
+---
+
+## 参考来源
+
+### Wiki 知识库
+- `practices/ai-native-multi-agent-architecture`
+- `practices/multi-agent-collaboration-patterns`
+- `practices/network-ai-practices`
+- `practices/opal-bridge-practices`
+- `practices/clawteam-openclaw-practices`
+- `practices/hermes-kanban-v0.13-practices`
+- `practices/knowledge-management-system`
+
+### 学术论文
+- bMAS: arXiv:2507.01701 (2025.07)
+- KVCOMM: NeurIPS 2025
+- PSMAS: arXiv:2604.17400 (2026.04)
+- GWT: Baars (1988) + ACM CENs (2025)
+
+### 生产实践
+- O'Reilly: "Designing Effective Multi-Agent Architectures" (2026.02)
+- Meta: shared artifacts in one session
+- LangGraph: shared state + reducer pattern
+- OpenClaw RFC #35203