AgentKit 行銷自動化現在最重要的不是趕快做一個 agent，而是先避開錯誤路線。OpenAI 官方文件已標示 Agent Builder 與 Evals 有退場時程；台灣 SME 如果照舊版教學把行銷、客服、名單分級或報價流程全部綁在即將退場的原型工具上，後面會遇到重做、資料外洩、人工接手不清楚與成效無法驗證的風險。比較務實的做法，是把 Agent Builder 當原型參考，把正式流程規劃到 ChatKit、Agents SDK、既有 CRM 或內部工作流，並先做小範圍試點。
為什麼不能照舊版 AgentKit 教學一路做到底
AgentKit 原本的定位，是把 Agent Builder、ChatKit、Evals 等工具串起來，幫團隊設計、部署與優化 agent 工作流。OpenAI 的 AgentKit cookbook walkthrough 展示了從 Agent Builder 建 workflow、用 ChatKit 部署聊天介面、再用 Evals 進行 prompt optimization 與 trace grading 的模式。不過這份 cookbook 現在標示為 archived，適合拿來理解概念，不適合照抄成 2026 的正式導入計畫。
更關鍵的是，Agent Builder 官方文件目前直接標示 OpenAI is deprecating Agent Builder，既有使用者可在 transition window 繼續使用，產品預定在 2026-11-30 shut down。這代表台灣 SME 可以研究它的設計邏輯，但不應把長期行銷自動化押在只會存在到退場期限的工具上。
台灣 SME 先分三種路線
很多老闆聽到 agent workflow，會直接問「我們可不可以讓 AI 自動追名單、寫 LINE、改廣告、做報表？」真正該先問的是：這個流程現在是原型、內部助理，還是要對客戶產生實際承諾。三者風險完全不同。
| 路線 | 適合做什麼 | 不要誤會成什麼 | 下一步 |
|---|---|---|---|
| 原型試跑 | 整理名單分級、活動覆盤、素材檢查、報價前資料摘要 | 不是正式客服或自動成交系統 | 用少量資料建立任務範圍與失敗案例 |
| 內部工作流 | 讓行銷、客服、業務先用 AI 準備草稿與提醒 | 不是無人審核的自動發送 | 補上責任人、審核欄位、紀錄與人工接手 |
| 正式系統 | 接 CRM、預約、工單、報價、LINE 或網站聊天 | 不是照搬 archived cookbook 就上線 | 用 Agents SDK、既有系統權限與可回滾部署規劃 |
AgentKit 行銷自動化的 5 個檢查點
1. 任務要小到能驗收
第一版不要叫 AI「幫我做行銷」。比較好的任務是：把未成交名單分成三類、把 LINE 對話摘要成業務接手欄位、檢查廣告素材是否缺少證據、把活動結束資料整理成下週行動。任務越小，越容易判斷 AI 到底有沒有幫忙。
2. 資料邊界要先寫清楚
行銷 agent 常會碰到姓名、電話、Email、購買紀錄、LINE 對話、報價、付款狀態與客訴內容。台灣《個人資料保護法》要求個人資料利用要有合法範圍；若用於行銷，當事人表示拒絕接受行銷時也應停止利用。這表示 AI 工作流不能只寫 prompt，還要寫資料可用範圍、保存時間、去識別化方式與拒絕行銷處理。
3. 人工接手不能等出事才補
OpenAI 的 agent safety 文件提醒，agent workflow 可能遇到 prompt injection、data leakage 等風險。對 SME 來說，最實際的防線是先列出必須人工接手的情境：客戶抱怨、退款、價格承諾、合約、醫療金融法律問題、個資刪除、公開發文與大額折扣。這些不該讓 agent 自己判斷到底。
4. 評估方法要能離開舊 Evals 產品
OpenAI 的 Evals 文件目前也標示 Evals platform 將在 2026-10-31 對既有使用者變成 read-only，並預定 2026-11-30 shut down。這不代表 SME 不用評估，而是不要把 QA 制度只綁在退場產品。你可以先用試算表、抽樣人工審核、固定測試問題、錯誤分類與每週改稿紀錄建立最小評估法。
5. 遷移路線要在第一天寫進需求
如果流程未來要長期運作，需求文件就要寫清楚：哪些只是原型，哪些會移到 Agents SDK，哪些留在既有 CRM 或客服系統，哪些只做內部提示。Agents SDK 文件把 SDK 定位為用程式碼建立 agent app 的路徑；這比把整個營運流程停在視覺化原型工具裡，更適合需要版本控管、測試、權限和部署紀錄的團隊。
適用與不適用情境
這篇適合已經有固定詢問量、活動資料、客服紀錄、CRM 欄位或報價流程的台灣 SME。尤其是顧問服務、教育訓練、B2B 業務、在地服務、電商營運與需要多人協作的行銷團隊。
它不適合把 AI agent 當成「不用管理的員工」的團隊。如果你的資料來源混亂、客服話術沒有責任人、主管不願審稿、沒有權限控管，或希望 AI 直接自動承諾價格與交期，先不要做正式系統。先把 SOP 與資料欄位整理好，會比追最新工具更有效。
7 天試點流程
Day 1：選一個高頻但低風險任務
例如活動後名單摘要、素材檢查、FAQ 草稿、報價前需求整理。不要從退款、合約、付款、醫療金融或公開發文開始。
Day 2：準備 30 筆真實但去識別化樣本
保留問題型態、通路、時間、需求與最後結果，移除姓名、電話、地址、Email、訂單編號與可識別內容。
Day 3：寫輸入與輸出欄位
不要只寫「請分析」。輸出至少要有分類、判斷理由、信心程度、下一步建議、需人工確認欄位與不可自動處理原因。
Day 4：建立負面測試
把不該自動處理的案例放進測試集，例如客訴、要求刪除資料、價格爭議、過度承諾、政策例外與敏感資訊。
Day 5：安排人工審核與錯誤分類
每次輸出都讓負責人標記可用、需修改、不可用，以及錯誤類型。錯誤類型比單純分數更重要，因為它會告訴你要改資料、改指令、改流程，還是改人工接手規則。
Day 6：決定部署路線
如果只是內部草稿，可以留在工作流工具或文件流程。若要接系統、寫入資料或對客戶回覆，就應規劃正式權限、記錄、版本與可回滾部署。
Day 7：做 go 或 no-go 判斷
只有在錯誤可分類、人工接手清楚、資料來源穩定、使用者真的省時時，才進入下一版。否則先修 SOP，不要硬把 agent 推到前線。
資料更新與來源
本文於 2026-10-11 依 OpenAI 官方文件與台灣法規資料整理。AgentKit、Agent Builder、Evals、ChatKit、Agents SDK 的產品狀態可能變動；實作前應重新確認官方文件、OpenAI Platform 後台與你公司自己的資料治理要求。
- OpenAI Developers: AgentKit cookbook walkthrough
- OpenAI API docs: Agent Builder
- OpenAI API docs: Safety in building agents
- OpenAI API docs: Working with evals
- OpenAI API docs: Agents SDK
- 全國法規資料庫：個人資料保護法
結論
AgentKit 行銷自動化不是不能做，而是不能再照舊版教學一路做到正式系統。現在的正確順序是：先選小任務、控資料邊界、設人工接手、建立可攜帶的評估方式，再決定要不要走 Agents SDK、ChatKit 或內部工作流。
對台灣 SME 來說，最有價值的 agent 不是看起來很炫，而是能在不亂承諾、不亂用個資、不綁死退場工具的前提下，幫行銷、客服與業務少漏事、少重工、快一點做出可追蹤的下一步。
FAQ
AgentKit 行銷自動化現在還值得做嗎？
值得做小範圍試點，但不應把長期流程綁在即將退場的 Agent Builder 或 Evals 上。先選低風險任務，再規劃 Agents SDK、ChatKit 或既有系統的正式路線。
Agent Builder 退場會影響已經做好的流程嗎？
如果流程只停留在 Agent Builder，會有遷移壓力。官方文件顯示 Agent Builder 預定 2026-11-30 shut down，因此應盤點哪些流程要轉為程式碼、內部工作流或 Workspace Agents。
台灣 SME 第一個行銷 agent 應該做什麼？
建議從高頻但低風險任務開始，例如活動後名單摘要、素材檢查、FAQ 草稿、報價前需求整理。不要一開始就讓 agent 自動退款、報價、發折扣或公開發文。
沒有 Evals 產品後，還要怎麼評估 AI 行銷流程？
可以用固定測試集、人工抽樣審核、錯誤分類、信心欄位與每週改稿紀錄做最小評估。重點是讓評估方法可攜帶，不依賴單一即將退場的平台產品。
AgentKit 行銷自動化會碰到個資法問題嗎？
只要流程會使用姓名、電話、Email、LINE 對話、購買紀錄或行銷名單，就需要先確認蒐集、利用、保存、拒絕行銷與刪除處理方式，不能只靠 prompt 控制風險。