用 AI Agent 幫客戶寫 Power Automate Flow, 從 80 個 Action 到 17 個

分享這兩天用 AI Agent + MCP 幫客戶開發 Power Automate 的經驗。

客戶需求

客戶要做一個文件處理的自動化 - 有人上傳 Word 報告到 SharePoint list，Power Automate 自動把它轉 PDF、存到對應的 document library、發 Teams message、寄 email。不同的文件類型要存到不同的地方、發到不同的 channel。

客戶本來有一套在用的，3 種文件類型，用 Switch 分流。我要幫他們做一個新的給另一個團隊用，這次有 6 種文件類型。

我就想，要不要直接叫 AI agent 幫我做。

讓 Agent 讀現有的 Flow

我用的是 Claude（在 VS Code 裡面跑），透過 Flow Studio MCP 連到客戶的 Power Automate 環境。MCP 讓 agent 可以直接讀 flow definition、deploy 修改、trigger 測試、看 run history, 不用開 Power Automate designer。

第一步是讓 agent 讀現有的 flow：

agent → list_live_flows → 找到現有的 flow
agent → get_live_flow → 讀完整的 flow definition

Agent 看完之後馬上理解整個結構：trigger 是 SharePoint list item created，Apply to Each 跑 attachments，裡面兩個 Switch block 分文件類型, 一個處理 PDF 轉檔跟存檔，一個處理 Teams message 跟 email。

第一版：直接照抄

Agent 直接照抄邏輯，把 3 種改成 6 種 => 6 個 case 的 Switch，每個 case 裡面一整組重複的 action。deploy 上去，80 幾個 action。

其實也不是不行，畢竟舊的那一套也是我做的，結構一樣。只是改 bug 的時候在 Switch 裡面改有點麻煩, 6 種文件類型就要改 6 次，很容易漏。

舊版 Switch 長這樣：

3 個 case 展開，每個 case 裡面一整組重複的 action, Compose、HTTP Graph、Send email、Post Teams message。新版要 6 個 case，改一個 bug 要改 6 次。

第二版：Dictionary Lookup

然後我丟了我老公 John Liu 的一篇 blog 給 agent 看, split twice pattern，用 config 取代 Switch 的寫法。

Agent 看完之後建議用 dictionary lookup。做法是：

1. 一個 Compose action 放 JSON config，6 種文件類型當 key，value 放 library ID、Teams channel ID、mailing list 欄位名稱
2. 後面所有 action 都用 outputs('Compose_Config')?[triggerBody()?['Type/Value']] 去查表
3. 兩個 Switch 砍掉

80 幾個 action 變 17 個。

左邊是 Compose Config 的 JSON, 6 種文件類型當 key，每個 key 放對應的 library ID、channel ID、mailing list 欄位。右邊是乾淨的 Apply to Each，一組共用的 action 處理所有文件類型。加新的類型只要在 config 加一筆。

Deploy 之後才是真正踩坑的開始

新版 deploy 上去之後跑了第一次, 壞了。

SharePoint connector 有些限制是文件上寫不清楚的、path 格式跟你想的不一樣、JSON 字串組出來多了一個 single quote 就壞掉、欄位更新邏輯沒寫好會互相蓋掉。

每次都是這個 loop：

agent → update_live_flow（deploy 修改）
agent → trigger_live_flow（跑一次）
agent → get_live_flow_runs（看 run history）
agent → get_live_flow_run_error（找到哪個 action 壞掉）
agent → get_live_flow_run_action_outputs（看 input/output 確認問題）
→ 改 code → 再 deploy

來回了大概 7 次。中間還 cancel 了 11 個壞掉的 run。

重點是這 7 次我都沒有打開 Power Automate designer。

全部都是 agent 自己 deploy、自己跑、自己看錯在哪裡、自己改。我只是在旁邊看它跑，偶爾提示一下方向（像是丟 John 的 blog 給它看）。

為什麼 MCP 是關鍵

如果 agent 沒有 MCP，它還是可以 deploy flow。但 flow 壞掉的時候，它看不到 run history 裡面的 error detail 跟 action input/output。你就要自己去 Power Automate designer 看錯在哪，然後把 error message 跟 input/output 貼回去給 agent。

有了 MCP，agent 可以直接：

• 讀現有的 flow（get_live_flow）
• Deploy 修改（update_live_flow）
• Trigger 測試（trigger_live_flow）
• 看 run history 跟 action-level 的 error（get_live_flow_runs、get_live_flow_run_error）
• 看每個 action 的 input/output（get_live_flow_run_action_outputs）

差別就是 agent 能不能自己跑完 deploy → test → debug 的 loop。能跑的話，一個下午搞定。不能的話，你就是那個 loop 裡面的人肉 middleware。

想試試看的話：Flow Studio MCP 免費方案有 100 次 API call，不綁信用卡。

可用 VS Copilot, Claude 跟各種 MCP-compatible agent.

John 的 split twice pattern 原文：johnliu.net

Catherine Han, Flow Studio