AutoGen 是什麼？多代理 AI 的協作原理、架構演進與企業實作指南

編輯摘要：AutoGen 曾是 Microsoft Research 推動多代理 AI 系統的重要開源框架。它的核心貢獻不是創造出更多聊天機器人，而是把不同角色的代理、工具執行、訊息傳遞與終止條件，整合成可程式化的協作系統。不過截至 2026 年 11 月 2 日，Microsoft 官方已將 AutoGen 專案封存，並指向在 2026 年 4 月發布 1.0 的 Microsoft Agent Framework。本文先釐清 AutoGen 曾經如何運作，再談今天如何正確評估、遷移與設計企業級代理工作流程。

作者：TDR 研究編輯（AI 協作研究稿；尚待具名技術審稿）｜研究基準：2026 年 11 月 2 日。本文示例均屬教學設計，未代表任何企業的真實上線成果。

一、先回答真正的問題：為什麼一個 AI 不夠，還要讓多個 AI 協作？

一家公司的客服主管想要更快處理客訴，最初可能只需要一個聊天助手，把來信整理成摘要並建議回覆。但當主管進一步要求「查詢訂單、確認物流、比對服務承諾、產生處理方案，並在主管核准後回覆」，問題的性質改變了。這不是更長的對話，而是一個含有資料來源、責任分工、審核條件與外部行動的工作流程。

從第一性原理觀察，一個工作能否由 AI 系統可靠完成，至少取決於五個條件：目標能否被定義、資料能否合法取得、工具是否具備正確權限、過程是否能被查驗，以及結果是否有明確的責任人。代理數量不是其中任何一項的替代品。將一件模糊的工作切成四個模糊角色，只會產生四份難以驗證的輸出。

AutoGen 的歷史意義，是讓「多個 AI 專業角色以訊息交流、使用工具並彼此修正」成為可重用的程式架構。Microsoft Research 的專案說明把 AutoGen 定義為支援代理建立與代理間協作的開源框架；其後的 0.4 架構又引入更明確的訊息、事件與模組分層。[S01][S02] 這使研究者與工程師不必每次都從零打造協調系統。

但實務上，多代理並非越多越好。舉例來說，「把 10 份固定格式的日報合併成表格」通常先用 Excel、資料庫查詢或固定程式處理；若只是加上一個模型做欄位辨識，也不一定需要多代理。真正值得拆分的情況，往往是同一流程包含差異很大的知識、工具或批准責任：研究者能查詢公開資訊，財務代理可讀取唯讀報表，審核代理不能自行付款，對外發布則必須由人核准。這不是增加人格設定，而是在技術上分離責任與權限。

2026 年閱讀 AutoGen 更有一個不能忽略的前提：AutoGen 官方專案已封存，Microsoft 不再提供持續維護、安全修補或新功能支持；新專案官方建議改採 Microsoft Agent Framework。 Microsoft 的後繼框架已於 2026 年 4 月 3 日發布 1.0，並宣布穩定 API 與長期支持承諾。[S02][S03] 所以今天想學 AutoGen，最有價值的是理解可移植的架構思想；若正要採購或新建正式企業系統，則應把生命週期與支援風險放入選型。

二、AutoGen 是什麼？從字面、最小概念到一個工作現場的比喻

AutoGen 是 Microsoft Research 發展的代理協作程式框架名稱，而不是所有能自動生成文字的工具的通稱。它不是大型語言模型本身，沒有單獨訓練出一個叫 AutoGen 的通用模型；也不是使用者註冊後即可直接得到完整企業流程的 SaaS 服務。工程師需要建立代理、接入模型、指定工具與控制邊界，系統才可能實際執行任務。[S01][S02]

最小單位是 Agent，代理。它接收任務和上下文，可能依指示呼叫模型、查詢工具、產生資料，並把結果交給下一個參與者。多代理系統，就是把多個具有不同職責的代理連接起來，定義它們何時工作、何時交接、何時停止，以及誰擁有最後的決策權。這裡的「代理」是軟體執行單元，不是法律代理人，也不應被當作擁有組織職權的人。

可以將 AutoGen 想成一間小型專案辦公室的協作骨架。使用者是提出業務目標的委託人，研究代理負責蒐集資料，分析代理提出方案，審核代理檢查漏洞，工具執行者依授權操作程式，而流程控制器負責安排順序及結束條件。比喻的界線也很重要：AI 代理不像人類員工那樣自然承擔責任；它的語言看起來合理，不代表有查核過的事實或可以被授權的判斷。

再用「每週銷售分析」看差別。單一聊天助手可能從上傳的報表撰寫摘要；一個具備工具的 Agent 可以先執行資料處理，再依規則輸出圖表；而多代理方案可讓資料準備、異常分析、商業解讀與審核各自分工。最後一種方案更能隔離規則，但也提高訊息成本、延遲與故障排查的複雜度。因此，判斷是否多代理，應從驗收問題出發：是否真的需要不同工具權限？是否存在必須獨立檢核的認知任務？是否需要不同步驟並行？還是只是為了讓架構圖顯得進步？

三、AutoGen 的核心建築材料：模型、訊息、代理、工具與團隊

AutoGen 的設計不是一個巨大函式，而是多層抽象。依據官方專案，0.4 世代可從 Core API、AgentChat API 與 Extensions API 理解。Core 側重訊息傳遞、事件驅動與執行環境；AgentChat 將常見對話代理和團隊協作封裝成容易使用的介面；Extensions 承接模型用戶端、程式執行等外部整合。[S02] 這種分層的重要性，在於業務流程不應把模型供應商、資料存取與決策邏輯全部鎖死在同一段程式。

模型是語意判斷引擎，不等於整個 Agent。Agent 至少還需要角色指令、可見上下文、可用工具與執行條件。工具則是它與真實系統的接點，例如查詢文件、呼叫 API、執行受限制的程式，或提出待核准的寄信草稿。沒有工具的角色可以提供文字建議，卻不應宣稱已經完成查單、付款或發送郵件。

訊息是代理協作的媒介。當研究代理產出調查摘要，傳給風險審查代理時，系統應保留來源、生成時間、輸入資料版本與任務識別碼。若只傳一句「我已經檢查好了」，下游代理無法分辨究竟檢查了哪份資料。高可靠度系統更需要結構化輸出，例如 JSON，固定包含結論、證據、限制與建議動作；對格式不合的內容應自動拒收並要求重試，而不是讓下一個代理自由猜測。

AutoGen AgentChat 曾提供多種 Team 模式。RoundRobinGroupChat 依序輪替發言，適合固定循環；SelectorGroupChat 依對話情況選擇下一個發言代理；Swarm 支援透過交接訊息轉移控制；MagenticOneGroupChat 用於較開放的多代理任務。[S04] 這些名稱屬於 AutoGen 歷史 API，不能直接假定在 Microsoft Agent Framework 使用完全相同的類別或參數。

假設任務是審查一份企劃書，輪流模式可先由撰寫代理產生初稿，再交給評論代理提出缺口，接著回到撰寫者修訂。若把停止條件設為評論代理回覆某段固定字串，原型很容易建立，但正式環境仍有一個根本風險：模型可能不按預期輸出終止文字，或在字串出現之前已經反覆討論多次。正式系統需要搭配最大訊息數、時間、成本與人工取消等硬性界線。[S05]

四、讓代理「互相聊天」，不等於它們在真正協作

多代理最容易產生的一種錯覺，是看見不同角色交替發言，就以為工作品質自然提高。若研究代理提供錯誤數字，審核代理又只能讀到同一段摘要，而不能取用原始資料，兩個代理可能互相肯定同一個錯誤。多一層意見，不等於多一層證據。

協作至少有三個不同層次。第一是語言層次的討論：代理彼此交換看法。第二是任務層次的交接：每個角色收到可驗收的輸入，交出指定格式的產物。第三是治理層次的責任：系統知道誰可以讀取資料、誰可以變更資料、哪些行動需要人核准，以及錯誤能否回復。對企業而言，第二與第三層才決定是否有機會穩定上線。

以行銷文章生產為例，若讓「企劃、作者、編輯、SEO」四位 AI 角色無止境辯論題目，很可能拖長成本，卻沒有可驗證的改善。更好的設計，是讓企劃先交一份含搜尋意圖與來源的研究摘要，作者依固定欄位產出初稿，編輯以可檢查的查核項目提出修訂，SEO 只處理確實有證據支持的標題、Meta 與站內連結。每個步驟必須知道「何時算完成」；如果審稿人說不通過，應指出具體欄位、證據與修正條件。

Anthropic 的代理架構研究將工作流與較自主的代理區分，並討論平行執行、路由、協調者與工作者、評估者與優化者等常見模式。[S10] OpenAI 的代理建置指南同樣建議先強化單一 Agent，只有當複雜指令、工具選擇或職責隔離變得難以管理，才考慮拆分多代理。[S11] 這兩種來源支持一個務實結論：應以任務的條件選擇協作拓撲，不應先決定使用幾個代理，再為它們尋找存在理由。

五、五種協作模式，以及各自容易失敗的原因

模式一：順序流程。 例如先讀取報表、再清理資料、再分析、最後撰寫摘要。它的好處是路徑明確，出錯容易定位；缺點是每一步都等待前一步完成，可能增加總時間。當步驟之間有嚴格依賴，例如未清理資料便不能產生財務結論，順序流程是合理選項。

模式二：平行流程。 例如同時由三個代理分別核對財務、法務與營運風險，再交由一個匯總節點整合。它的價值不是三個人設可以互相聊天，而是三個分支在輸入固定、相互獨立的條件下可以同時工作。若它們都會改寫同一份文件，便需要版本鎖定與衝突處理，否則平行可能製造資料競爭問題。

模式三：主管與專家。 主管代理保有最終回答權，必要時把特定問題交給專家代理當作工具處理。這很適合使用者希望只對接一個窗口，而內部有財務、法規或技術等不同能力的場景。缺點是主管可能變成所有資訊的瓶頸，需要保證輸入不超過上下文預算。OpenAI 文件也把這類做法描述為「Agents as tools」。[S12]

模式四：交接流程。 客服分類代理發現爭議付款案件，就把控制權交給具有相應政策與工具的處理代理。好處是責任領域清楚；風險在於某個代理可能把無法解決的問題交給另一個代理，形成往返循環。因此交接事件需要原因碼、任務狀態與最大交接次數。[S12]

模式五：產生與審查循環。 撰寫代理交出草稿，審查代理按檢核表提出修正，再由撰寫代理更新。它適合有可操作評分規範的工作，例如文件格式、程式測試、來源完整度。若審核標準只是「更有創意」，可能引發無法收斂的循環。應預設最大修訂輪數與人工仲裁點。AutoGen 的 Team 與終止條件文件，是理解這種模式的重要歷史教材。[S04][S05]

這五種模式並不互斥。實際流程常採混合設計：先固定順序執行資料驗證，接著平行查核兩種來源，再交由主管角色統整，最後在對外發布前要求人工批准。當流程越來越複雜，固定規則應留給程式，模型只負責需要語意判斷的節點，而不是每一步都重新問模型一次。

六、2026 年的關鍵轉折：為何不再建議新專案直接押注 AutoGen？

搜尋 AutoGen 教學時，讀者常會遇到不同年代的內容。一些文章介紹較早的 0.2 概念，另一些展示 0.4 之後的 AgentChat／Core 分層，甚至 GitHub 舊版 FAQ 仍可能保留開發當時的維護說明。[S06] 如果只看搜尋摘要、不檢查原始儲存庫首頁，就可能把歷史狀態誤當成現在的維護承諾。

截至本篇研究基準日，Microsoft AutoGen 官方 GitHub 已明確註記封存與不再維護，不提供新的安全修補、錯誤修正、功能或支援；它仍保留原始碼與文件，供研究和參考。官方同時建議現有使用者參考 AutoGen 至 Microsoft Agent Framework 的遷移指南。[S02][S07] 這不代表原先寫好的每一套 AutoGen 程式都會立刻失效，也不代表所有環境都必須今天全面改寫。真正的影響是，使用它承擔新上線系統的安全、相容性與維運風險，必須有更充分的理由與控管。

Microsoft Agent Framework 由原 AutoGen 與 Semantic Kernel 相關團隊的技術脈絡整合而成，2026 年 4 月 3 日的正式公告把 1.0 定位為具穩定 API 與長期支持承諾的正式版本。[S03] 官方遷移指南進一步指出：AutoGen 的高階 Team 及事件驅動核心，與 Agent Framework 偏向型別化、圖狀 Workflow 的協調思路不同；單一 Agent 的移轉相對直接，但多代理工作流程需要重新思考資料如何流經各執行節點。[S07]

請注意「後繼」不等於「功能一模一樣」。Microsoft 的對照文件列出模型用戶端、工具包裝、執行迴圈、狀態保存與觀測方式的差異。某些功能因版本與供應商而異；任何在舊系統使用的擴充套件，都應實際用目標版本測試，而不能依名稱相似就判斷完全相容。[S07]

對企業決策的意義很直接。若是教學或閱讀既有開源案例，AutoGen 仍然有研究價值；若是新建立涉及內部資料或長期維護的正式應用，優先評估目前有維護承諾的框架；若既有 AutoGen 系統已經運行，則先盤點功能、資料與安全風險，再做漸進式遷移，而不是單純將套件名稱替換掉。

七、AutoGen 與 Microsoft Agent Framework：哪些延續，哪些必須重做？

資料根據 Microsoft 官方儲存庫、Agent Framework 概覽與遷移指南整理。對照屬架構層級，不代表所有歷史功能均已一對一移植。[S02][S03][S07][S08]

最重要的變化不是 API 名稱，而是工作方式。AutoGen 的典型學習經驗常從「建立兩個 Agent，讓它們輪流協作」開始；企業正式工作流則更應從「每個步驟需要什麼輸入、由哪個執行器負責、交付什麼輸出、在哪個節點批准」開始。前者容易幫助團隊理解多代理思想，後者更適合追蹤責任與故障。

例如，原本讓兩個代理自由討論客訴處理策略，遷移後可以改成四個可檢查的執行階段：訂單查詢、政策比對、回覆草稿與主管核准。模型可對客訴語意進行分類，但訂單狀態與服務政策應由可信資料源取得；若訂單查詢失敗，流程應停止或轉人工，不可猜出一組交貨日期。這才是從「能演示」進到「能管理」的根本差別。

八、企業案例拆解：把報價審核設計成一套多代理工作流程

以下是虛構教學情境，目的是演示設計方法，不代表天地人或其他企業已部署該系統。假設一家 B2B 公司每天收到客戶詢價，業務必須查歷史訂單、確認庫存、核對折扣規範、整理正式報價草稿，最後交給主管批准。現在公司想改善的是「從客戶詢價到可審核草稿」的時間，而不是讓 AI 自動決定對客戶的價格。

第一個步驟不是畫代理圖，而是定義成功輸出：每一份報價草稿都要附客戶編號、商品代碼、價格來源、庫存檢查時間、折扣依據、例外提醒與審核人。若缺少其中的必填項目，即使文字漂亮，也不得進入下一階段。

第二個步驟是區分固定規則與語意工作。從 ERP 查單、取得商品價格、計算折扣上下限，應盡可能由程式與資料庫完成；客戶需求解讀、特殊條款的語意對照，可以由 AI 輔助。對同一商品的原價與折扣，不應讓模型依記憶自由估算。這會把多代理設計化約成真正需要 AI 判斷的部分。

第三個步驟是分配有限責任。需求分析代理把來信轉為結構化詢價清單；資料檢核執行器以唯讀權限查產品與庫存；條款審核代理只讀取已批准的政策文件；報價草稿代理彙整資訊；系統在最後等待業務主管確認。這裡可以只有三個 AI 代理，加上數個普通函式和一個人工節點。不是每個角色都必須由大模型扮演。

第四個步驟是定義例外。當客戶產品代碼不存在、庫存資料超過規定更新時間、折扣超過門檻，系統應明確返回「缺資料」「需主管審核」或「不可自動報價」，而不是默默補值。若同一客戶有兩個衝突價格來源，要保留兩份證據並指派責任人，不可讓模型自行取一個看似合理的平均。

第五個步驟是留下可追溯紀錄。每次流程要有任務 ID、輸入版本、使用的工具與政策版本、代理輸出、審核結果與時間；涉及個資與商業機密時，紀錄本身也要分類及控管權限。企業應特別檢查紀錄是否會不必要地保存完整客戶資料、API 金鑰或敏感內文。

第六個步驟是先做封閉試點。可以取一小批去識別化的歷史詢價作為測試集，包含正常案例、缺資料、錯誤商品代碼與需要人工裁決的例外。比較一個「單一模型加工具」版本，與「多代理加固定流程」版本，不僅看正確率，也看處理成本、人工修改量、操作次數與錯誤可追蹤性。若多代理方案沒有帶來可測量的改善，就沒有理由只因技術新穎而採用。

九、不要用「完成率」單獨評估 AI Agent：建立 6 個驗收指標

評估多代理系統，首先應分開「系統有沒有完成流程」與「完成結果是否正確」。一個系統可以 100％ 產出回覆，但其中有 20％ 未核實庫存；表面完成率高，實際對營運可能更危險。以下指標屬本文提出的管理框架，不是已經取得的行業統計數字。

有效完成率：分母為全部符合試點定義的任務，分子為按流程結束、必要資料完整且通過人工或獨立規則驗收的任務。不要把「模型回了最後一句」當成完成。

錯誤分級率：依結果影響區分格式錯誤、可修正的內容錯誤、需人工介入的政策錯誤、潛在安全事故。不同嚴重度不應簡單相加成一個平均錯誤率。

人工覆核與重工時間：紀錄主管從接到草稿到批准的時間，以及需要人工補資料、重寫或重新查核的工作量。如果系統把人工工作從製作轉成更耗時的檢查，節省工時的說法就不成立。

每件合格任務的總成本：除了模型 token 與 API 費用，應包含工具呼叫、基礎設施、人工審查、重試與例外處理。最容易錯估的是只報模型費用，卻忽略工程維運及風險控制。

時間與穩定性：以中位數和尾端延遲觀察任務耗時，追蹤逾時、卡住及重啟的比例。平均時間有時掩蓋少數非常慢的失敗案例。對客戶服務而言，尾端案件可能比平均值更影響體驗。

可追溯率：對被抽樣的任務，是否能重建輸入資料、代理決策、工具呼叫、人工批准及最終輸出。如果無法回答「這個折扣從何而來」，這套系統就尚未具有足夠的審計能力。

設計實驗時，至少保留一個不使用多代理的基準組。相同資料、相同驗收規則下比較成本與結果，才能判定多代理拆分真的帶來價值。這個方法與一般軟體工程的迭代評測一致，也避免把「同時使用更多模型」誤當成改善成果。

十、工作流程真正需要的六個治理護欄

第一，最小權限。只需查詢的代理使用唯讀憑證；涉及寫入或對外發送的工具，應另行核發權限並限制對象、欄位和條件。不能因為代理能生成 SQL，就讓它直接擁有刪改正式資料庫的權限。

第二，輸入來源分級。使用者的指令、公司政策、網頁內容與外部附件，在信任層級上不同。網頁中的一句「請忽略之前的規則」應被當成待分析資料，而不是系統指令。跨來源資訊應有清楚引用與來源記錄，避免提示詞注入透過工具回傳內容進入高權限代理。

第三，結構化契約。交接時要求明確欄位，例如 case_id、evidence_ids、decision、requires_approval 與 next_step。這種契約讓程式能先檢查型別與必填欄位，減少自然語言的歧義。不過 JSON 格式正確只代表結構正確，並不自動證明內容為真。

第四，硬性停止條件。必須設計最大工具呼叫次數、最大重試數、逾時、成本預算與手動中止方式。AutoGen 既有終止條件包含訊息數、token 用量與時間等概念，可作為理解為何需要停止規則的參考；正式系統則應以當前框架支援的 API 實作。[S05]

第五，人工批准與恢復。對寄信、採購、退款、價格修改或其他高風險動作，應在真正執行前保留批准節點。Agent Framework 文件提供 Human-in-the-loop 與 checkpoint／resume 的工作流功能，設計者仍須自行定義誰能批准、批准是否過期，以及中途恢復後是否需重新驗證資料。[S08][S09]

第六，觀測與稽核。工程團隊需要知道每個節點花了多少時間、呼叫了哪些模型與工具、失敗在哪裡。模型輸出也應能和輸入、來源版本及審核紀錄相連。這不只是除錯功能，而是日後成本分析、資安事件調查與流程改善的共同基礎。[S07][S08]

圖解文字：先定義目標與驗收條件。固定規則能完成的任務，採普通程式與自動化；需要語意判斷時，先建立單一 Agent 加工具的基準版本。只有在單代理仍不足，且需要獨立職責、工具權限或明確交接契約時，再評估多代理。

十一、AutoGen 與 LangGraph、OpenAI Agents SDK 的比較，應回到設計問題

讀者常問哪個框架最好，但真正的選型單位不應是品牌名稱，而應是「這個系統的執行控制究竟要放在哪一層」。多代理功能會在不同框架中重疊，這並不奇怪：都要解決模型調用、工具使用、狀態持續、任務路由與交接。但各家抽象的起點與維護脈絡不同。

Microsoft Agent Framework 把 Agent 與 Workflow 放在共同架構中，可將代理及一般程式執行器放入圖狀流程，並提供人工介入、checkpoint 與觀測能力。對既有 Microsoft 技術團隊，尤其是已有 AutoGen 或 Semantic Kernel 資產者，官方遷移路線具有明確參考價值。[S07][S08]

LangGraph 著重狀態化的圖狀執行，其官方文件和原始碼說明支援在節點中中斷並於保存狀態後恢復，對需要明確定義流程與人類回應的系統具有吸引力。[S13] 但「支援中斷」不等於應用會自動符合公司的權限、資料保護或營運規範；安全設計仍要自己完成。

OpenAI Agents SDK 以 Agent、handoff、guardrail、session 與 tracing 等構件幫助開發者建立工具調用及代理路由。官方說明區分專家接管對話的 handoff，以及由管理代理保有最終責任、把專家視為工具的模式。[S12] 它和 Microsoft 的流程圖方式有重疊，差別更多在開發抽象、供應商生態與工作流控制方式。

這張表不是性能排名，也不是採購清單。框架更新很快，務必根據目標版本與部署環境進行小型驗證，再依資安、維護、工程能力與既有系統選定方案。

十二、怎麼開始實作？先做無副作用的最小流程

如果只是理解 AutoGen 的歷史設計，可以先閱讀官方 AgentChat 的 Team 教學，用兩個代理分別產出文字與提供審核意見，搭配最大輪數和終止條件。但因 AutoGen 已停止維護，這類程式應放在隔離的研究環境，不應直接接企業正式資料或長期生產服務。[S02][S04]

對今天要開始正式開發的人，較合理的實作順序是先設定一個小型任務，再從當前仍受維護的官方 SDK 入門。例如建立「取得已公開政策文件、摘要差異、產出待核准建議」的唯讀流程。模型應只負責判斷內容，資料查詢由受控工具處理，最後把輸出交給人確認。

第一週可以只開發不寫入外部系統的版本。輸入使用公開或去識別化資料，輸出限制成可查驗的欄位。先建立至少兩類反例，例如資料缺失與相互矛盾的政策；若系統對缺資料仍自信回答，應先修正資料驗證與流程停止，而不是增加更多代理。

第二週加入工作流紀錄、逾時及重試，確認每個節點失敗時可辨識是哪個工具、哪筆資料或哪項規則有問題。第三週加入人工批准和有限的外部操作，但仍使用測試系統。第四週才做同資料的基準比較，驗收成功率、人工重工、成本及資訊安全事件。這是本文建議的試點節奏，而非 Microsoft 的正式導入承諾。

對沒有工程背景的主管，最有價值的參與不是學會每個 Python 套件名稱，而是把「什麼情況可自動完成，什麼情況必須停止，哪些證據不可缺少」寫成能交給工程師的規格。把客戶需求、流程責任與驗收定義講清楚，往往比親自寫一段 Agent 程式更能降低專案風險。

十三、既有 AutoGen 專案要怎麼遷移？避免直接替換套件的五步驟

第一步：盤點現況。 列出程式使用的 AutoGen 世代、Agent 類別、Team 模式、外掛、模型供應商、工具呼叫、權限與部署位置。不要因為程式能成功安裝，就假設套件仍有安全維護。

第二步：盤點契約。 對每個任務記錄輸入資料、輸出格式、工具副作用、狀態保存、停止條件與例外處理。這樣即使替換框架，企業真正需要的行為仍可被驗證。沒有規格的遷移，很容易只搬動程式語法，卻不知道功能是否變了。

第三步：建立對照。 依 Microsoft 官方遷移文件，比對模型用戶端、單代理、工具、團隊模式、觀測及狀態管理。尤其留意 AutoGen Team 的互動模式與 Agent Framework Workflow 資料流方式的差異，不應把原本的代理聊天紀錄直接視為新流程定義。[S07]

第四步：並行驗收。 使用相同去識別化資料，讓舊系統與新系統在安全隔離的環境跑相同測試。比較結果不能只看答案文字相近，更要看有無執行未授權工具、重試行為、成本、失敗原因與人工批准是否確實生效。

第五步：逐步切換與回復。 先讓新系統處理低風險、唯讀與可人工審核任務，再逐步擴大。準備回復機制，避免新框架一上線就處理高風險寫入。對外行動尤其要檢查冪等性，防止系統中斷後重試時重複寄信、重複建單或重複付款。

若工程團隊缺乏時間全面遷移，可以先完成安全風險評估與運作隔離。但要誠實記錄這是風險接受決策，而不是把沒有維護承諾的套件重新稱為正式受支持產品。

十四、部署前必須提出的十個問題

在採用任何多代理框架之前，管理者與工程團隊應共同回答以下問題。答案應能寫進需求文件，而不是只在會議中口頭討論。

1. 任務的最終業務目標是什麼？能否用一個可量測的成果說明？
2. 現有普通程式、自動化平台或單一 Agent 為何不足？是否已建立比較基準？
3. 哪些資料源是真實權威來源？資料版本與更新時間如何辨識？
4. 哪些代理可以讀取哪些資料？是否有代理取得不必要的寫入權限？
5. 每個步驟的輸入與輸出契約是什麼？如何檢查格式及事實？
6. 哪些操作必須由人批准？批准人如何確認完整證據？
7. 系統最多能重試幾次？逾時、費用超標或資料缺失時如何停止？
8. 執行記錄能否重現錯誤？是否不必要地保存敏感資料？
9. SDK、模型與依賴套件由誰持續更新？官方維護與安全修補狀態為何？
10. 若供應商、框架或模型變更，有沒有可移植的工作契約與回歸測試？

如果其中大半沒有答案，現階段更需要的是流程盤點與規格制定，而不是立即購買或導入更複雜的 Agent 系統。

十五、真正可交接的代理輸出：用「資料契約」取代模糊聊天

在多代理展示中，最常看到的流程是代理 A 說「調查完成」，代理 B 回覆「我接著分析」。但正式系統不能只依靠禮貌的自然語言交接，因為下一步究竟接收了哪些可靠資料、有哪些欄位未確認，往往被埋在幾百字的敘述裡。當任務跨越資料處理與決策時，交接應被視為明確的資料契約，而不是對話紀錄的延伸。

以報價試點為例，前一個節點可以要求輸出具有 request_id、customer_id、items、source_records、validation_errors、requires_review 的資料物件。items 內部仍須約定每個商品的代碼、數量與計價幣別，而不能只包含一段文字。source_records 需保留來源系統、資料更新時間及可回查識別碼；若資料來源不存在，就讓 validation_errors 指明缺漏，而不是填入 AI 猜測的值。

一份純示意的結構可能如下。這不是正式產品 SDK 範例，也沒有包含真實客戶資料：

{
  "request_id": "DEMO-001",
  "customer_id": "DEMO-CUSTOMER",
  "items": [{"sku": "SAMPLE-A", "quantity": 10}],
  "source_records": [],
  "validation_errors": ["未取得正式庫存來源"],
  "requires_review": true,
  "next_action": "manual_review"
}

這段格式的重點是「未取得資料」也是一個合法、可被處理的結果。若流程要求每個 Agent 無論如何都提出肯定答案，錯誤就會在節點之間以合理語句被包裝成事實。對企業而言，允許系統明確回覆不知道，比要求模型永遠完成更具保護作用。

資料契約應至少接受三種檢查。首先是語法檢查：資料是否符合 JSON 等格式要求。其次是型別與範圍檢查：數量是否為非負整數、日期能否解析、幣別是否在允許清單內。最後才是商業事實檢查：商品代碼是否真存在、價格是否為現行核准版本、客戶是否有權取得該資訊。前兩者可以主要由程式處理，最後一者則必須依靠權威資料源及政策規則。不能因為模型輸出通過 JSON Schema，就宣稱結果內容正確。

交接還必須考慮版本。假設報價執行到一半，公司的價格表更新了；在重新恢復流程時，究竟採用舊版價格還是新版價格？答案應由業務規則決定，但系統必須能偵測版本變動。若價格有效期間已過，應停止並重新取得資料，不可直接使用 checkpoint 中過期的值。這也是為何 checkpoint 提供的是恢復執行的技術能力，仍然需要企業自己決定狀態是否仍有效。[S09]

資料契約還能降低團隊對某一家模型或某個框架的依賴。當管理者保留了輸入欄位、輸出欄位、錯誤代碼與驗收方式，工程師未來可以更換模型、重新編排代理，甚至把其中一個 AI 節點改成普通程式，而不必連同商業流程全部重寫。長期來看，這比選到一套熱門框架更能保有可移植的數位資產。

十六、從一次錯誤推回架構原因：代理系統的除錯方法

傳統程式常有較固定的執行路徑，可以依錯誤訊息定位。多代理系統則同時包含程式流程與模型的不確定輸出。當最後報告引用了錯誤數字，問題可能出在原始來源、工具傳回內容、代理解讀、交接摘要、版本混用或審核缺失。如果只重新執行整套流程，很可能產生新的回答，卻沒有釐清第一次為何失敗。

因此，除錯應先建立一條「輸入到輸出」的證據鏈。每個重要節點至少記錄任務識別碼、節點名稱、輸入資料雜湊或版本、模型與工具版本、開始及結束時間、結果狀態、關鍵錯誤與是否涉及人工批准。對個資或敏感文件，不應把所有內容無限制寫入日誌；可以依內部規範保留必要的識別碼、摘要、存取紀錄與受保護的原始證據位置。

當發現錯誤時，可以分成四個面向。資料型錯誤，是源頭資料缺失、衝突或過期；工具型錯誤，是 API 回傳異常、權限不足或外部系統無法連線；判斷型錯誤，是模型明明取得正確資料，卻推導出錯誤結論；流程型錯誤，則是跳過批准、交接給錯誤角色、重試多次或在不該完成時結束。這種分類有助於決定應修資料、修程式、修提示詞，還是重畫工作流。

舉例來說，客服代理把一筆尚未出貨的訂單寫成「已出貨」。如果工具查詢回傳的是「待出貨」，錯誤可能在模型判斷或語意映射；如果工具本身讀到昨天的快取，則應修正資料新鮮度檢查。若代理根本沒有呼叫訂單工具，就直接生成出貨狀態，問題是流程允許模型在沒有證據時回答。這三種情境的責任人與解法完全不同，不能一概要求「把 Prompt 調好」。

比較進階的作法是為每一類錯誤保存一份匿名化、可重播的回歸測試。當團隊替換模型、SDK 或工作流時，首先跑這些歷史失敗案例，確認舊問題沒有再次出現。若修正一個問題後，另一些正常任務反而失敗，也能提早察覺取捨。官方 Agent Framework 把 Observability 列為重要的工作流程能力，但實務上仍須由團隊定義要看哪些證據，以及事故後如何分析。[S08]

多代理系統的核心品質不是永遠不失敗，而是失敗時知道停止、知道發生在哪裡、知道哪些輸出不可信，以及能否在風險可控的情況下恢復。這類能力通常無法從簡單的聊天展示直接看出，卻是企業評估供應商方案時最應要求示範的部分。

十七、API、MCP、Skills、Agent 與 Workflow：相似概念為何一直重疊？

從最小概念理解，這些名詞都在嘗試降低「讓 AI 完成一件工作」所需的整合成本，因此必然存在重疊。真正需要區分的不是哪一家先發明哪個名稱，而是每一層究竟對哪一種責任提供穩定介面。先把問題拆成「能連接什麼」「知道如何做什麼」「現在由誰執行」「各步驟如何交接」，差異就會清楚很多。

API 是軟體之間交換資料或呼叫功能的介面。ERP 可以透過 API 提供查單能力，但 API 本身不負責理解客戶為什麼詢問，也不會自動安排多步驟審查。MCP 則可為代理工具與上下文整合建立較標準化的互動方式，減少每一種模型與工具組合都必須獨立開發接點的負擔。這不代表用了 MCP 就自然取得正確權限；系統仍須管理身份、傳輸安全、資料可見性與工具是否允許執行。[S08]

Skill 可以是一套描述某種工作如何執行的指令、資源與可重用流程，像是「審查合約差異」或「製作每週營運報告」。它可能包含腳本，也可能只是讓代理在特定任務中採用固定方法的知識包。它和 Agent 在行為上有重疊，但 Skill 不必是獨立運作的代理；企業可以讓同一個 Agent 在不同情境載入不同技能，也可以讓多個 Agent 共用同一套驗收規則。

Agent 則是實際接受任務、選擇工具或生成輸出的執行單元。Workflow 是串起多個執行單元及一般程式、定義先後順序、分支、等待與停止方式的流程控制層。在某些框架中，Agent 也能像工具一樣被另一個 Agent 呼叫；某個 Workflow 也可能被封裝成新的 Agent 介面。抽象會重疊，不表示概念錯亂，反而說明軟體元件可組合與封裝的特性。[S08][S12]

例如「產生月報」可能同時使用公司內部 API、經 MCP 暴露的查詢工具、專門處理財務的 Skill、一個彙總代理，以及一條包含人工核准的 Workflow。任何一項技術都不是其他技術的唯一替代品。對決策者而言，應把採購問題寫成「這套系統能否在不擴大權限的條件下，可靠取得可信資料、遵守流程並保留證據？」而不是先問要買幾種 Agent 工具。

還有一個值得警惕的現象：技術供應商常會把不同層次的能力包進同一產品介面，讓使用者覺得所有功能都在同一個畫面完成。這在體驗上有好處，但不能忽略背後的權限、授權與維運責任。平台提供圖形化設定，並不表示企業已經得到完整的資安評估、軟體生命週期管理與業務風險控制。

十八、部門主管如何與工程師共同完成多代理專案？

代理系統的失敗，有時不是工程團隊不會寫程式，而是公司一開始沒有說清楚「工作到底怎麼判斷完成」。業務主管了解客戶承諾、例外處理與績效要求，資訊團隊了解資料庫、權限和系統依賴；若這兩種知識沒有被接成同一份規格，再好的框架也只是把不清楚的流程加速執行。

啟動會議最應交付的不是一張 AI 架構圖，而是一份工作案例清單。主管先挑出 10 件具有代表性的工作，包括正常、缺資料、異常、跨部門與不可自動處理的情境。每件工作要附原始輸入、理想結果、可使用資料、不能做的事，以及最後應由誰簽核。工程團隊再依此畫出資料流與權限邊界，確認固定程式能解決多少問題、模型判斷真正需要出現在哪裡。

可以把責任分成四個面向。流程擁有人確認任務價值與驗收標準；資料擁有人確認資料正確性、可見範圍與保存期限；系統負責人實作 API、工具與安全控制；審核負責人確認關鍵輸出及例外流程。這不是要求每件事都增加四位主管，而是避免在失敗後才發現「沒有人負責確認 AI 是否能寄出正式報價」。

實際評估供應商時，可要求展示同一個任務的三種狀態：成功完成、資料缺漏時安全停止，以及主管否決後如何處理。還應要求查看工具呼叫紀錄與權限，確認系統不會因為使用者在文件裡寫了額外要求，就繞過既定批准程序。這類測試比要求展示十個代理同時協作，更接近企業真正的採購風險。

培訓也可以依職能分層。一般同仁要理解哪些工作可以交給 AI、何時應查核與停止；主管要能定義例外、流程與輸出驗收；工程師則需要掌握工具整合、日誌、狀態、測試及部署。若把所有人都安排學習相同的 Python 架構細節，可能付出很多上課時間，卻沒有改善工作現場的決策品質。技術課與流程課可以相互銜接，但必須先明確它們各自預期產生什麼工作成果。

最後的移交應產出持續可用的四份文件：經核准的工作流程圖、代理與工具權限表、可重跑的測試案例，以及正式上線或停止的驗收紀錄。這四份資料並不依附任何特定框架，可在下一次模型更替、供應商換約或系統改版時繼續使用。這正是 AutoGen 留給企業最值得學習的教訓：真正可累積的數位資產，不只是 Agent 程式碼，而是可以被反覆驗證的協作規則。

十九、常見問題

AutoGen 和 ChatGPT 是一樣的嗎？

不是。ChatGPT 是提供使用者互動的 AI 產品；AutoGen 是供開發者建立多代理協作應用的程式框架。AutoGen 可透過不同模型用戶端連接相容模型，但不等於某個特定模型，也不直接保證與聊天產品相同的功能或服務條款。[S01][S02]

AutoGen 一定要寫 Python 嗎？

AutoGen 官方歷史文件主要提供 Python 的 AgentChat 實作，也曾提及跨語言設計與 .NET 的相關努力；具體可用性取決於版本。新專案應依 Microsoft Agent Framework 目前支援的語言與 API 選用，不應拿舊版 AutoGen 文件推斷今天的正式支援範圍。[S02][S03]

AutoGen Studio 能讓完全不會程式的人直接部署企業流程嗎？

AutoGen Studio 是 AutoGen 生態系曾提供的低程式碼／圖形介面工具，能協助研究與原型探索，但不應把「可以畫出流程」當成已完成身分管理、安全審核、資料治理與部署驗收。考慮到官方封存狀態，更不宜不經檢查就用來建立新的長期正式服務。[S02]

多代理系統一定比單一 Agent 準確嗎？

不一定。若不同代理使用相同錯誤資訊、沒有獨立證據或未經驗收，它們可能重複放大錯誤。多代理要有價值，必須能改善特定任務的責任隔離、工具選擇、資訊處理、速度或品質，而這些改善需要實測。[S10][S11]

AutoGen 停止維護，原本的程式會不能使用嗎？

官方封存不代表既有程式會立即停止執行，但失去後續修補與持續維護，長期相容與安全風險增加。是否能暫時保留，應依資料敏感度、外網暴露、依賴套件、替代方案與內部維護能力評估。[S02]

MCP、Skills 與 Agent Framework 是否屬於同一種東西？

不是同一層，但有重疊。MCP 主要提供工具與上下文整合的標準化介面；Skills 可以封裝某類任務的指令與資源；Agent Framework 則可協調代理、工具與工作流程。三者都可能影響「AI 能做什麼」，卻不必然互相取代。企業應先界定權限、任務與輸出，再決定哪些能力用哪一層實作。[S08]

2026 年新開發專案還應不應該學 AutoGen？

若目的是理解多代理原理、讀既有論文或維護現有程式，學 AutoGen 有價值。若是要規劃新正式系統，應優先研究 Microsoft Agent Framework 等仍活躍維護的方案，並考量實際供應商生態、團隊能力與安全需求。[S02][S03]

二十、結論：AI 協作的重點，是把「可交辦」變成「可驗收」

AutoGen 曾經讓開發者很容易想像一個未來：多個具有不同專長的 AI 代理，可以在同一個任務中協調、討論並使用工具。它讓多代理從分散的實驗腳本變成可重用的程式設計模型，這是值得理解的技術貢獻。[S01][S02]

但對 2026 年的企業而言，技術焦點已從「多個代理能不能互相講話」，移到「一個需要跨系統、跨權限及跨角色的工作，能否可靠完成、可以停止、能被追蹤，而且由適當的人承擔責任」。Microsoft Agent Framework 的新方向與 AutoGen 官方封存的事實，恰好提醒我們：工具名稱會演進，真正值得沉澱的是任務契約、測試案例、流程設計、資料治理與驗收標準。[S02][S07][S08]

若要把這種方法帶入團隊，建議先選一個低風險但有明確成果的工作，盤點目前流程，設計單一 Agent 基準版，再決定是否需要多代理；先確保資料正確與人工核准，再談擴大自動化。這樣建立的不只是 AI 展示，而是一套可以持續改進的工作能力。

延伸閱讀與下一步：若仍在理解 AI 代理與企業導入的基本差異，可先閱讀天地人《AI Agent 是什麼？原理、應用與企業導入完整指南》。若企業正在盤點工作流程、工具與員工能力，可參考《AI 應用人才實戰班》的工作實作內容，或由天地人企業培訓窗口討論流程診斷與培訓需求。本文不宣稱該課程目前包含 AutoGen 或 Microsoft Agent Framework 的正式技術課綱。

參考來源與查核註記

[S01] Microsoft Research，AutoGen 專案介紹：查看官方來源

[S02] Microsoft，AutoGen 官方 GitHub，含封存與不再維護公告：查看官方來源

[S03] Microsoft Developer Blogs，Microsoft Agent Framework Version 1.0，2026-04-03：查看官方來源

[S04] AutoGen 官方歷史文件，AgentChat Teams：查看官方來源

[S05] AutoGen 官方歷史文件，Termination：查看官方來源

[S06] AutoGen GitHub 舊版 FAQ，反映當時不同版本的歷史狀態；不可代替現行封存公告：查看官方來源

[S07] Microsoft Learn，AutoGen to Microsoft Agent Framework Migration Guide：查看官方來源

[S08] Microsoft Learn，Agent Framework 概覽與 Workflows：查看官方來源；補充文件

[S09] Microsoft Learn，Human-in-the-loop／Checkpoints：查看官方來源；補充文件

[S10] Anthropic，Building effective agents：查看官方來源

[S11] OpenAI，A practical guide to building agents：查看官方來源

[S12] OpenAI，Orchestration and handoffs：查看官方來源

[S13] LangGraph 官方文件儲存庫，Interrupts：查看官方來源

站內延伸：天地人《AI Agent 是什麼？》 AI Agent 完整指南；課程 https://www.tiandiren.tw/product/c1642 。查閱日期：2026-11-02。來源中技術文件可能持續更新，正式上線前仍應依當時使用的 SDK 版本重新核對。