Agent

Properties2
tags狀態/草稿
aliasesAgent, LLM Agent, AI Agent, 智能體

閱讀時間約 11 分鐘

Agent

一句話定義

Agentic system 的一種——LLM 動態決定自己的流程與工具使用，並維持對「如何完成任務」的控制；對比於 workflow（走預定義 code path）。

核心要點

Workflow vs Agent（Anthropic 的分法）

  • Workflow：LLM + tools 走預定義 code path；流程固定可預測
  • Agent：LLM 動態決定流程；可規劃、自我糾正、向環境請求資訊、在 checkpoint 暫停

自主程度光譜（從固定到完全自主）

「動態決定」不是二元，而是光譜。同樣是「動態」，決策範圍不同產生不同 pattern：

級別Pattern動態決定的是什麼受限於什麼
0直接呼叫 LLM無——一次輸入一次輸出任務必須單步可解
1Routing把輸入分類到哪個後續處理後續處理本身固定
2Parallelization無——子任務在啟動時已知sectioning / voting 結構固定
3Prompt-Chaining中間閘門可分支，但主鏈固定主鏈是預定義 code path
4Evaluator-Optimizer何時停止迭代生成 / 評估角色固定
5Orchestrator-Workers子任務組成（看到輸入即時決定）合成策略固定，子任務只能在 worker 池內挑
6Agent（本頁）整個流程（規劃 / 工具選擇 / 何時停止 / 如何修正）環境的 ground-truth feedback + ACI

Orchestrator-Workers vs Agent 的灰色地帶：兩者都「動態」，但 O-W 的決策只在子任務拆解這一層（合成是 fixed），Agent 的決策遍及整個流程（包含「合成不滿意要不要重來」「要不要新增一個工具呼叫」）。O-W 仍歸 workflow；Agent 是 workflow 之外的另一類。光譜上越往右，預測性越低，需要的 ACI 與環境回饋越強。

Stanford / Andrew Ng 語境的三層自主性

2026-05-13-Stanford-AI系統課程 以 Agentic-Workflow 角度補上另一種 production-friendly 分法：

層級設計實務意義
Hardcoded steps步驟順序寫死，LLM 只處理部分判斷最安全、最可預測，但彈性最低
Hardcoded tools工具集固定，agent 自行決定步驟與工具組合常見 production 起點：可控又有彈性
Fully autonomousagent 自己決定步驟，甚至自己寫工具 / code能力最強，但風險最高，需要更強 guardrail

這個分法不是取代上方 0-6 光譜，而是從產品控管角度提醒：先固定工具邊界，再讓 agent 在邊界內規劃，通常比一開始追求全自主更健康。

何時用 agent

  • 問題開放、步驟不可預測、無法 hardcode 路徑
  • 需要對 model 決策有信任
  • 需要環境提供 ground-truth feedback（測試、編譯、API 回應）

何時不用 agent

  • 任務定義良好 → 用 workflow（5 個 pattern 之一）
  • 簡單任務 → 直接呼叫 LLM
  • 「先用最簡單的解法，只在必要時增加複雜度。」

對話式 Agent 的兩個觸發信號（2026-05-02-Agent神文沒告訴你的事 整理）

多步驟 ≠ Agent；狹義對話式 Agent 通常只有兩個觸發信號：

  1. 流程必須讓人參與——不管是被動（模型能力達不到 / 需人指導）還是主動（需要人的偏好）
  2. 功能選項多到前端會指數型增長——不能或不想為每種功能加單獨前端時，才需要 Agent 作為通用入口

反例：每出現一種新需求就加一個按鈕（一鍵重做 / 一鍵改風格 / 一鍵改顏色 / 一鍵換模板…）→ 最後產品變成飛機駕駛艙——這時才天然需要 Agent 通用入口。

判斷指標的反面：「用戶不需要在中間反覆參與，那你大概率不需要對話 Agent」——多步驟但中間不需用戶介入 = 確定性流程 = 用 chain workflow 即可（N8N / Diffie / 純 Prompt-Chaining 編排已夠）。

複雜度演化軸（縱向時序視角）

本節提供縱向時序視角，補位本頁前段 自主程度光譜 的橫向 pattern 分類；詳見 Agent複雜度演化。

  • 橫向（既有 7 級 pattern 表）回答：「你的任務該用哪個 pattern」
  • 縱向（Agent複雜度演化）回答：「你的任務從小變大時該按什麼順序升級」

7 階段速覽（每階段都對應一個明確的觸發信號）：

階段升級觸發信號
0. API Call一句話可解
1. Workflow多步驟但中間不需用戶介入
2. 對話 Agent流程需人參與 / 功能選項指數爆炸（兩信號之一）
3. 加工具Prompt 已到頂仍做不好——任務需要的能力它沒有
4. Context-Engineering工具 3-4 個後 Agent 持續性變差（注意力犧牲）
5. Agent-Memory需傳遞不能改動的長內容（指針而非內容）
6. Observability（Trace）系統複雜後 debug 困難

核心紀律：「不需要一上來就優雅，千萬不要讓優雅變成你 AI 系統設計路上的絆腳石」——AI Agent 是非確定性系統，在它上面再搭一層精緻架構等於是在不確定性上再疊加一層不確定性。詳見 Agent複雜度演化。

三大成功原則

  1. 維持簡潔（simplicity）
  2. 透過明確規劃步驟提升透明度（transparency）
  3. 用完善文件與測試打造好的 Agent-Computer-Interface（ACI）

Agent = LLM + Harness（Harness-Engineering 視角）

2026-05-02-Harness-Engineering駕馭工程 李宏毅 整理：

  • AI Agent 的兩個成分：(1) LLM（Claude / Gemini / GPT；雲端 / 地端 / 開源 / 閉源）+ (2) Harness（其他所有支援 LLM 呼叫工具、管理 context、執行迴圈的程式 = 馬具）。
  • 強化 agent 兩條路：(a) 改 LLM（pre-train / fine-tune）/ (b) 改 Harness（AGENTS.md / CLAUDE.md / 工具設定 / 工作流 / feedback 機制）。
  • Harness Engineering 把 Agent 的「夠不夠聰明」議題從模型本身延伸到 harness 設計：「有時候模型無法完成任務不是能力不行，而是沒有好的 harness」——同一個 Gemma 4 2B 模型，加了不到 80 字的工作原則就從幻想者變正常 agent。

Context 視角下的 Agent = LLM 的守門人 / 經紀人

2026-05-02-AI-Agent-Context-Engineering系統化 李宏毅 整理：

  • LLM 是文字接龍、活在當下，且輸入長度有上限——Agent 攔截在 LLM 與外界之間，選擇給 LLM 看的內容（不能太長、也不能太短）。
  • 這層工程化載體就是 Context-Engineering——演算法層形式 C = (P, M) + 更新函式 F；Agent 的工程性質很大程度上 = 設計 F 的策略。
  • OpenCode 是 AI Agent 的 Nokia 時代代表（李宏毅 比喻）——這只是初代原型，未來會有更多進展。
  • Sub-Agent 是 Agent 在自主程度光譜中的延伸：超越 Orchestrator-Workers 的固定合成，能動態決定「要不要新開一個 sub-agent」+「主 / 副 agent 之間怎麼切割任務」。

多 agent 協作

當任務需要多個專業 agent 互相協作時，單一 agent 的工具呼叫不足以描述整個系統。Agent2Agent 提供 agent 之間的能力發現、任務提交、狀態更新、訊息交換與工件回傳協議，讓 agent 可以作為 agent 互相合作，而不只是被當成工具呼叫。

兩個實證有效的領域

  • 客戶支援：對話 + 工具整合（客戶資料、訂單、退款、ticket）；resolutions 可量化
  • Coding agents：解可被自動測試驗證的問題（如 SWE-bench、GitHub issue 解決）

與其他概念的關係

相關來源

備註

反向連結