31 支程式在用 AI,只有 3 支算 AI agent

實驗 2026-09-06 · Satsuma Creative · 閱讀 8 分鐘

「AI agent」這個詞被用到失去資訊量。我把自己機器上 31 支會呼叫 AI 的程式一支一支對判準,只有 3 支算 agent——而且那 3 支全是內部用的,對外賣的客服一支都不是,還是刻意的。這篇給三條可操作的判準、一個 30 秒的測試、以及為什麼「客服不該做成 agent」。

現在什麼都叫 agent。網站掛個聊天框叫 agent,寫個排程呼叫 API 也叫 agent,把兩段 prompt 串起來更是 agent。這個詞被用到失去資訊量——聽到有人說「我們有 AI agent」,你其實不知道他做了什麼。

上週我把自己機器上所有會呼叫 AI 的程式列出來,一支一支對判準。31 支程式,只有 3 支算 agent。

而且更值得講的是:那 3 支全部是內部自己用的。對外賣的客服,一支都不是——而且是刻意的。

三條判準

一個系統要叫 agent(代理),三個條件缺一不可:

1. 你給的是目標,不是步驟。「把這個壞掉的地方修好」是目標。「第一步讀這個檔、第二步比對、第三步輸出」是步驟。給步驟的東西,AI 只是其中一格的填空題。

2. 它能真的動手。 它有工具——可以讀檔案、改檔案、執行指令、打 API。沒有工具的 AI 只能講話,講完就沒了。

3. 它自己決定下一步。 跑在迴圈裡:做一件事、看結果、再決定下一件。不是你的程式排好順序讓它照走。

三條都成立才是 agent。沒有工具、只會講話的,那是聊天機器人。流程由你的程式寫死、AI 只負責某一格的,業界叫 workflow(工作流)

這不是貶義。 多數情況 workflow 才是對的選擇,後面會講為什麼。

一個 30 秒的測試

判斷一個系統是不是 agent,最快的方法是問:

把它的工具全部拿掉,它還能做原本九成的事嗎?

能 → 不是 agent,工具只是裝飾。 不能 → 是。

我們所有的客服都通過「拿掉工具還能跑」這一關——因為它們本來就沒有工具。啟動參數寫的是「工具清單:空」,一個都不給。

對號入座

算 agent 的三支

① 夜間自動修復。 我們自己的 LINE 訂餐服務,每天半夜跑一次:先看五個健康訊號,全部是零就收工不動刀;有訊號就把目標和邊界交給 AI,讓它自己去驗屍、找原因、改程式、部署。沒有人監督,我在睡覺。

② 多代理系統。 每個成員是一個常駐的 AI 程序,有自己的記憶,彼此能交辦工作。它動手之前會被攔下來問我 Allow 還是 Deny。(做這個的過程寫在我開了 AI 幕府

③ 手機遙控。 用通訊軟體下指令,AI 在我的電腦上讀檔案、查狀態、回報結果。預設唯讀,要動手得先過一次動態密碼。

不算的(其餘 28 支)

我們對外交付的每一支 AI 客服——不管是餐飲、預約還是知識庫問答——都是同一個形狀:

客人的問題
  → 我們的程式做檢索(RAG:把最相關的幾段資料撈出來)
  → 呼叫 AI 一次
  → 一段回答(有時附一個「轉真人」或「建預約」的標籤)
  → 我們的程式決定接下來做什麼

AI 在這裡做兩件事:讀懂問題、寫出人話。決定「接下來做什麼」的是我們的程式,不是 AI。 那就是 workflow。

還有一批更單純的:翻譯、貼文排版、線索判讀——固定管線,AI 當一格分類器。這些連 workflow 都算勉強,本質就是「呼叫 API」。

為什麼客服刻意不做成 agent

這是這篇最想講的一段。

因為 agent 的優點,在客服場景全部變成缺點。

agent 客服要的
下一步 AI 自己決定 每次都一樣
出錯 可能連鎖 只錯一句話
稽核 要看整段軌跡 一問一答,攤開就看得懂
動到資料 有工具就能改 只能讀,不能改
成本 一題可能呼叫十幾次 一題一次

客人問「你們幾點關門」,你不需要一個會自己決定要不要翻資料庫、要不要打三個 API、要不要重試的東西。你需要一個每次都回同一句話的東西。

而且風險完全不對稱:客服的上限是「答得好」,下限是「亂承諾、亂改資料、亂寄信」。agent 讓上限高一點點,讓下限低很多。

我們上個月做過一次全面收緊:把系統裡二十幾處呼叫 AI 的地方,全部改成明確列出「只准用這些工具」的白名單,其中對外服務一律設成零工具。那次改動的本質,就是把 agent 性從客服身上拿掉

那什麼時候該用 agent

四個條件同時成立才值得:

  1. 任務講不清楚步驟——你自己也不知道要改哪裡,只知道「壞了」
  2. 結果值這個錢——agent 慢、貴,一次跑可能是單次呼叫的幾十倍
  3. AI 真的做得到——不是你希望它做得到
  4. 錯了收得回來——有測試、有審查、有回滾

第四條是分水嶺。收不回來的事,不要交給 agent。

護欄不靠權限擋,靠可逆性擋

夜巡跑的時候是跳過權限詢問的。這聽起來很瘋,但那是刻意的:一個半夜三點沒人在的自動化流程,如果設計成「動手前要問人」,它等於不會動。

風險改成用四道牙擋:

  1. 先重現才准修——問題重現不出來,不准動刀
  2. 部署鏈每一環都驗——不是「指令沒報錯」就算過
  3. 失敗自動回滾——退回上一個好的版本
  4. 連續兩次回滾就跳斷路器——停手,等人來看

差別在哪:權限審批擋的是「它做了什麼」,可逆性擋的是「它做錯了會怎樣」。 無人監督的場景只有後者有用——因為前者需要有人在。

所以「AI agent」這個詞值不值錢

值錢,但只在講對的時候值錢。

如果你在評估廠商,聽到「我們做 AI agent」,問一個問題就夠了:

「它有哪些工具?失敗的時候怎麼收回來?」

答得出具體工具清單和回滾機制的,是真的。答「它很聰明,會自己判斷」的,多半是把一次 API 呼叫包裝成 agent。

如果你要做的是 AI 客服——你要的大概不是 agent。 你要的是答案穩定、只會讀不會改、出錯只錯一句話的東西。那個東西比較無聊,但它是對的。

常見問題

RAG 聊天機器人算 AI agent 嗎? 不算。RAG 是「先檢索、再讓 AI 根據檢索到的資料回答」,檢索是程式做的,AI 只負責最後那段生成。決定下一步的不是 AI。

會呼叫工具就算 agent 嗎? 不一定。關鍵是「誰決定要不要呼叫、呼叫完之後做什麼」。如果是程式排好的順序,那是 workflow;如果是 AI 看完結果自己決定下一步,那才是 agent。

workflow 是不是比較低階? 不是。workflow 可預測、可稽核、便宜、出錯範圍小,多數商業場景要的就是這個。agent 是給「講不清楚步驟、而且錯了收得回來」的任務用的。

怎麼判斷廠商說的 agent 是真的? 問工具清單和回滾機制。真的 agent 一定講得出它能動什麼、以及做錯了怎麼退回去。

我的公司該從哪一種開始? 從 workflow。先讓 AI 在一個固定流程裡做好一格——分類、摘要、草稿——確認它穩定之後,再考慮要不要把決策權交出去。跳過這一步直接上 agent,通常是在為「我們也有 AI」這句話付錢。


延伸閱讀: