update · TowCue 編輯團隊
Zapier 正把 Agents 併入 AI by Zapier：AI Agent 與確定性自動化正在合流
Zapier 正將獨立 Agents 遷移進 Zap 編輯器中的 AI by Zapier。本文解析工具呼叫、逐工具審批、可觀測性、Task 成本，以及更可靠的混合式 AI 自動化架構。
快速解答
Zapier 在 2026 年 9 月 7 日更新了正式遷移文件，方向已經很明確：原本獨立運作的 Zapier Agents 正被整合進一般 Zap 編輯器裡的 AI by Zapier。
真正重要的不是產品名稱換了，而是架構變了。過去 Agent 的推理與工具呼叫主要待在 agents.zapier.com 的獨立環境；現在 Zapier 希望把 AI 推理、工具呼叫、傳統 Zap 動作、Filter、Paths、審批與執行歷史放進同一條工作流。
遷移後，一個 Agent 會變成一個 Zap：前面是原生 Trigger，後面是一個 AI by Zapier step，裡面保留原本的提示詞、指令、工具與 Agent 推理。之後團隊可以再選擇把某些工具動作抽離成獨立、確定性的 Zap step，以取得更細的控制。
這也是 TowCue 認為這次更新值得關注的原因：真正能進入生產環境的 AI 自動化，往往既不是完全自主，也不是完全硬編碼，而是把兩者組合起來。
若想建立更安全的 Agent 流程，可以搭配 TowCue 的 AI Agent 最佳實務指南、工作場景 AI 工具選擇指南，以及 ChatGPT 與 Claude 比較 一起閱讀。
Zapier 實際改了什麼
Zapier 說明，過去 Agents 是獨立產品，因此無法完整結合一般 Zap 已有的 Trigger、Action、Filter、Paths、分支邏輯與 automation history。AI by Zapier 的目的，就是把這兩套系統重新合在一起。
遷移完成後，Zapier 會建立：
- 一個原生 Zap Trigger，例如排程或 webhook
- 一個 AI by Zapier step，保留 Agent 原本的 prompt 與 instructions
- 原本連接的 tools 與所有工具呼叫
- 原本 Agent 的推理行為
有一個容易被忽略但很重要的細節：遷移不會自動把每一次工具呼叫拆成原生 Zap Action。
剛遷移完成時，整個 Agent 仍然包在一個 AI step 裡，行為盡量接近舊版。之後如果某一個動作需要更精準、更透明或更可控，使用者才手動把它移成獨立的 Zap step。
這讓工作流設計多了一個很實用的選擇：模糊判斷留給 AI，規則清楚的動作交給傳統自動化。
為什麼這比「所有步驟都 Agent 化」更適合正式工作流
很多 AI Agent Demo 的假設是：既然模型會推理，那就讓它決定整條流程。
原型階段這很方便，但正式業務未必如此。
例如一條客服自動化中，AI 很適合負責：
- 理解客戶真正想問什麼
- 判斷案件緊急程度
- 選擇需要參考的知識
- 草擬一段回覆
但下面這些工作，用確定性 Zap step 往往更合理：
- 把固定欄位寫入 CRM
- 把案件送進明確的 Queue
- 比對一個精確 Status 值
- 只有在 approval flag 為 true 時才發送訊息
兩者放在同一條 Zap 裡，意味著「需要理解的地方」用 AI，「規則已經知道的地方」用傳統 automation。
TowCue 的核心判斷是：讓 AI 解讀語意與意圖；可以明確寫成規則的限制，盡量交給確定性步驟。
逐工具審批是一個很實用的安全邊界
AI by Zapier 可以針對單一工具開啟「執行前要求批准」。Zapier 官方也建議，可以讓低風險的讀取操作自動執行，而對較敏感的寫入操作加入人工審批。
這比只有一個全域的「Agent 開 / 關」更符合真實風險。
讀取 CRM 與刪除 CRM 資料都是 tool call，但兩者顯然不應擁有相同程度的自治權限。草擬 Email 與真正把 Email 發出去也一樣。
比較穩健的生產配置可以是：
- 讀取型工具先允許無審批執行
- 外部溝通與破壞性寫入要求人工批准
- 高頻且規則固定的動作移成原生 Zap step
- AI step 專注在真正需要語意判斷的地方
Zapier 也提供組織層級控制，管理員可以停用 tool calling 或 agentic behavior，並限制可選模型。
可觀測性正在變成 Agent 產品的一部分
Agent 被搬進 Zap 的另一個好處，是 agentic run 可以直接出現在 Zap history 裡。
Zapier 表示，使用者可以查看：
- 呼叫了哪些 tools
- 傳入哪些資料
- 使用哪一個 model tier
- 這次 run 消耗多少 tasks
這點很重要，因為很多 Agent 系統出問題時，最難的不是「知道它錯了」，而是找不到它在哪一步錯。
正式運行的自動化至少應該回答：
- 模型到底呼叫了哪一個工具？
- 工具收到什麼資料？
- 當時跑的是哪一個模型？
- Loop 到底消耗了多少 tasks？
- 是工具失敗，還是模型做錯決定？
把這些資訊放回既有的 Zap history，代表 Zapier 正試圖把 Agent 從聊天式黑盒子轉成可營運、可追蹤的自動化元件。
遷移前一定要先看 Task 成本
AI by Zapier 採用 task-based billing，而且模型等級會直接改變 Task multiplier。
Zapier 目前公布的內建等級為：
| Model tier | Task 倍率 | Tool support |
|---|---|---|
| Standard | 1x | 不支援 |
| Advanced | 3x | 支援 |
| Premium | 5x | 支援 |
Zapier 官方文件目前還指出，付費方案新建立的 AI by Zapier step 預設會使用 Premium。
其 Task 計算公式為：
每次 run 使用的 Tasks = (1 × model rate) + (tool calls × model rate)
也就是說，一次 Premium AI step 如果呼叫 2 個工具，就會使用 15 Tasks：AI step 本身 5 Tasks，加上兩次工具呼叫共 10 Tasks。
另外，如果單次 AI by Zapier run 達到 75 Tasks，系統會暫停並要求人工確認後才繼續。這是一個防止長 Loop 或重複工具呼叫造成失控成本的重要機制。
但 TowCue 仍建議用「每個完成工作流的總成本」來評估，而不是只看模型方案名稱。Agent 一旦需要反覆呼叫很多工具，Task 消耗可能比固定步驟的普通 Zap 高得多。
舊版 Agents 使用者會遇到哪些差異
Zapier 表示大多數 Agent 可以自動轉換，不需要從零重建。Prompt、instructions、tools 與 agent reasoning 都會保留下來。
不過幾種場景需要另外處理。
如果 Agent 會呼叫其他 Agent，Zapier 建議在新架構中改用 Sub-Zap。如果原本是透過聊天即時觸發的 On-demand Agent，目前 Zap 編輯器還沒有完全對等的 Trigger；官方建議可用 webhook 從 Slack、Web App 或自訂聊天介面啟動。
另外，目前仍有兩項不完整：
- 組織層級的 Bring Your Own Model 設定仍規劃於未來版本
- 部分原 Agents Knowledge Sources 還沒有進入 AI by Zapier
因此這次遷移不應被視為單純的格式轉換，而應做一次完整的 regression test。
TowCue 建議的低風險遷移流程
不要把正式 Agent 一鍵遷移後，馬上關掉舊版本。
更穩健的方式是：
- 先讓 Zapier 自動建立遷移版本
- 檢查 Prompt、Instructions 與所有連接工具
- 用具代表性的 Sample Data 測試 AI step
- 查看它實際呼叫哪些 Tools，以及用了多少 Tasks
- 執行完整 Zap end-to-end test
- 對外部訊息與敏感寫入加入 approval
- 將規則固定的動作拆成原生 Zap step
- 比較新舊版本的結果品質與 Task 消耗
- 確認穩定後再關閉原本 Agent
Zapier 特別提醒，如果新 Zap 與舊 Agent 同時保持 Published，兩邊可能同時執行，造成重複動作。
誰應該關注這次更新
現有 Zapier Agents 使用者
如果你的 Agent 會互相呼叫、依賴 Knowledge Sources，或主要由 Chat 觸發，應該優先檢查新架構是否完全覆蓋目前需求。
Operations 與自動化團隊
即使過去沒有用 Agents，這次整合也值得研究。它提供一個更清楚的方法，把不確定的 AI reasoning 與確定性的業務流程放進同一套運行系統。
重視 AI Governance 的團隊
逐工具批准、管理員模型控制、發布審批與完整 run history，都比一個獨立的「自主 Agent 聊天介面」更接近正式企業治理需求。
成本敏感的團隊
不要把 AI step 當成普通 Zap Action 計算。Model tier 與 Tool calls 都可能乘上更高的 Task rate，長鏈路 Agent 尤其需要先做成本測試。
TowCue 觀點
Zapier 這次整合其實透露了一個比產品本身更大的方向。
第一波 Agent 產品都在證明：「模型可以自己決定很多步驟。」
下一階段真正有價值的問題則是：
到底哪些地方應該讓模型決定，哪些地方必須把規則寫死？
AI by Zapier 進入核心 Zap editor 後，這條邊界更容易被設計。分類、理解與規劃可以留在 Agentic step；權限、不可逆操作、固定路由與已知 business rules 則可以拆成 deterministic steps。
這種混合模式不像「Fully Autonomous Agent」那麼吸睛，但更可能是 AI 自動化真正大規模進入生產環境的樣子。
研究來源
- Zapier — Migrating from Agents to AI by Zapier（2026/09/07 更新）
- Zapier — AI by Zapier model tier pricing（2026/08/20 更新）
- Zapier — How task usage is measured（2026/08/21 更新）
- Zapier — View and manage your Zap history