把流程交給 Agent 之前：用 Copilot Studio 打造業務代理人

「哪些工作可以交給 AI 代理人」這個問題，很多團隊是從工具開始想的，結果做出一堆沒人用的東西。比較有效的順序，是先看清楚一個代理人到底由什麼組成。

這篇用 Copilot Studio 當例子走一次，並標出 2026 年 8 月的官方現況。它的位置是低程式碼，貼著 Microsoft 365 生態，跟給專業開發者的 Microsoft Foundry 分工不同。

把流程交給代理人，跟把工作交給新同事很像：你要講清楚他是誰、能查什麼、能動什麼，以及遇到不確定時要找誰。

這四件事在 Copilot Studio 裡都有對應的設定位置。先把對應關係認出來，工具怎麼點反而是最容易的部分。

它現在做得出三種東西

官方把 Copilot Studio 定位成建置與管理代理人與工作流程的低程式碼工作室。裡面的建構區塊有三種，可以單獨用，也可以互相呼叫。

• 代理人：處理對話與完成任務，依你給的指示、連上的知識來源與工具，推理出下一步該做什麼。
• 工作流程：用拖放設計器建的自動化，每一步都可以推理與行動，內建測試與人在迴路的控制。
• 代理人流程：既有的流程格式，編寫體驗接近 Power Automate，可以獨立執行，也可以掛在代理人身上當工具用。

這三者會互相呼叫，所以不必一開始就選死。比較常見的起手式，是先做一個代理人，再把它需要的動作包成流程掛上去。

第一個真正的決定是選引擎

2026 年的 Copilot Studio 引入了引擎的概念。官方明說你選的引擎會影響它怎麼推理、能承擔多複雜的任務、內建什麼能力，以及怎麼計費。

這一格選錯的成本不小，因為後面的能力與計費都跟著走。先問一句：這個流程的步驟能不能事先畫成流程圖？能，就別急著上推理引擎。

串接後端：工具有哪幾種接法

官方把工具定義成讓代理人與外部系統互動的建構區塊。可以接的東西比多數人想的多。

• 連接器：預建連接器涵蓋大量常見服務，自訂連接器則用來接自家的 API。
• 代理人流程：把一連串動作包成一個工具，回傳結果給代理人。
• 提示：單輪的模型呼叫，可以引用你提供的知識。
• REST API：直接定義端點與方法，適合沒有現成連接器的內部系統。
• MCP 伺服器：以標準協定接上一組工具與資源，維護成本比逐支包裝低。
• 電腦使用：讓代理人操作有圖形介面的系統，適合沒有任何 API 可用的老系統。

另外記得設定「執行前先問使用者」這個選項。會改動資料或對外送出東西的工具，讓它先問一句，成本很低，省下的麻煩很大。

什麼流程適合交出去

這是營運端最該花時間的一題，而它跟技術幾乎無關。我的判準是三個問句。

1. 完成的定義清楚嗎？說得出「什麼情況算做完」，代理人才知道要停在哪裡。
2. 需要的資料查得到嗎？資料散在沒有 API 的地方、或根本沒數位化，先解這個再談自動化。
3. 做錯了能回復嗎？能回復的先交出去，不能回復的一律加人工確認。

一個實務建議：第一個上線的代理人選查詢類。它出錯的代價最小，而且最快能累積出「使用者到底會怎麼問」的真實語料。

身分與治理，別留到最後

代理人會替人做事，所以它需要一個能被稽核的身分。這件事在 2026 年已經有正式機制。

依官方文件，Copilot Studio 會自動為新代理人建立 Microsoft Entra Agent ID，把代理人納入與使用者、工作負載相同的治理模型。

• 條件式存取原則可以套用在代理人身上，跟套用在使用者身上一樣。
• 集中稽核記錄與生命週期管理，讓「這個代理人是誰建的、還在不在用」查得到。
• 發布時，代理人設定的每個連接器，其 API 權限會掛到這個身分上，管理員因此看得到它能呼叫哪些連接器。

上線前我會做的四件事

1. 用低權限帳號實際問一次，確認它拿不到不該拿的資料。
2. 建一組評估用的問題集，包含刁鑽問法與明知它答不出來的題目，看它會不會硬掰。
3. 檢查每個會改動資料的工具，有沒有設「執行前先問使用者」。
4. 把分析與代理人清單打開，確定上線後看得到誰在用、用得怎麼樣。

最後一句給營運主管：代理人不會因為做得好就自己被用起來。真正決定成敗的，是它有沒有出現在同事本來就會打開的那個視窗裡。