sanguo/sanguo_moziplus_v2
8
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f1e513cba2fcd28fab358c79aaec9362534be30f
sanguo_moziplus_v2/docs/research/shared-consciousness-research.md
T

20 KiB
Raw Blame History

共享意识空间（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
Reference in New Issue View Git Blame Copy Permalink