AI agent 流程自動化卡在哪？你公司花最多時間的流程，大部分都在「等」

你有沒有發現一件事。

你導入 AI 到現在，真正導得動的，好像都是那種「問了就有答案」的事。寫商品文案、整理客訴摘要、把一堆評論歸類、做一份週報。這些都很好，也都省時間。

但你公司裡最讓人抓狂的那幾條流程，AI 一條都沒接住。

退貨換貨審核、B2B 報價與合約審批、客訴升級、KOL 合作洽談、廣告素材送審、供應商比價。你去看這幾條，共同點不是難，是「久」。而且久的原因，通常不是誰在做事做很慢。

是大家都在等。

等消費者把商品寄回來、等倉庫驗貨、等主管按核准、等對方採購回信、等法務看完合約、等平台審核素材。切入重點，你公司真正花時間的流程，大部分時間根本沒有人在動作。

而現在市面上絕大多數的 AI 工具，預設任務要在一次對話裡結束。

這就是你導不動的原因。

先講清楚這份材料的來歷

本篇的起點是一支教學影片，裡面有一段把「長時間運行的代理」講得特別清楚。但要先做一個更正，不然後面全部都會歪掉。

這支影片是 Janice Ong SG | Tech • Business • Lifestyle 頻道 在 2026 年 8 月 1 日發布的。它是個人創作者做的教學合輯，不是 Google 的官方課程。 Janice Ong 是新加坡的講師與數位行銷顧問，我查不到她有 Google 員工或 Google Developer Expert 的身分。影片標題掛了 Google 的名字，又套了一個當紅技術名詞當包裝，但我查過 Google Cloud 與 Google Skills 的官方課程目錄，沒有同名的官方課程。

那哪一部分是真的 Google 的？

Google ADK（Agent Development Kit，代理開發套件）是真的，Google 開源的正式產品，官方站在 adk.dev。我查了 GitHub 上的 google/adk-python，最新版本是 2026 年 8 月 7 日的 v2.6.3，穩定版，不是 preview（預覽版）。

更關鍵的是，影片講長時間運行代理那一段，講者自己說了：「我們的同事 Shubham 跟 Eric 上週發了一篇 blog。」我把原文找出來了：Google Developers Blog 的 Build Long-running AI agents that pause, resume, and never lose context with ADK，作者 Shubham Saboo 與 Eric Dong，2026 年 5 月 12 日發布。

所以本文的第一手依據是那篇官方文章，影片只是我遇到它的路徑。另外，我拿到的影片摘要裡還出現了日文殘留字。摘要那一層不能當事實用，底下每個機制我都回去對過逐字稿跟官方原文。

你不會請一個員工站在門外等三天

先把名詞講完，後面都講生意。

長時間運行的代理（long-running agent），中文目前沒有統一講法，搜尋量也幾乎是零，所以你不用記這個詞，記住它在解決什麼問題就好。

Google 那篇文章的定義是：它跨越多次對話保存狀態，可以運作好幾小時、好幾天、甚至好幾週。用他們的話講，你的工作單位不再是一個 prompt（提示詞），而是一個 workflow（工作流程）。

要做到這件事，第一個條件聽起來很反直覺。

代理必須真的會睡覺。

Google 原文寫得很直白：「主動輪詢（active polling）浪費運算資源，卡住的執行緒也撐不起規模。代理必須真的睡著，然後只在外部事件進來時才醒過來。」

翻成生意話就是：你不會請一個員工站在會議室外面，連續三天，只為了等對方回覆。

但大多數人日常在用的那種對話式 AI 工具，只給你兩個選項：整條對話開著一直佔資源，或是關掉之後它什麼都不記得。沒有第三個。

長時間運行代理的做法是：沒事就休眠，不佔資源，也不空燒 token（模型計費單位），等外部訊號進來才被叫醒。訊號可以是 webhook（系統對系統的回呼通知）、排程時間到、主管按了核准，或某個工具跑完回報。

Google 那篇的示範是新人到職協調：寄出迎新資料包後代理就停住，等新人簽文件可能停好幾天，簽完才醒，接著再停住等筆電到貨，收到物流通知才繼續，最後發出第一天行程表。全程沒有輪詢迴圈，也沒有一條執行緒空轉。

有個細節值得講：他們的介面故意不做「樂觀更新」，不先假裝成功再回頭修正，一定要等後端真的接續完成才顯示。講者的說法是，這樣才能證明這個模式是真的，不是演出來的。會做這種設計的人，是知道大家看多了假 demo。

順帶說一句，「事件把 agent 叫醒」這一層，我之前寫過一篇 AI 正在從你去用的工具變成自己上工的同事，講的是觸發方式從聊天改成事件。那篇的單位是「一個事件，叫醒一個 agent 去做一件事」。

這篇不一樣。

這篇的單位是「同一個案子，被叫醒五次」。

而真正難的，從來不是第一次叫醒。

流程斷在第三天，你是續辦還是重辦？

這是整篇最重要的一段。

第二個條件叫檢查點（checkpoint）。Google 原文的說法是：每一次工具呼叫都會自動產生一個檢查點。如果容器在寄出迎新資料包之後立刻當掉，那個狀態早就已經寫進去了。

為什麼這件事這麼重要？

因為它決定了一件很現實的事：流程斷掉的時候，你是續辦，還是重辦。

想像一下，你早上打開電腦，看到一張退貨案。消費者上週三申請退貨，上傳了三張商品瑕疵照片，客服初判可以退，通知消費者寄回。週五貨到倉庫，倉管驗貨發現包裝配件少了一個，卡住。這中間你們系統升級重開了一次，處理這張單的同事也請假了。

今天是週一。這張單現在在哪裡？

如果你的答案是「要請人重新翻對話紀錄、重新問一次消費者、重新判一次」，那就是重辦。消費者要再講一次自己的問題，這就是客訴升級的起點。

如果系統知道「這張單已經走到驗貨異常，前面的照片、初判結論、通知紀錄都在」，那就是續辦。

這個差別，在你公司裡不是技術問題，是客訴率問題，也是退款天數問題。

Google 那篇文章有個技術細節翻成白話特別有用：狀態要存成資料庫裡的一個明確欄位，而不是把整串對話紀錄倒進去。原文提到，如果每次推論都要重播兩週的完整對話歷史，token 預算會燒得非常快。

翻成生意話：你要的是一張「這張單走到第幾關」的進度表，不是一整疊會議逐字稿。

這就像從「請大家翻一下 LINE 群組往上滑」，進化到「打開後台看單號狀態」。

以前你要靠承辦人的記憶，跟一條翻不完的對話串，才知道這件事辦到哪。現在你要的是一個機器讀得懂的狀態欄位，加上每次轉換都存檔。

如果你問我，這一條才是把 AI 從「聰明的助理」變成「接得住流程的同事」的分水嶺。因為助理可以健忘，同事不行。

兩件輕的事，但不能不提

第一件是記憶要分層。

跨天流程需要分層，是因為「這張單辦到哪」跟「這個客人一向要求開統編」是兩種完全不同的東西，不該塞在同一個地方。前者是進度，後者是偏好。混在一起，就是你 AI 客服越用越蠢的原因之一。原理我寫過，不重講：你的 AI 客服為什麼越用越蠢。代理怎麼串外部工具，可以看 MCP stateless 新規格解讀。

第二件是驗收不要自己驗自己，要交給獨立的角色，這條我寫過一整篇 你的 AI 需要一個天敵，不展開。

只補一個查證。影片講者說「包含 Anthropic 在內的多個實驗室研究相當一致地指出，代理評估自己的產出會持續高估」。這句是講者口頭轉述，Google 那篇官方文章裡沒有這個說法。我找到最接近的原始研究是 Panickssery、Bowman、Feng 的 LLM Evaluators Recognize and Favor Their Own Generations（NeurIPS 2024，作者含 Anthropic），但它的實際結論是「自我偏好偏誤」，模型給自己的產出打分比人類評分者高，跟「過度自信」不完全是同一件事。

差一個字，結論的強度就差很多，所以標出來。

那你現在該做什麼

我自己是從傳統產業出來的，雨傘產業待了七年，跑過工廠業務，站過百貨專櫃，後來才轉到數位行銷這一塊。這種「大部分時間在等」的流程，傳產跟零售現場真的到處都是，只是以前沒有人覺得那是可以自動化的東西，因為等本來就不能加速。

現在能處理的，不是把等變快，是讓等的過程不用有人顧著。

► 第一：先盤流程，不要先挑框架。 不要一開始就問「要用 ADK 還是 n8n」。先列出你公司所有跨天以上、而且中間卡在等別人的流程。退貨、報價、合約、客訴升級、合作洽談、素材送審、供應商比價，先各寫一行。

► 第二：把「等什麼」寫出來。 標出每條流程停在哪幾個點、等的是誰。等的對象決定你要接哪種訊號：等主管就接核准動作，等物流就接物流回拋，等對方回信就接信箱。

► 第三：先設狀態欄位，再談 AI。 讓每一張單在後台有一個明確的狀態欄位，每次轉換都留紀錄。這件事你完全不導 AI 也該做。做完你會發現，有些流程根本不需要 AI，只需要一個通知。

► 第四：一次對話做得完的，用現成工具就好。 寫文案、分類評論、做摘要，不需要長流程架構。不要為了用新技術把簡單的事複雜化。

► 第五：第一條先挑低風險、高頻率的。 不要拿 B2B 合約審批當第一個實驗對象，金額太大、法遵風險太高。挑退貨進度追蹤，或是素材的「內部初審」這種，做錯了頂多重跑一次。注意送到廣告平台的正式審核不算低風險，那牽涉到違規紀錄跟帳號品質。

如果你要開會用，直接照這張表填，一條流程一行：

填完你會很快看出來：那些「現在怎麼記進度」欄位寫著「某某人自己記」的流程，就是最容易斷、也最該先動的。

最後

這年頭大家都在問 AI 能不能取代誰。我覺得問錯了。

你公司裡那些拖三天、五天、兩週的流程，卡住的從來不是聰明程度，是沒有人有耐心一直盯著它，也沒有系統記得它辦到哪一關。

一次對話就能講完的事，AI 早就做得比你快了。

真正值錢的，是那些講不完、要等、要接力、會斷掉的事。

先去把你公司那幾條「大部分時間在等」的流程寫下來吧，寫完你大概就知道，該從哪一條開始了。

資料來源

• 影片來源：Google Graph Engineering Course: From AI Agents to Full Automation (Complete 2026 Guide)，創作者 Janice Ong（Janice Ong SG | Tech • Business • Lifestyle 頻道），2026 年 8 月 1 日發布。此為個人創作者製作的教學合輯，非 Google 官方課程。
• 長時間運行代理的第一手依據：Shubham Saboo、Eric Dong，Build Long-running AI agents that pause, resume, and never lose context with ADK，Google Developers Blog，2026 年 5 月 12 日。
• Google ADK 官方文件：adk.dev；原始碼與版本紀錄：google/adk-python。
• 自我評估偏誤研究：Arjun Panickssery、Samuel R. Bowman、Shi Feng，LLM Evaluators Recognize and Favor Their Own Generations，NeurIPS 2024。

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。