AI Agent 到底是什麼？從 Chatbot 到閉環決策系統

AI Agent 到底是什麼？從 Chatbot 到閉環決策系統

前面幾篇，我們一路從 LLM 本身走到了 Production AI。

我們談過：

• LLM 為什麼不是知識庫
• Context Window 與 Context Engineering
• Attention、Embedding
• Structured Output、Tool Calling
• Production AI 的 failure、validation 與 observability

這時候終於可以處理一個被使用得非常氾濫的詞：

AI Agent。

現在很多產品只要：

LLM
+
Tool

就會被叫做 Agent。

有些系統只是在 Prompt 裡寫：

You are an autonomous AI agent.

也開始自稱 Agent。

但如果「會呼叫工具」就等於 Agent，那幾乎所有現代 LLM Application 都可以叫 Agent。

這個定義就失去意義了。

所以真正值得問的不是：

有沒有 LLM？
有沒有 Tool？

而是：

這個系統有沒有形成一個根據環境結果持續決策的閉環？

---

一、先不要從 LLM 開始理解 Agent

理解 Agent 最容易犯的錯，就是先從模型開始。

例如：

GPT
Claude
Gemini

然後問：

哪一個模型比較像 Agent？

但 Agent 首先不是一種 Model。

它比較接近一種：

System Architecture。

同一個 LLM：

可以放進 Chatbot。

也可以放進 RAG Application。

可以放進 Workflow。

也可以成為 Agent 系統裡的一個 decision component。

所以：

Model ≠ Agent

更精確地說：

Agent 描述的是整個系統如何觀察、決策、行動與持續更新，而不是底層模型叫什麼名字。

二、Chatbot：最簡單的 Input → Output

先從最熟悉的 Chatbot 開始。

基本流程大概是：

User Input
↓
LLM
↓
Response

使用者提出一個問題。

模型產生一個答案。

這是一個典型：

Input → Output

系統。

就算加入 Conversation History：

User
↓
Context
↓
LLM
↓
Response

本質仍然沒有改變太多。

模型的任務通常還是：

根據目前輸入產生下一個 response。

三、加上 Tool，也不一定就是 Agent

假設現在加入 Calculator：

User
↓
LLM
↓
Calculator
↓
LLM
↓
Response

模型可以判斷：

這題需要計算。

然後使用 Calculator。

這已經比普通 Chatbot 更像一個 system。

但仍然不一定需要叫 Agent。

例如：

使用者問匯率
↓
模型選 currency tool
↓
取得結果
↓
回答

整個流程可能只有：

one decision
+
one tool call
+
one response

它仍然很接近：

Tool-enabled LLM Application。

所以：

Tool Calling 是 Agent 常見能力，但不是 Agent 的充分條件。

四、Agent 真正開始出現的地方：Closed Loop

現在想像另一個任務：

幫我找出系統測試失敗的原因並修正。

如果系統只做一次：

Read error
↓
Generate answer

它比較像分析助手。

但如果流程是：

Observe error
↓
Analyze
↓
Choose action
↓
Modify code
↓
Run test
↓
Observe result
↓
Choose next action
↓
...

事情開始不一樣。

這不是一次：

Input → Output

而是：

Observe
↓
Decide
↓
Act
↓
Observe
↓
Decide
↓
Act
...

也就是一個：

Closed Loop。

這是理解 Agent 最重要的一個概念。

五、Agent 的基本閉環

可以把 Agent 抽象成：

Environment
    ↓
Observation
    ↓
State
    ↓
Decision
    ↓
Action
    ↓
Environment changes
    ↓
New Observation
    ↓
New State
    ↓
Next Decision

或者更簡單：

Observe
↓
Decide
↓
Act
↓
Observe again

重點在最後一句：

Observe again。

因為 Action 產生的結果，會重新變成下一次 Decision 的輸入。

這就是 feedback loop。

六、所以 Agent 不只是「做事情」，而是根據結果繼續決定

假設我們叫模型：

寄一封 Email。

如果系統直接：

LLM
↓
send_email()

這只能證明它能執行 Action。

但另一個系統可能是：

讀 Email thread
↓
判斷需要回覆誰
↓
找相關文件
↓
草擬回覆
↓
檢查是否缺資料
↓
如果缺資料 → 搜尋
↓
重新草擬
↓
送出
↓
讀取送出結果
↓
確認任務是否完成

這時 Agent 的關鍵不是：

它用了很多 Tool。

而是：

Tool result 會影響下一步決策。

七、Goal：Agent 為什麼需要目標？

一般 Chatbot 通常回答：

這一句 User Message 要怎麼回答？

Agent 面對的問題比較像：

我現在離 Goal 還差多少？

例如：

把這個 bug 修好。

Goal 並不是：

產生一段程式碼。

真正目標是：

Tests pass
+
問題被修正
+
沒有造成新的 regression

所以 Agent 必須判斷：

現在完成了嗎？

如果沒有：

下一步做什麼？

這就是 goal-directed behavior。

因此 Agent 的另一個重要特徵是：

它不是只生成下一個 response，而是在選擇下一個 action 來接近某個 goal。

八、Decision：Agent 的核心不是生成，而是選擇

這裡又會出現一個很重要的認知轉換。

一般 LLM 使用方式關注：

What should the model say?

Agent architecture 更關注：

What should the system do next?

這兩個問題並不一樣。

下一步可能是：

回答使用者

也可能是：

搜尋資料

或者：

讀檔案
跑測試
呼叫 API
等待
要求人工確認
重新規劃
停止

所以 Agent 中的 LLM 很常扮演：

Decision Engine

而不只是：

Text Generator。

九、Action：決策必須能影響環境

如果系統永遠只能產生文字，那它能形成的 interaction loop 非常有限。

Agent 通常會有某種：

Action Space

例如 Coding Agent：

read_file
write_file
search_code
run_tests
git_diff

Travel Agent：

search_flights
search_hotels
check_calendar
create_itinerary

Customer Service Agent：

lookup_order
check_policy
update_ticket
issue_refund_request

這些 Action 讓 Agent 不只是「想」。

而能：

改變 environment。

不過這裡先只談 Action 的存在。

至於：

• 哪些 Action 可以執行
• 哪些需要 permission
• 哪些需要 human approval
• 什麼時候必須 stop

這些會留給 Article 09。

十、Observation：Action 的結果必須回到系統

假設 Agent 執行：

run_tests()

結果：

12 passed
2 failed

這不只是給使用者看的結果。

它還是 Agent 的：

Observation。

下一輪模型可能因此判斷：

還有兩個 test failed
↓
任務未完成
↓
讀 failure stack
↓
繼續修正

所以 Agent loop 的價值就在：

Action Result
→ New Observation
→ New Decision

如果 Action 的結果完全不影響下一步，那就很難稱為真正的 closed-loop Agent。

十一、State：系統需要知道「現在走到哪裡」

一旦任務變成多步驟，系統就需要記住：

已經做過什麼？
目前得到什麼結果？
還有哪些問題？
現在處於什麼階段？

這就是：

State。

例如：

Goal:
修復登入問題

State:
- 已讀 authentication code
- 已找到 token expiration bug
- 已修改 refresh logic
- unit tests passed
- integration test still failing

下一步 Decision 就不應該從零開始。

它應該根據：

Current State

繼續。

State、Memory、Context 的差異會在 Article 08 再完整拆。

目前只需要知道：

Closed-loop Agent 如果沒有某種 State，很難知道自己現在在哪裡。

十二、一個比較完整的 Agent Loop

現在可以把前面的概念組起來：

Goal
 ↓
State
 ↓
Observe Environment
 ↓
Decision
 ↓
Select Action
 ↓
Execute
 ↓
Observe Result
 ↓
Update State
 ↓
Goal completed?
 ├─ Yes → Stop
 └─ No  → Next Decision

這比：

LLM + Tools

更接近 Agent 真正有用的定義。

十三、Workflow 和 Agent 差在哪？

這裡是非常重要的一條界線。

假設我們有：

Step 1：搜尋資料
Step 2：摘要
Step 3：寫文章
Step 4：寄 Email

不管 Step 2 的結果是什麼：

系統都固定走：

1 → 2 → 3 → 4

這比較接近：

Workflow。

Agent 則可能是：

Search
↓
結果夠嗎？
├─ No → 再搜尋
└─ Yes
      ↓
分析
      ↓
有衝突嗎？
├─ Yes → 找更多 evidence
└─ No
      ↓
產出

也就是：

下一步不是全部預先寫死，而是會根據目前 observation / state 動態決定。

十四、但 Workflow 和 Agent 不是非黑即白

現實系統通常不是：

100% Workflow

或：

100% Autonomous Agent

很多真正好用的系統反而是：

Deterministic Workflow
        ↓
Agent Decision Point
        ↓
Deterministic Execution
        ↓
Validation
        ↓
Agent Decision Point

例如：

固定：
先取得資料

↓

Agent：
判斷需要哪種分析

↓

固定：
執行指定分析工具

↓

Agent：
判斷結果是否足夠

因此 Agent 並不代表：

所有事情都交給模型決定。

更實用的設計通常是：

只在真的需要判斷的地方加入 agency。

這個問題會直接帶到下一篇 Article 07：

LLM / RAG / Workflow / Agent 到底怎麼選？

十五、Agent 不是「越自主越高級」

看到 Closed Loop 之後，另一個常見誤會是：

Loop 越長、自由越高，就是越好的 Agent。

不一定。

如果任務其實可以：

SQL query
→ deterministic calculation
→ answer

卻改成：

Agent 自己規劃
↓
自己選 Tool
↓
自己重新嘗試
↓
自己驗證

只會增加：

• latency
• cost
• failure surface
• debugging difficulty

所以 Agent 不是 AI Application 的最高級形態。

它只是一種：

適合特定問題的 architecture。

十六、什麼情況才開始需要 Agent Thinking？

可以先用一個很簡單的判斷方式。

如果任務是：

Input
↓
一次推理
↓
Output

通常不需要 Agent。

如果是：

Input
↓
固定步驟
↓
Output

Workflow 可能就夠。

如果是：

目標已知
但下一步必須根據前一步結果決定

這時 Agent Thinking 才開始真正有價值。

例如：

Debugging
Research
Complex troubleshooting
Multi-step operations
Open-ended task execution

因為這些問題的：

next step

常常無法在任務開始前全部確定。

十七、Agent 的第一性原理定義

如果把所有 buzzword 拿掉：

Agent 至少需要：

Goal
+
State
+
Observation
+
Decision
+
Action
+
Feedback

形成：

Goal
↓
Observe
↓
Decide
↓
Act
↓
Observe Result
↓
Update
↓
Continue or Stop

所以我會把 Agent 定義成：

能根據目前狀態與環境觀察，自主選擇下一步行動，並利用行動結果持續更新決策直到任務停止的閉環系統。

LLM 可以是這個系統的 decision engine。

但：

Agent ≠ LLM。

十八、這也解釋為什麼 Agent 更難做

前一篇 Production AI 已經看到：

普通 AI Application 就有：

Model Failure
Retrieval Failure
Tool Failure
Validation
Latency
Cost
Observability
Evaluation

Agent 加入 Closed Loop 之後，這些問題不是消失。

而是會被放大。

因為現在：

一次錯誤 decision

可能產生：

錯誤 action

而錯誤 action 又改變：

下一輪 environment / state

所以 failure 可以沿著 loop 累積。

這也是為什麼真正做 Agent 時：

「讓模型能做更多事情」

不是最困難的部分。

真正困難的是：

讓系統知道什麼時候應該自己決定、怎麼判斷下一步，以及什麼時候根本不需要 Agent。

而這就是下一篇要回答的問題：

LLM、RAG、Workflow、Agent 到底怎麼選？

不是選「最先進」的架構。

而是找：

完成任務所需要的最低必要複雜度。