Paperclip：把多個 AI Agent 組織成可治理的自動化團隊

當我們同時開啟多個 Claude Code、Codex 或其他 coding agent 時，真正困難的往往不是「如何再叫一個模型寫程式」，而是如何管理任務上下文、權限、成本、排程與責任歸屬。Paperclip 將這個問題往上抽象：它不是另一個 agent framework，而是一個用來協調 AI agent 團隊的開源 control plane。

Paperclip 的核心想法很直白：agent 負責工作，Paperclip 負責組織。使用者可以先定義公司或專案目標，再建立角色與回報關係，接著把不同 runtime 的 agent 接進來，由同一個 dashboard 管理任務、預算、審批與執行紀錄。對正在把 AI 從單次對話推向長時間自動化的團隊來說，這是一個值得拆開研究的架構。

閱讀導航

為什麼多 agent 系統需要 control plane
Paperclip 的核心模型：目標、組織、任務與 heartbeat
從成本控制到治理，Paperclip 解決了什麼問題
本機啟動與第一個實驗
適用場景、限制與導入建議

先釐清：Paperclip 不想取代 agent

Paperclip README 將自己的定位說得很清楚：它是 Node.js server 加上 React UI，用來協調一組 AI agent 執行工作。它不規定你要怎麼建造 agent，也不是聊天機器人、prompt manager 或拖拉式 workflow builder。

這個區分很重要。Claude Code、Codex、Cursor、Bash agent 或 HTTP bot 都可以是執行端；Paperclip 則處理執行端上方的管理問題。換句話說，Paperclip 不是把所有 agent 重新包裝成同一個模型，而是提供一層跨 runtime 的共同語言：誰負責什麼、任務從哪個目標而來、現在花了多少成本、下一步是否需要人批准。

這種分層也讓架構比較容易演進。當團隊替換模型或 agent runtime 時，組織目標、任務記錄與治理規則不必一起重寫；當工作從一個人擴大到多個 agent 時，也不需要繼續依賴一堆散落的 shell script、終端機分頁與手動提醒。

四個核心模型

1. Goal：讓 agent 知道「為什麼」

單一任務通常只描述「做什麼」，但多 agent 系統還需要知道「為什麼做」。Paperclip 將公司、專案、目標與 issue 串起來，讓任務保留完整的 goal ancestry。這代表 agent 取得的上下文不只是一張孤立的 ticket，而是可以一路追溯到更高層的組織目標。

這種設計能降低一個常見問題：每個 agent 都完成了局部工作，整體卻沒有朝同一個方向前進。當任務與父層目標有明確關聯，管理者可以檢查工作是否仍然值得執行，agent 也比較容易在遇到取捨時使用一致的優先順序。

2. Org chart：用角色與邊界取代一堆獨立 session

Paperclip 將 agent 視為有角色、職稱、回報線、權限與預算的組織成員。README 的示例包括 CEO、CTO、工程師、設計師與行銷角色，但重點不在於模仿人類公司，而在於把責任、委派與權限變成可追蹤的資料模型。

有了 org chart，管理者可以讓一個 agent 負責拆解目標，再把子任務委派給其他 agent；也可以把不同 agent 限制在特定公司、專案或工具範圍內。對需要同時管理多個產品或客戶環境的部署來說，這比把所有 bot 放在同一個共享工作區更容易維持隔離。

3. Issue 與 workspace：把工作變成可恢復的執行單位

Paperclip 的任務系統不只儲存標題。官方文件列出的 issue 關聯包含 company、project、goal、parent、blocker dependency、comment、document、attachment 與 work product；任務也使用 atomic checkout 與 execution lock，避免兩個 agent 同時搶同一份工作。

這裡的價值在於可恢復性。多 agent 系統不應該假設每次執行都一次成功，也不應該把上下文綁死在某個終端機視窗。Paperclip 以持久化 issue、session state、結構化 log 與 worktree workspace 保存執行狀態。即使服務重啟，agent 仍有機會從原本的任務脈絡繼續，而不是重新猜測上一輪發生了什麼。

4. Heartbeat：用事件與排程啟動工作

Paperclip 的 heartbeat 是把 agent 從「等人下指令」推向「依規則工作」的關鍵。agent 可以按照排程醒來，檢查自己的工作，或在任務指派、@mention 等事件發生時被喚起。README 也描述了 cron、webhook 與 API trigger，以及 concurrency 與 catch-up policy。

這讓週期性工作可以被建模為 routine，而不是由人記得手動啟動。例如每日整理客服資料、定期產生報告、檢查某個專案的測試結果，都可以留下可追蹤的 routine execution，並且建立對應 issue。重要的是，每次執行仍然會進入同一套預算、權限與稽核流程。

Paperclip 的治理層：讓自動化不等於放任自流

只要 agent 能長時間執行，治理就不是附加功能，而是系統邊界的一部分。Paperclip 將治理拆成幾個可操作的機制。

預算與成本硬停止

Paperclip 可依 company、agent、project、goal、issue、provider 與 model 追蹤 token 與成本，並設定 warning threshold 和 hard stop。當 agent 超過預算時，系統可以暫停它並取消排隊中的工作。這比事後才從帳單發現 agent 進入 runaway loop 更實用。

導入時，我會先為每個 agent 設定小額上限，再觀察正常任務的成本分布；確認 heartbeat 頻率、重試策略與工具呼叫都符合預期後，才逐步放寬。預算不是只為了省錢，也是讓實驗具有明確的爆炸半徑。

Approval、pause 與 audit log

Paperclip README 列出 board approval workflow、execution policy、review stage、decision tracking，以及 pause、resume、terminate agent 等治理操作。這讓高風險工作可以採用「agent 提案，人類核准，系統執行」的流程，而不是把所有權限一次交出去。

同時，mutating action、heartbeat 狀態、成本事件、審批、留言與 work product 都能形成 durable activity。當結果不如預期時，團隊可以回頭追查誰在什麼時間做了哪個決定，而不必只依賴模型產生的最後一段文字。

Secrets 與工具邊界

多 agent 部署最容易被忽略的是秘密與工具權限。Paperclip 描述了 instance secret、company secret、加密本機儲存，以及依 scope 將秘密注入特定 run 的機制；MCP tool gateway 與 plugin system 則提供延伸工具與受控能力的方向。

實務上，我不會把整個 .env 或 production token 放進所有 agent 都能讀取的 workspace。比較安全的做法是按照工作角色分配最小權限，將需要的秘密限定在一次執行、特定公司與特定工具，並讓每次使用都能在 activity log 中被追蹤。

從原始碼看它的形狀

Paperclip 的 control plane 可以用幾個模組理解：

Identity and Access：管理 board user、agent API key、run JWT、company membership 與邀請流程。
Org Chart and Agents：保存角色、職稱、回報關係、權限與預算，並透過 adapter 連接不同 runtime。
Work and Task System：處理 issue、依賴、留言、附件、工作產物與 atomic checkout。
Heartbeat Execution：管理 wakeup queue、預算檢查、workspace resolution、secret injection、skill loading 與 adapter invocation。
Governance and Approvals：提供審批、政策、決策紀錄、硬停止及完整 audit log。
Plugins、MCP 與 Observability：讓系統可擴充，並以 opt-in OpenTelemetry traces 或 Sentry error monitoring 觀察服務。

這個切法揭示一個架構判斷：Paperclip 的核心不是「如何呼叫一次 LLM」，而是如何把一次 agent run 放進可重試、可審批、可計費、可稽核的企業流程。這也是它和一般 agent framework 的差異。

本機啟動：先建立安全的小型實驗

官方 README 提供兩條快速路徑。直接使用 installer 時，官方建議先下載安裝腳本及其 SHA-256 檔案，完成檢查後再執行。README 同時提醒，checksum 與腳本來自同一個來源；若需要獨立驗證，應改用 release tag 或 commit pinned 的 GitHub 版本。

curl -fsSLO https://paperclip.ing/install.sh
curl -fsSLO https://paperclip.ing/install.sh.sha256
sha256sum -c install.sh.sha256
bash install.sh

也可以採用手動開發模式：

git clone https://github.com/paperclipai/paperclip.git
cd paperclip
pnpm install
pnpm dev

官方目前列出的需求是 Node.js 24.11 或更新版本，以及 pnpm 9.15 或更新版本。開發模式會啟動 API server，預設位址是 http://localhost:3100；README 說明 embedded PostgreSQL 會自動建立，因此初次試用不必先準備獨立資料庫。

我的建議是把第一次測試限制在本機 loopback，先建立一個低權限 agent，並使用小額預算。先驗證以下四件事，再考慮 LAN、tailnet 或正式部署：

任務是否能正確從目標傳遞到 agent。
heartbeat、重試與 orphaned run recovery 是否符合預期。
預算達到上限時，執行是否真的停止。
審批、工具呼叫、成本與 work product 是否留下可讀的紀錄。

不要因為介面看起來像 task manager，就直接讓 agent 擁有 production repo 的寫入權限。先用測試資料與隔離 workspace 做演練，往往比事後清理一次錯誤委派更省成本。

什麼時候值得使用 Paperclip

我認為 Paperclip 最適合以下三種情境。

第一，你已經有多個 agent runtime，而且開始遇到「誰正在做什麼」的可見性問題。Paperclip 可以把不同供應商或 CLI agent 放進同一個組織與任務脈絡。

第二，你有大量週期性或事件驅動工作，希望 agent 不只是被動回答，而是按照排程、任務與權限持續推進。Heartbeat、routine 與 durable activity 能讓這些工作比較接近可運維的服務。

第三，你需要在自主性與人類控制之間取得平衡。預算、審批、pause、terminate、secret scope 與 audit log 都是把「可以自動做」變成「可以在邊界內自動做」的基礎。

相反地，如果你只有一個 agent、幾個手動任務，或只是需要一個 prompt chaining library，Paperclip 可能會顯得過重。它的價值來自組織與治理；沒有多 agent 協作問題時，直接使用原本的 agent 工具通常更簡單。

導入時的三個判斷

先定義不可自動化的事情

不是所有動作都該交給 agent。先列出需要人類核准的資源、資料與外部副作用，再把 approval policy 寫進流程，而不是等事故發生後才補規則。

把成本當成產品指標

除了總額，也要看每個 goal、issue、provider 與 model 的成本。若某個任務反覆重試或工具呼叫異常，成本資料應能幫你找到根因，而不只是提供月底報表。

讓可攜性早於規模化

Paperclip 的 company export/import、secret scrubbing 與 collision handling，顯示組織本身也應該是可移動的資產。建立範本時，將秘密、環境差異與 agent adapter 分開保存，未來才容易複製到另一個專案或隔離環境。

結語：AI agent 的下一個瓶頸是運營

當 agent 從一次性的聊天工具變成長時間工作的團隊成員，瓶頸會從模型能力轉向運營能力：任務如何排隊、上下文如何保存、成本如何限制、權限如何收斂、決策如何追蹤，以及人類何時介入。

Paperclip 的做法是提供一個開源、可 self-host 的 control plane，把 goal、org chart、issue、heartbeat、budget 與 governance 放進同一個系統。它不承諾替你建造最聰明的 agent，而是試圖讓不同 agent 在清楚的組織邊界內工作。

對 AI 工程團隊而言，最值得借鑑的未必是某一個 UI 功能，而是這個分層：把 agent runtime 和公司級協作、治理、觀測分開。當我們開始管理的不只是幾次模型呼叫，而是一群會持續行動的數位工作者，這層 control plane 很可能會成為不可或缺的基礎設施。

參考資料