很多人聽到「AI Agent」會覺得很玄，好像是什麼高深的自動化系統，需要很厲害的工程能力才能搞懂。
但其實 Agent 的本質非常簡單。
這篇文章會從 Anthropic 官方的定義出發，帶你理解 AI Agent 到底是什麼，以及它跟一般的 AI 對話有什麼不同。
Anthropic 對 AI Agent 的定義：augmented LLM
要理解 Agent 是什麼，最好的起點是 Anthropic 在 2024 年底發表的一篇文章：《Building Effective Agents》。
這篇文章可能是目前業界討論 AI Agent 時被引用最多的一篇。
Anthropic 在文中提出了一個核心概念叫做「augmented LLM」，翻成白話就是「被強化過的大型語言模型」。
原文是這樣寫的：
The basic building block of agentic systems is an LLM enhanced with augmentations such as retrieval, tools, and memory.
翻譯過來的意思是：Agent 系統的基本組成單元，就是一個被加上三種能力的 LLM。
這三種能力分別是：
檢索（Retrieval）：讓模型能夠去「找資料」
想像你問一個 AI：「我們公司上一季的營收是多少？」
如果這個 AI 沒有檢索能力，它只能靠訓練時學到的知識來回答。
但它的訓練資料裡根本不會有你公司的內部數據，所以它只能瞎猜，或是很誠實地說「我不知道」。
有了檢索能力之後，它可以先去你公司的資料庫查一下，找到上一季的財報，再根據查到的數字來回答你。
這就是檢索的價值：讓模型不再只靠「記憶」回答問題，而是能夠即時去「查」。
常見的檢索方式包括：搜尋網頁取得最新資訊、查詢公司內部的文件資料庫、從一堆 PDF 裡面撈出相關段落。
也可以連到 Notion、Confluence 這類知識庫去找答案。
你可能聽過「RAG」這個詞，全名是 Retrieval-Augmented Generation（檢索增強生成），就是在講這件事：先檢索，再生成。
工具（Tools）：讓模型能夠「做事情」
檢索是「查資料」，工具則是「做動作」。
舉個例子：你跟 AI 說「幫我約明天下午三點跟 Kevin 開會」。
沒有工具的模型，頂多幫你「寫出一封邀請信」的文字，但它沒辦法真的幫你在 Google Calendar 上建立一個會議。
有了工具之後，它可以直接呼叫 Google Calendar 的 API，幫你把會議建好、發出邀請，整件事就完成了。
工具的範圍非常廣，幾乎什麼都可以變成工具：呼叫外部 API、執行一段程式碼、把資料寫進 Google Sheets、發送 Email、甚至操作瀏覽器幫你填表單。
重點是，模型不只是被動地「被叫去用工具」，而是會自己判斷「現在該不該用工具、該用哪一個」。
你跟它說「幫我查一下明天台北的天氣」，它會自己決定要呼叫天氣 API，而不是等你告訴它「請使用天氣工具」。
記憶（Memory）：讓模型能夠「記住東西」
你有沒有過這種經驗：跟 ChatGPT 聊了很久，結果開一個新對話，它就什麼都不記得了？
這就是「沒有記憶」的狀態。
每次對話都從零開始，你得重新交代一次背景、重新說明你的偏好、重新解釋你的專案狀況。
有了記憶能力之後，模型可以記住你之前說過的事情。
例如它知道你偏好用 TypeScript 而不是 JavaScript，知道你的專案用的是 Next.js，知道你上次請它寫的那個功能還沒完成。
記憶讓 Agent 從「每次都是陌生人」變成「一個了解你的長期助手」。
記憶的實作方式有很多種：有些是把重要資訊存進資料庫，下次對話時自動載入；有些是把對話摘要壓縮後保留；有些則是讓使用者自己設定「要記住什麼」。
augmented LLM 的三種能力如何對應到 AI Agent 的三個元素
這三種能力就是 Anthropic 定義的 Agent 基礎配備。
不過在實務上，我們可以用一個更直覺的方式來理解 Agent 的組成。
把視角拉遠一點看，你要打造一個 Agent，實際上要決定的就是三件事：
AI Agent 的第一個元素：模型（Model）— 大腦
模型就是你選擇用哪個 LLM 來驅動這個 Agent。
模型決定了這個 Agent 的「基礎智力」—— 它能理解多複雜的指令、能處理多長的上下文、能做出多精確的判斷。
AI Agent 常用的 LLM 模型：Claude、GPT、Gemini、開源模型
Claude（Anthropic）
在長文理解和寫程式方面表現很強。
如果你的 Agent 需要處理大量上下文，例如讀完一整份合約再回答問題，或是要在一個大型程式碼庫裡找出 bug 並修復，Claude 會是不錯的選擇。
目前很多開發者常用的 AI 程式編輯器，像是 Cursor 和 Windsurf，底層都是用 Claude 驅動的。
GPT（OpenAI）
速度快、生態系最大。
OpenAI 是最早推出 ChatGPT 的公司，所以它的第三方整合最多，社群資源也最豐富。
如果你的 Agent 需要串接很多現有的工具和外掛，GPT 系列的相容性通常最好。
Gemini（Google）
多模態能力最強。
Gemini 可以同時處理文字、圖片、影片和音訊，而且它的 context window 很大。
如果你的 Agent 需要看圖片回答問題、分析影片內容、或是處理混合多種媒體的任務，Gemini 會比較適合。
開源模型（Llama、DeepSeek、Qwen 等）
免費、可自己部署。
如果你的資料有隱私考量，不能傳到外部 API，或者你想要完全掌控模型的行為，開源模型讓你可以在自己的伺服器上跑，不需要依賴任何公司的服務。
選模型就像選員工：你要根據任務需求來挑。
同一個 Agent 可以動態切換模型（Routing）
模型不是選了就不能換。
很多 Agent 系統會根據任務的複雜度，動態切換不同的模型。
舉個實際的例子：假設你做了一個客服 Agent。
當使用者問「你們的營業時間是幾點？」這種簡單問題，其實不需要出動最強的模型。
用一個小型、便宜、反應快的模型（例如 Claude Haiku 或 GPT-4o mini）就能處理得很好，而且成本可能只有大模型的十分之一。
但如果使用者的問題很複雜呢？
例如「我上個月買的方案跟這個月的新方案差在哪裡？幫我算一下如果現在換約，剩餘的費用怎麼處理？」
這種問題需要理解多個條件、交叉比對、還要做計算。
這時候就需要切換到能力更強的大模型（例如 Claude Opus 或 GPT-5）來處理。
這個概念在 Anthropic 的文章裡叫做「Routing」（路由），就是先用一個分類器判斷問題的類型和複雜度，再決定要把它交給哪個模型處理。
這種做法的好處很實際：大部分的請求其實都是簡單問題，用小模型就能搞定。
只有少數真正複雜的問題才需要大模型出馬。
這樣算下來，整體的 API 費用可以大幅降低，同時不會犧牲困難問題的回答品質。
AI Agent 的第二個元素：指示（Prompt）— 任務說明書
你告訴這個 Agent 要做什麼、怎麼做、扮演什麼角色。
很多人以為 Prompt 就是你打進去的那一句話，例如「幫我寫一封 Email」。
但在實際的 Agent 設計中，Prompt 的範圍比你想像的大很多。
Agent 的 Prompt 組成：System Prompt、Tool Definitions、Tool Outputs
系統指示（System Prompt）
定義這個 Agent 的身份和行為規則。
這是你在 Agent 啟動之前就先設定好的「底層人格」。
使用者看不到這段內容，但它會影響 Agent 的每一次回答。
例如你可以寫：「你是一個專業的客服助理，回答時要用繁體中文，語氣要友善但專業，不確定的事情不要亂猜，遇到無法處理的問題要引導使用者聯繫真人客服。」
System Prompt 寫得越具體，Agent 的行為就越可預測。
你甚至可以在裡面規定它的回答格式、禁止它做某些事情、或是告訴它在特定情境下要用特定的語氣。
工具的使用說明（Tool Definitions）
告訴模型它手邊有哪些工具可以用、每個工具怎麼呼叫。
每個工具的定義會包含：名稱、功能描述、需要傳入的參數、以及回傳結果的格式。
舉個例子，如果你的 Agent 有一個「查詢訂單」的工具，它的定義可能是：名稱 get_order_status，需要傳入一個訂單編號。
呼叫之後會回傳訂單的狀態、金額和預計出貨日期。
模型看到這些定義之後，就知道「當使用者問訂單狀況的時候，我可以用這個工具去查」。
這些工具說明也是 Prompt 的一部分，模型就是靠讀它們來決定要不要用工具、用哪一個。
工具回傳的結果（Tool Outputs）
模型用了工具之後，工具回傳的資料也會被塞進 Prompt 裡面。
這是很多人沒想到的：Agent 的 Prompt 不是一開始就固定的，它會隨著對話過程不斷增長。
每次模型呼叫一個工具，工具回傳的結果就會變成 Prompt 的新內容。
模型會根據這些新資訊來決定下一步：是繼續用另一個工具、還是已經有足夠的資訊可以回答使用者了。
使用者的輸入（User Instructions）
也就是你實際打進去的問題或指令。
這是大部分人最熟悉的部分，但在整個 Prompt 的結構裡，它只是其中一塊。
使用者的輸入會跟前面三個部分合在一起，形成模型實際看到的完整內容。
這些全部加在一起，就是 Agent 收到的完整「任務說明書」。
換句話說，你以為你只打了一句「幫我查訂單」，但模型實際看到的可能是好幾千字的內容。
包含它的身份設定、所有可用工具的說明、之前的對話記錄、之前工具回傳的結果，最後才是你的那句話。
Prompt 品質決定 AI Agent 的表現：好壞對比實例
Prompt 的品質直接決定了 Agent 做事的品質。
同一個模型，給不同的 Prompt，表現可以天差地遠。
假設你要做一個幫使用者回覆 Email 的 Agent，好的 Prompt 跟壞的 Prompt 差在哪裡？
從表格可以看出來，差別就在於「有沒有把規則講清楚」。
壞的 Prompt 只給了一個模糊的身份，剩下全部讓模型自己猜。
好的 Prompt 把語言、語氣、長度、格式、例外處理全部定義好，模型就不用猜了。
一個寫得模糊的 Prompt 會讓 Agent 亂用工具、給出不相關的回答。
一個寫得精確的 Prompt，會讓 Agent 像一個訓練有素的員工，知道什麼時候該查資料、什麼時候該直接回答、什麼時候該問你確認。
AI Agent 的第三個元素：工具（Tools）— 雙手
你允許這個 Agent 使用哪些外部能力。
前面在講「檢索」和「工具」的時候已經提過一些例子，這裡要從更高的視角來看：工具就是讓 Agent 從「只會說話」變成「能動手做事」的關鍵。
AI Agent 常用的四類工具：搜尋、執行、程式碼、瀏覽器
工具的種類非常多，大致可以分成幾類：
搜尋與檢索類
讓 Agent 能夠找資料。
例如搜尋網頁、查詢公司內部的知識庫、從向量資料庫裡找出相關文件。
前面提到的「檢索（Retrieval）」能力，實際上就是透過這類工具來實現的。
常見的搜尋工具包括：Tavily（專門為 AI Agent 設計的搜尋 API）、Brave Search API（有自己獨立的搜尋索引）、Exa（用語意搜尋而非關鍵字比對）、以及 Firecrawl（搜尋加上網頁內容擷取一次搞定）。
執行動作類
讓 Agent 能夠做事情。
例如發送 Email、在 Google Calendar 上建立會議、在 Jira 上建立一張 ticket、把資料寫進 Google Sheets、或是在 Slack 發一則訊息。
這類工具讓 Agent 不只是「告訴你該做什麼」，而是直接幫你做完。
程式碼執行類
讓 Agent 能夠寫程式並且跑起來。
例如執行 Python 腳本來分析資料、跑 SQL 查詢資料庫、或是在終端機裡執行 shell 指令。
Claude Code 就是一個典型的例子：它可以直接在你的電腦上讀寫檔案、執行指令、跑測試。
OpenAI 的 Code Interpreter 也是類似的概念，讓 ChatGPT 可以在沙盒環境裡執行 Python 程式碼。
瀏覽器操作類
讓 Agent 能夠操作網頁。
例如自動填寫表單、點按鈕、截圖、或是從網頁上抓取特定資訊。
常見的工具包括：Playwright（自動化瀏覽器框架）、Browserbase（為 AI Agent 設計的雲端瀏覽器）、以及 Stagehand（讓 Agent 用自然語言操作網頁，不需要寫 CSS 選擇器）。
Anthropic 的 Computer Use 功能也屬於這類，它讓 Claude 可以像人一樣操作電腦畫面。
不管是哪一類工具，有一個重點值得強調：現在的模型已經能夠主動判斷「現在該用哪個工具」。
你不需要跟它說「請使用搜尋工具」，你只要說「幫我查一下明天台北的天氣」，它就會自己決定要呼叫天氣工具。
工具串接 AI Agent 的兩種方式：Function Calling 和 MCP
知道工具有哪些之後，下一個問題是：要怎麼把這些工具接到 Agent 上面？
目前主要有兩種方式：
第一種：直接用 API 的 Function Calling 功能。
大部分的 LLM 平台（Claude、GPT、Gemini）都有提供 Function Calling（函式呼叫）的功能。
你在呼叫 API 的時候，把工具的定義用 JSON 格式傳進去，模型就知道它有哪些工具可以用。
當模型判斷需要用某個工具的時候，它會回傳一個結構化的工具呼叫請求，你的程式收到之後去執行對應的動作，再把結果傳回給模型。
這是最基本也最靈活的方式，適合你要完全掌控工具行為的情境。
第二種：用 MCP（Model Context Protocol）。
MCP 是 Anthropic 推出的開放協定，讓工具的串接變得更標準化。
它的概念是：與其每個工具都自己寫串接程式，不如定義一個統一的標準，讓任何服務都可以變成 LLM 的「工具」。
有了 MCP，你不用自己從頭寫每個工具的串接邏輯，而是可以直接用別人已經做好的 MCP Server。
例如已經有人做好了 Google Calendar、Slack、GitHub、Notion 的 MCP Server，你的 Agent 只要接上去就能用。
兩種方式沒有誰比較好，端看你的需求。
如果你需要串接的工具已經有現成的 MCP Server，直接接上去最快。
如果你的工具很客製化，或是你需要更精細地控制工具的行為，用 Function Calling 自己寫會更靈活。
Claude Code 本身就是一個 AI Agent
如果你覺得前面講的都太抽象，Claude Code 就是一個最好的實際例子。
Claude Code 是 Anthropic 推出的命令列開發工具，讓你可以在終端機裡直接跟 Claude 協作寫程式。
但它不只是一個「聊天視窗」，它其實就是一個完整的 AI Agent。
用三元素拆解 Claude Code
模型：Claude Code 底層用的是 Anthropic 的 Claude 模型
你可以根據任務需求選擇不同的模型。
用 Sonnet 來處理日常的程式碼修改（速度快、成本低）。
用 Opus 來處理需要深度推理的複雜重構或架構設計（能力更強、但比較貴）。
這就是前面提到的「動態切換模型」在實際產品中的應用。
指示：透過 CLAUDE.md 設定 Claude Code 的行為規則
CLAUDE.md 就是 Claude Code 的 System Prompt。
你可以在裡面寫任何你希望它遵守的規則，例如：
「這個專案用 TypeScript，不要用 JavaScript。」
「測試框架用 Vitest。」
「commit message 一律用英文，格式是 conventional commits。」
「不要在沒有跑過測試的情況下提交程式碼。」
這些規則會影響 Claude Code 的每一次操作。
寫得越具體，它的行為就越符合你的預期。
你甚至可以為不同的專案寫不同的 CLAUDE.md，讓同一個 Claude Code 在不同專案裡有不同的「個性」。
工具：內建開發工具，還能透過 MCP 擴充
Claude Code 內建了多種開發者常用的工具。
它可以讀寫檔案、執行終端機指令、搜尋程式碼、查看目錄結構、跑測試、甚至直接用 git 做版本控制。
除了內建工具之外，你還可以透過 MCP 幫它接上更多外部工具。
例如接上 GitHub 的 MCP Server 讓它能直接建立 Pull Request、接上 Jira 讓它能讀取 ticket 的需求描述、接上 Slack 讓它能查看相關的討論訊息。
這些工具讓 Claude Code 不只是「幫你寫程式碼」，而是能夠理解整個開發流程的上下文。
Claude Code 實際修 bug 的流程
把三個元素組合起來之後，Claude Code 的行為就跟一個 Agent 完全一致。
當你跟它說「幫我修這個 bug」，它不會只是傻傻地等你告訴它該改哪個檔案。
它會自己去讀相關的程式碼、理解錯誤訊息、找出問題的根源、修改程式碼、然後跑測試確認修好了。
如果測試沒過，它會自己看測試失敗的原因，再試一次。
整個過程你只給了它一個目標，流程完全由它自己決定。
Subagent：讓 Agent 把任務交給另一個 Agent
當一個 Agent 要處理的任務太大或太複雜，它可以把部分工作「外包」給另一個獨立的 Agent。
這個被外包出去的 Agent 就叫做 Subagent（子代理）。
為什麼需要 Subagent？用實際例子說明
每個 Agent 都有 context window（上下文視窗）的大小限制。
Context window 就是 Agent 一次能處理的資訊總量，包含你給它的指示、對話記錄、工具回傳的結果，全部加在一起不能超過上限。
當任務太大，需要處理的檔案和資訊太多，一個 Agent 的 context window 就不夠用了。
舉個實際的例子：假設你跟 Claude Code 說「幫我把這個專案從 JavaScript 全部轉成 TypeScript」。
這個任務可能涉及幾十個檔案。
如果全部塞在同一個對話裡處理，每個檔案的內容、修改記錄、錯誤訊息都會累積在 context window 裡面，很快就會超過上限。
這時候 Claude Code 可以把任務拆成多個子任務。
例如：「把 src/utils 資料夾裡的檔案轉成 TypeScript」「把 src/components 裡的轉成 TypeScript」「把 src/pages 裡的轉成 TypeScript」。
每個子任務交給一個 Subagent 去處理。
每個 Subagent 有自己獨立的 context window，只需要專注在自己負責的那幾個檔案，不會被其他子任務的資訊干擾。
做完之後，Subagent 只把最終結果（例如「src/utils 的 12 個檔案全部轉好了，沒有型別錯誤」）回報給主 Agent。
主 Agent 再彙整所有 Subagent 的結果，確認整個專案的轉換是一致的。
Subagent 的好處有兩個：第一，不會佔用主 Agent 的 context window 空間；第二，多個 Subagent 可以平行處理，速度更快。
打造 AI Agent 的原則：先用最簡單的方式解決問題
看完前面的介紹，你可能已經躍躍欲試，想趕快做一個 Agent 出來。
但 Anthropic 在文章中反覆強調一個原則：先找最簡單的解法。
他們跟數十個團隊合作建構 Agent 之後發現，最成功的案例都不是用什麼複雜的框架或專門的套件，而是用簡單、可組合的模式來打造的。
他們甚至建議開發者直接用 LLM 的 API 就好，很多模式只需要幾行程式碼就能實現。
具體來說，你應該按這個順序來思考：
先試試看一個寫得好的 Prompt 能不能解決問題。
很多時候你以為需要一個 Agent，但其實調整 Prompt 的寫法、加上幾個範例，模型就能給出你要的結果。
如果單純的 Prompt 不夠，再加上工具和檢索，讓模型能查資料、能做事。
如果任務更複雜，需要多個步驟按照固定順序執行，再考慮用預定義的流程把它們串起來。
只有在真的需要動態決策、沒辦法事先規劃好路徑的時候，才讓它變成一個完整的 Agent。
這個原則不只是 Anthropic 的建議，也是很多實際開發團隊踩過坑之後的共識。
不要因為「Agent」這個詞很潮就急著用它，先確認簡單的方法真的不夠用再說。
AI Agent 重點整理
回到最開始的問題：AI Agent 到底是什麼？
三句話就能說完：
- 模型：選一個 LLM
- 指示：告訴它要做什麼
- 工具：讓它能動手做事
把這三樣東西組合起來，就是一個 Agent。
不需要神秘化它，也不需要害怕它。
理解了這個本質，你就能開始思考：我的工作中，有哪些事情可以交給 Agent 來做？