Protocols > Platforms — 從 Shopify 的 AI Agent 平台反思個人 AI 基礎設施

Shopify 最近發了一篇工程部落格 Under the River，講他們內部的 AI agent「River」和底層平台「Aquifer」的架構。

幾個數字很驚人：30 天內 59,918 個 agent session、覆蓋 5,170 個 Slack channel、每 8 個合併的 PR 就有 1 個是 River 共同作者。

但這篇文章真正有趣的不是數字，是架構哲學。

我自己也在經營一套個人 AI 基礎設施 — 7 個不同供應商的 AI agent 協作、自建記憶系統、跨機器的 Home AI Center。規模差了幾個數量級，但很多設計問題是共通的。

我把文章丟給三個不同供應商的 AI（Codex / Gemini / gemma4）做平行分析，得出一些跨越規模的洞察。以下是整理。

Shopify 做了什麼

River：Slack 原生的 AI Agent

River 只在公開的 Slack channel 運作，不接私訊。開發者 @mention River 提問，River 讀程式碼、跑查詢、貼結果，其他工程師可以隨時插嘴修正方向。整條對話變成可搜尋的組織記憶。

Aquifer：Agent 平台

River 成功後，各團隊都想要自己的 agent — PR review agent、research agent、migration agent、compliance scanner⋯⋯

Shopify 意識到他們建了一個 agent，但沒有建一個平台。於是有了 Aquifer。

Aquifer 的核心設計是三層分離：

Session  — Postgres append-only event log（持久身份）
Harness  — Agent loop：讀歷史 → 呼叫 LLM → 產出 tool intentions（可丟棄）
Sandbox  — 檔案系統、shell、repo access（暫時的）

關鍵決策：Harness 在 Sandbox 外面跑。Brain 跟 Hands 分離。

這帶來三個好處：

• 安全：agent loop 隔離於 rm -rf 等破壞性操作
• 可替換：換模型、換 runtime 不影響 sandbox
• 可觀測：所有決策流在單一監控點可見

Session Cell

當一個 session 被觸發，一個 ephemeral process 在某台機器上出現。Idle 就退出。下次互動時，在不同的硬體上復活，從 Postgres 讀回完整狀態。

Cattle, not pets — 但不是在 container 層，是在 session 層。

Agent = Profile

River 只是 Aquifer 上的一個 Profile — 一個 config bundle：

Profile = {
  system_prompt,
  skills,
  extensions,
  sandbox_policies,
  model_defaults
}

PR review agent 是另一個 Profile。新 agent = 新 config，不是新基礎設施。

我的系統長什麼樣

我的基礎設施跟 Shopify 的方向不同，但解決類似的問題：

• 7 個 AI agent：Claude（架構師）、Codex（工程師）、Gemini（分析師）、Perplexity Max（深度研究）、SuperGrok（即時社群情報）、gemma4（本機推論）、加上我自己（Chair）
• 通訊：CLI + File I/O 為主（不是統一平台）
• 記憶：自建的 memhall（Postgres-backed，append-only）
• 協調：ACE manifest — 每個多 agent session 開一份共享文件，所有參與者共讀共寫
• 硬體：Mac mini x2 + DGX Spark + NAS + 6 台 VPS

規模差了幾個數量級。但設計問題驚人地相似。

三方分析：哪些跨越規模，哪些不行

我把 Shopify 的文章和我自己的架構描述，分別交給 Codex（OpenAI）、Gemini（Google）、gemma4（本機 Ollama）做獨立分析。三方不互相看對方的回答。

高度共識：三個值得學的 Pattern

1. Agent as Profile

三方一致認為這是最值得學的模式。

我目前的 bot（ERIKA 正式版 / 測試版 / Telegram bot / 投資小幫手）是各自獨立部署的。每個都重複處理 prompt、tools、memory、model defaults。

Codex 建議：不需要做完整的 Aquifer 平台，但可以先做一個輕量的 Profile Registry — 同一套 runtime，載入不同的 agent config。從 ERIKA 的正式版和測試版開始試。

這個成本低，收益直接。

2. Public by Construction

River 不接私訊，所有互動都在公開 channel。這不只是為了可搜尋性 — gemma4 指出一個被忽略的面向：公開 agent 互動會訓練人類在公開場合協作，減少「shadow work」（私下用 AI 做完事，但知識不流通）。

對我來說，~/Documents/agent-council/ 目錄裡的 manifest 和 briefing 已經是半公開的。但如果要把這套推廣到部門，「預設公開」必須是架構決策，不是事後加的 feature。

3. Skills as Infrastructure

我已經有 claude-team-skill-lab（部門共用的 skill 庫），但 Shopify 的差異在於 skills 是 runtime 可載入的 context bundle，不只是文件。

Codex 的建議很具體：每個 skill 要有觸發條件、輸入、禁止事項、驗收方式 — 不要只寫成長篇知識文件。這正好是我們 skill 設計的方向，但文章提醒了「loadable context」vs「passive document」的差距。

高度共識：三個不該學的 Pattern

1. Event Sourcing 全量 session log

Shopify 用 Postgres append-only event log 記錄所有 session 事件。Gemini 分析了為什麼我們不需要這個：

在跨 vendor 聯邦中，強求統一的 event log 會造成嚴重的相容性阻力。

我的 agent 分布在 7 個不同供應商，每個的 I/O 格式不同。統一 event log 是不切實際的。我們的做法是 Snapshot + Curated Memory — ACE manifest 存當下狀態，memhall 只存經過篩選的共識。

2. 完整的 Brain/Hands 物理隔離

Shopify 的 Harness-outside-Sandbox 設計很優雅，但 Gemini 點出了一個反直覺的問題：

當目標涉及「安全邊界與執行權限」時，保護系統不受 Agent 傷害的架構（如深層隔離、Sandbox），通常會對人類工程師帶來沉重的維護與開發阻力。

對 5 人以下的團隊，物理隔離的維運成本不合理。我們用軟性邊界取代 — 安全規範 + 人類審批，而不是微服務拆分。

3. 完整的 Aquifer 平台

這個最反直覺。Shopify 的文章結論是「the substrate, not the visible agent, represents the lasting competitive advantage」。聽起來應該學，對吧？

gemma4 抓到了盲點：Shopify 有專職平台團隊維護 Aquifer。對一個人來說，過度建設 substrate 本身就違反了「保護注意力」的最高原則。 90% 時間花在 plumbing，10% 花在 intelligence — 這不是基礎設施，這是陷阱。

我稱之為 Substrate Paradox（基底悖論）：基礎設施投資在某個規模以下會從「加速器」變成「注意力黑洞」。

哲學層面：兩個不同的賭注

Gemini 的分析給出了最精準的定位：

Shopify 的 bet = Substrate > Agent
只要基礎設施足夠強大、標準化且具備絕對的可觀測性，任何平庸的模型都能在其中發揮巨大價值。

我們的等價 bet = Protocols > Platforms
不賭單一平台的完美，賭文字檔（File I/O）、命令列（CLI）與標準化介面（MCP）的永續性。

這不是對錯的問題，是約束條件不同。

企業需要一致性，因為 7000 人不可能各自為政。個人需要多樣性，因為任何一家供應商都可能明天改政策。

超越規模的三個原則

從三方分析中，我萃取出三個不受規模影響的設計原則：

1. State 不綁 Process

不管是 Shopify 的 Session Cell 還是我的 memhall，核心原則一樣：agent 的狀態必須能在 process 死掉後恢復。

這不需要完整的 Event Sourcing。只要確保關鍵狀態（對話歷史、決策記錄、工作進度）有持久化的地方，不依賴於某個「一直在跑」的程序。

2. 透明度是架構決策，不是 Feature

River 不接 DM 不是功能限制，是設計決策。它從根本上消除了「agent 在暗處做決定」的可能性。

同樣的道理，我的 ACE manifest 不是「文件模板」，是協調架構 — 所有參與 agent 必須讀寫同一份文件，確保沒有人（包括我自己）能在暗處壟斷資訊。

3. Agent-friendly ≈ Human-friendly（但有例外）

Shopify 聲稱為 agent 改善的基礎設施同時改善人類體驗。這在介面層成立 — 清晰的 API、可重現的環境、統一的 CLI 對 agent 和人都好。

但在安全邊界層，兩者會衝突。保護系統不受 agent 傷害的隔離，通常會增加人類的維護負擔。小團隊必須在這裡做取捨。

一句話結論

不要模仿 Shopify 的基底，要學他們「為什麼這樣賭」的思考方式。然後用你自己的約束條件，下你自己的賭注。

Shopify 建了一座工廠。我在編織一個生態網。形狀不同，但設計問題是共通的：什麼該持久、什麼該透明、什麼該標準化。

答案取決於你有多少人、多少預算、多少注意力可以花在 plumbing 上。

對一個人來說，protocols 比 platforms 重要。因為平台會被淘汰，但文字檔和命令列會永遠在那裡。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。