AI 代理類型詳解：從反射式到學習型代理

AI 代理的類型

AI 代理的類型源自一套分類法：簡單反射式、基於模型的反射式、基於目標式、基於效用式以及學習型代理。每個名稱描述了一件事：代理記憶的深度，以及在採取行動前規劃的遠近。另外兩個術語「多代理」與「階層式」則描述多個代理如何串聯，而非單一代理的決策方式。

這份清單比你使用過的任何模型都更古老。它源自標準的 AI 教科書，且在大型語言模型出現後依然適用，因為它提出了決定設計的核心問題：此系統在行動前需要知道什麼？如果你還在釐清代理與其運作的 LLM 聊天助理之間的界線，請先閱讀 AI 代理與其運作之 LLM 的差異。本頁內容將從該界線之後開始。

簡單反射代理：單一條件，單一動作

簡單反射代理將當前輸入對應至一個動作，且不會保留任何先前的記憶。若溫度高於 25 度，則開啟風扇。這就是其全部機制。

你幾乎肯定執行過這類代理。一個觸發 n8n 工作流程的 webhook，在讀取表單提交內容並將資料寫入資料庫後，即是一個簡單反射代理。即使中間加入語言模型來為該列資料選擇類別，它依然是簡單反射代理。若詢問它一小時前做了什麼，它無法回答，因為沒有任何機制保留該答案。

這種類型正確運作的頻率比人們預期的更高。其執行成本低廉，且故障原因明確：條件符合與否一目了然。當工作內容確實是「當 X 到達時，執行 Y」時，記憶只會增加出錯的可能性，卻毫無助益。由 webhook 觸發的 n8n 代理 即是此分類中具備使用者介面的實例。

一旦正確的動作取決於歷史紀錄，這類代理便會失效。一個沒有執行緒狀態的自動回覆機器人，在第三則訊息時就會自相矛盾，因為前兩則訊息從未被納入其輸入範圍。

基於模型的反射代理：在事件間維持狀態

基於模型的反射代理會在內部維護環境的狀態，並隨著新輸入的到來更新該狀態。此處的「模型」是指對世界的模擬，而非神經網路。這個術語比現今的定義早出現約 40 年，初次閱讀時幾乎會讓所有人感到困惑。

一種在偵測不到動作 20 分鐘後關閉燈光的家庭自動化規則，即屬於基於模型的代理。它必須如此運作。對於簡單的反射代理而言，「現在沒有動作」與「自 21:40 起沒有動作」是相同的輸入，因此唯有儲存的狀態才能區分兩者。

LLM 版本是指任何背後具備記憶儲存機制的代理：例如滾動式的對話摘要，或是代理在每次執行開始時讀取的純文字 markdown 檔案。代理的本地記憶體服務即是將此概念封裝後的產物。其運作機制並未改變。代理對世界的認知會持續存在，並超越產生該認知的事件本身。

狀態是有代價的。過時的事實比沒有事實更糟，因為代理會毫無戒心地根據這些事實採取行動。任何儲存的資訊都需要具備過期機制或重新驗證方式，否則代理將會持續針對您在 3 月已停用的伺服器進行邏輯推論。

目標導向代理：朝向可驗證狀態的規劃

目標導向代理會接收一個目標狀態，並搜尋能達成該狀態的動作序列。它從終點目標反向推導，因此路徑並非預先寫好的。

程式編寫代理是您能親自執行的最明確範例。「讓失敗的測試通過」這項指令並未指定任何檔案或步驟。代理會讀取測試、擬定計畫、進行編輯、執行測試、讀取錯誤訊息，然後再次嘗試。迴圈會在代理實際可執行的檢查點結束，這就是為什麼該指令有效，而「改善此程式碼」卻無效的原因。代理能評估的目標，才是代理能達成的目標。代理無法評估的目標，最終只會變成產生帳單的無窮迴圈。在您自己的 VPS 上執行程式編寫代理 將該迴圈置於可持續運作的環境中，而不會佔用您的筆記型電腦資源。

成本取決於此。每一個規劃步驟都是一次模型呼叫，且需攜帶目前的歷史紀錄，因此十個步驟的任務成本不只是單一步驟的十倍，而是更高。關鍵的工程設計在於迴圈的結構與終止條件，這正是 迴圈工程 的主題。

基於效用的代理程式：在多個可行方案中進行選擇

目標是二元的，而效用是一個分數。基於效用的代理程式會面對多個可接受的結果，並從中挑選出一個符合您所編寫函數、得分最高的結果。

一個必須在工作日開始前完成，且不能佔滿上行頻寬的備份作業，就是一個效用問題。這類問題沒有單一的正確答案，只有取捨。路由器決定由哪個模型處理請求時，需權衡價格與回答品質，其本質也是如此。

演算法本身並不困難，困難的是編寫一個誠實的效用函數。若僅以成本作為評分標準，系統對每個請求都會選擇最便宜的模型，即使是那些需要昂貴模型處理的請求也不例外。系統會精確地優化您所測量的指標；當您選擇該指標僅是因為它容易測量時，這就會成為一個問題。

學習代理：大多數人誤以為自己已經擁有的類型

學習代理會根據過去結果的回饋來改變自身的行為。它需要一個能評估結果的機制，以及一個能根據評估結果調整策略的機制。

極少數自架系統符合此定義。一個會讀取上週所寫筆記的代理，屬於具備記憶檔案的「模型基礎代理」（model-based agent）。其權重並未改變，其策略也完全相同。檢索（retrieval）並不等於學習，兩者的區別在於實務層面：記憶基礎系統會不斷重複同樣的錯誤，除非有人手動編輯其記憶；而學習系統則應具備停止犯錯的能力。

若您需要學習功能，請先建立評估機制。包含評分測試集、針對變更進行測試，以及決定保留或捨棄變更的決策過程，這是一個閉環系統，而您本人即是其中的學習組件。這比聽起來更耗時，但卻是目前在自架環境中唯一可行的方案。自架評估工具是入門的第一步。

多代理與階層式系統：架構而非類型

這並非第六與第七種代理類型，而是描述代理如何進行配置。

多代理系統（multi-agent system）在共享環境（如佇列或 git 儲存庫）中同時執行多個代理。由於環境是共享的，代理之間會產生衝突。兩個代理同時編輯同一個檔案是典型的失敗案例，解決方法是使用鎖定機制或工作佇列。單靠提示詞（prompt）無法解決此問題。

階層式系統（hierarchical system）在工作者之上設置了監督者。監督者負責拆解任務、分配工作並合併回傳的結果。這種架構之所以普及，是因為它符合人類分工的方式；但其代價高昂，因為監督者讀取的報告越多，其上下文（context）負擔就越重。多代理工具鏈 展示了實際的串接方式。

一個能穩定運作的代理，勝過四個勉強運作的代理。

每一次交接都是資訊遺失的潛在點。請從單一迴圈開始，只有在能明確指出瓶頸步驟時，才進行拆分。

為何幾乎所有實際系統皆為混合式

試想一個您自行執行的部署代理程式。Webhook 會觸發它，這是反射式（reflex）。它讀取當前的發布狀態，這是基於模型（model-based）。它規劃從執行版本到目標版本的步驟，這是基於目標（goal-based）。它根據當前負載選擇發布窗口，這是基於效用（utility-based）。由於它從不編輯自身的策略，因此它不具備學習能力。

單一系統同時涵蓋了分類學中的四個層級。此分類學的價值在於作為設計檢查清單，而非成品標籤。當系統運作異常時，有用的問題是哪一層出了錯。因錯誤事件觸發、狀態過期、永遠無法達成的目標檢查，以及獎勵錯誤結果的評分，這四種是截然不同的錯誤，且各有其對應的修復方式。

哪種類型適合哪種工作

• 固定觸發、固定回應、無需歷史紀錄：簡單反射（simple reflex）。
• 正確回應取決於先前發生的事件：基於模型的反射（model-based reflex）。
• 最終狀態可驗證，但路徑事先未知：基於目標（goal-based）。
• 多種可接受的結果，且彼此之間存在實際權衡：基於效用（utility-based）。
• 需要結果隨時間改善：建立評估迴圈（eval loop），並接受您自己就是學習組件的事實。

可以自行託管這些代理程式嗎？成本為何？

可以，成本分為兩部分。編排（Orchestration）的成本很低。一個 n8n 實例或 Python 代理迴圈大部分時間都在等待網路呼叫，因此 2 vCPU 與 4 GB RAM 即已足夠。模型才是主要的支出來源。

若代理程式呼叫託管的 API，伺服器幾乎不需要資源，帳單則隨 Token 用量增減。對於目標導向的代理程式而言，這意味著成本取決於您允許的規劃步驟數量，因此請務必限制迴圈次數。

若您在自己的硬體上執行模型，RAM 大小決定了您能執行的模型規模。以下數據為 2026 年 8 月時，4-bit 量化權重常見的發布檔案大小，旁邊列出了所需的總 RAM 規劃數值，因為上下文視窗（context window）與執行時期（runtime）都需要權重以外的記憶體空間。

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

一個 4-bit 的 8B 模型權重約為 4.9 GB，配備 10 GB RAM 的機器可順暢執行且不會發生 Swap。相同量化規格的 70B 模型權重為 43 GB，則需要約 64 GB RAM。請注意這些數字忽略了速度因素。在沒有 GPU 的 VPS 上，4-bit 的 8B 模型每秒僅能產生個位數的 Token。這對於在背景處理佇列的代理程式尚可接受，但若需即時互動則會非常緩慢。請將本地推論用於批次作業，互動式任務則建議使用 GPU 或 API。可自架 AI 代理程式精選清單 涵蓋了值得安裝的專案，而 2026 年代理程式學習路徑 則說明了學習順序。

分類法失效之處

該分類法未提及工具或權限。教科書中的代理程式僅負責感知與行動，撰寫該章節時，無人考量代理程式持有生產環境 API token 的風險。一個擁有 shell 存取權的目標導向代理程式，與僅具備唯讀資料庫連線的代理程式，在表格中雖處於同一列，但兩者帶來的風險截然不同。在決定代理程式的智慧程度前，請先定義其可存取的範圍；在交付憑證前，請務必閱讀 如何防止 AI 代理程式洩漏機密。

此外，該分類法也未說明步驟失敗時的處理機制。實際運作的代理程式，大部分執行時間都在處理錯誤：例如速率限制（rate limit），或是工具回傳了模型預期之外的結果。這段程式碼決定了系統是否可用，而分類法中的任何一列皆未涵蓋此層面。

FAQ

AI 代理（AI agents）有哪五種類型？

分別為簡單反射式（simple reflex）、基於模型的反射式（model-based reflex）、基於目標（goal-based）、基於效用（utility-based）以及學習型（learning）代理。這些類型的區別在於代理在採取行動前所具備的知識量。簡單反射式代理僅觀察當前輸入；基於模型的代理會維護環境狀態；基於目標的代理會針對目標狀態進行規劃；基於效用的代理會評估多種可接受的結果並選擇分數最高者；學習型代理則會根據回饋調整自身策略，這在目前的自架環境中幾乎不存在。

簡單的自動化任務應該使用哪種類型的 AI 代理？

使用簡單反射式代理即可，實務上這通常是指透過 webhook 或排程來觸發固定的執行序列。如果正確的響應僅取決於剛收到的輸入，那麼引入記憶機制只會增加故障點而無實質助益。只有當你需要根據過去發生的事件來做出決策時，才需要升級為基於模型的設計。

我可以在 VPS 上執行自己的 AI 代理嗎？

可以。編排層（orchestration layer）相當輕量，2 vCPU 與 4 GB RAM 已足以順暢執行工作流引擎或代理迴圈。真正的決策點在於模型運行的位置。使用託管 API 可保持伺服器輕量，並將成本轉化為 token 計費；若運行本地模型，則需根據參數數量配置對應的 RAM，且在沒有 GPU 的情況下，生成速度僅為每秒個位數的 token，這較適合排隊處理的批次作業，而非即時對話視窗。

大型語言模型（LLM）本身就是 AI 代理嗎？

不是。模型僅負責將輸入文字映射為輸出文字，隨後便停止運作。當模型被封裝在一個能對外部世界採取行動並將結果回饋的迴圈中時，它才成為代理；這需要模型能呼叫工具，並具備判斷迴圈何時停止的條件。封裝層才是代理，而模型僅是其中的一個組件。

我需要多代理系統（multi-agent system）嗎？

通常不需要。單一迴圈搭配多種工具即可處理大多數工作，且除錯容易得多。當任務的各個部分確實獨立且可同時執行，或者不同部分需要使用不同模型時，多代理系統才有幫助。其代價在於協調成本：包含共享狀態，以及一個隨著每個工作者報告而導致上下文（context）不斷膨脹的監督者。只有當你能明確指出哪一個步驟執行緩慢時，才考慮加入第二個代理。