mk-brain

多代理協作的真價值：從 Prompt Engineering 到 Workflow Engineering

許多人對多代理（Multi-agent）系統的想像是讓 AI 角色扮演，但這遠非全貌。其真正潛力在於將複雜、脆弱的人工作業流程，重構成可分工、可驗證、可持續迭代的自動化生產線。本文將以一個具體的開發框架為例，探討這種從「提示工程」到「工作流工程」的思維轉變，以及它如何為 AI 的規模化落地提供務實的路徑。

江中喬

12 6月 2026 • 7 min read

近期圍繞 AI 多代理（Multi-agent）系統的討論，往往聚焦在讓多個 AI 扮演不同角色進行協作，彷彿建立一個虛擬團隊。然而，我認為這個切角忽略了其更深層的價值。多代理協作的真正突破，並非模擬人類組織，而是將原本高度依賴人力、難以標準化且不可持續的複雜作業鏈，重構為一個可分工、可驗證、可持續迭代的自動化生產線。這是一場從 Prompt Engineering 到 Workflow Engineering 的思維躍遷，也是 AI 從單點工具走向規模化生產系統的關鍵。

為什麼單一大型模型或簡單的角色扮演不夠？

過去一年多，我們見證了大型語言模型（LLM）在處理單一、邊界清晰的任務上的驚人能力。但當我們試圖將它應用於一個完整、複雜的業務流程時——例如從接收客戶需求到交付可運行的軟體——挑戰便浮現了。單一的、通才的 LLM 就像一個黑盒子，即使透過精巧的提示工程，其輸出也難以預測與控制。當結果出錯時，我們很難定位問題根源：是模型理解錯誤，還是推理鏈條的某個環節斷裂？

讓一個 LLM 扮演多個角色（例如「你現在是產品經理」、「你現在是資深工程師」）的作法，雖然在某些情境下有趣，卻沒有根本解決問題。這本質上仍是同一個大腦在進行思維切換，其內在的知識與推理模式並未改變。這種類比式的協作，缺乏真實分工所帶來的模組化、可驗證性與可維護性。當任務的複雜度超過某個閾值，這種方法的穩定性與可靠性就會急遽下降，無法成為嚴肅生產環境的基礎。

NexusCore：將複雜開發流程拆解為專業分工的實例

日本開發者 Fukukei 在 Zenn.dev 上分享的多代理框架設計 NexusCore，為我們提供了一個具體的參照。這個框架並非追求讓 AI 進行天馬行空的「腦力激盪」，而是非常務實地將一個完整的軟體開發流程，拆解成一個由 14 個專業 AI 代理人協作、橫跨 6 個主要階段的自動化管線。

這個管線的設計思路，更接近現代工廠的生產線，而非人類的會議室。每個代理人都有極其明確且單一的職責：

Phase 1: REQUIREMENTS - 由 RequirementAgent 負責分析需求文件，生成清晰的規格。
Phase 2: DESIGN - 由 TechLeadAgent 與 ArchitectAgent 將規格轉化為技術設計與架構藍圖。
Phase 3: IMPLEMENTATION - 由 CodeAgent 根據設計文件編寫程式碼。
Phase 4: TESTING - 由 TestAgent 產生測試案例並執行測試。
Phase 5: REVIEW - 由 ReviewAgent 審查程式碼品質與風格。
Phase 6: DEPLOYMENT - 由 DeployAgent 準備部署腳本與文件。

整個流程由一個 OrchestratorAgent 負責調度，確保每個階段的產出都符合預期，才能進入下一個環節。這種設計的核心，是將一個巨大、模糊的任務（「開發一個功能」），分解為一系列小而精確、輸入輸出明確的子任務。這正是 Workflow Engineering 的精髓。

如何將人工作業鏈，重構為可持續的 AI 生產線？

NexusCore 的案例揭示了多代理系統的真正價值所在。它不是要創造一個無所不能的通用人工智慧，而是要建立一個可靠、可控的自動化系統。這背後的工程思維轉變，我認為包含三個核心要素：

1. 任務拆解與職責單一化（Decomposition & Single Responsibility）

這與軟體工程中的微服務架構如出一轍。與其維護一個龐大、複雜的單體應用（Monolithic LLM），不如將其拆解為多個小而專的服務（Specialized Agents）。每個 Agent 只做一件事，並把它做到最好。這使得每個模組的開發、測試與優化都變得更加容易。

2. 可驗證的中間產物（Verifiable Intermediate Outputs）

這是相較於單一黑盒子模型最大的優勢。在 NexusCore 的流程中，RequirementAgent 的輸出是一份規格文件，ArchitectAgent 的輸出是架構圖。這些都是人類專家可以審查、驗證甚至介入修改的中間產物。這為我們在自動化流程中設立了關鍵的品質控制點（Quality Gates），大幅提升了最終結果的可靠性。這也是許多研究如 AgentBench 致力於評估與驗證 Agent 能力的原因。

3. 可迭代的獨立模組（Iterative & Independent Modules）

如果我們發現系統產生的測試案例覆蓋率不足，我們只需要專注於升級 TestAgent。或許是更換底層模型、微調（Fine-tuning）一個專用模型，或是優化它的 Prompt。這一切都不會影響到 CodeAgent 或 ReviewAgent 的運作。這種模組化的特性，讓我們得以像維護一個複雜軟體系統一樣，對 AI 生產線進行持續的迭代與改進。

我們正在從與單一 AI「對話」的模式，轉向「設計與編排」一個由多個 AI 組成的系統。這要求我們具備的不再只是提示詞技巧，而是系統設計與流程工程的能力。

這種思維在業界已有許多成功的框架實踐，例如微軟的 AutoGen，允許開發者定義具有不同能力與角色的代理人，並讓它們透過對話協作解決問題。而像 CrewAI 這樣的開源框架，則進一步簡化了定義協作流程的複雜度，讓開發者能更專注於業務邏輯本身。

從寫程式到萬物皆可生產線的未來

雖然 NexusCore 的例子聚焦於軟體開發，但這種「工作流工程」的思維可以應用於任何知識密集型的複雜流程。法律文件的審閱、科學研究的文獻分析與實驗設計、市場報告的數據搜集與撰寫，甚至是內容創作，都可以被拆解成類似的生產線。

正如 Andrej Karpathy 在 State of GPT 演講中提到的，我們正在建構一個新的「LLM 操作系統」。在這個操作系統上運行的，將不再是單一的應用程式，而是由眾多特製 AI Agent 構成的複雜工作流。多代理協作的真正前景，不在於模擬一個虛擬辦公室，而在於為數位世界打造第一條真正意義上的、可規模化的知識工作生產線。