# 共享意识空间（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