第 7 章 · AI Agent 核心：拆穿「代理」的神秘感

「AI Agent」是這兩年最紅、也最被過度神化的詞。這一章要把它拆開給你看：一個 agent，本質上只是「一個會用工具、會自己決定下一步的迴圈」。懂了第 4 章的工具呼叫，你其實已經懂了 agent 的一大半。

💡 這一章你會懂：agent 的四個要素、它運轉的「迴圈」長什麼樣、以及它為什麼會失控（無限迴圈、燒錢）。第 11 章你會親手把這個迴圈寫出來。

先講一個心態。很多人聽到「agent」腦中浮現的是電影裡那種有自我意識、會自己上網搞事的 AI。不是那樣。 你讀完這一章會發現，agent 樸素到有點反高潮——它就是把你前面學過的東西（模型會猜下一個字、會呼叫工具、有 context 當工作記憶）用一個迴圈串起來而已。神秘感是行銷加上去的，拆穿之後，你反而更知道怎麼用它、以及它什麼時候會出事。

什麼叫「Agent」？先跟 Workflow 對照

回顧第 5 章的關鍵區別：

• Workflow：路徑你事先定好（火車照鐵軌走）。
• Agent：路徑模型自己臨場決定（計程車司機選路）。

所以 agent 的靈魂是自主性——你只給它目標（「把這個 bug 修好」），它自己決定要先讀哪個檔、要不要跑測試、下一步做什麼。你沒有幫它畫流程圖。

這個對照值得再講深一點，因為它決定了你什麼時候該用哪個。用一個生活比喻：

• Workflow 像捷運：站與站之間的軌道是鋪死的，每天發車都走同一條路線。好處是準時、可預期、便宜——你永遠知道下一站是哪。壞處是不能臨機應變，前面塌方了它也只會撞上去（除非你事先鋪了一條分岔軌）。
• Agent 像計程車：你只說「帶我去松山機場」，司機自己看路況決定走高速還是市區、塞車了自己繞道。好處是會應變、能處理你事先想不到的狀況。壞處是貴、慢、而且他可能繞遠路甚至迷路（這就是後面要講的失敗模式）。

所以第 5 章那句金科玉律「先用 workflow，不夠再上 agent」的真正意思是：路線你能事先畫得出來的，就別讓它自己找路。你能畫出流程圖的任務（例如「收到發票 → 抽出金額 → 存進試算表 → 寄確認信」），用 workflow 又穩又省；只有當「下一步要做什麼」得看前一步的結果臨場判斷、而且分支多到你畫不完時（例如「修好這個沒看過的 bug」——你根本不知道 bug 在哪、要讀哪些檔），才輪到 agent 上場。

💡 一句話記住分界：workflow 是你排好路線讓它照走，agent 是你給它目標讓它自己找路。 找路的能力很強大，但每一步都要多花一次模型呼叫去「想」，所以也更慢更貴、更可能出錯。

Agent 的四個要素

一個東西要稱得上 agent，通常具備這四樣：

把這四樣組合起來運轉，就是下面這個迴圈。

在往下看之前，先用一個你熟悉的畫面把這四樣串起來——一個人第一次到陌生城市自助旅行：你有自主性（沒有導遊，行程自己拿主意）、你會用工具（Google 地圖查路、翻譯 App 點餐、悠遊卡搭車）、你會規劃（先想「上午博物館、下午老街、晚上夜市」，但下雨了就臨時改室內行程）、你有記憶（記得旅館在哪、記得早上已經去過哪、記得這家店踩過雷別再來）。agent 做的事一模一樣，只是把「你」換成模型。少了任何一樣它就不完整：沒自主性只是照表操課（那是 workflow）、沒工具只能空想不能動手、沒規劃會亂衝、沒記憶會一直忘記自己做到哪。

核心：Agentic Loop（代理迴圈）

Agent 的運轉就是一個不斷重複的循環——感知 → 推理 → 行動 → 觀察，直到任務完成：

flowchart LR
    P[感知<br/>目前狀態/上一步結果] --> R[推理<br/>決定下一步]
    R --> A{需要用<br/>工具嗎?}
    A -->|要| T[行動<br/>呼叫工具]
    T --> O[觀察<br/>拿到結果]
    O --> P
    A -->|不用，完成了| D((回覆使用者))

看懂這張圖，你就看懂了 Claude Code、Cursor、所有 coding agent 的本質。它做的就是：

1. 推理：看目前情況，想「下一步該做什麼」；
2. 行動：如果需要，就呼叫工具（第 4 章的 tool_use）；
3. 觀察：拿到工具結果，塞回 context；
4. 回到第 1 步，直到它判斷「做完了」才停。

💡 這就是 agent 的全部祕密——一個 while 迴圈套著工具呼叫。 第 11 章你會用大約 20 行程式碼把它寫出來，親眼驗證這件事。

為什麼「迴圈」這個設計這麼關鍵？

你可能會問：為什麼一定要「迴圈」？直接叫模型一次把整件事做完不行嗎？

不行，而且原因很根本，正好接回第 1 章：模型是「猜下一個字」的，它沒辦法在還沒看到結果前，就預知每一步會發生什麼。 你叫它修 bug，它不可能一口氣寫出「先讀 A 檔（會看到 X）→ 所以改 B 檔（測試會過）」——因為它還沒讀 A 檔，根本不知道裡面是 X 還是 Y。真實世界會給它意外：檔案內容跟它猜的不一樣、測試爆出新的錯、搜尋結果推翻了原本假設。

迴圈就是為了吸收這些意外而生的。每轉一圈，它就多看到一點真實世界的回饋（「觀察」），再根據新資訊修正下一步（「推理」）。這正是它比 workflow 強的地方：workflow 的每一步是你事先寫死的，遇到你沒預想到的狀況只能撞牆；agent 的每一步是臨場現想的，所以能處理開放式、你畫不出流程圖的任務。

換個角度看：這個迴圈，本質上就是把第 1 章的「猜下一個字」從『猜文字』升級成『猜下一個動作』。 模型原本是看著前文猜下一個 token，現在是看著「目前任務進行到哪」猜下一個該做的動作（讀檔？搜尋？改 code？還是收工？）。一樣是根據看過的東西算機率、挑一個最合理的往下走——只是這次挑的不是字，是行動。想通這點，agent 就一點都不神秘了。

💡 停下來的判斷也是模型做的。 迴圈不是無止境轉——每一圈模型都會問自己「任務完成了嗎？」，判斷「做完了」它就跳出迴圈、回覆你。這個「該不該收工」的決定同樣是模型猜出來的，所以它有時會太早收手（其實還沒做完就說完成了）或太晚（明明卡住了還一直轉），這是後面失敗模式的伏筆。

一個真實迴圈長什麼樣：coding agent 修 bug

光看圖太抽象，我們把一個 coding agent（像 Claude Code）修一個 bug 的迴圈，一圈一圈攤開給你看。假設你只丟給它一句話：「使用者說登入按鈕點了沒反應，修好它。」

看到重點了嗎？它沒有一開始就知道 bug 在第 42 行——那是它「搜尋 → 讀檔」之後才發現的。每一圈的行動，都建立在上一圈觀察到的新事實上。這就是迴圈的威力：它是邊做邊查、邊查邊調整，而不是照著一張你事先畫好的流程圖走。 你給的只有一句目標，中間那五步全是它自己長出來的。

🔧 動手試試：如果你手邊有 Claude Code、Cursor 這類 coding agent，丟一個小任務給它（例如「幫我在這個檔案加一個檢查空字串的功能」），然後別急著看結果，盯著它中間的動作：它讀了哪些檔、搜了什麼、跑了什麼指令。你會親眼看到上面這張表在你面前一圈一圈跑出來——這比看十張圖都有感。

兩個你會一直聽到的名詞

• ReAct（Reason + Act）：讓模型先講出它的推理，再採取行動，交錯進行。這幾乎是最經典的 agent 模式——上面那張迴圈圖就是 ReAct 的精神。
• Reflection（反思）：讓 agent 做完後回頭檢查自己的成果、發現問題再修。加了反思的 agent，品質通常更好（呼應第 5 章的 Evaluator–Optimizer）。

ReAct 為什麼要「邊想邊做」，而不是「想完再做」？

ReAct 這名字是 Reason（推理）+ Act（行動）兩個字拼起來的，核心主張是：每做一個動作前，先用文字把「我為什麼要做這個」講出來。 聽起來多此一舉，為什麼不省掉這段、直接做？

因為第 1 章教過的事在這裡發威了：模型是靠「把話講出來」來思考的。 還記得第 1 章結尾的推理模型嗎？它「先想再答」的祕密，不過是「在正式回答前先多生成一段推理文字」。ReAct 是同一招用在行動上——逼它在每次出手前先寫一句「我現在知道 X，所以下一步該做 Y」，等於強迫它把思路攤在檯面上，再根據這段思路挑動作。 這麼做有兩個實打實的好處：

1. 決策品質更好：跟人一樣，先想清楚「為什麼」再動手，比莽撞亂試更少犯錯。它把推理寫出來的過程，本身就在幫自己整理接下來該幹嘛。
2. 你看得懂它在幹嘛：那段「我為什麼這樣做」的文字，就是它的思路日誌。它繞圈、走歪的時候，你一讀那段推理就知道它是哪一步想錯了——這對除錯至關重要（第 10 章的可觀測性會再深入）。

具體長相很簡單，就是「想一句、做一個動作、看結果」不斷交錯，例如一個查資料的 agent：

Thought（想）：使用者問「台灣人口多少」，我沒有最新數字，得查。
Action（做）：搜尋「台灣 最新人口統計」
Observation（看）：搜尋結果顯示約 2340 萬人（某年某月）。
Thought（想）：有數字了，可以回答，不需要再查。
Action（做）：回覆使用者。

看到那個「Thought → Action → Observation」不斷交錯了嗎？這就是前面那張迴圈圖的文字版——你現在該相信「那張圖就是 ReAct 的精神」這句話了。

Reflection：讓它「交卷前先自己檢查一遍」

Reflection（反思）是在迴圈裡多加一個動作：做完之後，回頭審視自己的成果，發現不對再修一輪。 為什麼有用？想想人是怎麼寫東西的——初稿寫完很少一次到位，你會回頭讀一遍、抓出漏洞、再改。Reflection 就是把這個「自我校對」的習慣裝進 agent。

一個具體場景：一個寫程式的 agent 生成完一段函式後，如果沒有反思，它可能就直接交卷了；加了反思，它會多做一步「我來檢查這段有沒有漏掉邊界情況」，然後自己發現「啊，沒處理空陣列」，再補一段修正。成果品質常常因此明顯變好——這正是第 5 章 Evaluator–Optimizer 模式（一個生成、一個挑錯、來回打磨）在單一 agent 內部的體現。

💡 ReAct 管的是「動手之前先想」，Reflection 管的是「做完之後回頭檢查」。一前一後，都是在用「多花點字、多想一輪」換「做得更對」——本質跟第 1 章推理模型的邏輯一模一樣。

規劃（Planning）：agent 怎麼把大目標拆成小步驟

四要素裡的「規劃」值得單獨拉出來講，因為它是 agent「不亂衝」的關鍵。

規劃就是：拿到一個大目標，先把它拆成一連串小步驟，而不是埋頭亂做。 為什麼需要這一步？因為模型的 context 是有限的工作記憶（第 3 章），一個複雜任務如果不先拆解、列出計畫，它很容易做到一半就迷失方向——就像你不列購物清單直接衝進大賣場，繞了三圈還漏買東西。

拆解為什麼有效，其實也接回第 1 章：模型做「多步推理」本來就不擅長一步到位，但把大問題切成一個個小到它能可靠處理的步驟，它每一步的成功率就高得多。一個複雜任務直接叫它做，錯誤會層層累積；先拆成十個小步驟、一步一步確認，反而穩。這就是「先規劃再執行」的價值。

實務上你會看到兩種規劃風格：

• 先規劃再執行（Plan-and-Execute）：一開始就把完整計畫列出來（「第一步做 A、第二步做 B……」），然後照著做。好處是有全局視野、不容易漏步驟；壞處是計畫是死的，中途發現前提錯了、狀況變了，這份計畫可能整個不適用。
• 邊做邊規劃（ReAct 式）：不先列完整計畫，每一步看著當下情況決定下一步。好處是極度靈活、隨時能應變；壞處是容易見樹不見林，走著走著偏離大方向。

成熟的 agent 常常兩者混用：先列一個粗略計畫抓大方向，執行過程中再根據新觀察動態調整——這也呼應了前面 agentic loop「邊做邊修」的精神。

一個真實場景：研究 agent 跑一輪規劃

把規劃講活，我們看一個研究 agent（你給它一個題目，它自己查資料、彙整成報告）怎麼運作。假設任務是：「幫我研究『2024 年電動車在台灣的銷售趨勢』，寫成一份摘要。」

它可能先列出一份計畫（這就是規劃）：

計畫：
1. 搜尋 2024 台灣電動車總銷量數字
2. 找出前三大品牌與各自市佔
3. 查政府補助政策有沒有變化（可能影響銷量）
4. 對照 2023 年數字，算出成長率
5. 把以上整理成一段摘要

然後它進入 agentic loop，一步步執行這份計畫：搜尋 → 讀結果 → 發現「補助政策查到一半資料不夠」→ 臨場多加一步「再搜尋交通部公告」→ 補齊 → 繼續下一步。看到了嗎？計畫是它列的、執行中它還會自己補步驟。 這就是規劃（列計畫）＋自主性（臨場調整）＋工具（搜尋）＋記憶（把查到的都留在 context 裡最後彙整）四要素同時運轉的樣子。

🔧 動手試試：找一個你會用的 AI 助理，給它一個需要多步驟的任務（例如「幫我規劃一個三天兩夜的京都行程，要包含交通、住宿區域和每天的景點」），並在指令最後加一句「請先列出你的執行計畫，再開始做」。觀察它列出的計畫，跟它實際執行時有沒有中途調整。你會直接看到「規劃」這個要素在動。

記憶：agent 怎麼記得自己做到哪

因為模型是金魚腦（第 3 章），agent 的「記得進度」也是外掛的：

• 短期：這次任務的迴圈歷史（做過哪些動作、拿到哪些結果）都留在 context 裡。
• 長期：跨任務要記的東西（使用者偏好、專案慣例）寫進檔案或資料庫，下次再撈。

你在 Claude Code 看到它「記得這個專案用 Go、之前踩過某個雷」，背後常是這種檔案式記憶在運作。

為什麼記憶非得「外掛」不可？

這一點務必想通，因為它是 agent 很多行為的根源。回到第 1 章：模型本身沒有記憶，它每次生成只看得到「這一次塞進 context window 的東西」。你上一句跟它說的話，它之所以「記得」，純粹是因為那句話還被放在 context 裡一起餵給它——一旦被擠出窗口，它就真的忘了，跟從沒發生過一樣。所以模型是不折不扣的金魚腦：關掉對話，它對你這個人一無所知。

那 agent 跑一個要好幾十步的長任務，怎麼「記得」前面做過什麼？答案就是上面那兩層，我們各補一個畫面：

• 短期記憶＝把迴圈歷史堆在 context 裡：每轉一圈，就把「這一步做了什麼、拿到什麼結果」接到 context 後面。所以它「記得五步前搜過什麼」，不是因為它有記憶，而是那五步全都還躺在 context 裡陪著它。這也埋下一個問題：任務越長，context 堆得越滿，早晚會塞爆（第 3 章的老問題）——這是後面「context 塞爆」失敗模式的根。
• 長期記憶＝寫進外部檔案/資料庫：跨任務要留的東西（你偏好用繁體中文、這個專案用 Go、上次某個做法行不通），不能靠 context（關掉就沒了），得主動寫進一個檔案，下次任務開始時再讀回來。Claude Code 的 CLAUDE.md、各種「記憶檔」就是幹這個的——本質上就是 agent 的外接硬碟。

💡 一句話串起來：模型是 CPU（只會即時運算、斷電就忘），context 是 RAM（工作記憶、關機就清空），檔案/資料庫才是硬碟（永久保存）。 agent 的「記憶」不是模型變聰明了，是工程上幫它接了 RAM 和硬碟。

🔧 動手試試：如果你用 Claude Code，在專案根目錄建一個 CLAUDE.md，寫進一兩條你的偏好（例如「回答用繁體中文」「這個專案的測試指令是 npm test」）。下次開新對話，看它是不是「一開始就記得」這些事——你就親手做了一次 agent 的長期記憶。

Human-in-the-loop：別讓它全自動亂來

Agent 能自主，但不代表所有事都該讓它自己決定。**Human-in-the-loop（人在迴路）**指在關鍵、危險或不可逆的動作前，停下來問人：

• 刪除資料、寄出信件、付款、git push → 執行前先問使用者同意。
• 這個「審批關卡」設在哪，正是你（透過第 9 章的 harness）決定的。

⚠️ 讓 agent 全自動執行高風險動作，是新手最容易出事的地方。能自動的自動、該問的一定要問。

判斷「哪些動作該停下來問」，有個很好用的直覺：看這個動作可不可逆、以及出錯了代價多大。

原則就是：動作越「潑出去收不回來」，就越該在執行前踩煞車問人。 讀一個檔案錯了無所謂再讀就好；但一封道歉信寄錯客戶、一筆款付錯帳戶，是收不回來的。

🔧 動手試試：下次用 coding agent 時，故意給它一個「有點危險」的任務（例如「把這個沒用到的資料夾刪掉」），觀察它是直接動手、還是先跟你確認。順便想一想：如果是你來設計這個 agent，你會把「刪除」這個動作設成要不要先問人？這正是第 9 章 harness 在替你把關的事。

Agent 的三大失敗模式（一定要知道）

Agent 因為「自己決定」，就會有 workflow 不會有的翻車方式：

💡 這三個坑，正是為什麼「先用 workflow、不夠再上 agent」（第 5 章）是金科玉律——agent 的彈性，是用可控性換來的。

這三個失敗模式非常重要，我們各配一個真實會發生的畫面，讓你以後一看到就認得出來。

無限迴圈——它會鬼打牆。 想像一個 coding agent 要修 bug：它改了一行 code、跑測試、測試失敗；於是它把那行改回去、再跑、又失敗；再改成第三種寫法、又失敗……然後它回到第一種寫法，整個循環重來。它自己不知道在繞圈，因為每一步「看起來」都是合理的下一步，但它缺乏「我已經試過這招了」的大局觀，就這麼卡死。這就是為什麼步數上限是保命符：轉超過（比如）30 圈還沒完成，就強制停下來、把狀況交還給人，總比讓它無止境燒下去好。

目標漂移——它會忘了初衷、越走越歪。 你叫一個研究 agent「查電動車銷量，寫一頁摘要」。它查到一半看到一則「某電池新技術」的有趣資料，於是深入去研究電池；電池又扯到充電樁佈建，它又去查充電樁……一小時後你拿到一份三千字的電池技術報告，卻沒有你要的銷量摘要。它不是壞掉，是每一步的「岔路」單看都合理，累積起來就整個偏離了原始目標。防法就是定期把原始目標重申給它（「提醒你：任務是寫一頁『銷量』摘要」），像給它一個不斷回正的指北針。

成本失控——它會安靜地燒錢。 這點最容易被新手忽略，因為它沒有「錯誤」，只是貴。還記得第 1 章說「API 按 token 計費」嗎？agent 每轉一圈都是一次（甚至多次）模型呼叫，而且它會把越來越長的迴圈歷史一起送進去（短期記憶那節講的），所以token 用量是隨圈數滾雪球的。一個沒設上限的 agent 卡進無限迴圈，可能一個晚上就燒掉你預期十倍、百倍的錢。防法是設預算上限（花超過就停）並監控用量——這正是第 10 章要專門處理的事。

⚠️ 再補一個新手常踩的坑：context 塞爆導致「開頭失憶」。 長任務跑久了，迴圈歷史把 context window 塞滿（第 3 章的上限），最早的內容——包括你一開始交代的目標和關鍵限制——就被擠出去了。這其實是「目標漂移」的一種物理成因：不是它不想記得，是你的原始指令真的被擠出它的工作記憶了。這也是為什麼「定期重申目標」有效——等於把被擠掉的東西再塞回來。

💡 把三大失敗連起來看，你會發現它們常常手牽手一起出現：無限迴圈 → 圈數暴增 → token 暴燒（成本失控）＋ context 塞爆 → 忘了初衷（目標漂移）。所以那幾道防線（步數上限、預算上限、重申目標）不是三個獨立的補丁，而是同一套「別讓它脫韁」的韁繩。

一個「繞圈失控」的完整反例

把上面串起來，看一個活生生的翻車現場。假設一個沒設任何上限的 agent，任務是「把專案裡一個測試修到通過」：

圈 1：改了 A 檔 → 跑測試 → 失敗（錯誤訊息：找不到變數 x）
圈 2：在 A 檔補上變數 x → 跑測試 → 失敗（新錯誤：型別不對）
圈 3：改 x 的型別 → 跑測試 → 失敗（又回到「找不到變數 x」）
圈 4：又補上變數 x → 跑測試 → 失敗（型別不對）
圈 5：改型別 → 失敗 …
圈 6～50：在圈 3、4 之間反覆鬼打牆，每圈都燒 token
         → 迴圈歷史越堆越長，塞爆 context
         → 最早那句「只要修好這一個測試」被擠出窗口
         → 它開始「順手」去動別的檔案，把原本好的地方也改壞了

看到災難是怎麼滾出來的嗎？無限迴圈（圈 3–4 鬼打牆）→ 成本失控（每圈都燒錢）→ context 塞爆 → 目標漂移（忘了「只修一個測試」，跑去亂改別的檔）。四個坑一條龍。如果一開始就設好「最多 20 圈」「花超過某金額就停」「每 5 圈重申一次目標」，這場災難在圈 6 就會被攔下來。這就是為什麼那幾道韁繩不是可有可無的裝飾，是 agent 上線前的基本安全帶。

🔧 動手試試：給一個 agent 一個它其實做不到、或條件矛盾的任務（例如叫它「修好」一個你故意留成無解的 bug，或要求兩個互相衝突的目標），然後盯著它。你會看到它開始鬼打牆——重複嘗試類似的招數、繞不出來。這是最有價值的一堂課：親眼看過 agent 卡死，你才會真心相信「步數上限」「預算上限」這些防線不是理論，是保命的。（記得自己盯著、準備隨時喊停，別真讓它燒太久。）

重點回顧

• Agent = 自主決定路徑的 AI；核心是「感知→推理→行動→觀察」的迴圈（就是個 while 套著工具呼叫）。它跟 workflow 的分界是：workflow 是你排好路線讓它照走，agent 是你給它目標讓它自己找路——找得出路線就別用 agent。
• 這個迴圈的本質，是把第 1 章的「猜下一個字」升級成「猜下一個動作」；需要迴圈，是因為模型無法預知每一步的結果，得靠「觀察」吸收真實世界的意外、再修正下一步。
• 四要素：自主性、工具、規劃、記憶。規劃是把大目標拆成小步驟（拆小了每步才可靠）；記憶必須外掛（模型是金魚腦，context 是 RAM、檔案才是硬碟）。
• 經典模式：ReAct（動手前先把推理講出來，邊想邊做）、Reflection（做完回頭自我檢查）——兩者都是用「多想一輪」換「做得更對」，跟第 1 章推理模型同源。
• 關鍵動作前要 human-in-the-loop（人來審批）；判準是「這動作可不可逆、出錯代價多大」——潑出去收不回來的（刪庫、付款、寄信、push）一定要先問。
• 三大失敗：無限迴圈、目標漂移、成本失控——分別用步數上限、重申目標、預算上限來防；它們常一條龍連環爆（繞圈→燒錢→塞爆 context→忘了初衷），所以那幾道韁繩要一起上。

你現在懂 agent 的「腦」了。但它怎麼接到「一大堆工具」？下一章講一個讓工具接得又快又標準的東西——MCP。