From 745c9d4218405bfbaf6d0dae11407967d2223a11 Mon Sep 17 00:00:00 2001 From: cfdaily Date: Thu, 14 May 2026 07:58:21 +0800 Subject: [PATCH] =?UTF-8?q?docs:=20=E5=85=B1=E4=BA=AB=E6=84=8F=E8=AF=86?= =?UTF-8?q?=E7=A9=BA=E9=97=B4=E8=B0=83=E7=A0=94=E6=8A=A5=E5=91=8A=20v1.0?= =?UTF-8?q?=20-=20=E7=BB=BC=E5=90=88=20wiki=20+=20=E5=AD=A6=E6=9C=AF=20+?= =?UTF-8?q?=20=E7=94=9F=E4=BA=A7=E5=AE=9E=E8=B7=B5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../research/shared-consciousness-research.md | 416 ++++++++++++++++++ 1 file changed, 416 insertions(+) create mode 100644 docs/research/shared-consciousness-research.md diff --git a/docs/research/shared-consciousness-research.md b/docs/research/shared-consciousness-research.md new file mode 100644 index 0000000..6d2705e --- /dev/null +++ b/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