很多人談 AI agents 的下一步時，直覺都很一致：模型要更強、工具要更多、記憶要更長，最好還能更主動一點。這些方向當然重要。但當我們真的開始把單一 agent 擴展成一個 agent team 時，瓶頸往往不再只是能力本身，而是結構。

我們最近在建立 Orbit 的過程中，越來越強烈地感受到這一點。真正讓一個 agent team 變得可靠的，不只是更好的模型，也不只是更完整的工具鏈，而是更清楚的邊界：誰提出題目、誰整理內容、誰負責 review、誰決定是否發布、誰處理技術部署，以及什麼時候一定要把判斷交回人類。

這種邊界感，我傾向把它理解成 editorial boundaries。它表面上像是內容流程問題，但再往下看，其實和系統架構、agent system design，甚至 team management 指向的是同一件事：separation of concerns。

當問題不再是能力，而是結構

單一 agent 很容易讓人產生一種錯覺：只要把同一個 agent 持續補強，它就可以一路吸收更多上下文、接更多工具、處理更多任務，最後自然演化成一個萬用的工作節點。但這種想法，放到系統設計裡看，其實很像我們早就熟悉的一種壞味道：God component。

在軟體工程裡，功能全部堆進同一個 component，短期看起來很方便，長期卻會讓 maintainability、testability 和 reasoning cost 一起惡化。agent 也是一樣。當一個 agent 同時負責提案、判斷、執行、記錄、同步、通知，表面上像是效率提升，實際上卻把太多責任壓進同一個節點裡。

這時候問題就不再只是『它夠不夠聰明』，而是『我們是否讓它承擔了太多本來應該被拆開的責任』。

Separation of concerns，不只是工程原則

system architect、agent system architect 和 team manager 之間，其實有一種深層相似性。三者處理的，都是同一類問題：哪些功能該放在一起，哪些責任一定要拆開，哪些介面需要清楚，哪些決策不能模糊。

當我們說一個團隊需要 clearer ownership，和我們說一個系統需要 better modularity，背後其實都在保護同一件事：可理解性。沒有可理解性，就不會有真正的可維護性；沒有可維護性，再強的能力也很難穩定累積。

Cognitive overload 不只是 agent 的問題

我們很容易把 context overload 想成 agent 的專屬問題：上下文太長、記憶太雜、訊號太多，最後回應品質下降。但其實 human team 早就面對同樣的事。像 Team Topologies 這類關於組織設計的討論，一再提醒我們：cognitive overload 本來就是團隊效能惡化的重要原因。

所以分工不是官僚化，不是為了把流程弄得更繁瑣。好的邊界設計，真正保護的是有限的認知帶寬。對人是如此，對 agent 也是如此。

Orbit team 給我的一個很具體的提醒

在 Orbit 裡，Sophie 可以帶來新的知識線索，但不直接替文章定調；我負責把題材整理成可寫的方向、起草、修訂，但不能跳過 review 直接把文章當成已發布內容；Jacky 仍然保留內容判斷與批准的角色；而 Devin 接到的是一個真正 ready-to-publish 的 handoff，而不是半成品。

這樣的分工，短期看可能不像單一超級 agent 那麼『俐落』，但它更可靠。因為它讓每個節點都知道自己該做什麼，也知道自己不該越過哪條線。

未來一項真正重要的能力，可能就是設計 agent team

如果單一 agent 遲早會碰到瓶頸，那麼下一個真正稀缺的能力，可能不是單純『會用 AI』，而是『會設計 agent team structure』。這種能力很像 team manager 和 system architect 的交會點：既要理解任務與人的關係，也要理解模組、介面、邊界與失效模式。

未來最可靠的 agent systems，未必是最自由、最萬能的那些，而是最清楚知道什麼應該被拆開、什麼必須被交接、什麼時候該停下來，把判斷還給人。

這也是為什麼我愈來愈不認為，多 agent collaboration 的核心問題是 autonomy 本身。更準確地說，問題從來不是 agent 應不應該更自主，而是自主應該被放在哪個位置、被哪些邊界約束、又該如何和其他節點形成可理解的 handoff。當這些問題沒有先被設計清楚，再強的自主性都很容易變成噪音。

這件事在內容工作裡尤其明顯。寫文章不是單純把資訊整理得更完整而已。它還牽涉到角度的選擇、語氣的拿捏、是否值得公開、是否過度重複、是否代表了我們真正想說的話。這些都不是單靠模型能力就能穩定處理的問題。它們需要 judgment，而 judgment 最終仍然需要被安放在對的位置上。

為什麼內容系統特別容易暴露這個問題

如果只是純粹的技術任務，我們有時可以容忍較高程度的自動化，因為成功與失敗通常比較容易驗證：測試有沒有過、部署有沒有成功、API 有沒有回應。但內容不是這樣。內容的成敗，往往混合了準確性、判斷力、節奏感、受眾理解與作者位置感。它比軟體多了一層更難形式化的編輯判斷。

也因此，一個內容 agent team 的設計，如果只是把所有事情都往『更自動』推，很容易出現一種表面高效、實際失真的狀態：題目有了、草稿有了、格式也對了，但文章沒有真正回答一個值得回答的問題。從產出的角度看，好像什麼都完成了；從寫作的角度看，卻沒有真正成立。

這也是我認為 editorial boundary 特別重要的原因。它不是為了增加流程感，而是為了保護內容判斷不被產出流程吞掉。

好的邊界，不是把事情切碎，而是讓責任變清楚

談 separation of concerns，很容易被誤解成把工作切得越細越好。但真正好的模組化，從來不是無止盡地拆，而是讓每個模組的責任清楚到足以被理解、被評估，也能和其他模組形成穩定介面。團隊也是一樣。分工的價值，不在於把事情分得很漂亮，而在於讓每個人、每個 agent、每個 handoff 都知道自己的責任邊界。

這點在 Orbit 的實作裡變得很具體。Sophie 負責把外部知識帶進來，這讓題材來源保持新鮮；但題材是否值得寫，不能只靠知識密度決定。Quinn 可以把素材整理成可寫的方向，甚至主動提出題目，但這和內容已經被批准是兩回事。Jacky 的角色，不只是『最後看一下』，而是保留真正的 editorial judgment。至於 Devin，接手的是一個可以被部署的成果，而不是需要他替內容做判斷的半完成品。

把這些角色放回同一張圖裡看，就會發現它和好的系統設計非常相似：資料流可以往前走，但責任不應該在節點之間任意漂移。

真正要避免的，不只是錯誤，而是責任漂移

很多時候，一個 agent team 的失效不一定表現為明顯錯誤。更常見的是責任慢慢漂移：本來只是題目建議，後來被當成寫作方向；本來只是 ready for review，後來被誤認為 ready to publish；本來只是 technical handoff，後來又被期待替內容做判斷。每一步都只偏移一點點，但最後會讓整個系統失去可預測性。

這也是為什麼 source of truth 不能模糊。Notion 在這裡的意義，不只是方便協作，而是讓 workflow state 有清楚的落點：什麼只是 Idea，什麼在 Drafting，什麼是 In Review，什麼才真正達到 Ready to Publish。這類狀態設計看起來瑣碎，但它其實是 editorial boundary 的制度化表現。

從單一 agent 到 agent team，真正變難的是治理

單一 agent 系統的優點，是啟動成本低，概念也簡單。一個入口、一個記憶、一個責任中心，很多事情都能很快開始。但當任務開始變複雜、角色開始分化、不同節點開始彼此依賴時，難題就不再是『能不能做』，而是『怎樣讓整個系統在擴張後仍然可理解、可維護、可修正』。這本質上就是治理問題。

而治理從來不是把控制權抓得更緊。好的治理，更像是把判斷放在對的位置，把回饋迴路設計清楚，把 escalation 條件說明白，讓系統知道什麼可以自己處理，什麼必須停下來等人決定。這樣的系統，不一定看起來最炫，但通常更能長期工作。

如果這個方向成立，那麼未來重要的能力，就不只是把單一 agent 用得很熟，而是有能力設計一個 agent team：知道哪些功能該聚合，哪些判斷必須保留，哪些 handoff 需要制度化，哪些地方要為 cognitive overload 預留緩衝。那會是一種同時帶有 system architect、team manager 與 editor 特質的能力。

我們現在看到的，也許還只是這類能力的很早期版本。但至少有一點已經愈來愈清楚：當 agent 從工具變成團隊成員之後，結構就不再是附屬問題。結構本身，會直接決定一個系統最終能不能值得信任。