多智能体的记忆接线：同一任务：每个角色看到的不一样

同一任务，不同角色看到的记忆清单也不同，这揭示了多智能体系统协作的关键细节。
核心内容：
1. 阶段7实现多智能体与记忆层的权限对接
2. 通过权限映射与适配层实现差异化记忆注入
3. 对比阶段4的模拟通信，展示真实协作机制

真一片文章的内容是接着上一个阶段的

上一篇文章说清记忆层与多智能体层应该怎么接；这一篇把过程跑通，核心循环：

for agent in DAG_order:    manifest = FederatedInjector.inject(scope, route)   # 记忆层系统调用    result   = Agent.execute(task, manifest)            # 多智能体层回合    writeback(manifest.memory_ids, result)              # 审计 + 持久化

democode/phase7/ 已实现骨架。通过采购 Kafka 幂等场景实测：意图智能体注入 3 条、本体智能体 8 条、模拟验证智能体 3 条——同一任务，注入清单不相同。而第四阶段的 mock 切片做不到这一点。

阶段 4 的记忆为什么是模拟

为了证明制衡演示有效，但记忆通信是假装的：build_agent_context() 返回 Python 字典，不经过 OntologyRegistry.validate()，也不产生节点清单；check_permission() 定义了读写矩阵，但执行路径没有强制拦截越权。

阶段 7 不重写 Phase 4 智能体逻辑，用适配层补记忆接口：

阶段 4 演示仍可独立运行；阶段 7 在其外包装联邦记忆。

权限范围：把两张表合成一张

阶段4 用层名（critical/rule/context）描述读写；阶段 6 用语义域 + 层级描述检索——语义空间不同，不能直接替换。AgentMemoryScope 是显式映射：

协调器每回合：查权限范围 → 调意图路由器 → 主力域满额预算、辅助域 ×0.5 → 生成注入清单。

    图：本体 8 条 vs 模拟验证 3 条——同一任务，不同清单

协调器执行流

    图：多智能体有向无环图 × 联邦注入 × 每回合写回

每回合：设置版本窗口 → 查 scope → 路由 → 注入 → manifest_parser 解析约束/模式记忆 → 执行 → 写回决策记录。

现在增加了几个优化：清单解析（本体不再读硬编码约束）、模拟验证制衡重试（否决 → 排队写回 → 本体重试）、代码生成校验（语法树检查 enforcement=reject 约束）。

[本体] 来自注入清单：['BIZ-CN-001', ...] [模拟验证] ✗ Beta供应商剩余13天 15天  → 排队写回 [本体] 修正为 keep_threshold_add_warning (v2) [模拟验证] ✓ 通过  → 触发代码生成

写回含 derived_from: [注入节点编号]——决策血缘在智能体回合级的最小实现。

从 Codex 借鉴了什么

上一篇文章对 Codex 做了源码分析。这篇文章落地了四条模式：

明确不借鉴的：大模型动态创建子智能体（丧失数据依赖）、子智能体跳过记忆管线、会话级统一注入、无版本和审计的 MEMORY.md 合并。

最后我们选择了固定有向无环图，而没有使用Codex 的spawn tree 因为 制衡要求模拟验证在本体之后——这是数据依赖，不是偏好。Codex 适合探索性任务；我们服务的是受治理的业务规则变更。

五、后面还会写的内容

1. 权限范围外置角色配置文件

2.BackgroundTaskStore异步化

3. 通过一个完整的示例展示多智能体系统与记忆系统是如何协作的。

最后，可以运行下面的示例代码进行验证：


python3 phase7/run_multi_agent_memory_demo.py --full --scenario threshold --dry-run