假設一家五十人的精密加工廠，想做第一個 AI agent：客服收到「孔徑超差」這類品質回報時，agent 自動讀訂單與檢驗紀錄、核對批次和機台，建立一張品質異常單草稿，交給品保主管確認。
會議上出現三個提案。IT 同事說他可以用 SDK 自己寫；業務主管說公司已經在用 Microsoft 365，用 Copilot Studio 拖拉幾下就好；還有一家顧問公司來報價，說可以派人駐點做。三個提案都做得出第一版。差別在三個月後：訂單系統改了欄位、模型換了版本、品保主管想多加一個檢查項目，那時候誰來改？
選自建、平台還是委外，先看流程要串幾個系統、例外有多少，以及上線後誰來維護。
這有點像要一張椅子。你可以買組裝包自己鎖、直接去展示間挑一張現成的，或找木工師傅訂做。三種都能坐，但椅子搖了之後，第一種你自己鎖緊，第二種看店家保固，第三種要看師傅還接不接電話。
三條路各是什麼
自建：用 SDK 或框架寫程式
主要的模型供應商都提供了開發工具。OpenAI 的 Agents SDK 用少量元件組出 agent：指令與工具、agent 之間的交接、輸入輸出的檢查（guardrails），並內建人工介入機制和執行追蹤。
Anthropic 的 Claude Agent SDK 把 Claude Code 背後的工具、權限控制、hooks 與 agent 迴圈做成程式庫。Google 的 ADK 是開源的 agent 開發框架，支援 Python、TypeScript、Go、Java、Kotlin，也能把固定邏輯和模型推理用圖狀流程串在一起。
如果不想自己管執行環境，OpenAI 的 Agents API 和 Anthropic 的 Managed Agents 則由供應商代管 agent 的執行與狀態。你仍要寫程式定義 agent 做什麼，只是少管一層基礎設施。
自建的好處是每一步都看得到、改得動。代價是工程師要懂模型的行為，也要有人寫測試、看紀錄；只靠一個人兼著做，很難撐過第一次大改版。
平台：低程式碼或無程式碼
Microsoft Copilot Studio 是低程式碼的工作室，可以用自然語言描述來建立 agent 和工作流程，接上組織的資料與系統，發布到使用者習慣的管道，並提供分析、評估與管理功能。Google 的 Gemini Enterprise 提供不寫程式的 Workflow Builder，能接 Google Drive、SharePoint、HubSpot、Jira 等資料來源，並讓管理者控制 agent 能存取哪些應用程式和資料。
原本就在用自動化工具的團隊，也可以在既有流程裡加 agent。n8n 的 AI Agent 節點接上聊天模型和工具後，會自己決定呼叫哪個工具；Zapier Agents 則以可連接九千多個應用程式為主要賣點。
平台的好處是快，代價是只能用它提供的積木。試用時先拿流程裡最難的那個例外去測，看平台做不做得到，會比看示範影片準確。決定走平台之後，Dify、n8n、Copilot Studio 怎麼選，可以看 AI agent 平台怎麼選。
委外：找外部團隊從需求做到上線
外部團隊負責需求盤點、系統串接、測試上線，有時也包含後續維護。你買的是一組人的時間和經驗，最後拿到的東西可能是程式碼、平台上的設定，或兩者都有。
以開頭那家加工廠為例，如果選委外，合理的第一個交付物是一份流程盤點：客服收到回報後實際查了哪些系統、每一步怎麼判斷、哪些情況會直接找品保主管。這份文件不管最後由誰來做，都用得到。
| 路線 | 代表選項 | 適合 | 你要自己負責 | 常見風險 |
|---|---|---|---|---|
| 自建 | OpenAI Agents SDK、Claude Agent SDK、Google ADK | 要串內部系統、有工程師長期維護 | 程式、部署、監控、模型更新 | 只有一個人看得懂，他離職就停擺 |
| 平台 | Copilot Studio、Gemini Enterprise、n8n、Zapier Agents | 資料多在既有辦公套件、流程較單純 | 設定、權限、授權費用 | 被平台功能限制，平台調整時要跟著改 |
| 委外 | 外部開發團隊 | 要串多個系統、內部沒有工程人力 | 需求確認、驗收、合約範圍 | 交付後改不動，每次調整都要重新報價 |
真正的成本在上線之後
第一版做出來，通常只占整體工作的一小部分。上線後會一直發生的事包括：模型推出新版本、供應商調整 API、內部系統改欄位、使用者提出新的例外、權限需要重新檢查，以及每週看一次執行紀錄，確認 agent 沒有默默做錯。
平台也會變。OpenAI 在 2026 年 6 月宣布淘汰 Agent Builder 這個視覺化建置工具，預定 2026 年 11 月 30 日關閉，已在使用的團隊要在過渡期內轉移；它原本就提供下載 SDK 程式碼的選項，有匯出的人轉移起來輕鬆很多。選任何一條路之前，先問清楚設定和程式能不能帶走。
椅子做好只是開始，工具箱、保養油和紀錄本代表交付後還要有人持續維護。
所以比較三條路時，我會把「一年的維護」一起算進去。下面這張表可以拿來問自己，也可以拿去問廠商：
| 維護項目 | 大約頻率 | 自建 | 平台 | 委外 |
|---|---|---|---|---|
| 看執行紀錄、抽查結果 | 每週 | 內部工程師 | 內部管理者 | 看合約是否包含 |
| 調整指令或新增例外 | 每月 | 內部工程師 | 內部管理者 | 通常要另外報價 |
| 模型或 API 更新後重新測試 | 每季或不定期 | 內部工程師 | 平台處理大部分，仍要自己驗收 | 看合約是否包含 |
| 權限與帳號盤點 | 每季 | 內部 IT | 內部 IT | 內部 IT |
最後一列三條路都一樣：權限盤點永遠是公司自己的責任。
用三個條件判斷由誰來做
條件一：流程串幾個系統、例外有多少
只讀一兩個資料來源、做的事以回答和整理為主，平台通常就夠了。要跨 ERP、MES、客服信箱、檢驗紀錄等多個系統，每一步又有不同的例外，平台的設定會越堆越複雜，這時寫程式反而比較清楚。
條件二：資料和系統在哪裡
資料主要在 Microsoft 365 或 Google Workspace，對應的平台已經有現成的連接器，省下很多串接工作。資料在內部 ERP 或只能點畫面操作的舊系統裡，就需要客製串接。以開頭的品質異常單為例，訂單在 ERP、檢驗紀錄在另一套系統、客服信在 Outlook，只有最後一項有現成連接器。
Model Context Protocol（MCP）是一個開放標準，用來把 AI 應用接上外部資料和工具，Claude、ChatGPT 等都支援；OpenAI 與 Anthropic 的 SDK、n8n 也都能接 MCP 伺服器。內部系統若能包成 MCP 伺服器，之後換平台或換模型時比較不用重做串接。
條件三：公司內有沒有人能維護
這是最常被低估的條件。有人能讀執行紀錄、改指令、處理 API 變更，自建才撐得下去。沒有這樣的人，自建的 agent 很可能在第一次出問題時就被擱置。有沒有人能維護，比選哪個工具更早決定這個 agent 能用多久。
| 情境 | 建議先試 | 理由 |
|---|---|---|
| 單一部門，資料都在 Microsoft 365，流程以問答和簡單動作為主 | Copilot Studio 這類平台 | 連接器現成，授權與權限管理沿用既有環境 |
| 已經用 n8n 或 Zapier，想在流程中加一個判斷步驟 | 在既有流程加 agent 節點 | 不用重建整條流程，出錯範圍小 |
| 要串 ERP、舊系統，內部有工程師 | SDK 自建 | 串接彈性大，能力留在公司內 |
| 要串多個內部系統，內部沒有工程人力 | 委外，並要求完整交付 | 需要有人到現場梳理流程並負責上線 |
| 流程還說不清楚 | 先做需求盤點，暫緩選路線 | 需求沒定，任何路線都會一直改 |
什麼時候不適合委外
委外很方便，但有幾種情況我會建議先別找外部團隊。
- 平台就做得到的簡單流程：例如讓員工在 Teams 裡查請假規定、找表單下載位置，平台設定幾天就能完成。為這種需求付一整個專案的費用，不划算。
- 公司想長期擁有這個能力：內部已經有工程師、也打算培養，外部團隊只協助第一版或擔任顧問就好，避免核心能力一直在別人手上。
- 需求還沒定：邊做邊想的專案委外，很容易變成無止境的需求變更與追加報價。
真的要委外，合約裡把這幾件事寫清楚：交付物包含哪些（程式碼、平台設定、提示詞、測試案例、權限設計文件）、驗收標準是什麼、維護範圍與回應時間，以及結束合作時怎麼交接。驗收要怎麼設計，可以看 AI agent 專案怎麼驗收。
評估時要問的六個問題
不管選哪條路，跟內部團隊、平台業務或外部廠商談的時候，都可以拿這六題去問。答不出來的地方，就是之後會出問題的地方。
- 資料會存在哪裡、保留多久、誰看得到？
- 模型或平台更新時，誰負責測試、多久通知？
- agent 在哪些步驟會停下來請人確認？權限怎麼分級？
- 執行紀錄能不能查、能不能匯出？
- 設定、程式和提示詞能不能匯出帶走？
- 出錯時誰處理、多久回應？
其中第 5 題最容易被略過。設定和提示詞留在某個平台帳號或某位工程師的電腦裡，換人或換平台時就得從頭再來一次，連當初為什麼這樣設定都查不到。
方案與價格變動很快，以各家官方頁面當下的說明為準。權限與人工確認的設計細節，可以看 AI agent 的權限與人工確認怎麼設。
這些比較的限制
各家的功能更新很頻繁，今天的比較幾個月後就可能改變，所以選擇時看的應該是自己的條件，而不是某個功能的有無。
另外，第一版試做成功只能證明技術上做得到。假設試做時只用了 20 張格式整齊的品質回報單，上線後才發現客戶常用 LINE 截圖回報、批號寫在照片裡，agent 的表現就會跟試做時差很多。試做時就放進真實資料和真實的例外案例，會比用示範資料更早發現問題。
選路線之前先做的事
選路線之前，有兩件事要先想清楚。第一件是這一段工作真的需要 agent，還是固定流程就夠了。例如品質異常單的「建立表單、通知品保主管」其實是固定步驟，需要判斷的只有「核對批次和機台」那一段。可以先看 AI agent 和聊天機器人、RPA、自動化流程差在哪。
第二件是先挑哪個流程，看哪些企業流程適合先交給 AI agent。資料要準備到什麼程度，則在企業知識庫要整理到什麼程度裡有說明。
我們能協助的部分
我們的企業 AI 營運方案屬於委外這條路：前線工程團隊到現場梳理作業細節，確認交付與驗收標準，打通既有軟體與資料庫，在真實業務中驗證後上線，之後提供長期的技術支援與維護，需要判斷的步驟會設計人工審核機制。
如果評估後發現平台就做得到，我建議先用平台，等流程需要串更多系統時再談下一步。
常見問題
公司已經有 Microsoft 365，直接用 Copilot Studio 就好嗎？
流程單純、資料多在 Microsoft 365 裡的話，很適合先從它開始。要注意的是當流程需要串內部 ERP 或舊系統時，設定可能變得很複雜，這時再評估是否改用程式開發。給員工日常使用的 AI 助理是另一個採購決定，可以看企業版 AI 助理怎麼選。
用 n8n 或 Zapier 做 agent，和用 SDK 自建差在哪？
n8n、Zapier 讓你在既有的自動化流程裡加一個 agent 步驟，上手快、出錯範圍小。SDK 自建則能完整控制 agent 的每一步、權限和紀錄，適合要深度串接內部系統的情況，但需要工程師長期維護。
委外做完之後，公司自己改得動嗎？
要看合約。交付物有程式碼、設定、提示詞和測試案例，內部又有人接手，就改得動；如果只交付一個能跑的系統，之後每次調整都得回頭找原廠商。
選路線時要在意 MCP 嗎？
值得一併考慮。內部系統若能包成 MCP 伺服器，之後換平台或換模型時比較不用重做串接。MCP 的組成和導入前要檢查什麼，見 MCP 是什麼。
平台停止服務怎麼辦？
先確認設定和程式能不能匯出。OpenAI 淘汰 Agent Builder 時，提供了過渡期，而且原本就能下載 SDK 程式碼；有定期匯出的團隊，轉移成本低很多。
參考來源
以下依官方文件整理，功能與方案以官方頁面當下為準。
- OpenAI：Agents 指南（Agents API、Agents SDK、Responses API）
- OpenAI Agents SDK
- OpenAI：Agent Builder（淘汰公告）
- Anthropic：Claude Agent SDK overview
- Model Context Protocol：What is MCP?
- Google：Agent Development Kit（ADK）
- Google Cloud：Gemini Enterprise
- Microsoft Learn：Copilot Studio overview
- n8n Docs：AI Agent node
- Zapier：Zapier Agents（業者自述）