技術分享
從 POC 到生產：AI 系統為何撐不住上線與如何重構
一套 AI 系統在 Demo 裡跑得漂亮，搬上線卻狀況百出，這幾乎是每個導入團隊都遇過的落差。本文從工程視角，用 Gartner、RAND、MIT 的數據與真實判例拆解 POC 累積的技術債，並提供絞殺者模式的分層抽換策略與上線前必備的工程底座。
先選對拓撲，別急著加 Agent
多數 Multi-Agent 專案卡關，不是 Agent 不夠聰明，而是一開始就把 Agent 硬湊在一起，沒先決定它們用什麼形狀協作。協作拓撲決定了任務怎麼流動、由誰做決定、失敗時往哪裡收斂；選錯拓撲，再多 Agent 也只是更貴的混亂。而且這不是抽象的美學問題——Anthropic 的生產實測與 Google Research 的對照研究顯示，同一種任務改用不同拓撲，token 成本與可靠度可以差到十幾倍。本文只談架構形狀怎麼選，也就是 Agent 之間的連接方式與決策權分布，不碰它們怎麼傳訊息、記憶怎麼共享、角色怎麼分工那些後續問題。先把形狀定對，後面的實作才有依據。
四種拓撲 × 主流框架對照表
| 拓撲 | 代表框架 | 最適任務與真實案例 | 主要取捨（含實測數據） |
|---|---|---|---|
| 主控-工作者 | LangGraph Supervisor、Anthropic Research、CrewAI Hierarchical | 可平行拆解的探索：Anthropic Research 由主控派 3~5 個子代理同時查找 | 可靠度高但貴：Anthropic 版比單代理 +90%，卻耗約 15 倍 token |
| 階層式 | LangGraph 多層 Supervisor、CrewAI Hierarchical | 大型任務、子任務本身還能再拆 | 可深度擴展；管理層的額外 LLM 呼叫會增加 token 成本 |
| 對等式 | OpenAI Agents SDK handoffs、AutoGen Group Chat | 邊界不清、需臨場交棒的探索型工作 | 最有彈性也最脆：無中心時錯誤放大達 17.2 倍 |
| 管線式 | CrewAI Sequential、MetaGPT SOP | 步驟固定的線性流程，如 PRD→架構→開發 | token 成本最低、最好除錯；任一站塞住全線停 |
主控-工作者：Anthropic 與 LangGraph 的實戰數據
主控-工作者是最有實績的起手式：一個主控 Agent 拆解並分派，若干工作者各做一塊、回報結果。Anthropic 的 Research 系統就是這個形狀——主控先規劃，再平行開出 3~5 個專職子代理各自蒐證，最後由主控彙整、另跑一次引用查核。實測結果，用 Claude Opus 當主控、Sonnet 當子代理的組合，比單一 Opus 高出 90.2%，而 token 用量正好解釋了八成的效能差異。代價是它約吃掉一般對話 15 倍的 token。工程上，LangGraph 的 langgraph-supervisor 把這個模式標準化：主控節點用 Command 決定下一個呼叫哪個工作者節點，責任清楚、好追蹤，但主控天生是瓶頸與單點。
階層式：規模到了才往下疊層
當子任務本身又大到需要再拆，就把主控-工作者升級成階層式：上層主控只做粗分工，把每一塊交給下層次主控再細分。LangGraph 官方直接支援「管理多個主控的主控」，做出多層團隊；CrewAI 的 Hierarchical Process 則自動或指定一個 manager agent，由它動態分派、審查產出、要求重做。這讓系統能擴展到單層扛不住的規模，但層級是有成本的——管理者本身也要消耗 LLM 呼叫來分析任務、挑選代理、審查產出，每多一層就多一層協調開銷，token 成本隨之上升。判準很直接：單層的分派清單長到主控自己都追不動，才往下多切一層，別為了架構好看預先疊層。
對等式：彈性換來 17 倍的錯誤放大
對等式沒有中央指揮，Agent 平權、誰有能力接手就往下做。OpenAI 把早期的 Swarm 演進成 Agents SDK，核心就是 handoffs——一個 Agent 遇到不在自己領域的請求，直接連同上下文把主導權交棒給更適合的同儕；AutoGen 的 Group Chat 也提供 auto、round_robin 等挑選下一位發言者的策略。它適合邊界模糊、事前無法規劃步驟的探索型工作，最有彈性，卻也最難預測與除錯。Google Research 的對照研究《Towards a Science of Scaling Agent Systems》（2025 年 12 月發表）在 180 種受控組態中量出殘酷的數字：沒有中央協調的獨立式多代理，錯誤會被放大到單代理的 17.2 倍，而加上中心協調可把放大倍數壓到 4.4 倍。所以對等式適合小群、高自主、容許試錯的場景，不適合追求穩定產出的關鍵流程。
管線式：最省、最好追，但最脆
管線式正好相反：任務像生產線依序流過每一站，每站專注一道工序，把上一站的成果加工後交給下一站。CrewAI 的 Sequential Process 是典型代表——任務照定義順序執行，前一步的輸出自動成為下一步的 context，因為沒有協調開銷，它的 token 成本最低、也最好除錯。MetaGPT 更把這套流水線做到極致，用「Code = SOP(Team)」的理念把產品經理、架構師、專案經理、工程師串成一條 SOP 產線，一句需求跑完就吐出 PRD、設計到程式碼。管線式在步驟固定時最高效、最好監控，也最容易在每站間插檢查點；但它天生脆弱，任一站卡住整條線就停，所以每站都要有明確的逾時、重試與失敗處理。
恩梯科技：從任務特性反推架構
從上面的數據可以看出，拓撲選型不是比誰先進，而是拿任務的可拆解性、規模、流程形狀去反推，並在可靠度與 token 成本之間權衡：要穩就付中心化的協調成本，要省就走管線，要彈性才動用對等式。多數企業的務實解，是先用主控-工作者跑起來，規模到了往階層式長、流程固定時抽成管線，並隨任務演進混用。恩梯科技的 AI 系統顧問服務，會先盤點你的實際任務結構，對應到最合適的協作拓撲與框架選型，讓系統從一開始就長在對的形狀上，而不是上線後才發現架構撐不住、被迫打掉重練。
參考資料
- Anthropic，《How we built our multi-agent research system》，2025。來源連結
- Google Research，《Towards a science of scaling agent systems: When and why agent systems work?》，2026。來源連結
- LangChain，《langgraph-supervisor-py（GitHub）》，2025。來源連結
- OpenAI，《Swarm（GitHub，說明 Agents SDK 為其正式後繼）》，2025。來源連結
- Microsoft，《AutoGen 0.2：agentchat.groupchat 文件》，2024。來源連結
- FoundationAgents，《MetaGPT: The Multi-Agent Framework（GitHub）》，2025。來源連結
- CrewAI，《Sequential Processes 官方文件》，2026。來源連結
- CrewAI，《Hierarchical Process 官方文件》，2026。來源連結
