現在什麼工具都自稱 AI Agent，但你手上那件事，可能根本不需要 Agent。Anthropic 官方對 Agent 和 Workflow 的定義只有各一句話，我把它接上自己平常在用的 3 層判斷法：先看你的流程會不會變，答案就出來了。
AI Agent 是什麼？Anthropic 官方的定義只有一句話
這個定義不是誰在社群上自己講的，是 Anthropic 在 2024 年 12 月 19 日的工程部落格〈Building effective agents〉裡寫的。他們把「agentic system」拆成兩種架構，各給一句話。
Workflow 是：「systems where LLMs and tools are orchestrated through predefined code paths.」——LLM 和工具，是照著預先寫好的程式路徑被調度的。
Agent 是：「systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.」——LLM 自己動態指揮流程和工具怎麼用，自己掌握要怎麼完成任務。
兩句話擺在一起，分界線其實很清楚：路線是你先畫好的，還是它自己邊做邊決定的。
官方也畫了一張最基礎的架構圖，把「加強版 LLM」長什麼樣講清楚：一個 LLM，外面接上檢索（Retrieval）、工具（Tools）、記憶（Memory）。不管你最後做成 Workflow 還是 Agent，底層都是這塊積木。
Workflow 意思是什麼？差別在「誰決定下一步」
很多人把 Workflow 想成「比較低階的版本」，其實不是。Workflow 是一種選擇，而且在很多場合是更好的選擇。
官方的說法是：「workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale.」翻成人話——任務定義得清楚時，Workflow 給你的是可預期、每次結果都一致；要彈性、要模型自己做決定而且量很大時，才輪到 Agent。
官方在那篇文章裡也整理了幾種常見的 Workflow 模式：prompt chaining（一步接一步）、routing（先分類再分流）、parallelization（同時跑多路）、orchestrator-workers（一個指揮多個執行）、evaluator-optimizer（一個生、一個評，來回修到過）。
看到 evaluator-optimizer 那張圖你會發現，它一樣有迴圈、一樣會重跑，但每一步該做什麼是寫死的。會繞圈不等於是 Agent，這是最多人搞混的地方。
3 層判斷法：你的流程會不會變？
官方給的是定義，實際要決定「這件事該用哪一種」，我自己是分三層看。判準只有一個問題：這件事的流程會不會變、需不需要中途做選擇。
第 1 層：完全固定的流程，不用判斷
如果這件事完全不會變，每次步驟一模一樣——固定時間去某個網頁抓一份報表、下載、改檔名、丟進資料夾。這種其實用 RPA 就解決掉了，連 AI 都不用請。
這一層最容易踩的坑，是明明可以用最笨的方法解決，硬要接一個模型上去，結果變成又慢又貴、還多一個會出錯的環節。
第 2 層：固定流程，但需要一點微調判斷
比如說上網收集資訊、整理資訊，然後產出某種文件。步驟是固定的，但每次拿到的材料不一樣，需要模型做一點判斷。
這種現在用 AI Agent 很流行的 Cowork 模式就可以了。Gemini 有 Spark、ChatGPT 有 Cowork、Claude Code 也有 Cowork，本質上是同一件事。重複性高、又可以排程的工作，大部分都落在這一層。
第 3 層：隨機性高、需要高度判斷
任務隨機性比較高，但你可以給它目標、可偵測的範圍和辨別依據——這時候才需要交給 Agent 去判斷。
最好懂的例子是客服系統。它必須先判斷詢問者的意圖：如果是要預約時間，這跟排程有關，可能要串接資料庫；如果只是問服務項目或規格，就去讀知識庫撈內容再回答。「先判斷對方在問什麼」這一步沒辦法寫死，所以它是 Agent。
自動化流程用 AI 還是 RPA？一張表對照
| 層級 | 流程特性 | 用什麼 | 例子 |
|---|---|---|---|
| 第 1 層 | 完全固定，不用判斷 | RPA | 固定抓報表、改檔名、歸檔 |
| 第 2 層 | 流程固定，材料會變 | Workflow／Cowork 模式 | 收資料、整理、產出文件 |
| 第 3 層 | 隨機性高，中途要選路 | Agent | 客服先判斷意圖再分流 |
要記的其實只有一句：先問「這件事的下一步是誰決定的」。你決定的，寫成 Workflow；它決定的，才叫 Agent。
我自己怎麼分：每天在跑的社群 loop 是 workflow，不是 agent
我自己每天在跑一條社群內容的自動化流程：固定時段選題、寫稿、配圖、發布、發完回報。這條線我從 6 月就在調，之前寫過的〈停止一條一條餵指令：我用 Loop Engineering 讓 AI 自己經營 Threads〉講的就是這套。
它看起來很像 Agent——會自己上網找題目、自己寫、自己發，中間我完全沒碰。但照上面的定義拆開看，它其實是一條 workflow：什麼時候跑、跑哪幾步、每一步用哪支腳本，全部是我先寫好的。模型負責的是每一步「內容怎麼寫」，不是「下一步要做什麼」。
分清楚這件事對我很有幫助，因為它直接決定我出問題時去哪裡找。發文格式跑掉，那是某一步的提示詞或腳本的問題，不是「AI 不夠聰明」；真正要模型自己判斷的地方（例如今天這題跟前 30 篇有沒有撞），我才會寫成一段給它自己決策的邏輯，而且會給它一份明確的判斷依據。
再往前一步是「怎麼讓它記得規則」。這也是為什麼要有一份寫給模型看的說明書——我在〈教過 AI 的事它都忘？agents.md 是什麼〉那篇整理過做法：規則寫進檔案，它每次開工自己讀，而不是靠你每次重講一遍。
用同一套判準去看課堂上被問最多的那些需求，答案通常也很快：每個月做一份格式一樣的報表？第 1 層或第 2 層，別動用 Agent。要一個能接各種奇怪問題的客服？那才是第 3 層。
開 Agent 之前，先想這 3 件事
第一，它會用時間和錢換表現。官方講得很直白：「Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense.」——這個交換划不划算，是你要判斷的。
第二，要給它看得出對錯的目標。Agent 之所以能自己決定下一步，前提是它有辦法知道自己做得對不對。沒有可偵測的範圍、沒有判斷依據，它只會一直繞。
第三，從最簡單的做法開始。這句是官方原話：「we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all.」最簡單的解法，需要時才加複雜度——有時候答案是根本不用做成 agentic 系統。
掌握這幾個大方向，基本上就能清楚辨別跟理解了。下次看到某個工具說自己是 AI Agent，你可以先問一句：這件事的下一步，到底是誰決定的？
延伸閱讀
本文整理改寫自 Anthropic 官方工程部落格〈Building effective agents〉（2024-12-19），定義與引述皆出自該文；3 層判斷法為作者自己的實務分法。
留言
張貼留言