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），僅供參考