MEX 評測：把團隊記憶寫進 Git 的 AI 代理上下文層

為什麼「上一個人的上下文」值得一個獨立工具

專案裡總有幾類知識沒有自然歸屬。某個限制條件為什麼存在，只有當初踩過坑的人知道；某段除錯歷史留在某次代理對話裡，沒有人會再打開；某個邊界情況是代理在單次工作階段發現的，下一個接手的人得從頭推一遍。這些內容既不適合寫進程式碼註解，也不適合塞進 issue 追蹤系統，因為它們要跟程式碼一起被檢視、一起被版本控制。

MEX 的定位就是把這類知識放進 repository，用可讀的 Markdown 保存，並透過 Git 的 commit、push、pull 傳遞。README 把要保留的東西分成幾類：Wiki 記錄系統如何運作與為什麼，Inbox 承接值得分享的提案，Specs 保留既有需求與驗收條件，Relays 保存交接進度與待辦，Members 與 Activity 記錄參與者與事件歷史。

目標讀者很明確：已經讓編碼代理參與日常開發，並且發現「每個人的代理都從零開始」是浪費的團隊。README 也直接點出單人情境，下一個使用這份記憶的人可以是新工作階段的你自己。這個說法合理，但單人使用時 Git 的共享價值並不存在，剩下的只是本機檔案組織。

檔案進 Git，索引留本機：MEX 的資料流

README 對架構的說明集中在一個區分上：canonical memory 隨一般 Git 操作移動，而每個成員保有自己的本機索引、草稿、身分選擇與 Hub。圖說寫得很直白，一位工程師與其代理貢獻共享記憶，另一位隊友在獨立 checkout 中重用，各自擁有本機索引。

這個切法決定了幾件事。第一，不需要託管的 MEX 服務、Docker、代理伺服器、MEX 帳號或 MEX 持有的模型金鑰。第二，衝突不會發生在伺服器端，而是發生在 Git 合併時，這代表團隊原本的程式碼審查流程可以直接套用到記憶檔案上。第三，索引是本機產物，所以換一台機器或新進成員要重新建立索引，這在 README 的範例步驟裡以「視需要更新本機索引」帶過。

程式碼關聯由 Code Graph 提供。README 提到 Wiki 的架構、決策、慣例與模式都帶有 Code Graph grounding，Hub 的 Context 檢視會顯示知識實體與關係，選取某一項可以看到它直接關聯的程式碼依據。技術棧標籤列出 tree-sitter，這與程式碼解析的需求一致，但 README 沒有說明支援哪些語言、解析到什麼粒度，這是要自行驗證的部分。

v0.8.1 的說明提到 Hub 在 Graph 建構期間仍能繼續處理請求，v0.7.3 的標題則是圖形效能與復原。從版本節奏看，Code Graph 是近期改動的重心，也意味著這部分的行為可能還在調整。

Relay 交接的邊界：發布不等於送達

Relay 是這個專案最有意思也最容易被誤解的設計。README 的範例流程是：Alex 請代理以 $mex-relay 起草一份給 Sam 的 Relay，內容包含改了什麼、跑了哪些測試、還剩什麼、接下來該看哪裡；她在 Hub 檢視草稿與發布預覽，明確發布，然後透過 Git 檢視、提交並推送程式碼與 canonical MEX 檔案；Sam 拉取分支後在 Hub 檢視並接收 Relay，他的確認動作同樣是一次需要提交推送的 canonical 變更。

關鍵限制寫在範例之後：Relay 攜帶的是說明與觀察到的 repository 狀態，不是未提交的程式碼。發布只會把檔案寫進 Alex 的 checkout，不會通知 Sam，也不會遞送任何東西，直到他們透過 Git 共享。這句話值得反覆讀，因為它劃清了工具與通訊軟體的界線。MEX 不會取代「跟隊友說一聲」，它只保證你說的那一聲有地方落腳。

README 另有一句提醒，Relay 的生命週期與並行細節請見 Relay boundaries 一節，但提供的材料在此截斷。並行發布同一份 Relay 會發生什麼、接收後能否撤銷、多個成員同時編輯同一份 Wiki 檔案如何處理，這些都無法從現有資訊確認。如果你的團隊有高頻交接需求，這幾點應該在試用階段就測出來，而不是等到正式導入才發現。

安裝與最小可用設定

套件名稱是 mex-agent，可從 npm 取得。執行環境要求 Node.js 22.5 以上，語言是 TypeScript 5.9，授權為 MIT。

README 提供的 Quick start 章節在本次素材中沒有展開，因此無法給出完整的初始化指令序列。可以確認的是專案以 CLI 為主要操作介面，README 有獨立的 Command map 章節，並提到代理透過專案指令與 CLI 檢索和維護記憶。代理端的整合方式包含 Claude Code skills，範例中出現 $mex-relay 這種呼叫形式，以及對 Codex 下指令的敘述。

專案同時標示為 MCP server，但徽章寫的是 source only。這表示 MCP 整合目前不透過套件直接提供，需要從原始碼取得。對已經在用 MCP 串接工具的團隊，這是一個要先確認的安裝路徑問題。

Hub 是本機服務，用於瀏覽 Wiki 與程式碼、審核 Inbox 提案與 Specs、協調 Relays 與成員。README 強調 Hub 在 Graph 建構期間仍可服務請求，這是 v0.8.1 的改進項目，暗示更早版本在這段期間可能無法使用。

具體的設定鍵名稱在素材中沒有出現，只有 Hub、Inbox、Relay、Members、Activity 這些功能區塊名稱。若你需要確切的 config key，得直接查閱 repository 的說明文件。

Inbox 的人工關卡是特色也是成本

MEX 對知識進入正式記憶的路徑設計得相當保守。代理可以更新 Wiki 說明與程式碼引用，但對於團隊應該審視的結論，它準備的是 Inbox 知識提案，等待明確核准。README 用「explicit approval」描述這個動作。

這個選擇有明確理由：讓代理直接改寫團隊的架構文件，風險太高。但代價也要說清楚。提案需要有人讀、有人判斷、有人核准，這是持續的人力投入。如果團隊沒有指定誰負責消化 Inbox，它會變成另一個堆積待辦的地方，而且堆積的是團隊自己代理產出的內容，心理負擔可能比外部 issue 更重。

另一個細節是 Specs 與 Workstream 的措辭。README 說既有的 Specs、需求、限制與驗收條件「remain supported」，既有的 Workstream 記錄「remain readable」。這種寫法通常意味著這些是較早版本的功能，目前處於維護而非發展狀態。新導入的團隊如果把 Specs 當成主要工作流，可能會發現文件與實際重心有落差。

什麼情況下這是錯的工具？如果團隊的知識主要存在於會議與口頭討論，而且沒有人願意把它寫成 Markdown，MEX 不會改變這件事，只會多出一個空的目錄結構。它獎勵願意寫的人，不強迫不願意寫的人。

與單純的 AGENTS.md 慣例相比差在哪

最直接的替代方案不是另一個產品，而是倉庫根目錄放一份 AGENTS.md 或 CLAUDE.md，再加上團隊自己的文件慣例。兩者都放在 repo 裡、都走 Git、都不需要額外服務，差別在結構與流程。

單一檔案的做法是扁平的。所有指示擠在一起，代理每次都要讀完整份，也沒有人知道哪一條是誰在什麼時候為了什麼加的。MEX 把它拆成 Wiki、Inbox、Relays、Members 等有型別的實體，加上 Code Graph 把說明連到實際程式碼位置，再加上 Hub 作為檢視與審核介面。這些結構讓「這條知識從哪來、關聯到哪段程式碼、誰核准的」有答案。

代價是複雜度。單一 Markdown 檔案不需要 Node.js 22.5、不需要本機索引、不需要理解 canonical 與本機狀態的區別、不會遇到 Graph 建構期間的行為問題。MEX 換來的是可審核性與可檢索性，但這只有在知識量超過某個門檻後才划算。十條規則用一份檔案就好，兩百條互相關聯的決策與交接才需要圖形與提案流程。

另一個差異是代理整合的深度。AGENTS.md 是純文字約定，任何工具都能讀。MEX 有自己的 CLI、專案指令與 skills，這帶來更緊密的整合，也帶來綁定。如果團隊之後換掉編碼代理，MEX 的檔案還在，但工作流程要重新接。

維護、授權與版本節奏

授權是 MIT，這是寬鬆授權，允許修改與再散布，通常只要求保留著作權聲明與授權條款。這裡不提供法律意見，實際條款以 repository 內的 LICENSE 檔案為準。對多數商業團隊而言，MIT 不會構成採用障礙。

維護成本主要來自兩處。一是記憶檔案本身需要人維護，Inbox 提案需要審核，Wiki 內容會隨架構變動而過時。二是 Code Graph 需要重建，README 提到 Hub 在 Graph 建構期間的服務能力，這暗示建構是一個需要時間的步驟，且會隨程式碼規模增長。

版本節奏可以從近期發布看出輪廓：v0.7.3 在 2026 年 8 月 26 日，v0.8.0 在 9 月 2 日，v0.8.1 在 9 月 9 日。三週內三個版本，且 v0.8.0 的主題是「整個團隊的專案記憶」，v0.8.1 加入 Context graph、Inbox 貢獻、開放給團隊的 Relays、可設定的代理日誌與更安全的 grounding。這是快速演進期的節奏，功能名稱與行為都還可能變動。

對照之下，0.8 這個版本號本身說明了成熟度：介於 0 與 1 之間，API 與檔案格式都還沒有穩定承諾。如果你的團隊對工具鏈變動敏感，這個階段導入需要接受偶爾的遷移工作。如果你們本來就習慣跟著快速迭代的開發工具走，這個節奏是可以接受的。

最後回到一個具體判斷：MEX 的價值取決於團隊是否真的會寫。README 的範例裡，Alex 主動請代理起草 Relay、檢視發布預覽、明確發布，這三步都需要人。工具把路鋪好了，走不走還是人的事。

編輯結論

MEX 適合已經在用 Claude Code、Codex 或 Cursor，且團隊願意把架構決策與交接寫成可審核檔案的工程組織；單人專案或不想在 repo 內新增記憶目錄的團隊則不必引入。採用前先確認三件事：Node.js 版本是否達到 22.5、團隊能否接受 Inbox 提案需要人工核准才進入正式知識、以及 MCP 伺服器目前僅支援原始碼安裝這件事是否會卡住你們的代理設定。

官方來源

1. License: MIT
2. mex-memory/mex on GitHub
3. Project website
4. README
5. Releases