# 策展 · X (Twitter) 🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Rahul (@sairahul1) · 平台：X (Twitter) · 日期：2026-05-25

> 原始來源：https://x.com/sairahul1/status/2058464422306443766

## 中文摘要

# AI Agents：完整課程

2026 年，每個人都在談論 AI Agents。

但大多數人根本不知道它們是如何運作的。

今天，這一切將會改變。

我花了數週時間將所有精華濃縮於此：課程、書籍、實際開發經驗以及生產環境中的失敗案例。

以下是你真正需要知道的內容。

無論你是要自動化自己的工作流程，還是為公司建構生產級的 AI 系統，這都是你的路線圖。

收藏起來。這篇文章很長，但絕對值得。

## 第一部分：初學者——AI Agents 究竟是什麼

## 1. 什麼是 AI Agent？

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672549359-diaHJD1ZuGbEAAFM1jpg.jpg)

一般的 LLM 只做一件事：

你提問，它回答，結束。

單次執行（One shot）、線性、沒有迭代。

AI Agent 的運作方式則完全不同。

它模仿你處理困難任務時的真實邏輯：

→ 先規劃 → 搜尋資料 → 草擬 → 審查自己的工作 → 修改 → 重複

這被稱為 ReAct 循環：

Reason（推理）→ Act（行動）→ Observe（觀察）→ Repeat（重複）

模型會推理下一步該做什麼，採取行動（通常是呼叫工具），觀察結果，然後決定是給你答案還是繼續循環。

為什麼這很重要？

每一次循環都會增加深度。推理更強、幻覺更少、組織更嚴謹。

當你試圖用單次執行（One shot）完成任務時所失去的一切，Agent 都能透過循環找回來。

## 2. Agent 真正擅長什麼？

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672548731-iaHJD1id4bMAAm7gPjpg.jpg)

並非所有任務都需要 Agent。

正確的思維模型是一個 2×2 矩陣。

軸向：複雜度 vs. 所需精確度。

→ 低複雜度 + 高精確度 = 直接用程式碼處理
→ 低複雜度 + 低精確度 = 直接用單一 LLM Prompt
→ 高複雜度 + 高精確度 = 需要嚴格 Guardrails 的 Agent（例如稅務表格、法律文件）
→ 高複雜度 + 低精確度 = 最適合起步的甜蜜點

最後這個象限是你最快能取得早期勝利的地方。

適合 Agent 的完美任務範例：

→ 搜尋資料並撰寫報告
→ 回覆客戶 email（查詢訂單 → 草擬回覆）
→ 處理發票
→ 儲存至資料庫
→ 回答「你們有 80 美元以下的藍色牛仔褲嗎？」——透過實際檢查庫存來回答

當任務需要以下條件時，Agent 表現最出色：

→ 多個步驟
→ 外部資訊
→ 迭代與自我修正

如果用一個 Prompt 就能解決，那就不要建構 Agent。

## 3. 自主性光譜

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672547787-ediaHJD1lZ5aMAA57jpg.jpg)

建構 Agent 時的第一個重大決策：

你要給它多少控制權？

想像一個光譜。

**指令式（左端）**
你硬編碼（Hard-code）每一個步驟。

→ 產生搜尋詞
→ 呼叫網路搜尋
→ 抓取網頁
→ 撰寫文章

模型只負責文字生成，其他一切由你決定。可預測、易於除錯，但功能受限。

**半自主（中間）**
Agent 從你定義的工具中進行選擇，並在你設定的 Guardrails 內做決策。這是大多數真實生產系統所處的位置。

**全自主（右端）**
LLM 決定一切。搜尋什麼、抓取多少頁面、是否反思、是否撰寫並執行新程式碼。功能強大，但極難控制。

你應該從哪裡開始？

光譜的中間。給它工具，設定 Guardrails。隨著你對系統的信心增加，再逐步增加自主性。

## 4. Context Engineering（情境工程）

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672549699-iaHJD2ADiaQAARimbjpg.jpg)

這才是讓 Agent 顯得「聰明」的關鍵。

這不僅僅是模型本身的問題。

而是你圍繞它所建構的 Context。

Context Engineering = 決定 Agent 在任何時刻擁有什麼資訊。

這包括：

→ 背景資訊 — 任務是什麼、使用者是誰
→ 角色設定 — 「你是一位專精於市場分析的研究 Agent」
→ 記憶 — 先前步驟發生了什麼
→ 可用工具 — 它能呼叫哪些函式
→ 知識庫 — 它能參考的文件、資料庫、PDF

Context 工程做得好 → 模型表現穩定。

Context 工程做得差 → 產生不可預測的垃圾資訊。

無論哪種情況，模型本身都是一樣的。

Context 是區分優秀 Agent 與故障 Agent 的關鍵。

## 5. 任務拆解（Task Decomposition）

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672547698-iaHJD2tg5aIAAB3Ekjpg.jpg)

這是建構 Agent 最重要的 skill。

從這裡開始：人類會如何完成這項任務？

然後針對每個步驟問：LLM 能做嗎？需要一點程式碼嗎？需要 API 呼叫嗎？

如果答案是否定的 → 將其拆解得更小，直到可以為止。

範例 — 寫作 Agent：

1. 大綱 → LLM 產生結構
2. 搜尋詞 → LLM 產生，然後呼叫搜尋 API
3. 抓取網頁 → 工具呼叫
4. 撰寫草稿 → LLM 使用抓取到的來源
5. 自我批判 → LLM 列出缺失與弱點
6. 修改 → LLM 根據批判進行重寫

每個步驟都是：→ 小型的 → 可檢查的 → 有明確的輸入與輸出

當最終輸出結果很差時，你可以精確地知道該修正哪個步驟。

這就是拆解帶來的超能力。

## 第二部分：中級——建構真正有效的多 Agent 系統

## 6. 評估（區分專業人士與業餘愛好者的無聊工作）

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672550056-diaHJD2kMybMAAwDKjpg.jpg)

沒人想談論評估（Evals）。

但所有發布真實系統的人都在做。

你如何衡量你的 Agent 是否有效？

簡單任務 → 計算正確答案數量。客服機器人回答庫存問題正確嗎？是/否。

複雜任務 → 使用 LLM 作為裁判（LLM-as-judge）。讓第二個模型使用固定標準對輸出進行 1–5 分評分。這篇文章有強而有力的論點嗎？引用正確嗎？語氣對嗎？

你需要兩個層級的評估：

→ 元件層級 — 每個獨立步驟是否運作正常？（搜尋查詢夠精確嗎？批判是否提供了真實的回饋？）
→ 端到端層級 — 最終輸出是否良好？（這篇文章真的寫得好嗎？）

如果端到端失敗但元件評估通過 → 這是交接問題。如果特定元件失敗 → 該 Agent 需要改進。

從第一天就開始評估。不要等到有了「完美」的評估系統才開始。快速發布並進行迭代。

## 7. 記憶與知識

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672549232-iaHJD20oyaEAAH2Wtjpg.jpg)

這是兩個常被混淆的截然不同的概念。

**記憶（Memory）= 動態的。每次執行都會更新。**

→ 短期：Agent 在工作時寫筆記。其他 Agent 可以讀取這些筆記。
→ 長期：任務結束後，Agent 進行反思。什麼做得好？什麼沒做好？儲存經驗教訓。

下次執行 → 載入這些經驗教訓 → 應用它們。

這就是你如何在不進行微調（Fine-tuning）的情況下「訓練」Agent 的方式。提供回饋 → Agent 在每次執行後都會進步。

**知識（Knowledge）= 靜態的。預先載入。**

→ PDF、CSV、內部文件、資料庫存取
→ Agent 的參考圖書館
→ 給它一次。它會在需要準確答案時隨時提取。

這樣想：

記憶 = 你從經驗中學到的東西。知識 = 你可以參考的教科書。

兩者都很重要，且無法互相取代。

## 8. Guardrails

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672548370-iaHJD25jgasAADfRyjpg.jpg)

一個能運作的 Agent 不代表是一個安全的 Agent。

LLM 是非確定性的（Non-deterministic）。

它們可能會格式錯誤、陳述錯誤事實、偏離任務。

Guardrails 是「Agent 說它完成了」與「任務真正完成」之間的品質閘門。

三種類型：

類型 1 — 程式碼檢查（快速且便宜）
用於確定性事物。→ 輸出格式正確嗎？長度正確嗎？必要欄位都在嗎？寫一個簡單的驗證函式，立即執行。盡可能優先使用此方法。

類型 2 — LLM 裁判
用於細膩的品質檢查。→ 「此回應是否與來源文件事實一致？」→ 「語氣是否專業且正面？」如果裁判說不 → 解釋原因 → Agent 修改 → 再試一次。

類型 3 — 人類參與（Human in the loop）
用於高風險決策。Agent 在最終定案前停止，將輸出發送給人類審查。人類批准、拒絕或要求修改。

大多數生產系統至少會使用這三種中的兩種。

## 9. 提升每個 Agent 的 4 種設計模式

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672548137-diaHJD3YPb0AEFkojjpg.jpg)

這四種模式能可靠地讓 Agent 變得更好。

模式 1：反思（Reflection）
不要停在第一版草稿。
模型產生輸出 → 批判它 → 根據批判重寫。
Email v1：「嘿，下個月見。謝謝。」批判：日期模糊、沒有簽名、語氣太隨意。Email v2：「嗨 Alex，我們 1 月 5-7 日見面。告訴我哪個時間方便。祝好，Sai。」
這在程式碼中更強大——寫程式碼、執行、捕捉錯誤、回饋、模型修正。
適用於：結構化輸出、長篇寫作、程式碼、程序步驟。

模式 2：工具使用（Tool Use）
給 LLM 一份它可以呼叫的函式選單。
模型決定何時以及使用哪個工具。
網路搜尋、資料庫查詢、程式碼執行、行事曆、Email、API 呼叫。
LLM 單獨無法完成這些工作。工具是 Agent 與世界互動的方式。

模式 3：規劃（Planning）
與其使用固定的管線，不如讓 Agent 決定步驟。
給它工具箱，提示它制定計畫，然後逐步執行。
零售範例：「有 100 美元以下的圓形太陽眼鏡嗎？」Agent 規劃：搜尋描述 → 檢查庫存 → 按價格篩選 → 回答。
你沒有寫死這些步驟，是 Agent 自己選擇的。

模式 4：多 Agent 協作（Multi-Agent Collaboration）
將複雜工作分配給專業的 Agent。
研究員 → 設計師 → 寫手。
每個 Agent 都擅長其特定工作。輸出結果更好，因為沒有單一 Agent 試圖做完所有事。

## 10. 多 Agent 系統設計

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672548132-iaHJD3d1pbQAA96Qcjpg.jpg)

你該如何建構多 Agent 系統？

四種協調模式，從最簡單到最複雜。

模式 1：序列式（Sequential）
每個 Agent 完成後 → 將輸出傳遞給下一個 Agent。像裝配線一樣。研究員 → 設計師 → 寫手 → 完成。易於除錯，可預測。從這裡開始。

模式 2：平行式（Parallel）
同時執行獨立的 Agent。研究員 + 設計師同時工作，寫手整合他們的輸出。速度更快，但協調複雜度較高。

模式 3：經理層級（Manager Hierarchy）
一個經理 Agent 協調專家 Agent。經理規劃、委派、審查。專家向經理報告，而不是彼此報告。這是目前生產系統中最常見的模式。

模式 4：全對全（All-to-All）
任何 Agent 都可以傳訊息給任何其他 Agent。混亂且難以預測。僅適用於創意或低風險工作，且允許變異的情況。不要在生產環境中使用。

經驗法則：從序列式開始。只有在需要時才增加協調複雜度。

## 第三部分：生產環境——從原型到正式上線

## 11. 進階任務拆解

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672549012-iaHJD3i35a8AANPkmjpg.jpg)

在複雜的多 Agent 系統中，拆解方式至關重要。

4 種模式：

功能性（Functional）— 按技術領域拆分。前端 Agent、後端 Agent、資料庫 Agent。工程團隊的經典做法。

空間性（Spatial）— 按檔案或目錄結構拆分。Agent 1 處理 /services/users/，Agent 2 處理 /services/orders/。非常適合大型程式庫，能減少衝突。

時間性（Temporal）— 按順序階段拆分。階段 1：研究。階段 2：規劃。階段 3：建構。階段 4：發布。每個階段完成後才開始下一個。

資料驅動（Data-driven）— 按資料分區拆分。Agent 1 處理第一週日誌，Agent 2 處理第二週。對於大型資料集非常強大，可平行化分析。

你可以混合使用。

主結構使用功能性拆解 + 每個 Agent 內部使用時間性拆解。

使用任何符合你任務自然邊界的模式即可。

## 12. 在生產環境中提升品質

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672549716-diaHJD4RIaEAA2Yvojpg.jpg)

系統能運作但品質不夠好。

兩類元件，兩種不同的修正策略。

非 LLM 元件（網路搜尋、RAG、OCR、程式碼執行）：
→ 調整參數：搜尋日期範圍、Top-k 結果、區塊大小、相似度閾值
→ 更換供應商：嘗試不同的搜尋 API、視覺模型、解析器

LLM 元件（生成、推理、提取）：
→ 優化 Prompt：增加限制、範例、輸出 Schema
→ 嘗試不同的模型：有些模型擅長程式碼，有些擅長遵循指令
→ 將困難任務拆解得更細
→ 微調（最後手段，成本高，留給最後 1% 的提升）

順序很重要。

先修正 Prompt，再嘗試不同模型，進一步拆解，最後才考慮微調。

大多數團隊在第 2 步就能達到足夠的品質。

## 13. 延遲與成本

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672549139-iaHJD4anZa4AADL4Qjpg.jpg)

品質優先，然後才是速度與成本。

降低延遲：
1. 測量每個步驟，找出真正的瓶頸。
2. 平行化任何不依賴其他步驟的工作。
3. 模型規模適中化 — 簡單步驟用快速便宜的 LLM，推理用大型模型。
4. 嘗試更快的供應商 — token 串流速度差異很大。
5. 精簡 Context — 較短的 Prompt 解碼速度更快。

降低成本：
典型的研究 Agent 執行成本細分：
→ LLM 生成呼叫：~$0.04
→ 網路搜尋 API 呼叫：~$0.02
→ Embedding 呼叫：~$0.005
→ 基礎設施：~$0.015
→ 每次執行總計：~$0.08

每天 1,000 次執行 = 每天 80 美元 = 每月 2,400 美元。

如何削減：
→ 先攻擊成本佔比最大的部分
→ 分層使用模型 — 簡單任務用便宜的，困難任務用昂貴的
→ 強力快取結果（搜尋結果、Embedding、摘要）
→ 限制輸出（「回傳 JSON，最多 5 個欄位」）
→ 盡可能批次處理操作

## 14. 可觀測性：大規模監控你的 Agent

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672549034-iaHJD4fbwaUAAAfo6jpg.jpg)

傳統軟體：追蹤執行路徑。A 呼叫 B，B 呼叫資料庫，回傳結果。

AI Agent 不是這樣運作的。

它們是非確定性的，相同的輸入 → 不同的輸出。分散式執行，外部依賴可能失敗。

你需要兩種可視性：

**放大指標（單次執行除錯）**
→ 完整追蹤：每個 Prompt、每個工具呼叫、每個使用的 token
→ Agent 為什麼選擇這個工具？
→ 每個步驟回傳了什麼？
→ 到底在哪裡失敗了？

記錄的不是發生了什麼，而是為什麼：「Agent 選擇網路搜尋而不是 RAG，因為查詢包含『近期』」、「反思識別出 3 個問題：缺少引用、日期模糊、語氣錯誤」。

**縮小指標（跨多次執行的系統健康度）**
→ 品質分數趨勢
→ 幻覺率
→ 成功率
→ 變更是有幫助還是有害？

你無法手動檢查大規模下的每個追蹤。

使用品質抽樣 — 評估所有執行中的一定比例，建立趨勢線。

這就是你在使用者發現問題前，捕捉到系統退化的方式。

## 15. 安全性：沒人談論（但應該談論）的部分

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779672549871-diaHJD4kuuawAAJFXjpg.jpg)

AI Agent 的安全性與傳統應用程式安全性不同。

你不僅是在防禦外部攻擊者。

你還是在防禦你「自己的系統」做出危險的決策。

威脅：
→ Prompt 注入 — 使用者輸入中的惡意內容劫持了 Agent 的指令
→ 不安全的程式碼生成 — Agent 寫出的程式碼存取敏感資料或執行有害操作
→ 資料洩漏 — PII 或專有資訊透過輸出或工具呼叫外洩
→ 資源耗盡 — Agent 陷入無限循環或消耗昂貴的 API 額度

程式碼執行是最危險的功能。

如果你要啟用它，請務必安全地做：
→ 在 Docker 中進行沙盒處理，容器在每次執行後銷毀。
→ 設定嚴格的資源限制：逾時、記憶體上限、CPU 上限。
→ 只允許白名單中的安全函式庫。
→ 在輸入到達 Agent 前進行驗證。
→ 掃描所有輸出以防敏感資料（API 金鑰、PII）。
→ 使用確定性的 I/O — 程式碼回傳結構化 JSON，而非自由格式的文字給使用者。

大多數團隊都是在付出慘痛代價後才學到這些教訓。

在發布前請務必閱讀。

這就是完整課程。

## 重點回顧

**初學者：**
→ Agent 以迭代方式運作 — 規劃、行動、觀察、重複
→ 最適合處理 ~90% 準確度即可的複雜多步驟任務
→ 從半自主開始，不要一開始就全自主
→ Context Engineering 是真正的智慧所在
→ 任務拆解是最重要的 skill

**中級：**
→ 從第一天就開始評估 — 複雜任務使用 LLM-as-judge
→ 記憶（動態）≠ 知識（靜態）
→ 三種 Guardrails：程式碼檢查 → LLM 裁判 → 人類參與
→ 4 種必備模式：反思、工具使用、規劃、多 Agent
→ 從序列式開始，只有在需要時才增加協調複雜度

**生產環境：**
→ 4 種拆解模式：功能性、空間性、時間性、資料驅動
→ 先優化 Prompt 再考慮微調
→ 測量每個步驟的延遲與成本，先解決佔比最大的部分
→ 兩種可觀測模式：放大追蹤 + 縮小健康指標
→ 安全性 = 防禦你自己的系統，而不僅僅是攻擊者

---

大多數人開始建構 Agent。

但很少有人能發布在規模化下可靠運作的 Agent。

這之間的差距，就是這篇文章的全部精華。

---

如果這篇文章對你有幫助：

→ 轉發分享
→ 追蹤 @sairahul1 以獲取更多類似的深度解析
→ 收藏此文 — 你在開發時會需要參考它的

## 標籤

Agent, 教學資源, 自動化, AI Agents