從 20 個終端到 1 個儀表板：一人團隊是怎麼變成一家公司的

20 個 Claude Code 終端同時開著，每一個都在跑不同的任務，你已經記不清哪個在做什麼。然後電腦重開機了——所有 session 全滅，幾小時的工作就這麼蒸發。這是 Paperclip 開場就描述的場景，也是上一篇提到的「員工有了、公司缺席」問題的具體形狀。這篇沿著一條線展開：終端 → 專案 → 團隊 → 公司，四層演進裡，你現在在哪一層？

第一層：終端——Agent 的原生棲息地

一切從終端開始。Claude Code、Codex 都是跑在 terminal 裡的 agent，你開一個終端就是雇用一個臨時工。它快、它專注、它不需要 onboarding——但也沒有任何結構：沒有職稱、沒有任務編號、沒有誰該做什麼的紀錄。

終端層的問題不是「功能」，是狀態。等你開到第 10 個、第 20 個終端，你已經不是在管理 agent，而是在管理一片隨時會燒掉的草地。更糟的是，重開機或關閉 session，agent 的工作記憶就斷了——它下次得從零開始猜你要什麼。

第二層：專案——加一點上下文

第二層是專案：把 agent 跑在同一個 repo、同一份文件上，讓它有 context 可以讀。CLAUDE.md、README、docs 目錄——我們在工程師工具鏈裡拆過這層怎麼搭——都是在解決「agent 不知道自己在幹嘛」的問題。

專案層的價值是記憶的載體。但它的天花板很明顯：文件是死水，agent 之間的交接還是靠你當人肉轉運站。你還是那張唯一的 org chart，只是換成用 Markdown 畫的。

第三層：團隊——多 Agent 同時作業

再往上，你開始同時跑多個 agent 分工：一個寫程式、一個做 QA、一個管社群。這層開始有「團隊」的形狀，但沒有團隊的骨架——沒有共同的任務清單、沒有預算、沒有誰審核誰。

多 agent 並行的真實困境在 README 裡寫得很準：你開了 20 個 tab，卻追不上每個人在做什麼。 這不是組織文化的問題，是工具沒有提供最基本的協調原語：任務從哪來、做完長怎樣、誰負責驗收。就算你想升級 agent 本身的能力，也得先有記憶與記憶體系統當底層——而這同樣是組織層的事。

第四層：公司——複雜度的最終處理場

第四層是公司，而 Paperclip 卡位在這裡。它把第三層那些「靠你人肉協調」的原語，變成系統功能：任務有編號、agent 有職稱、每個 agent 有預算上限、每次輸出要過審核。心跳（heartbeat）讓 agent 依照排程醒來工作，而不是靠你盯著終端。單一職能可以先交給單一 super agent 頂上（如果你想看 agent 一個人扛一整個職能的極限，Okara 這類 AI 行銷長就是例子），但多職能協作還是得回到公司層。

利益揭露：本文部分連結為聯盟連結，你透過連結購買不影響價格，我會獲得小額分潤。

從「多 agent 同時作業」到「agent 組織自己作業」，中間的差距不是加幾個 feature，而是承認編排本身是一門學問——這件事過去在開源世界完全缺席。Paperclip 只是第一個把它做出來的人。

你不是在買工具，你是在建組織

這四層的演進有個容易被忽略的啟示：你不需要公司，但你會需要方向感。 20 個終端不是因為你真的需要 20 個 worker，而是因為沒有工具讓你把任務講清楚、讓 agent 自己排隊、自己回報。當工具補上這一層，你的角色會從「人肉排程器」變成「功能經理」——這群人過去叫老闆，現在叫你自己。

下一篇是這系列的最後一篇：用數據拆解 Paperclip 的 78k stars 到底是品質還是時機。

常見問題

Paperclip 一定要從四層全用嗎？ 不用。它可以只當任務管理器用，把現有 agent 接上心跳與任務清單；org chart 與預算可以之後再加。演進是漸進的，不是大爆炸。

20 個終端太誇張了吧？ 是誇張，但方向對了。重度使用者兩三個 agent 同時跑就是常態，而「追不上每個人」的痛感從第三個 agent 就開始。

心跳機制會讓 agent 無限自跑嗎？ 不會。心跳只是讓 agent 依照排程醒來檢查工作，每次執行都有預算上限與審核關卡，碰到上限就停。

跟其他 agent 框架（LangChain 等）差在哪？ 框架解決「單一 agent 怎麼建」；Paperclip 解決「一群 agent 怎麼管」。它們是不同層——前者是員工訓練，後者是公司營運。