1. 什麼是「Agentic 設計模式」？
Agentic 設計模式是一種可重複使用的高層次解法，用來應對打造智慧自主系統（也就是 Agent）時常遇到的問題。這些模式為設計 Agent 的行為提供一套結構化的框架，就像軟體設計模式對傳統程式設計所扮演的角色一樣。它們幫助開發者做出更穩健、更可預測、也更有效的 AI Agent。
2. 這本書的主要目標是什麼？
這本書的目標是提供一份實用、可動手做的入門指南，教你設計與打造 Agentic 系統。它不停留在理論探討，而是提供具體的架構藍圖，讓開發者能用來做出可靠地展現複雜、目標導向行為的 Agent。
3. 這本書寫給誰看？
這本書寫給正在用大型語言模型（LLM）與其他 AI 元件打造應用的 AI 開發者、軟體工程師與系統架構師。它適合那些想從簡單的「提示─回應」互動，跨足到打造複雜自主 Agent 的人。
4. 書中討論了哪些關鍵的 Agentic 模式？
根據目錄，這本書涵蓋幾種關鍵模式，包括：
- Reflection（反思）： Agent 能檢討自己的行動與輸出，藉此提升表現的能力。
- Planning（規劃）： 把一個複雜目標拆解成一個個較小、可處理的步驟或任務的過程。
- Tool Use（工具使用）： Agent 運用外部工具（例如程式碼直譯器、搜尋引擎或其他 API）來取得資訊、或執行自己做不到的動作的模式。
- Multi-Agent Collaboration（多 Agent 協作）： 讓多個各有專長的 Agent 一起解決問題的架構，通常會有一個「領導者」或「協調者」Agent。
- Human-in-the-Loop（人在迴圈中）： 把人的監督與介入整合進來，讓人能對 Agent 的行動給予回饋、修正與批准。
5. 為什麼「規劃」是很重要的模式
規劃之所以關鍵，是因為它讓 Agent 能處理那些無法靠單一動作解決的複雜多步驟任務。透過制定計畫，Agent 能維持一致的策略、追蹤自己的進度，並以有條理的方式處理錯誤或意外的阻礙。這能避免 Agent「卡住」或偏離使用者最終的目標。
6. 對 Agent 來說，「工具」和「技能」有什麼差別
這兩個詞經常被交替使用，但「工具（tool）」一般指的是 Agent 可以呼叫的外部資源（例如天氣 API、計算機）。「技能（skill）」則是 Agent 學會的、更整合的能力，通常會把工具使用和內部推理結合起來，去完成某個特定功能（例如「訂機票」這項技能，可能會用到行事曆和航空公司的 API）。
7. 「Reflection」模式如何提升 Agent 的表現
Reflection 是一種自我修正的機制。在產生回應或完成任務之後，可以引導 Agent 回頭檢視自己的成果、檢查錯誤、依據某些標準評估品質，或思考別的做法。這種反覆打磨的過程，能幫 Agent 產出更準確、更切題、品質更高的結果。
8. Reflection 模式的核心概念是什麼
Reflection 模式讓 Agent 能退一步、批判自己的成果。它不是一口氣產出最終結果，而是先寫出一份草稿，再對草稿「反思」，找出缺陷、缺漏的資訊或可以改進的地方。這個自我修正的過程，是提升回應品質與準確度的關鍵。
9. 為什麼單純的「提示鏈」不足以產出高品質的結果？
單純的提示鏈（Prompt Chaining，把一個 Prompt 的輸出當成下一個 Prompt 的輸入）往往太過陽春。模型可能只是把先前的輸出換句話說，並沒有真正改進它。真正的 Reflection 模式需要更有結構的批判，引導 Agent 依據特定標準分析自己的成果、檢查邏輯錯誤，或查證事實。
10. 本章提到的兩種主要反思類型是什麼？
本章討論兩種主要的反思形式：
- 「檢查你的成果」式反思： 這是最基本的形式，只是單純要求 Agent 檢視並修正它先前的輸出。用來抓出簡單的錯誤是個不錯的起點。
- 「內部評論者」式反思： 這是更進階的形式，用一個獨立的「評論者」Agent（或一段專門的 Prompt）來評估「工作者」Agent 的輸出。這個評論者可以被賦予特定的檢查標準，帶來更嚴謹、更有針對性的改進。
11. 反思如何幫助減少「幻覺」？
引導 Agent 檢視自己的成果，特別是把它的陳述拿去跟已知的來源比對、或檢查自己的推理步驟，Reflection 模式能大幅降低幻覺（憑空捏造事實）發生的機率。這麼做會迫使 Agent 更貼緊給定的上下文，比較不會生出沒有根據的資訊。
12. Reflection 模式可以套用不只一次嗎？
可以，反思本身就可以是個反覆的過程。可以讓 Agent 對自己的成果反思很多次，每一輪都把輸出再修得更好一點。這對複雜任務特別有用，因為第一次或第二次的成果可能還藏著細微的錯誤，或還有很大的改進空間。
13. 在 AI Agent 的脈絡下，Planning 模式是什麼？
Planning 模式是讓 Agent 能把一個複雜的高層次目標，拆解成一連串較小、可執行的步驟。Agent 不是一次就想解決一個大問題，而是先擬出一份「計畫」，再逐步執行計畫裡的每一步，這是可靠得多的做法。
14. 為什麼複雜任務需要規劃？
LLM 在處理需要多個步驟、或步驟之間有依賴關係的任務時，可能會力不從心。沒有計畫的話，Agent 可能會搞丟整體目標、漏掉關鍵步驟，或沒能把前一步的輸出當成下一步的輸入。計畫提供了一份清楚的路線圖，確保原始請求的所有要求都能按邏輯順序被滿足。
15. 實作 Planning 模式常見的做法是什麼？
一種常見的做法是先讓 Agent 用結構化的格式（例如 JSON 陣列或編號清單）產出一份步驟列表。系統接著逐一走過這份列表，一步一步執行，再把結果回饋給 Agent，好讓它決定下一個動作。
16. Agent 執行過程中如何處理錯誤或變化？
一個穩健的規劃模式允許動態調整。如果某一步失敗、或情況有變，可以引導 Agent 從當下的狀態「重新規劃」。它能分析錯誤、修改剩下的步驟，甚至新增步驟來克服障礙。
17. 使用者看得到計畫嗎？
這是一個設計上的選擇。很多情況下，先把計畫拿給使用者看、讓他批准，是很好的做法。這也呼應了「Human-in-the-Loop」模式，讓使用者在 Agent 提議的動作被執行前，對這些動作有透明度與掌控權。
18. 「Tool Use」模式包含什麼？
Tool Use 模式讓 Agent 能透過跟外部軟體或 API 互動，來擴充自己的能力。因為 LLM 的知識是靜態的、也沒辦法自己在真實世界裡採取行動，工具讓它得以取得即時資訊（例如 Google 搜尋）、專有資料（例如某家公司的資料庫），或執行動作（例如寄一封 email、訂一場會議）。
19. Agent 如何決定要用哪個工具？
通常會給 Agent 一份可用工具的清單，並附上每個工具的功能說明與所需參數。當它碰到光靠內部知識無法處理的請求時，Agent 的推理能力會讓它從清單裡挑出最合適的工具來完成任務。
20. 這裡提到的「ReAct」（Reason and Act，推理與行動）框架是什麼？
ReAct 是一個很受歡迎、把推理與行動整合在一起的框架。Agent 會依循一個循環：Thought（思考）（推理自己需要做什麼）、Action（行動）（決定用哪個工具、輸入什麼），以及 Observation（觀察）（看工具回傳的結果）。這個循環會一直進行，直到蒐集到足夠的資訊來滿足使用者的請求。
21. 實作工具使用有哪些挑戰？
主要的挑戰包括：
- 錯誤處理： 工具可能會失敗、回傳意料外的資料，或逾時。Agent 要能認出這些錯誤，並決定要重試、換一個工具，還是向使用者求助。
- 安全性： 讓 Agent 有權存取工具，尤其是那些會實際做出動作的工具，會帶來安全上的顧慮。針對敏感操作，設下防護措施、權限控管，以及往往少不了的人工批准，都很重要。
- 提示（Prompting）： 必須把 Agent 的 Prompt 設計得夠好，才能讓它產出格式正確的工具呼叫（例如正確的函式名稱與參數）。
22. 什麼是 Human-in-the-Loop（HITL）模式？
HITL 是一種把人的監督與互動整合進 Agent 工作流程的模式。Agent 不是完全自主運作，而是在關鍵節點暫停下來，尋求人的回饋、批准、澄清或指示。
23. 為什麼 HITL 對 Agentic 系統很重要？
有幾個關鍵原因：
- 安全與掌控： 對於高風險的任務（例如金融交易、發送正式的對外通訊），HITL 能確保有人在 Agent 提議的動作被執行前先做驗證。
- 提升品質： 人可以提供修正或細膩的回饋，讓 Agent 用來改善表現，在主觀或模稜兩可的任務上尤其如此。
- 建立信任： 對於一個能由自己引導與監督的 AI 系統，使用者比較願意信任並採用。
24. 工作流程中哪些環節該讓人介入？
常見的人為介入時機包括：
- 計畫批准： 在執行一份多步驟計畫之前。
- 工具使用確認： 在使用一個會造成真實後果、或會花錢的工具之前。
- 消解歧義： 當 Agent 不確定該怎麼繼續、或需要使用者提供更多資訊時。
- 最終輸出審查： 在把最終結果交給終端使用者或系統之前。
25. 一直讓人介入不是很沒效率嗎？
的確可能會，所以關鍵在於拿捏適當的平衡。HITL 應該部署在關鍵的檢查點，而不是每一個動作都要。目標是在人與 Agent 之間建立一種協作的夥伴關係，由 Agent 承擔大部分工作，人則提供策略層面的指引。
26. 什麼是 Multi-Agent Collaboration 模式？
這個模式是打造一個由多個各有專長的 Agent 組成的系統，讓它們一起達成共同目標。與其讓一個「通才」Agent 什麼都攬，不如組一支「專才」Agent 團隊，每個成員各有特定的角色或專長。
27. 多 Agent 系統有什麼好處？
- 模組化與專業分工： 每個 Agent 都能針對自己負責的任務做微調與 Prompt 設計（例如一個「研究員」Agent、一個「寫手」Agent、一個「程式」Agent），帶來更高品質的結果。
- 降低複雜度： 把複雜的工作流程拆成一個個專門的角色，讓整個系統更容易設計、除錯與維護。
- 模擬腦力激盪： 不同的 Agent 能對同一個問題提出不同觀點，激盪出更有創意也更穩健的解法，就像一支人類團隊那樣運作。
28. 多 Agent 系統常見的架構是什麼？
一種常見的架構會有一個 Orchestrator Agent（協調者 Agent）（有時稱為「管理者」或「指揮」）。協調者掌握整體目標，把它拆解開來，再把子任務分派給合適的專才 Agent。接著它收集各個專才的成果，整合成最終的輸出。
Agent 之間如何互相溝通？
溝通通常由協調者來管理。舉例來說，協調者可能會把「研究員」Agent 的輸出，當成上下文傳給「寫手」Agent。另一種常見的溝通方式，是設一個共享的「便條紙（scratchpad）」或訊息匯流排（message bus），讓各個 Agent 把自己的發現貼上去。
為什麼評估 Agent 比評估傳統軟體程式更難？
傳統軟體有確定性的輸出（同樣的輸入永遠得到同樣的輸出）。Agent，尤其是用 LLM 的那些，是非確定性的，而且它們的表現往往帶有主觀成分。要評估它們，得判斷輸出的品質與相關性，而不只是它在技術上是不是「正確」。
有哪些常見的方法可以評估 Agent 的表現？
書中提出幾種方法：
- 以結果為準的評估： Agent 有沒有成功達成最終目標？例如任務是「訂機票」，那到底有沒有正確訂到一張機票？這是最重要的衡量標準。
- 以過程為準的評估： Agent 的過程是否有效率、有邏輯？它有沒有用對工具？有沒有照著合理的計畫走？這有助於除錯，搞清楚 Agent 為什麼會出錯。
- 人工評估： 由人依據幫助程度、準確度、連貫性等標準，替 Agent 的表現打分數（例如 1 到 5 分）。這對直接面向使用者的應用非常關鍵。
什麼是「Agent 軌跡（agent trajectory）」？
Agent 軌跡是 Agent 執行任務時所有步驟的完整記錄，包含它全部的思考、行動（工具呼叫）與觀察。分析這些軌跡，是除錯與理解 Agent 行為的重要一環。
對一個非確定性的系統，要怎麼做出可靠的測試？
雖然你沒辦法保證 Agent 輸出的確切用字，但可以做一些檢查關鍵要素的測試。舉例來說，你可以寫一個測試，驗證 Agent 的最終回應有沒有包含某些特定資訊，或它有沒有用正確的參數成功呼叫某個工具。這通常是在一個專門的測試環境裡，用模擬工具（mock tool）來完成。
幫 Agent 寫 Prompt，跟寫一個簡單的 ChatGPT Prompt 有什麼不同？
幫 Agent 寫 Prompt，要打造一份詳細的「系統提示（system prompt）」或說一部運作章程，當作它的操作說明。這遠不只是單一句使用者的提問；它會界定 Agent 的角色、可用的工具、該遵循的模式（例如 ReAct 或 Planning）、它的限制，以及它的性格。
一個好的 Agent 系統提示，關鍵組成有哪些？
一份好的系統提示通常包含：
- 角色與目標： 清楚界定這個 Agent 是誰、它的主要目的是什麼。
- 工具定義： 一份可用工具的清單、它們的說明，以及使用方法（例如以特定的 function-calling 格式呈現）。
- 限制與規則： 明確指示 Agent 不該做什麼（例如「未經批准不得使用工具」、「不得提供金融建議」）。
- 流程指示： 指引它該用哪些模式。例如：「先制定計畫，再一步一步執行計畫。」
- 範例軌跡： 提供幾個成功的「思考─行動─觀察」循環範例，能大幅提升 Agent 的可靠度。
什麼是「提示洩漏（prompt leakage）」？
提示洩漏是指系統提示的某些部分（例如工具定義或內部指令），不小心出現在 Agent 給使用者的最終回應裡。這會讓使用者摸不著頭緒，也會暴露底層的實作細節。像是把推理用的 Prompt 和產生最終答案用的 Prompt 分開之類的技巧，有助於防止這種情況。
Agentic 系統未來有哪些趨勢？
書中指出未來會走向：
- 更自主的 Agent： 需要更少人為介入、能自行學習與調適的 Agent。
- 高度專門化的 Agent： 形成一個 Agent 生態系，可以針對特定任務去雇用或訂閱（例如旅遊 Agent、研究 Agent）。
- 更好的工具與平台： 開發出更精緻的框架與平台，讓打造、測試與部署穩健的多 Agent 系統變得更容易。