Agent輕松通-P1：什么是Agent？

歡迎來到啾啾的博客🐱。
記錄學習點滴。分享工作思考和實用技巧，偶爾也分享一些雜談💬。
有很多很多不足的地方，歡迎評論交流，感謝您的閱讀和評論😄。

1 引言
2 基礎概念
3 Agent的挑戰
- 3.1 復雜度帶來的“可控性”與“可靠性”的挑戰
- - 3.1.1 工具使用幻覺
- 3.2 ReAct循環帶來 “成本”與“狀態管理”的挑戰
- 3.3 “評估”與“錯誤處理”的挑戰
4 展望：超越ReAct
- 4.1 Plan-and-Execute Agents
- 4.2 Agentic Workflows with Graphs

1 引言

LLM應用開發的主要內容就是RAG與Agent。
在RAG輕松通系列中，我們已經了解了RAG基本流程與些許原理。
RAG的邏輯是固定的：檢索——>組裝提示——>生成。它只會“查資料”這一種行為。

而我們接下來要了解的Agent是動態的。它擁有一個“工具箱”，并且具備“思考”和“決策”的能力。面對一個任務，它會自己決定：

我應該使用哪個工具？ （例如：是上網搜索，還是計算數學題，還是查詢數據庫？）
我應該給這個工具輸入什么參數？
我拿到工具的輸出后，下一步該做什么？ （是繼續使用別的工具，還是已經可以得出最終答案了？）

下面，就讓我們一起來了解一下Agent。

2 基礎概念

Agent是一個能感知并自主地采取行動的實體，這里的自主性極其關鍵，Agent要能夠實現設定的目標，其中包括具備學習和獲取知識的能力以提高自身性能。
![[Agent入門-1.png]]

Agent核心思想：ReAct (Reason + Act)

在Agent中，LLM不再是一次性生成最終答案，而是在一個“思考-行動”的循環中工作:

Thought (思考): LLM首先會分析當前的任務和情況，然后生成一段“內心獨白”，說明它接下來的計劃。例如：“用戶想知道今天北京的天氣，我需要一個能查天氣的工具。”
Action (行動): 基于這個思考，LLM會決定調用一個具體的 工具 (Tool)，并確定該工具的 輸入 (Input)。例如：Tool: weather_api, Tool Input: “北京”。
Observation (觀察): 系統執行這個行動（即調用天氣API），然后將返回的結果（例如：“北京今天晴，25攝氏度”）作為“觀察結果”反饋給LLM。
Repeat (重復): LLM接收到這個觀察結果，然后再次進入“思考”階段。它可能會想：“我已經拿到了天氣信息，現在可以回答用戶了。”然后生成最終答案，結束循環。也可能它會想：“用戶還問了明天是否適合戶外活動，我還需要查詢明天的天氣預報。”然后開始一個新的“思考-行動-觀察”循環。

這個循環往復的過程，賦予了LLM規劃復雜任務和與外部世界互動的能力。

Q：目前的Agent是“真自主”還是“偽自主”？
A：Agent所有行為都源于其提示（Prompt）中的指令和工具描述。它的“自主性”更像是一種被精確引導的、在有限選項內的“決策能力”，而非人類意義上的自由意志。

3 Agent的挑戰

不同于RAG的挑戰主要在分塊與檢索相對單調。
Agent的ReAct明顯要復雜的多。

3.1 復雜度帶來的“可控性”與“可靠性”的挑戰

Agent的復雜度體現在“可控性”與“可靠性”：

可控性 (Controllability)
Q：如何引導它走在“正確的道路”上？
RAG的流程是線性的、確定的。而Agent的路徑是動態的、非確定的。它可能會選擇一條你意想不到的工具調用路徑，或者陷入一個無意義的循環（比如反復搜索同一個關鍵詞）。這是一個巨大的挑戰。
可靠性 (Reliability)
Q：如何用最少的ReAct步驟生成最準確的結果？
一個Agent可能會因為對工具的錯誤理解、對觀察結果的錯誤解讀，或者糟糕的推理鏈，而導致任務失敗。比如，它可能決定用“計算器”工具去回答“蘋果和橘子哪個好吃”的問題。

A：高質量的工具描述+引導（提示詞+計劃圖）。

精巧的提示工程： 在主提示中加入更強的約束和示例（Few-shot Prompting），向Agent展示“好的思考路徑”是什么樣的。
高質量的工具描述： 給工具起一個清晰的名字，并寫一段詳盡、無歧-義的描述，告訴Agent這個工具“能做什么”、“不能做什么”、“輸入應該是什么格式”。這是引導Agent正確選擇工具的最重要手段。
強制的路徑規劃： 對于一些關鍵任務，可以不讓Agent完全自由發揮，而是預先定義一個大致的“計劃圖”，Agent可以在這個框架內選擇工具，而不是天馬行空。

3.1.1 工具使用幻覺

在“可靠性”挑戰下，有一個非常具體且常見的問題，叫做 “工具使用幻覺” (Tool-use Hallucination)。
這指的是LLM“幻想”出了一個工具的執行結果，而不是真的去等待并使用工具的實際輸出。例如，它可能會在“Action”步驟后，不等“Observation”返回，就直接在下一步的“Thought”中編造一個觀察結果。這是導致Agent“脫軌”的重要原因之一，需要通過更強的提示約束和流程控制來解決。

3.2 ReAct循環帶來 “成本”與“狀態管理”的挑戰

在ReAct的每一次循環中，歷史的“思考-行動-觀察”記錄都會被加入到下一次的提示中，以維持Agent的“記憶”。這會導致上下文像滾雪球一樣越來越大。

成本 (Cost)
多次調用LLM，并且每次調用的上下文都在增長，會導致API費用急劇上升。
狀態管理 (State Management)
當上下文變得極長時，除了max_tokens的硬限制，還會遇到我們之前討論過的“中間迷失”問題。Agent可能會“忘記”它最初的目標或者早期的重要發現。

Q：循環中成本和狀態要怎么控制？
A：總結摘要+選擇記憶+限制循環次數

上下文摘要 (Context Summarization): 在幾次循環后，可以調用一次LLM，讓它將之前的對話歷史“總結”成一段簡短的文字，然后用這個摘要來代替冗長的歷史記錄。
選擇性記憶 (Selective Memory): 設計更復雜的記憶模塊，只保留與當前任務最相關的歷史記錄，而不是全部保留。
限制循環次數 (Max Iterations): 強制規定Agent最多只能進行N次循環，防止其陷入無限循環，同時也控制了成本上限。

這個總結摘要類似處理操作日志時保留數據的最終狀態。

除了“總結”，還有一種常見的記憶管理方式叫 “向量化記憶流” (Vectorized Memory Stream)。即，將每一步的“思考-行動-觀察”都向量化并存入一個臨時的向量數據庫，當上下文過長時，Agent可以“檢索”自己過去的記憶，找出與當前子任務最相關的歷史記錄來參考，而不是依賴一個線性的、易于遺忘的完整對話歷史。

3.3 “評估”與“錯誤處理”的挑戰

Agent的每一步都可能出錯，比如每次LLM生成的評估是9/10分，然后LLM再依據9/10的結果繼續循環。最后會產生類似“滑坡”的錯誤現象。給出一個看似合理但實際上完全錯誤的最終答案。
甚至過程中可能執行錯誤，以至于Agent的工具們難以解析LLM輸入，導致Agent崩潰。

應對方案思考：

健壯的工具封裝： 在代碼中，每個工具都應該被包裹在一個try…except塊中，捕獲所有可能的異常，并將錯誤信息作為“觀察結果”返回給Agent，讓它知道“這條路走不通，請換個思路”。
輸出解析器 (Output Parser): 使用專門的解析器來處理LLM的輸出。如果解析失敗，可以自動向LLM發送一條“你的輸出格式不對，請按此格式重試”的反饋，實現自動糾錯。
評估框架 (Evaluation Framework): 這是第二階段的另一個核心。我們將學習如何使用像LangSmith、RAGAs或自定義評估腳本這樣的工具，來量化評估Agent在特定任務上的成功率、效率和成本，用數據驅動的方式來發現和修復“結果滑坡”的問題。