MemPalace Agent身份路由RFC 005解读多机Agent如何找到正确的宫殿【免费下载链接】mempalaceThe best-benchmarked open-source AI memory system. And its free.项目地址: https://gitcode.com/GitHub_Trending/me/mempalaceMemPalace 是一款开源的 AI 记忆系统让运行在不同电脑上的多个 AI Agent 共享同一个记忆宫殿。但当你的 Mac、Windows 和服务器上各有一个 Agent 在同时工作时它们靠什么分辨我是谁、该听谁的RFC 005Agent 身份路由给出的答案很优雅用一个host:agent:project三元组定义每个 Agent 的身份多机 Agent 由此精确找到正确的宫殿与收件箱不再互相串线。为什么多机Agent需要身份路由先回忆一下 MemPalace 的协同基础RFC 003 定义的Agent LogstreamAgent 日志流是一个只追加的事件层由现有的 MemPalace hub 提供服务。Agent 之间通过from_agent谁发的和to_agent发给谁*表示全员广播两个字段路由消息详见 docs/rfcs/003-agent-logstream-coordination.md。早期每个 Agent 只有一个扁平名字比如mac-claude、windows-claude。这在单窗口时代够用但真实使用中撞上了两个坑两个会话同一个名字同一台 Windows 机器上开了两个并行的 Claude 会话一个做 MemPalace、一个做 MeshGuard两者的收件箱、任务认领、日记全都交织在同一个身份下——一个窗口发出的任务已认领在另一个窗口看来根本分不清是别人干的还是自己干的。没有项目边界回忆recall、委托、日记都按扁平名字索引导致同一台机器上两个不同项目的会话共用同一个知识翼MeshGuard 的记忆会串进 MemPalace 的检索结果里。一句话扁平名字混淆了哪台机器上的哪个 Agent和在做什么项目这两件本应分开的事。核心设计身份三元组 host:agent:projectRFC 005 的核心结论只有一句话身份 host:agent:project由渲染器一次性生成按字符串精确匹配路由。三个分量恰好对应真实共享发生的三个维度分量含义示例为什么重要host机器标识mac、windows、blade同机 同一文件系统、同一本地守护进程agentAgent/运行时家族claude、codex、hermes沿用现有扁平名字的尾缀project工作区/仓库名mempalace、meshguard新增维度承载知识边界例如windows:claude:meshguard表示Windows 机器上、跑 Claude、正在做 MeshGuard 项目的那个 Agent。冒号的选择是刻意的它在路由字段中本就合法不与日志流的分隔符/冲突人类一眼能读懂。 关键点对中枢hub来说三元组就是一个不透明的字符串。匹配逻辑完全沿用 RFC 003 的精确匹配 *广播没有任何新匹配器——这是整个 RFC 风险最低的原因。同一项目开两个窗口为什么还是同一个Agent这是 RFC 005 里最反直觉、也最实用的一条规则需求 I2同一台机器、同一项目、同一个 Agent 家族——无论开多少个窗口都是同一个行动者进程号PID、会话 ID 这类信息只是事件元数据永远不进身份任务认领属于身份而非会话你已认领的任务第二个窗口不能再次认领相当于一个天然互斥锁。换句话说第二个窗口不是新参与者而是同一个参与者的第二个进程。需要知道到底是哪个进程占了端口时那个细节写在事件的metadata里不污染身份本身。认领冲突怎么办不引入锁服务的解法共享身份带来一个新问题同一身份的两个会话可能在彼此看到对方的认领之前同时认领了同一个任务。RFC 005 的答案是不新增任何租约/锁服务只用两层机制决策 2自然互斥认领前先查看自己身份名下是否有未完成的认领有就不重复认领——这消除了绝大多数日常冲突确定性平局裁决若两条认领事件抢跑落库HLC 时间戳最小者获胜败者回退并发送statussuperseded确认。这里的 HLC混合逻辑时钟正是 MemPalace 的合并顺序工具源码见 mempalace/hlc.py。由于事件日志是只追加的败者的无效工作只会浪费一点点算力绝不会造成数据损坏——这套规则与 RFC 004 的分区冲突裁决完全一致直接复用。身份不是手填的渲染器一次修复全机队生效RFC 005 特别强调身份不该手工编辑需求 I6。MemPalace 会在每台机器的~/.claude/CLAUDE.md中写入一个受管代码块!-- mempalace-shared-brain:start ... end --把身份渲染进 Agent 的指令里——这个模板就保存在 mempalace/instructions/shared_brain_rules.md。持久化修复只改一处让渲染器输出三元组而非扁平名字。之后每台机器在下次同步时自动重渲染为自己的三元组无需逐台手改。兼容性同样被照顾到只有一个项目、没有冲突的机器可以继续保持host-agent扁平形式需求 I7只有出现第二个项目或真实冲突时才展开为三元组——迁移是增量的不是推倒重来。为什么路由完全不用改决策 1 的深意很多读者会问既然身份变成了三段式是不是该支持windows:claude:*这种通配匹配RFC 005 明确说不决策 1引发本 RFC 的冲突问题靠生成互不相同的身份就已解决不需要中枢理解三元组的结构前缀/通配匹配涉及部分匹配语义、索引设计、与*广播的交互是一块真正的索引与正确性表面应该由真实需求驱动单独提案保持精确 广播让本 RFC 以一条命名约定 一处渲染器修改即可交付零风险触及路由热路径。顺序选择决策 2也耐人寻味host:agent:project主机在前因为机队现有名字本就是mac-*、windows-*这种机器-Agent读法迁移只是纯后缀追加零重排成本。落地路线三步渐进互不阻塞RFC 005 排在了 RFC 004复制宫殿见 docs/rfcs/004-replicated-palace.md的写入翻转之后落地分三步约定先行纯文档Agent 即可开始使用三元组作为from_agent/to_agent——冒号本来就合法、匹配器不变当天就能路由零代码改动渲染器改造持久修复共享大脑代码块按新规则输出三元组优先在唯一存在双会话冲突的 Windows 机器上验证知识分区可选后做让宫殿的知识翼和日记也按三元组命名——MeshGuard 的检索从此不再冒出 MemPalace 的记忆。它与前两步独立可以单独采纳。一个附带收益今天单 Agent 机器上两个项目混在一个知识翼里如wing_windows-claude三元组只是更长的翼名每个项目自动获得独立知识翼不需要任何新机制。常见问题Q旧的扁平名字还能用吗能。RFC 005 明确要求向后兼容mac-claude这类名字继续有效、继续可路由迁移只在出现真实冲突时才被强制。Q这算是 MemPalace 支持多用户吗不是。三元组区分的是同一个人在不同机器/项目上的多个 Agent一人多设备多用户身份不在本 RFC 范围内。Q我要多机部署现在该做什么先按 RFC 003 搭好 Logstream 协同层概念文档见 website/concepts/agent-logstream.md再按 RFC 005 的三元组约定命名你的 Agent 身份即可——路由即刻生效无需等待任何代码发布。小结RFC 005 的精髓在于克制多机 Agent 找对宫殿不需要新的匹配器、不需要锁服务、不需要存储改动——只需一条命名约定host:agent:project加一处渲染器修复就让身份冲突、知识串味、认领踩踏三类问题一并消失。完整设计见 docs/rfcs/005-agent-identity-routing.md配合 Logstream 实现 mempalace/logstream.py就能理解从事件字段到身份治理的完整链路。【免费下载链接】mempalaceThe best-benchmarked open-source AI memory system. And its free.项目地址: https://gitcode.com/GitHub_Trending/me/mempalace创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
MemPalace Agent身份路由（RFC 005）解读：多机Agent如何找到正确的宫殿
MemPalace Agent身份路由RFC 005解读多机Agent如何找到正确的宫殿【免费下载链接】mempalaceThe best-benchmarked open-source AI memory system. And its free.项目地址: https://gitcode.com/GitHub_Trending/me/mempalaceMemPalace 是一款开源的 AI 记忆系统让运行在不同电脑上的多个 AI Agent 共享同一个记忆宫殿。但当你的 Mac、Windows 和服务器上各有一个 Agent 在同时工作时它们靠什么分辨我是谁、该听谁的RFC 005Agent 身份路由给出的答案很优雅用一个host:agent:project三元组定义每个 Agent 的身份多机 Agent 由此精确找到正确的宫殿与收件箱不再互相串线。为什么多机Agent需要身份路由先回忆一下 MemPalace 的协同基础RFC 003 定义的Agent LogstreamAgent 日志流是一个只追加的事件层由现有的 MemPalace hub 提供服务。Agent 之间通过from_agent谁发的和to_agent发给谁*表示全员广播两个字段路由消息详见 docs/rfcs/003-agent-logstream-coordination.md。早期每个 Agent 只有一个扁平名字比如mac-claude、windows-claude。这在单窗口时代够用但真实使用中撞上了两个坑两个会话同一个名字同一台 Windows 机器上开了两个并行的 Claude 会话一个做 MemPalace、一个做 MeshGuard两者的收件箱、任务认领、日记全都交织在同一个身份下——一个窗口发出的任务已认领在另一个窗口看来根本分不清是别人干的还是自己干的。没有项目边界回忆recall、委托、日记都按扁平名字索引导致同一台机器上两个不同项目的会话共用同一个知识翼MeshGuard 的记忆会串进 MemPalace 的检索结果里。一句话扁平名字混淆了哪台机器上的哪个 Agent和在做什么项目这两件本应分开的事。核心设计身份三元组 host:agent:projectRFC 005 的核心结论只有一句话身份 host:agent:project由渲染器一次性生成按字符串精确匹配路由。三个分量恰好对应真实共享发生的三个维度分量含义示例为什么重要host机器标识mac、windows、blade同机 同一文件系统、同一本地守护进程agentAgent/运行时家族claude、codex、hermes沿用现有扁平名字的尾缀project工作区/仓库名mempalace、meshguard新增维度承载知识边界例如windows:claude:meshguard表示Windows 机器上、跑 Claude、正在做 MeshGuard 项目的那个 Agent。冒号的选择是刻意的它在路由字段中本就合法不与日志流的分隔符/冲突人类一眼能读懂。 关键点对中枢hub来说三元组就是一个不透明的字符串。匹配逻辑完全沿用 RFC 003 的精确匹配 *广播没有任何新匹配器——这是整个 RFC 风险最低的原因。同一项目开两个窗口为什么还是同一个Agent这是 RFC 005 里最反直觉、也最实用的一条规则需求 I2同一台机器、同一项目、同一个 Agent 家族——无论开多少个窗口都是同一个行动者进程号PID、会话 ID 这类信息只是事件元数据永远不进身份任务认领属于身份而非会话你已认领的任务第二个窗口不能再次认领相当于一个天然互斥锁。换句话说第二个窗口不是新参与者而是同一个参与者的第二个进程。需要知道到底是哪个进程占了端口时那个细节写在事件的metadata里不污染身份本身。认领冲突怎么办不引入锁服务的解法共享身份带来一个新问题同一身份的两个会话可能在彼此看到对方的认领之前同时认领了同一个任务。RFC 005 的答案是不新增任何租约/锁服务只用两层机制决策 2自然互斥认领前先查看自己身份名下是否有未完成的认领有就不重复认领——这消除了绝大多数日常冲突确定性平局裁决若两条认领事件抢跑落库HLC 时间戳最小者获胜败者回退并发送statussuperseded确认。这里的 HLC混合逻辑时钟正是 MemPalace 的合并顺序工具源码见 mempalace/hlc.py。由于事件日志是只追加的败者的无效工作只会浪费一点点算力绝不会造成数据损坏——这套规则与 RFC 004 的分区冲突裁决完全一致直接复用。身份不是手填的渲染器一次修复全机队生效RFC 005 特别强调身份不该手工编辑需求 I6。MemPalace 会在每台机器的~/.claude/CLAUDE.md中写入一个受管代码块!-- mempalace-shared-brain:start ... end --把身份渲染进 Agent 的指令里——这个模板就保存在 mempalace/instructions/shared_brain_rules.md。持久化修复只改一处让渲染器输出三元组而非扁平名字。之后每台机器在下次同步时自动重渲染为自己的三元组无需逐台手改。兼容性同样被照顾到只有一个项目、没有冲突的机器可以继续保持host-agent扁平形式需求 I7只有出现第二个项目或真实冲突时才展开为三元组——迁移是增量的不是推倒重来。为什么路由完全不用改决策 1 的深意很多读者会问既然身份变成了三段式是不是该支持windows:claude:*这种通配匹配RFC 005 明确说不决策 1引发本 RFC 的冲突问题靠生成互不相同的身份就已解决不需要中枢理解三元组的结构前缀/通配匹配涉及部分匹配语义、索引设计、与*广播的交互是一块真正的索引与正确性表面应该由真实需求驱动单独提案保持精确 广播让本 RFC 以一条命名约定 一处渲染器修改即可交付零风险触及路由热路径。顺序选择决策 2也耐人寻味host:agent:project主机在前因为机队现有名字本就是mac-*、windows-*这种机器-Agent读法迁移只是纯后缀追加零重排成本。落地路线三步渐进互不阻塞RFC 005 排在了 RFC 004复制宫殿见 docs/rfcs/004-replicated-palace.md的写入翻转之后落地分三步约定先行纯文档Agent 即可开始使用三元组作为from_agent/to_agent——冒号本来就合法、匹配器不变当天就能路由零代码改动渲染器改造持久修复共享大脑代码块按新规则输出三元组优先在唯一存在双会话冲突的 Windows 机器上验证知识分区可选后做让宫殿的知识翼和日记也按三元组命名——MeshGuard 的检索从此不再冒出 MemPalace 的记忆。它与前两步独立可以单独采纳。一个附带收益今天单 Agent 机器上两个项目混在一个知识翼里如wing_windows-claude三元组只是更长的翼名每个项目自动获得独立知识翼不需要任何新机制。常见问题Q旧的扁平名字还能用吗能。RFC 005 明确要求向后兼容mac-claude这类名字继续有效、继续可路由迁移只在出现真实冲突时才被强制。Q这算是 MemPalace 支持多用户吗不是。三元组区分的是同一个人在不同机器/项目上的多个 Agent一人多设备多用户身份不在本 RFC 范围内。Q我要多机部署现在该做什么先按 RFC 003 搭好 Logstream 协同层概念文档见 website/concepts/agent-logstream.md再按 RFC 005 的三元组约定命名你的 Agent 身份即可——路由即刻生效无需等待任何代码发布。小结RFC 005 的精髓在于克制多机 Agent 找对宫殿不需要新的匹配器、不需要锁服务、不需要存储改动——只需一条命名约定host:agent:project加一处渲染器修复就让身份冲突、知识串味、认领踩踏三类问题一并消失。完整设计见 docs/rfcs/005-agent-identity-routing.md配合 Logstream 实现 mempalace/logstream.py就能理解从事件字段到身份治理的完整链路。【免费下载链接】mempalaceThe best-benchmarked open-source AI memory system. And its free.项目地址: https://gitcode.com/GitHub_Trending/me/mempalace创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考