首頁

快訊深度數據 Skill&API

三省六部幻覺：為什麼「虛擬公司」式多Agent架構在工程上不成立？

閱讀本文需 19 分鐘

三大AI廠商都沒這麼做，你的多Agent架構可能走錯了路。

原文標題：《三省六部幻覺：為什麼「虛擬公司」式多 Agent 架構在工程上不成立》
原文作者：SagaSu，AI創業者

一個在 AI 社群廣泛流傳的架構思路，正在讓大量團隊走彎路。

先說結論

如果你正在考慮把多個 AI Agent 分別命名為「產品經理」、「架構師」、「測試工程師」，讓它們像公司部門一樣傳遞文件、協作完成任務——請停下來。

這個模式看起來很直覺，邏輯上似乎很合理，但它在工程上有根本性的缺陷。更重要的是，Anthropic、OpenAI、Google 三家廠商在構建自己的 Agent 系統時，沒有一家採用這個模式。

這不是巧合。

什麼是「三省六部」式架構

這個比喻指的是一類在社群裡廣泛流行的多 Agent 設計思路，在不同框架和文章裡有不同名字：role-based agents、virtual team、CrewAI 式分工、MetaGPT 式組織——本文統稱「三省六部」。

核心模式是：把一個複雜任務拆解成若干職能，每個 Agent 扮演一個角色——PM 負責需求、Tech Lead 負責架構、Dev 負責實現、QA 負責測試。任務在 Agent 之間流轉，像一條流水線。

這個模式在圖示上非常好看。它滿足了人類對「分工協作」的直覺，也讓「AI 團隊」這個概念變得具象可解釋。CrewAI 等框架正是因此積累了大量用戶。

問題在於，它解決的是人類的瓶頸，不是 AI 的瓶頸。

為什麼這個類比從根本上是錯的

人類需要分工，是因為：

· 單個人的注意力有限，無法同時處理所有信息

· 人有專業壁壘，學習切換成本高

· 人與人之間需要介面來協調

但 LLM 的特性完全不同：

· 同一個模型既能寫 PRD 又能寫程式碼，沒有「職業邊界」

· 模型的瓶頸不是注意力廣度，而是推理深度和資訊完整性

· 模型之間沒有「文化」和「默契」來補償資訊損耗

給 Agent 貼上「產品經理」的標籤，不會讓它更專業——但會讓它拒絕越界。一個被框死在「測試工程師」角色裡的 Agent，看到架構層的問題可能直接跳過，因為「不在我職責範圍內」。最有價值的推理往往發生在邊界上，而三省六部模式在系統層面封死了這個可能性。

角色扮演製造了假邊界。這是第一個問題。

第二個問題：資訊在流轉中死亡

三省六部模式裡，Agent A 產出一個文件，傳給 Agent B。

這個過程傳遞的是結論，不是推理過程。

B 拿到文件，重新理解，重新建立上下文。原始意圖在衰減，隱含假設在遺失，每次傳遞都在累積誤差。工作流越長，最終輸出越「局部正確但整體漂移」——每個節點看起來合理，但整體已經偏離了最初的目標。

人類組織靠會議、文化、非正式溝通來補償這個資訊損耗。Agent 之間沒有這些機制。

這裡有一個常見的反駁：三家廠商的解法（progress.txt、spec 文件、runbook）不也是「傳文件」嗎？區別在哪？

區別在於誰在寫、寫給誰、怎麼更新。

三省六部的資訊流轉是角色間的單向交接：A 寫完交給 B，B 不再回頭，A 也不知道 B 怎麼用了這份文件。資訊被壓縮成結論，推理過程丟失，接棒就是斷點。

外部狀態檔案是同一任務的增量日誌：執行主體在每個檢查點時往同一份記錄裡追加，下一個會話讀取的是任務的完整歷史，不是上一個「同事」的輸出結論。寫狀態的人和讀狀態的人是同一個角色，只是時間不同。資訊不是被「壓縮傳遞」的，是被「連續累積」的。

這個區別決定了推理鏈能不能跨會話保持連續。

大量代幣被浪費在 Agent 之間的「交接檔案」上，而不是用於實際推理。你得到的是一個模擬公司行為的系統，而不是一個解決問題的系統。

三家廠商實際怎麼做的

值得注意的是，當 Anthropic、OpenAI、Google 真正構建自己的生產級 Agent 系統時，他們的工程文件裡幾乎找不到「角色扮演」或「部門分工」的字眼。

Anthropic：Context Engineering + 明確狀態檔案

Anthropic 內部把「Prompt Engineering」升級成了「Context Engineering」：問題不是怎麼寫好一個 prompt，而是什麼樣的 token 配置最能產生想要的行為。

在構建 Claude Code 和 Research 系統時，他們面對的核心挑戰是：Agent 必須在離散的會話裡工作，每個新會話對之前發生的事情沒有任何記憶。他們的比喻是「輪班工程師」——每個新班次的工程師到崗時對上一班的工作一無所知。

解法不是讓 Agent 扮演不同角色，而是：

· claude-progress.txt：一個跨會話的工作日誌，Agent 在每個會話結束時更新，下一個會話開始時讀取

· Git history：作為狀態錨點，記錄每一個增量變化

error

OpenAI：Compaction + Skills + 結構化 Spec 檔案

OpenAI 給出的長任務原則更直接：在任務開始時就為 continuity 做規劃。

他們的 Codex 實驗裡，工程師給 agent 一個 spec 檔案（凍結目標，防止 agent「做出了很 impressive 但方向錯誤的東西」），讓它生成 milestone-based plan，然後用一個 runbook 檔案告訴 agent 如何操作。這個 runbook 同時也是共享記憶和審計日誌。

結果：GPT-5.3-Codex 跑了約 25 小時不間斷，完成了一個完整的設計工具，保持了全程的連貫性。

Server-side compaction 作為默認 primitive，不是緊急 fallback。多步驟任務裡，previous_response_id 讓 model 能在同一個 thread 裡繼續工作，而不是每次重建上下文。

他們還引入了 Skills 概念——可複用的、版本化的指令集，掛載進 container，讓 agent 執行特定任務時有穩定的操作規範。這不是「角色」，是工具和操作規程，是本質上不同的事情。

Google：1M 上下文 + Context-driven Development

Google 的方向是硬擴窗口：Gemini 的 1M token context 是明確的差異化策略。他們的邏輯是：之前被迫使用的 RAG 切片、丟棄舊消息等技術，在足夠大的窗口下可以被「直接放進去」所取代。

但他們自己也承認這不夠用。Google 在 Gemini CLI 推出了 Conductor 擴展，核心思路和 Anthropic 如出一轍：把專案意圖從聊天窗口裡移出來，放進代碼庫裡的持久化 Markdown 檔案。哲學是：「不依賴不穩定的聊天記錄，依賴正式的 spec 和 plan 文件。」

Gemini 3 還引入了 Thought Signatures 機制：在長 session 裡保存推理鏈的關鍵節點，防止「reasoning drift」——長 context 裡邏輯前後不一致的問題。

真正的架構原則是什麼

從三家的工程實踐中，可以提煉出幾個共同的原則：

推理鏈不能斷，只能分叉再合併。 多 Agent 的正確用法不是流水線，而是一個主 agent 持有完整意圖，子調用是為了深挖某個子問題，結果回流給主 agent，不是傳給下一個 agent。

顯式外部狀態，不靠模型記住。 progress.txt、Git history、spec 檔案、資料庫——形式不重要，原則是：推理鏈的關鍵節點必須外化到持久存儲裡，而不依賴模型在 context window 裡「記住」。

多 Agent 的價值是並行覆蓋，不是分工。 Anthropic Research 系統的結論很清楚：性能提升主要來自於「花了更多 token」，而不是來自「分工更合理」。多 Agent 適合 breadth-first 類任務——需要同時探索多個獨立方向的場景。不適合需要連續推理、深度依賴上下文的場景。

驗證 Agent 是否定者，不是接棒者。 如果要用多 Agent 做品質控制，正確的設計是讓一個 Agent 專門找另一個 Agent 的問題，而不是「傳遞工作成果」。對抗性檢驗，不是流水線傳遞。

工具是工具，不是角色。 給 Agent 配什麼工具（bash、檔案讀寫、搜索、程式碼執行）遠比給它貼什麼標籤重要。工具決定了 Agent 能做什麼；角色標籤只是約束它願意做什麼。

那三省六部為什麼會流行？

因為它好解釋。

「這個 Agent 是 PM，那個是 QA」——這句話任何人都能理解。它滿足了人類對 AI 系統可解釋性的渴望，也滿足了管理層對「AI 像團隊一樣工作」的想像。

它還好展示。用流程圖畫出來，有部門、有箭頭、有交接，非常直觀。

但好解釋和好展示，和工程上是否成立是兩件事。

更深層的原因是：大多數採用這個模式的團隊，並沒有真正面對過「上下文在多 Agent 間傳遞時的損耗」這個問題。他們的任務可能不夠複雜，或者問題被其他因素掩蓋了。等到任務複雜度上來，系統開始出現詭異的「局部正確整體錯誤」時，問題才會暴露。

實踐建議

最好的多 Agent 系統，不像公司。它更像一個思考者的多次草稿——同一個大腦，在不同維度上展開推理，最終合併成一個連貫的結論。

從這個原則出發：

不要問「我需要幾個 Agent」，要問「這個任務的信息依賴結構是什麼」。

如果任務需要連續推理、上下文高度依賴（比如寫一個複雜功能的設計文檔），單 Agent + 好的 context engineering 通常優於多 Agent。

如果任務需要同時探索多個獨立方向（比如同時研究 10 個競品的不同模塊），多 Agent 並行是合理的——每個 subagent 的任務相互獨立，信息損耗代價最小。這正是 Anthropic Research 系統 token 量解釋 80% 性能差異背後的原因：不是分工讓它更好，是更大的搜索覆蓋讓它更好。

如果任務跨越多個 session，外部狀態文件是必須的。一份有效的狀態文件應該包含四類信息：

· 任務目標（不變，session 開始時讀取，防止漂移）

· 已完成的步驟（追加，不覆蓋，保留完整歷史）

· 目前狀態（覆蓋，反映最新發展）

· 已知的坑（追加，避免下一個 session 重踩）

這四類信息分開維護，合在一起就是「下一個自己」需要的完整上下文。

如果要加驗證環節，讓驗證 Agent 的唯一任務是找問題，不是「接棒繼續做」。對抗性檢驗，不是流水線傳遞。

最後：模型能力在快速提升，今天 harness 里需要的 workaround，六個月后可能變成死重量。Anthropic 已經驗證了這一點——Sonnet 4.5 的 context anxiety 在 Opus 4.5 里消失了，為它設計的 context reset 隨即變成了無用代碼。保持架構的可演化性，比選一個「完美架構」更重要。

三省六部是一個讓人感覺良好但工程上代價高的錯覺。它的真正成本不是直接的失敗，而是讓你的系統在複雜度上升時，以一種難以診斷的方式退化——每個節點都「看起來在工作」，但整體在漂移。

等你發現問題的時候，流水線已經很長了。

參考資料：

Anthropic Engineering Blog（Building Effective Agents, Effective Context Engineering, Multi-Agent Research System, Effective Harnesses for Long-Running Agents, Managed Agents）；OpenAI Developers Blog（Run Long Horizon Tasks with Codex, Shell + Skills + Compaction）；Google Developers Blog（Architecting Efficient Context-Aware Multi-Agent Framework, Conductor: Context-Driven Development for Gemini CLI）