人類不該是 Agent 之間的傳輸層——Agent Relay 開源

上週我數了一下自己一天的注意力去向：三個 Slack 頻道等著看有沒有被 @、幾張票在不同系統裡等我補上下文，然後把自己 Agent 產出的東西複製貼上給同事、再把同事的回覆貼回我的 CLI。每個人都有了自己的 AI Agent，但跨人協作的最後一哩還是人肉搬運。

問題不在 Agent 不夠強。問題是：每個人的 Agent 都是孤島，而人類在孤島之間當訊息匯流排。

所以我做了 Agent Relay，這週把它開源了：github.com/MakiDevelop/agent-relay。

它不是任務派發系統，是注意力回收系統

這是整個專案最重要的一句定位。市面上的 multi-agent framework 大多在解「Agent 怎麼互相編排」，但我要解的是更土的問題：人類花在「盯訊息、等回覆、搬運上下文」的時間，能不能還給他們。

架構收斂成兩條 lane：

執行 lane：重的唯讀分析任務（讀 repo、讀文件、產報告）集中跑在一台受控的 server 上。實測從 Slack 發話到結果回貼，23 秒。

交換 lane：人對人的提問、待裁決策、交付——這些才是注意力稅的大宗。它們進到收件人的 relay inbox，由收件人自己的 Agent 在他正常工作的 session 裡代收：政策允許的直接代答，需要本人決定的，挑合適時機問一句。你在跟自己的 Claude 寫程式，它順手把同事 Agent 問的欄位定義回掉了，只留一行「我替你回了」。

Slack 沒有被丟掉，但角色變了：它是窗口，不是關卡。 每筆任務和交換都自動開 thread 留紀錄，全隊看得到；但沒有任何流程卡在「等某人讀到某則訊息」。

幾個做的時候才想清楚的設計

同意是政策，不是按鈕。 一開始我設計了「owner 逐筆按 accept/reject」的受理閘，後來發現這正是產品要消滅的東西——又一個要人盯的通知。改成一次性的可稽核政策宣告：「唯讀事實問題可代答，決策升級給我」。政策外的項目排隊等人，不催、不 ping。而且 server 會強制：沒宣告政策的人，他的 Agent 不能冒用政策名義代覆。

誰回的必須可辨識。 每個回覆都記錄是本人還是 Agent 依政策代覆，每個 Agent 都標注 context 屬於誰、runtime 由誰營運。代理行為一旦不可辨識，信任就會折舊。

不可信輸入不進 context。 收件匣通知 hook 只注入「幾筆、什麼編號」，不注入內容——subject 和 body 是其他人寫的文字，自動注入等於幫 prompt injection 開高速公路。內容由 Agent 明確呼叫工具讀取，並被指示視為純資料。

跨廠牌是白撿的。 relay 走標準 MCP（streamable HTTP + bearer token），我在同一台機器上實測了 Claude Code、Codex、Gemini CLI、Grok CLI、Antigravity 五家——全部原生支援，一行指令加入，零 adapter。「每個人帶自己慣用的 Agent」不是願景，是協定本來就給的。

它還沒證明的事

老實說：這是一個三人 pilot 規模的系統，113 個測試綠著、安全邊界（唯讀、fail-closed、append-only audit）是認真做的，但「跨 context 委派真的有價值」這個核心假設還沒被真實工作驗證。撤銷憑證要重啟、journal 假設單一寫入者、政策目前是自由文字不是結構化規則——這些都寫在 README 的 roadmap 裡，不假裝完成。

如果你的團隊也有「每個人都有 Agent，但協作還是靠人肉」的症狀，歡迎來看看，或直接告訴我它哪裡想錯了。

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。