AI Agent 是什麼？和 Chatbot、Workflow 差在哪

AI Agent 是什麼？用「誰決定下一步」區分 chatbot、workflow 與 agent，拆解模型、工具、迴圈、記憶四個組成，並說明什麼情境會失敗、成本怎麼控制。

AI Agent 是什麼？一句話：能自己決定下一步要做什麼、並且真的去做的 AI 系統。

差別在最後那半句。ChatGPT 告訴你該怎麼改設定檔，是助理；一個 agent 會自己打開設定檔、改好、跑一次確認沒壞、然後回報結果——中間沒有人按下一步。它有工具可以用（讀寫檔案、呼叫 API、執行指令、上網查），有一個目標，然後在「觀察 → 決定 → 行動 → 看結果」的迴圈裡跑，直到目標達成或它判斷卡住了。

這篇把「AI Agent」這個被講到爛掉的詞拆開講清楚：它跟 chatbot 差在哪、實際怎麼運作、什麼情境值得用、什麼情境是反效果，以及你要自己做一個的話最短路徑是什麼。

Chatbot、Workflow、Agent 的分界

三個常被混用的東西，用「誰決定下一步」一刀就切開了：

這個分界很重要，因為大多數宣稱是 agent 的產品其實是 workflow，而且那通常是對的選擇。步驟固定、輸入可預期的事情，寫死比讓模型自己決定更快、更便宜、更好除錯。

真正需要 agent 的訊號只有一個：你事先不知道要幾步、也不知道是哪幾步。 修一個 bug 可能要看三個檔案，也可能要看三十個；你沒辦法把流程寫死。這時候讓模型自己決定路徑才划算。

一個 agent 實際上由什麼組成

拆開來只有四塊：

1. 模型（大腦） — 負責推理與決策。這是最容易換掉的一塊，也是成本主要來源。

2. 工具（手腳） — 模型能呼叫的函式：讀檔、寫檔、執行指令、查資料庫、打 API。工具的品質決定 agent 的上限：工具描述寫得含糊，模型就選錯工具；工具回傳的錯誤訊息含糊，模型就沒辦法自我修正。

3. 迴圈（節奏） — 模型輸出「我要呼叫工具 X」，系統執行、把結果餵回去、模型再決定下一步。反覆直到它輸出「做完了」。

4. 記憶與脈絡（工作檯） — 這一輪它看得到什麼。脈絡塞太滿會變笨、塞太少會失憶，這是實作上最花心思的一塊。

實際的請求長這樣（OpenAI 相容格式，多數框架底下都是這個形狀）：

from openai import OpenAI

client = OpenAI(
    api_key="sk-bl-你的金鑰",
    base_url="https://api.bazaarlink.ai/v1",
)

tools = [{
    "type": "function",
    "function": {
        "name": "read_file",
        "description": "讀取專案內一個檔案的完整內容",
        "parameters": {
            "type": "object",
            "properties": {"path": {"type": "string", "description": "相對於專案根目錄的路徑"}},
            "required": ["path"],
        },
    },
}]

resp = client.chat.completions.create(
    model="anthropic/claude-sonnet-4.6",
    messages=[{"role": "user", "content": "看一下 src/index.ts 在做什麼"}],
    tools=tools,
)
# resp.choices[0].message.tool_calls → 模型決定要呼叫 read_file

模型回的不是答案，是「請幫我執行 read_file(path="src/index.ts")」。你執行、把結果加回 messages、再呼叫一次——這就是迴圈。整個 agent 的核心大概就這麼多，剩下的都是工程。

現成的 agent 你其實已經在用

不必自己造。以編碼場景為例，成熟的終端機 agent 已經是日常工具：

• Claude Code — 開在專案目錄，自己讀結構、改多支檔案、跑測試。上手方式看 Claude Code 教學。
• Codex CLI — 同類工具，權限與沙箱設定特別細。看 Codex 教學。

其他常見型態：客服 agent（查訂單、改地址、開退款單）、研究 agent（多輪搜尋後產出報告）、維運 agent（讀 log、比對監控、給出處置建議）。

要自己組的話，Python 圈常用 LangChain / LlamaIndex / CrewAI，TypeScript 圈多半直接用 OpenAI SDK 加自己的迴圈——因為如前面所示，迴圈本身沒多少程式碼，框架的價值主要在記憶與工具管理。

什麼情境會失敗

比「能做什麼」更該先知道的事：

步驟固定的事。能寫死就寫死。讓模型每次重新決定一遍，你付的是額外的錢和額外的不確定性。

不能出錯的事。agent 會犯錯，這是常態不是 bug。所以危險動作一定要有人在迴圈裡：轉帳、寄信、刪資料、部署，一律停下來等核准。設計原則是唯讀與可還原的動作放行，會動到外部世界的不放行。

沒有回饋訊號的事。agent 靠「行動 → 看結果」自我修正。程式碼場景之所以特別成功，是因為有測試和編譯器當裁判。沒有裁判的任務（例如「寫一篇好文案」），它跑十輪也不會比第一輪好，只會比較久。

脈絡爆掉的長任務。跑久了脈絡塞滿舊資訊，品質反而下降。實務上要定期清理或壓縮脈絡。

成本：agent 比你想的貴

一次對話是一次呼叫；一個 agent 任務是幾十次呼叫，而且每次都帶著愈來愈長的脈絡。同樣一句話交給 agent，token 量可能是直接問的 20–50 倍。

三個實際有用的控制手段：

1. 分層用模型。 決策與規劃用強模型，摘要、分類、格式轉換這類雜活丟便宜的模型。這一步通常就砍掉大半成本。
2. 設上限。 最大迴圈次數、最大 token、單一任務預算，全部設好，避免它卡在一個解不開的問題上燒錢。
3. 善用快取。 系統提示與工具定義每輪都重送，會命中提示快取的服務可以省下可觀的重複費用。

想動手試的最短路徑

不要從框架開始，從一個工具開始：

1. 拿一把 OpenAI 相容的 API 金鑰。
2. 寫一個只有一個工具的迴圈（上面那段程式碼就是骨架）。
3. 給它一個真實但小的任務，例如「讀這個資料夾，告訴我哪些檔案沒有被 import」。
4. 看它每一步在想什麼，把每一輪的 messages 印出來。這一步是理解 agent 最快的方法，看一次勝過讀十篇文章。
5. 卡住的地方通常不是模型笨，是工具描述寫得不夠清楚。改描述，不要改模型。

金鑰可以到 bazaarlink.ai/free 開一把，免費層足夠把整個迴圈跑通；BazaarLink 是 OpenAI 相容的中繼站，同一段程式碼換個 model 字串就能比較不同模型在你這個任務上的表現與成本，可用清單見 模型列表。

小結

AI Agent 不是更聰明的 chatbot，是多了工具、多了迴圈、少了每一步的人。這三件事帶來能力，也帶來風險與成本。

判斷要不要用 agent，回到那個唯一的問題：你事先知不知道要做哪幾步？ 知道，就寫成 workflow；不知道，才輪到 agent。想直接感受它能做到什麼程度，從一個現成的編碼 agent 開始，比自己造快得多。

台幣計費・統一發票・主流 AI 模型・OpenAI 相容 API