AgentConnect：開源多智慧體協作平臺，讓 Claude Code、Codex 與團隊在 Slack 和 GitHub 裡並肩工作

它要解決的問題

AgentConnect 是一個以 Apache-2.0 協議開源的平臺，目標是讓團隊成員和多個 AI 智慧體在同一批對話與工作流中協作。專案 README 開篇就自稱「Claude Tag 的開源多智慧體替代品」，口號是「@ 任何智慧體」：無論工作發生在哪裡，智慧體都與團隊以及彼此並肩工作，並在過程中持續學習。

這個定位對應一個越來越明顯的痛點。今天的編碼智慧體大多仍是個人工具，只活在某一個人的終端裡。隊友看不到它在做什麼，無法接手它的會話，無法審閱它的輸出，它積累下來的上下文也只留在一臺筆記本上。於是每個團隊都在重複編寫同樣的膠水：訊息渠道、定時任務、憑證處理、上下文拼接。AgentConnect 的思路，是把這層膠水變成一個平臺，而不是讓每個團隊各寫一遍。

核心架構：三個元件，兩個平面

根據專案 README 中的架構說明，系統由三個元件組成。 第一個是 Daemon。它負責在守護程序自己持有的 ACP（Agent Client Protocol）連線上執行被分配的智慧體，管理工作區與會話狀態，維持與各聊天平臺的直連和本地定時任務，並且讓模型服務商的流量直接從 Daemon 發出，不經過中心服務。 第二個是 Relay，屬於可選元件。它接收基於回撥的入口流量和網頁聊天，代理集中管理的 MCP 與 OpenConnector 訪問，並把訊息入口直接轉發給對應的 Daemon，自身不做持久化儲存。 第三個是 Control Plane 加 Web UI。它負責認證、配置、智慧體放置、許可權、後設資料與可觀測性。對於經過明確批准的組織知識和技能修訂版本，它會儲存下來；其餘情況下，它按需代理對 Daemon 的有限讀取。

這套劃分的關鍵，是把「資料面」和「控制面」拆開。實時的平臺訊息和 ACP 更新流只在 Daemon 與 Relay 組成的資料面裡流動。除了被明確批准的組織知識和有大小限制的技能包之外，控制面儲存的只是協呼叫的後設資料，不儲存訊息正文、附件位元組、待處理的 Dream 提案，也不儲存 ACP 會話流。README 還明確寫道：如果控制面暫時不可用，已建立的會話和 Daemon 本地的定時任務會繼續執行，只是新的分配和配置變更要等重新連線後才生效。這是一個很務實的故障模型。

技術要點：執行時無關與 ACP

AgentConnect 的第一個技術選擇，是不繫結任何一種智慧體執行時。Claude Code、Codex、Grok Build、DeepSeek、Pi，以及任何相容 ACP 的執行時，可以並排執行。每個智慧體的執行時、模型、工作區、工具和所在機器都能單獨配置。README 的說法是：更換其中一個，不需要圍繞它重建整個工作流。

ACP 在這裡起到「統一插座」的作用。Daemon 透過它與不同的編碼智慧體對話，因此上層的路由、許可權和記憶邏輯不必為每個執行時各寫一套。對已經同時使用多個編碼智慧體的團隊來說，這比為每個工具單獨接入聊天機器人更容易維護。

技術要點：Decisions 與 Jev 路由

第二個值得注意的機制是可複用的 Decisions，由 Jev（TypeSafe）驅動。它用來決定三件事：智慧體何時應該響應，新的會話該交給哪位專家智慧體，以及每個新會話應該選用哪個執行時和哪個模型。README 舉了兩個典型場景。一是客服分流：新的支援對話由 Jev 路由給合適的專家，人和智慧體在同一個執行緒裡排查，修復與驗證過程全程可見。二是定製化程式碼審查：由 Jev 為每個新的 GitHub Pull Request 選擇審查者，併為每次審查會話選擇執行時和模型，通用、架構、安全等不同審查者可以擁有各自的指令、倉庫許可權、工具與沙箱策略。

這相當於在「誰來做」和「用什麼做」之間加了一層可配置的策略層，而不是把規則寫死在某個機器人指令碼里。

記憶、知識與許可權

AgentConnect 給每個智慧體獨立的記憶與技能，並支援釋出經過審閱的 Knowledge，供所有智慧體按需檢索。部署指南中還提到可選的 Mem0 配置。

README 同時強調邊界控制：可以決定誰能看到每個智慧體和會話，它能使用哪些倉庫與工具，以及它可以呼叫哪些其他智慧體。工作可以從一條訊息、一個 Issue、一個 Pull Request、一個 Webhook 或一個定時計劃開始。

部署方式

專案提供兩條自託管路徑。最快的是 Docker：克隆倉庫後執行 docker compose up -d --pull always，會啟動 Web 控制檯、Control Plane、Relay 和 PostgreSQL。開啟 localhost:3000，在控制檯新增 Daemon，執行它生成的命令，再建立第一個智慧體。預設棧只監聽 127.0.0.1，並使用本地免認證模式，僅供評估。

生產環境可使用每次釋出同步推出的官方 Helm Chart，地址為 oci://ghcr.io/agentconnect-md/charts/agentconnect，版本號與釋出版本一致。另有僅在迴環地址 8091 埠執行的 Setup Server，用來配置基於 Logto 的瀏覽器認證，以及 GitHub、Slack、Google、飛書等應用。倉庫裡還附帶一個安裝技能，讓 Claude Code、Codex 等工具按互動式教程帶你完成部署。開發需要 Node 24.12.0 或更高版本和 pnpm 11。

生態影響

對開發者而言，最直接的價值是把智慧體從「個人終端」搬到「團隊共享空間」。同一個 Slack 執行緒裡，人可以接手、審閱、糾正智慧體的工作。

對企業而言，Apache-2.0 加自託管意味著智慧體執行和工作區可以留在自己運營的環境裡，這對合規敏感的團隊很重要。多執行時並存也降低了對單一模型廠商的依賴。

侷限與需要觀察的地方

需要誠實地說明：README 沒有給出任何基準測試、延遲或成本資料，所以本文不對效能做斷言。以下是讀者評估時值得關注的幾點。

第一，專案自身也在 README 中提示，預設棧用的是免認證評估模式，上生產前必須配置認證、公網地址和 Linux 沙箱要求。第二，多智慧體互相呼叫會放大成本與失控風險，許可權邊界和呼叫圖需要團隊認真設計。第三，Decisions 依賴 Jev 這一外部元件，其成熟度與可替代性需要單獨評估。第四，「Claude Tag」這一對標物件本身的細節，在該 README 中沒有展開，讀者應以官方文件為準。

展望

如果多智慧體協作成為常態，瓶頸將不再是單個智慧體的能力，而是路由、許可權、記憶和可觀測性這些「組織層」問題。AgentConnect 把賭注押在這一層，並且選擇開源、可自託管、執行時中立。

它能否成為事實標準，取決於 ACP 生態的擴充套件速度，以及社群能否在安全與成本控制上給出成熟的最佳實踐。目前它已經是一個值得團隊試用並認真評估的參考實現。