AI Agent 工作原理解析：感知、規劃、工具呼叫、記憶與回饋的迴圈

很多人知道 AI Agent「會自己做事」，但問它一句話、它回你一個結果之間，中間到底發生了什麼，多數人其實說不清楚——這也是為什麼 Agent 卡住或出錯時，團隊常常只能憑感覺猜測「是不是模型不夠聰明」，卻找不到真正的卡點在哪一層。這篇把一次互動拆成五個可被檢查的階段，讀完你會知道每個階段在做什麼、最容易在哪裡出問題。

本質與範圍：這篇要拆的是「怎麼跑」，不是「是什麼」

市面上多數介紹 AI Agent 的文章，停在「Agent 是一個能自主完成任務的 AI 系統」這個定義層次就結束了，但這個定義對想實際導入的人幫助有限，因為它沒有回答「自主完成任務」這四個字背後，系統實際上做了哪些具體的事。這篇要拆的，是這個黑盒子內部實際運作的五個階段：感知、規劃、工具呼叫、記憶、回饋。這五個階段不是課本上的抽象分類，而是你可以在任何一次 Agent 互動的日誌（log）裡，實際對照找出來的具體步驟。

理解這五個階段的價值，不在於背下名詞，而在於建立一套「故障排除地圖」。當一個 Agent 給出奇怪的結果時，有了這張地圖，你才能問出正確的問題——是它一開始就理解錯你的輸入（感知層問題），還是它理解對了但拆解步驟拆錯了（規劃層問題），還是步驟拆對了但呼叫工具時參數給錯了（工具呼叫層問題）。沒有這張地圖，所有問題都只能籠統地歸因成「AI 不夠聰明」，這種歸因方式對改善任何事都沒有幫助。

核心迴圈：五階段如何串接

下面這張圖，畫出一次完整互動裡，這五個階段如何串接成一個迴圈。重點在於它是一個迴圈，不是一條直線——回饋階段的結果，會回頭影響下一輪的感知與規劃，而不是任務結束後就斷開。

        ┌───────────┐        ┌───────────┐        ┌─────────────┐
        │   感知層   │ ─────▶ │   規劃層   │ ─────▶ │  工具呼叫層  │
        └───────────┘        └───────────┘        └──────┬──────┘
              ▲                                          │
              │                                          ▼
        ┌───────────┐        ┌───────────┐        ┌─────────────┐
        │   回饋層   │ ◀───── │   記憶層   │ ◀───── │   執行結果   │
        └───────────┘        └───────────┘        └─────────────┘

這個迴圈每跑一輪，就是一次「感知—規劃—行動—記住—檢查」的循環。一個任務如果需要多輪才能完成，代表這個迴圈會被連續跑好幾次，而每一次跑的時候，前一輪累積在記憶層裡的東西，都會變成這一輪感知與規劃的一部分輸入。這也是為什麼同一個 Agent，跑到第五輪的表現，跟第一輪的表現可能差異很大——不是模型變笨了，而是迴圈裡累積的上下文，品質正在悄悄改變。

感知與規劃：從雜訊輸入到行動序列

感知階段做的事，是把使用者的輸入、系統當下的狀態、外部環境的資訊，整理成模型可以拿來判斷的素材。這一步聽起來簡單，但實際上是整個迴圈裡最容易被低估的環節，因為「整理」這個動作本身就帶有取捨——哪些資訊該保留、哪些該過濾掉、衝突的資訊該怎麼排序，這些判斷在感知階段就已經發生，如果這一步整理得有偏差,後面所有階段都是在錯誤的素材上做判斷,而且這種錯誤通常很難在後面被發現,因為後面的階段並不知道感知層原本看到的素材已經失真。

規劃階段接手感知層整理好的素材,把目標轉換成一組具體的行動序列。值得強調的是,規劃階段做的不是憑空生成步驟,而是在「目標」與「Agent 可用的工具與能力範圍」這兩個限制條件之間,找出一條可行的路徑。換句話說，規劃的品質,同時取決於目標本身有多清楚,以及 Agent 對自己能力邊界的判斷有多準確——如果 Agent 高估了自己能做到的事，規劃出來的步驟即使邏輯通順,執行到工具呼叫階段也會卡關。

這裡有一個容易被忽略的細節：感知與規劃這兩個階段,雖然在邏輯上是先後順序，但在實際運作裡,常常會有來回修正的情況——規劃過程中發現某個步驟需要更多前提資訊，會回頭觸發一次新的感知動作，去補齊原本沒掌握到的細節。如果把感知跟規劃想成兩個完全獨立、單向接力的階段，反而會誤判系統的實際行為，以為「規劃錯了就是規劃階段的問題」，卻沒注意到根本原因其實是感知階段一開始就沒抓到關鍵資訊，規劃階段只是忠實地把錯誤的素材變成了錯誤的步驟。

工具呼叫與記憶：決定做什麼、留下什麼

工具呼叫階段,是規劃出來的抽象步驟,轉換成具體可執行動作的環節。這裡每一步都要決定三件事：呼叫哪個工具、給什麼參數、以及如果這個工具呼叫失敗該怎麼辦。第三件事常常被忽略,但它其實是工具呼叫階段設計品質的關鍵指標——一個只考慮「成功路徑」的設計,遇到工具回傳錯誤或逾時,Agent 往往不知道該重試、該換工具、還是該停下來回報,結果是用一連串看似合理但方向錯誤的後續動作,把一個小錯誤放大成一連串連鎖反應。

這個階段還有一個容易被低估的風險：工具回傳的結果,本身可能是「格式正確、內容過時或不準確」。舉例來說,一個查詢庫存的工具,即使呼叫成功、回傳了一個看起來完全正常的數字,但如果這個數字其實是十分鐘前的快取資料,Agent 並不會知道自己拿到的是過時資訊,只會把它當成最新狀態繼續往下判斷。這種「形式上成功、實質上失準」的工具呼叫，比明顯的錯誤訊息更難被察覺，也是企業導入時最容易忽略的一塊風險。

記憶階段決定的是,這一輪迴圈裡發生的事,有多少該被留下來給下一輪用。這裡的取捨跟感知階段類似，但方向相反：感知階段在篩選「這一輪該看哪些資訊」，記憶階段在篩選「這一輪結束後,該留下哪些資訊」。留得太少,Agent 會在下一輪重複做已經做過的判斷,甚至忘記前面已經失敗過的嘗試,陷入重複犯錯的迴圈;留得太多,則會稀釋掉真正重要的上下文,讓下一輪的感知與規劃,被一堆無關的細節干擾判斷。記憶層該怎麼做這個取捨,牽涉到更深的技術設計考量,不在這篇的範圍內展開。

回饋與收斂：迴圈什麼時候該停

回饋階段檢查的是,這一輪執行的結果,跟原本的目標相比,是更接近完成了,還是出現了新的偏差。一個設計良好的回饋機制,應該能明確回答「這個任務現在算完成了嗎」這個問題,而不是模糊地繼續跑下一輪。下面這張表,整理了五個階段各自最常見的失敗樣貌,以及對應的徵兆,方便你在 Agent 表現異常時，快速定位問題出在哪一層。

可用 Prompt：強制 Agent 把推理過程說出來

要判斷一個 Agent 出錯時是卡在哪個階段，最直接的方法是要求它把每個階段的判斷過程明確說出來，而不是只給最終結果。下面這個 Prompt 設計給開發或導入團隊在除錯階段使用。

【角色】你是一個會自我說明推理過程的任務執行助理。

【要求】針對接下來的任務，請依照以下五個階段，分別說明你的判斷，再給出最終結果：

【感知】你從我的輸入裡，理解到的目標與限制條件是什麼？
【規劃】你打算拆成哪些步驟？拆解的依據是什麼？
【工具呼叫】每一步你打算用什麼方式執行？如果這一步失敗，你的備案是什麼？
【記憶】這一輪結束後，你認為哪些資訊值得留給下一輪參考？
【回饋】你怎麼判斷這個任務現在算不算完成？

請先完整輸出上面五段說明，再附上最終結果。

這個 Prompt 的價值，在於把原本隱藏在模型內部的判斷邏輯，逼著它用文字攤開來。即使最終結果是對的，攤開的過程也能讓你看出,這個 Agent 是「真的判斷對了」,還是「碰巧矇對了」,這兩者在下一次任務換了情境之後，表現會差異很大。

## 導入 SOP：把這套五階段框架用在你的工作流程

把這套框架實際用在導入評估上，建議依照以下五個步驟操作。

1. **先用這套框架，畫出你想導入的任務的理想流程**：在還沒導入任何工具之前，先用感知、規劃、工具呼叫、記憶、回饋這五個階段，描述這個任務理論上該怎麼跑，這份描述會變成後續驗收的基準。
2. **針對每個階段，列出「可能出錯的具體情境」**：不要只停在抽象層次，盡量列出具體會發生的情境，例如感知階段「使用者輸入裡同時包含兩個互相矛盾的需求時該怎麼辦」。
3. **小規模試跑，並用前面的 Prompt 要求 Agent 攤開每階段的判斷**：在小範圍、低風險的場景先試跑，並要求系統說明每個階段的判斷依據，藉此驗證實際運作跟你畫的理想流程有沒有落差。
4. **針對發現的落差，逐階段補強**：如果落差出現在工具呼叫階段，就針對那個階段補強失敗處理邏輯，而不是籠統地「換一個更強的模型」了事——很多落差其實跟模型能力無關，而是某個階段的設計本身有缺口。
5. **正式上線後，持續追蹤迴圈跑了幾輪才收斂**：如果一個任務的迴圈輪數突然變多，往往是回饋階段的收斂判斷出了問題，這個指標可以當成系統健康度的早期警示。

## ROI／成本分析：迴圈每多跑一輪，要付出什麼代價

迴圈每多跑一輪，帳面上看不到的成本就多了一筆——這筆隱藏成本，正是多數團隊在計算導入 Agent 的投資回報率時最容易漏算的部分。一個簡單的估算方式，是先觀察試跑階段裡，同類任務平均要跑幾輪迴圈才會收斂，再用這個輪數乘上單輪的運算與時間成本，跟人工處理同一個任務的成本做比較。如果你想把這幾個變數放進一個試算表裡互相比對，[AI ROI 計算機](/tools/ai/ai-roi-calculator)可以幫你快速抓出一個粗略的對照數字，再決定這個任務適合用幾輪迴圈內就該收斂的設計去導入，還是維持人工處理更划算。

值得提醒的是，迴圈輪數不是一個固定值，它會隨著任務複雜度與感知、規劃階段的設計品質而變動。同一個任務,如果感知階段整理輸入的品質提升,規劃階段拆解步驟更精準,迴圈往往能在更少輪次內收斂,這意味著成本估算不該只做一次,而該在每次調整這兩個前段階段後重新評估一次。

## ❓ 讀完後，先問自己這幾個問題

1. **你上次遇到 Agent 表現異常時，有沒有具體判斷出問題卡在五個階段裡的哪一層？** 引導思路：回想那次異常，試著用這篇的故障排除地圖重新定位一次,而不是籠統歸因成「模型不夠好」。
2. **你的記憶層設計，是留得太少導致重複犯錯，還是留得太多稀釋了重點？** 引導思路：觀察 Agent 跑到第三輪、第五輪時的表現，跟第一輪比起來是變好還是變差。
3. **你算過的 ROI，有沒有把迴圈多輪的運算與時間成本算進去，還是只算了省下的人力？** 引導思路：把試跑階段觀察到的平均迴圈輪數,拿來重新檢查一次你原本的成本估算。

## 結語：看懂迴圈，才看懂 Agent 真正的能力邊界

AI Agent 看起來像一個黑盒子，但它的內部其實是一個可以被拆開檢查的五階段迴圈——看懂這個迴圈，你才能在它表現異常時問出正確的問題，也才能在導入之前，誠實評估它真正適合處理哪一種任務。