第一章：初識智能體

歡迎來到智能體的世界！在人工智能浪潮席捲全球的今天，智能體（Agent）已成為驅動技術變革與應用創新的核心概念之一。無論你的志向是成為AI領域的研究者、工程師，還是希望深刻理解技術前沿的觀察者，掌握智能體的本質，都將是你知識體系中不可或缺的一環。

因此，在本章，讓我們回到原點，一起探討幾個問題：智能體是什麼？它有哪些主要的類型？它又是如何與我們所處的世界進行交互的？通過這些討論，希望能為你未來的學習和探索打下堅實的基礎。

圖 1.1 智能體與環境的基本交互循環

開源地址：

https://github.com/datawhalechina/Hello-Agents

1.1 什麼是智能體？

在探索任何一個複雜概念時，我們最好從一個簡潔的定義開始。在人工智能領域，智能體被定義為任何能夠通過傳感器（Sensors）感知其所處環境（Environment），並自主地通過執行器（Actuators）採取行動（Action）以達成特定目標的實體。

這個定義包含了智能體存在的四個基本要素。環境是智能體所處的外部世界。對於自動駕駛汽車，環境是動態變化的道路交通；對於一個交易算法，環境則是瞬息萬變的金融市場。智能體並非與環境隔離，它通過其傳感器持續地感知環境狀態。攝像頭、麥克風、雷達或各類應用程序編程接口（Application Programming Interface, API）返回的數據流，都是其感知能力的延伸。

獲取信息後，智能體需要採取行動來對環境施加影響，它通過執行器來改變環境的狀態。執行器可以是物理設備（如機械臂、方向盤）或虛擬工具（如執行一段代碼、調用一個服務）。

然而，真正賦予智能體"智能"的，是其自主性（Autonomy）。智能體並非只是被動響應外部刺激或嚴格執行預設指令的程序，它能夠基於其感知和內部狀態進行獨立決策，以達成其設計目標。這種從感知到行動的閉環，構成了所有智能體行為的基礎，如圖1.1所示。

1.1.1 傳統視角下的智能體

在當前大語言模型（Large Language Model, LLM）的熱潮出現之前，人工智能的先驅們已經對“智能體”這一概念進行了數十年的探索與構建。這些如今我們稱之為“傳統智能體”的範式，並非單一的靜態概念，而是經歷了一條從簡單到複雜、從被動反應到主動學習的清晰演進路線。

這個演進的起點，是那些結構最簡單的反射智能體（Simple Reflex Agent）。它們的決策核心由工程師明確設計的“條件-動作”規則構成，如圖1.2所示。經典的自動恆温器便是如此：若傳感器感知的室温高於設定值，則啓動製冷系統。

這種智能體完全依賴於當前的感知輸入，不具備記憶或預測能力。它像一種數字化的本能，可靠且高效，但也因此無法應對需要理解上下文的複雜任務。它的侷限性引出了一個關鍵問題：如果環境的當前狀態不足以作為決策的全部依據，智能體該怎麼辦？

圖 1.2 簡單反射智能體的決策邏輯示意圖

為了回答這個問題，研究者們引入了“狀態”的概念，發展出基於模型的反射智能體（Model-Based Reflex Agent）。這類智能體擁有一個內部的世界模型（World Model），用於追蹤和理解環境中那些無法被直接感知的方面。它試圖回答：“世界現在是什麼樣子的？”。例如，一輛在隧道中行駛的自動駕駛汽車，即便攝像頭暫時無法感知到前方的車輛，它的內部模型依然會維持對那輛車存在、速度和預估位置的判斷。這個內部模型讓智能體擁有了初級的“記憶”，使其決策不再僅僅依賴於瞬時感知，而是基於一個更連貫、更完整的世界狀態理解。

然而，僅僅理解世界還不夠，智能體需要有明確的目標。這促進了基於目標的智能體（Goal-Based Agent）的發展。與前兩者不同，它的行為不再是被動地對環境做出反應，而是主動地、有預見性地選擇能夠導向某個特定未來狀態的行動。這類智能體需要回答的問題是：“我應該做什麼才能達成目標？”。經典的例子是GPS導航系統：你的目標是到達公司，智能體會基於地圖數據（世界模型），通過搜索算法（如A*算法）來規劃（Planning）出一條最優路徑。這類智能體的核心能力體現在了對未來的考量與規劃上。

更進一步，現實世界的目標往往不是單一的。我們不僅希望到達公司，還希望時間最短、路程最省油並且避開擁堵。當多個目標需要權衡時，基於效用的智能體（Utility-Based Agent）便隨之出現。它為每一個可能的世界狀態都賦予一個效用值，這個值代表了滿意度的高低。智能體的核心目標不再是簡單地達成某個特定狀態，而是最大化期望效用。它需要回答一個更復雜的問題：“哪種行為能為我帶來最滿意的結果？”。這種架構讓智能體學會在相互衝突的目標之間進行權衡，使其決策更接近人類的理性選擇。

至此，我們討論的智能體雖然功能日益複雜，但其核心決策邏輯，無論是規則、模型還是效用函數，依然依賴於人類設計師的先驗知識。如果智能體能不依賴預設，而是通過與環境的互動自主學習呢？

這便是學習型智能體（Learning Agent）的核心思想，而強化學習（Reinforcement Learning, RL）是實現這一思想最具代表性的路徑。一個學習型智能體包含一個性能元件（即我們前面討論的各類智能體）和一個學習元件。學習元件通過觀察性能元件在環境中的行動所帶來的結果來不斷修正性能元件的決策策略。

想象一個學習下棋的AI。它開始時可能只是隨機落子，當它最終贏下一局時，系統會給予它一個正向的獎勵。通過大量的自我對弈，學習元件會逐漸發現哪些棋路更有可能導向最終的勝利。AlphaGo是這一理念的一個里程碑式的成就。它在圍棋這一複雜博弈中，通過強化學習發現了許多超越人類既有知識的有效策略。

從簡單的恆温器，到擁有內部模型的汽車，再到能夠規劃路線的導航、懂得權衡利弊的決策者，最終到可以通過經驗自我進化的學習者。這條演進之路，展示了傳統人工智能在構建機器智能的道路上所經歷的發展脈絡。它們為我們今天理解更前沿的智能體範式，打下了堅實而必要的基礎。

1.1.2 大語言模型驅動的新範式

以GPT（Generative Pre-trained Transformer）為代表的大語言模型的出現，正在顯著改變智能體的構建方法與能力邊界。由大語言模型驅動的LLM智能體，其核心決策機制與傳統智能體存在本質區別，從而賦予了其一系列全新的特性。

這種轉變，可以從兩者在核心引擎、知識來源、交互方式等多個維度的對比中清晰地看出，如表1.1所示。簡而言之，傳統智能體的能力源於工程師的顯式編程與知識構建，其行為模式是確定且有邊界的；而LLM智能體則通過在海量數據上的預訓練，獲得了隱式的世界模型與強大的涌現能力，使其能夠以更靈活、更通用的方式應對複雜任務。

表 1.1 傳統智能體與LLM驅動智能體的核心對比

這種差異使得LLM智能體可以直接處理高層級、模糊且充滿上下文信息的自然語言指令。讓我們以一個“智能旅行助手”為例來説明。

在LLM智能體出現之前，規劃旅行通常意味着用户需要在多個專用應用（如天氣、地圖、預訂網站）之間手動切換，並由用户自己扮演信息整合與決策的角色。而一個LLM智能體則能將這個流程整合起來。當接收到“規劃一次廈門之旅”這樣的模糊指令時，它的工作方式體現了以下幾點：

• 規劃與推理：智能體首先會將這個高層級目標分解為一系列邏輯子任務，例如：[確認出行偏好] -> [查詢目的地信息] -> [制定行程草案] -> [預訂票務住宿]。這是一個內在的、由模型驅動的規劃過程。
• 工具使用：在執行規劃時，智能體識別到信息缺口，會主動調用外部工具來補全。例如，它會調用天氣查詢接口獲取實時天氣，並基於“預報有雨”這一信息，在後續規劃中傾向於推薦室內活動。
• 動態修正：在交互過程中，智能體會將用户的反饋（如“這家酒店超出預算”）視為新的約束，並據此調整後續的行動，重新搜索並推薦符合新要求的選項。整個“查天氣 → 調行程 → 訂酒店”的流程，展現了其根據上下文動態修正自身行為的能力。

總而言之，我們正從開發專用自動化工具轉向構建能自主解決問題的系統。核心不再是編寫代碼，而是引導一個通用的“大腦”去規劃、行動和學習。

1.1.3 智能體的類型

繼上文回顧智能體的演進後，本節將從三個互補的維度對智能體進行分類。

1）基於內部決策架構的分類

第一種分類維度是依據智能體內部決策架構的複雜程度，這個視角在《Artificial Intelligence: A Modern Approach》中系統性地提出^[1]。正如 1.1.1 節所述，傳統智能體的演進路徑本身就構成了最經典的分類階梯，它涵蓋了從簡單的反應式智能體，到引入內部模型的模型式智能體，再到更具前瞻性的基於目標和基於效用的智能體。此外，學習能力則是一種可賦予上述所有類型的元能力，使其能通過經驗自我改進。

2）基於時間與反應性的分類

除了內部架構的複雜性，還可以從智能體處理決策的時間維度進行分類。這個視角關注智能體是在接收到信息後立即行動，還是會經過深思熟慮的規劃再行動。這揭示了智能體設計中一個核心權衡：追求速度的反應性（Reactivity）與追求最優解的規劃性（Deliberation）之間的平衡，如圖1.3所示。

圖 1.3 智能體決策時間與質量關係圖

• 反應式智能體 (Reactive Agents)

這類智能體對環境刺激做出近乎即時的響應，決策延遲極低。它們通常遵循從感知到行動的直接映射，不進行或只進行極少的未來規劃。上文的簡單反應式和基於模型的智能體都屬於此類別。

其核心優勢在於速度快、計算開銷低，這在需要快速決策的動態環境中至關重要。例如，車輛的安全氣囊系統必須在碰撞發生的毫秒內做出反應，任何延遲都可能導致嚴重後果；同樣，高頻交易機器人也必須依賴反應式決策來捕捉稍縱即逝的市場機會。然而，這種速度的代價是“短視”，由於缺乏長遠規劃，反應式智能體容易陷入局部最優，難以完成需要多步驟協調的複雜任務。

• 規劃式智能體(Deliberative Agents)

與反應式智能體相對，規劃式（或稱審議式）智能體在行動前會進行復雜的思考和規劃。它們不會立即對感知做出反應，而是會先利用其內部的世界模型，系統地探索未來的各種可能性，評估不同行動序列的後果，以期找到一條能夠達成目標的最佳路徑 。基於目標和基於效用的智能體是典型的規劃式智能體。

可以將其決策過程類比為一位棋手。他不會只看眼前的一步，而是會預想對手可能的應對，並規劃出後續幾步甚至十幾步的棋路。這種深思熟慮的能力使其能夠處理複雜的、需要長遠眼光的任務，例如制定一份商業計劃或規劃一次長途旅行。它們的優勢在於決策的戰略性和遠見。然而，這種優勢的另一面是高昂的時間和計算成本。在瞬息萬變的環境中，當規劃式智能體還在深思熟慮時，採取行動的最佳時機可能早已過去。

• 混合式智能體(Hybrid Agents)

現實世界的複雜任務，往往既需要即時反應，也需要長遠規劃。例如，我們之前提到的智能旅行助手，既要能根據用户的即時反饋（如“這家酒店太貴了”）調整推薦（反應性），又要能規劃出為期數天的完整旅行方案（規劃性）。因此，混合式智能體應運而生，它旨在結合兩者的優點，實現反應與規劃的平衡。

一種經典的混合架構是分層設計：底層是一個快速的反應模塊，處理緊急情況和基本動作；高層則是一個審慎的規劃模塊，負責制定長遠目標。而現代的LLM智能體，則展現了一種更靈活的混合模式。它們通常在一個“思考-行動-觀察”的循環中運作，巧妙地將兩種模式融為一體：

• 規劃(Reasoning) ：在“思考”階段，LLM分析當前狀況，規劃出下一步的合理行動。這是一個審議過程。
• 反應(Acting & Observing) ：在“行動”和“觀察”階段，智能體與外部工具或環境交互，並立即獲得反饋。這是一個反應過程。

通過這種方式，智能體將一個需要長遠規劃的宏大任務，分解為一系列“規劃-反應”的微循環。這使其既能靈活應對環境的即時變化，又能通過連貫的步驟，最終完成複雜的長期目標。

3）基於知識表示的分類

這是一個更根本的分類維度，它探究智能體用以決策的知識，究竟是以何種形式存於其“思想”之中。這個問題是人工智能領域一場持續半個多世紀的辯論核心，並塑造了兩種截然不同的AI文化。

• 符號主義AI（Symbolic AI）

符號主義，常被稱為傳統人工智能，其核心信念是：智能源於對符號的邏輯操作。這裏的符號是人類可讀的實體（如詞語、概念），操作則遵循嚴格的邏輯規則，如圖1.4左側所示。這好比一位一絲不苟的圖書管理員，將世界知識整理為清晰的規則庫和知識圖譜。

其主要優勢在於透明和可解釋。由於推理步驟明確，其決策過程可以被完整追溯，這在金融、醫療等高風險領域至關重要。然而，其“阿喀琉斯之踵”在於脆弱性：它依賴於一個完備的規則體系，但在充滿模糊和例外的現實世界中，任何未被覆蓋的新情況都可能導致系統失靈，這就是所謂的“知識獲取瓶頸”。

• 亞符號主義AI（Sub-symbolic AI）

亞符號主義，或稱連接主義，則提供了一幅截然不同的圖景。在這裏，知識並非顯式的規則，而是內隱地分佈在一個由大量神經元組成的複雜網絡中，是從海量數據中學習到的統計模式。神經網絡和深度學習是其代表。

如圖1.4中間所示，如果説符號主義AI是圖書管理員，那麼亞符號主義AI就像一個牙牙學語的孩童 。他不是通過學習“貓有四條腿、毛茸茸、會喵喵叫”這樣的規則來認識貓的，而是在看過成千上萬張貓的圖片後，大腦中的神經網絡能辨識出“貓”這個概念的視覺模式 。這種方法的強大之處在於其模式識別能力和對噪聲數據的魯棒性 。它能夠輕鬆處理圖像、聲音等非結構化數據，這在符號主義AI看來是極其困難的任務。

然而，這種強大的直覺能力也伴隨着不透明性。亞符號主義系統通常被視為一個黑箱（Black Box）。它能以驚人的準確率識別出圖片中的貓，但你若問它“為什麼你認為這是貓？”，它很可能無法給出一個合乎邏輯的解釋。此外，它在純粹的邏輯推理任務上表現不佳，有時會產生看似合理卻事實錯誤的幻覺。

• 神經符號主義AI（Neuro-Symbolic AI）

長久以來，符號主義和亞符號主義這兩大陣營如同兩條平行線，各自發展。為克服上述兩種範式的侷限，一種“大和解”的思想開始興起，這就是神經符號主義AI，也稱神經符號混合主義。它的目標，是融合兩大範式的優點，創造出一個既能像神經網絡一樣從數據中學習，又能像符號系統一樣進行邏輯推理的混合智能體。它試圖彌合感知與認知、直覺與理性之間的鴻溝。諾貝爾經濟學獎得主丹尼爾·卡尼曼（Daniel Kahneman）在其著作《思考，快與慢》（Thinking, Fast and Slow）中提出的雙系統理論，為我們理解神經符號主義提供了一個絕佳的類比^[2]，如圖1.4所示：

• 系統1是快速、憑直覺、並行的思維模式，類似於亞符號主義AI強大的模式識別能力。
• 系統2是緩慢、有條理、基於邏輯的審慎思維，恰如符號主義AI的推理過程。

圖 1.4 符號主義、亞符號主義與神經符號混合主義的知識表示範式

人類的智能，正源於這兩個系統的協同工作。同樣，一個真正魯棒的AI，也需要兼具二者之長。大語言模型驅動的智能體是神經符號主義的一個極佳實踐範例。其內核是一個巨大的神經網絡，使其具備模式識別和語言生成能力。然而，當它工作時，它會生成一系列結構化的中間步驟，如思想、計劃或API調用，這些都是明確的、可操作的符號。通過這種方式，它實現了感知與認知、直覺與理性的初步融合。

1.2 智能體的構成與運行原理

1.2.1 任務環境定義

要理解智能體的運作，我們必須先理解它所處的任務環境。在人工智能領域，通常使用PEAS模型來精確描述一個任務環境，即分析其性能度量(Performance)、環境(Environment)、執行器(Actuators)和傳感器(Sensors) 。以上文提到的智能旅行助手為例，下表1.2展示瞭如何運用PEAS模型對其任務環境進行規約。

表 1.2 智能旅行助手的PEAS描述

在實踐中，LLM智能體所處的數字環境展現出若干複雜特性，這些特性直接影響着智能體的設計。

首先，環境通常是部分可觀察的。例如，旅行助手在查詢航班時，無法一次性獲取所有航空公司的全部實時座位信息。它只能通過調用航班預訂API，看到該API返回的部分數據，這就要求智能體必須具備記憶（記住已查詢過的航線）和探索（嘗試不同的查詢日期）的能力。

其次，行動的結果也並非總是確定的。根據結果的可預測性，環境可分為確定性和隨機性。旅行助手的任務環境就是典型的隨機性環境。當它搜索票價時，兩次相鄰的調用返回的機票價格和餘票數量都可能不同，這就要求智能體必須具備處理不確定性、監控變化並及時決策的能力。

此外，環境中還可能存在其他行動者，從而形成多智能體(Multi-agent) 環境。對於旅行助手而言，其他用户的預訂行為、其他自動化腳本，甚至航司的動態調價系統，都是環境中的其他“智能體”。它們的行動（例如，訂走最後一張特價票）會直接改變旅行助手所處環境的狀態，這對智能體的快速響應和策略選擇提出了更高要求。

最後，幾乎所有任務都發生在序貫且動態的環境中。“序貫”意味着當前動作會影響未來；而“動態”則意味着環境自身可能在智能體決策時發生變化。這就要求智能體的“感知-思考-行動-觀察”循環必須能夠快速、靈活地適應持續變化的世界。

1.2.2 智能體的運行機制

在定義了智能體所處的任務環境後，我們來探討其核心的運行機制。智能體並非一次性完成任務，而是通過一個持續的循環與環境進行交互，這個核心機制被稱為 智能體循環 (Agent Loop)。如圖1.5所示，該循環描述了智能體與環境之間的動態交互過程，構成了其自主行為的基礎。

圖 1.5 智能體與環境交互的基本循環

這個循環主要包含以下幾個相互關聯的階段：

1. 感知 (Perception)：這是循環的起點。智能體通過其傳感器（例如，API的監聽端口、用户輸入接口）接收來自環境的輸入信息。這些信息，即觀察 (Observation)，既可以是用户的初始指令，也可以是上一步行動所導致的環境狀態變化反饋。
2. 思考 (Thought)：接收到觀察信息後，智能體進入其核心決策階段。對於LLM智能體而言，這通常是由大語言模型驅動的內部推理過程。如圖所示，“思考”階段可進一步細分為兩個關鍵環節：

• 規劃 (Planning)：智能體基於當前的觀察和其內部記憶，更新對任務和環境的理解，並制定或調整一個行動計劃。這可能涉及將複雜目標分解為一系列更具體的子任務。
• 工具選擇 (Tool Selection)：根據當前計劃，智能體從其可用的工具庫中，選擇最適合執行下一步驟的工具，並確定調用該工具所需的具體參數。

3. 行動 (Action)：決策完成後，智能體通過其執行器（Actuators）執行具體的行動。這通常表現為調用一個選定的工具（如代碼解釋器、搜索引擎API），從而對環境施加影響，意圖改變環境的狀態。

行動並非循環的終點。智能體的行動會引起環境 (Environment) 的狀態變化 (State Change)，環境隨即會產生一個新的觀察 (Observation) 作為結果反饋。這個新的觀察又會在下一輪循環中被智能體的感知系統捕獲，形成一個持續的“感知-思考-行動-觀察”的閉環。智能體正是通過不斷重複這一循環，逐步推進任務，從初始狀態向目標狀態演進。

1.2.3 智能體的感知與行動

在工程實踐中，為了讓LLM能夠有效驅動這個循環，我們需要一套明確的交互協議 (Interaction Protocol) 來規範其與環境之間的信息交換。

在許多現代智能體框架中，這一協議體現在對智能體每一次輸出的結構化定義上。智能體的輸出不再是單一的自然語言回覆，而是一段遵循特定格式的文本，其中明確地展示了其內部的推理過程與最終決策。

這個結構通常包含兩個核心部分：

• Thought (思考)：這是智能體內部決策的“快照”。它以自然語言形式闡述了智能體如何分析當前情境、回顧上一步的觀察結果、進行自我反思與問題分解，並最終規劃出下一步的具體行動。
• Action (行動)：這是智能體基於思考後，決定對環境施加的具體操作，通常以函數調用的形式表示。

例如，一個正在規劃旅行的智能體可能會生成如下格式化的輸出：

Thought: 用户想知道北京的天氣。我需要調用天氣查詢工具。
Action: get_weather("北京")

這裏的Action字段構成了對外部世界的指令。一個外部的解析器 (Parser) 會捕捉到這個指令，並調用相應的get_weather函數。

行動執行後，環境會返回一個結果。例如，get_weather函數可能返回一個包含詳細天氣數據的JSON對象。然而，原始的機器可讀數據（如JSON）通常包含LLM無需關注的冗餘信息，且格式不符合其自然語言處理的習慣。

因此，感知系統的一個重要職責就是扮演傳感器的角色：將這個原始輸出處理並封裝成一段簡潔、清晰的自然語言文本，即觀察。

Observation: 北京當前天氣為晴，氣温25攝氏度，微風。

這段Observation文本會被反饋給智能體，作為下一輪循環的主要輸入信息，供其進行新一輪的Thought和Action。

綜上所述，通過這個由Thought、Action、Observation構成的嚴謹循環，LLM智能體得以將內部的語言推理能力，與外部環境的真實信息和工具操作能力有效地結合起來。

1.3 動手體驗：5 分鐘實現第一個智能體

在前面的小節，我們學習了智能體的任務環境、核心運行機制以及Thought-Action-Observation交互範式。理論知識固然重要，但最好的學習方式是親手實踐。在本節中，我們將引導您使用幾行簡單的Python代碼，從零開始構建一個可以工作的智能旅行助手。這個過程將遵循我們剛剛學到的理論循環，讓您直觀地感受到一個智能體是如何“思考”並與外部“工具”互動的。讓我們開始吧！

在本案例中，我們的目標是構建一個能處理分步任務的智能旅行助手。需要解決的用户任務定義為："你好，請幫我查詢一下今天北京的天氣，然後根據天氣推薦一個合適的旅遊景點。"要完成這個任務，智能體必須展現出清晰的邏輯規劃能力。它需要先調用天氣查詢工具，並將獲得的觀察結果作為下一步的依據。在下一輪循環中，它再調用景點推薦工具，從而得出最終建議。

1.3.1 準備工作

為了能從Python程序中訪問網絡API，我們需要一個HTTP庫。requests是Python社區中最流行、最易用的選擇。tavily-python是一個強大的AI搜索API客户端，用於獲取實時的網絡搜索結果，可以在官網註冊後獲取API。openai是OpenAI官方提供的Python SDK，用於調用GPT等大語言模型服務。請先通過以下命令安裝它們：

pip install requests tavily-python openai

1）指令模板

驅動真實LLM的關鍵在於提示工程（Prompt Engineering）。我們需要設計一個“指令模板”，告訴LLM它應該扮演什麼角色、擁有哪些工具、以及如何格式化它的思考和行動。這是我們智能體的“説明書”，它將作為system_prompt傳遞給LLM。

AGENT_SYSTEM_PROMPT = """
你是一個智能旅行助手。你的任務是分析用户的請求，並使用可用工具一步步地解決問題。

# 可用工具:
- `get_weather(city: str)`: 查詢指定城市的實時天氣。
- `get_attraction(city: str, weather: str)`: 根據城市和天氣搜索推薦的旅遊景點。

# 行動格式:
你的回答必須嚴格遵循以下格式。首先是你的思考過程，然後是你要執行的具體行動。
Thought: [這裏是你的思考過程和下一步計劃]
Action: [這裏是你要調用的工具，格式為 function_name(arg_name="arg_value")]

# 任務完成:
當你收集到足夠的信息，能夠回答用户的最終問題時，你必須使用 `finish(answer="...")` 來輸出最終答案。

請開始吧！
"""

2）工具1：查詢真實天氣

我們將使用免費的天氣查詢服務wttr.in，它能以JSON格式返回指定城市的天氣數據。下面是實現該工具的代碼：

import requests
import json

defget_weather(city: str) -> str:
    """
    通過調用 wttr.in API 查詢真實的天氣信息。
    """
    # API端點，我們請求JSON格式的數據
    url = f"https://wttr.in/{city}?format=j1"
    
    try:
        # 發起網絡請求
        response = requests.get(url)
        # 檢查響應狀態碼是否為200 (成功)
        response.raise_for_status() 
        # 解析返回的JSON數據
        data = response.json()
        
        # 提取當前天氣狀況
        current_condition = data['current_condition'][0]
        weather_desc = current_condition['weatherDesc'][0]['value']
        temp_c = current_condition['temp_C']
        
        # 格式化成自然語言返回
        returnf"{city}當前天氣：{weather_desc}，氣温{temp_c}攝氏度"
        
    except requests.exceptions.RequestException as e:
        # 處理網絡錯誤
        returnf"錯誤：查詢天氣時遇到網絡問題 - {e}"
    except (KeyError, IndexError) as e:
        # 處理數據解析錯誤
        returnf"錯誤：解析天氣數據失敗，可能是城市名稱無效 - {e}"

3）工具2：搜索並推薦旅遊景點

我們將定義一個新工具search_attraction，它會根據城市和天氣狀況，互聯網上搜索合適的景點：

import os
from tavily import TavilyClient

defget_attraction(city: str, weather: str) -> str:
    """
    根據城市和天氣，使用Tavily Search API搜索並返回優化後的景點推薦。
    """
    # 1. 從環境變量中讀取API密鑰
    api_key = os.environ.get("TAVILY_API_KEY")
    ifnot api_key:
        return"錯誤：未配置TAVILY_API_KEY環境變量。"

    # 2. 初始化Tavily客户端
    tavily = TavilyClient(api_key=api_key)
    
    # 3. 構造一個精確的查詢
    query = f"'{city}' 在'{weather}'天氣下最值得去的旅遊景點推薦及理由"
    
    try:
        # 4. 調用API，include_answer=True會返回一個綜合性的回答
        response = tavily.search(query=query, search_depth="basic", include_answer=True)
        
        # 5. Tavily返回的結果已經非常乾淨，可以直接使用
        # response['answer'] 是一個基於所有搜索結果的總結性回答
        if response.get("answer"):
            return response["answer"]
        
        # 如果沒有綜合性回答，則格式化原始結果
        formatted_results = []
        for result in response.get("results", []):
            formatted_results.append(f"- {result['title']}: {result['content']}")
        
        ifnot formatted_results:
             return"抱歉，沒有找到相關的旅遊景點推薦。"

        return"根據搜索，為您找到以下信息：\n" + "\n".join(formatted_results)

    except Exception as e:
        returnf"錯誤：執行Tavily搜索時出現問題 - {e}"

最後，我們將所有工具函數放入一個字典，供主循環調用：

# 將所有工具函數放入一個字典，方便後續調用
available_tools = {
    "get_weather": get_weather,
    "get_attraction": get_attraction,
}

1.3.2 接入大語言模型

當前，許多LLM服務提供商（包括OpenAI、Azure、以及眾多開源模型服務框架如Ollama、vLLM等）都遵循了與OpenAI API相似的接口規範。這種標準化為開發者帶來了極大的便利。智能體的自主決策能力來源於LLM。我們將實現一個通用的客户端OpenAICompatibleClient，它可以連接到任何兼容OpenAI接口規範的LLM服務。

from openai import OpenAI

classOpenAICompatibleClient:
    """
    一個用於調用任何兼容OpenAI接口的LLM服務的客户端。
    """
    def__init__(self, model: str, api_key: str, base_url: str):
        self.model = model
        self.client = OpenAI(api_key=api_key, base_url=base_url)

    defgenerate(self, prompt: str, system_prompt: str) -> str:
        """調用LLM API來生成迴應。"""
        print("正在調用大語言模型...")
        try:
            messages = [
                {'role': 'system', 'content': system_prompt},
                {'role': 'user', 'content': prompt}
            ]
            response = self.client.chat.completions.create(
                model=self.model,
                messages=messages,
                stream=False
            )
            answer = response.choices[0].message.content
            print("大語言模型響應成功。")
            return answer
        except Exception as e:
            print(f"調用LLM API時發生錯誤: {e}")
            return"錯誤：調用語言模型服務時出錯。"

要實例化此類，您需要提供三個信息：API_KEY、BASE_URL和 MODEL_ID，具體值取決於您使用的服務商（如OpenAI官方、Azure、或Ollama等本地模型），如果暫時沒有渠道獲取，可以參考Datawhale另一本教程的1.2 API設置。

1.3.3 執行行動循環

下面的主循環將整合所有組件，並通過格式化後的Prompt驅動LLM進行決策。

import re

# --- 1. 配置LLM客户端 ---
# 請根據您使用的服務，將這裏替換成對應的憑證和地址
API_KEY = "YOUR_API_KEY"
BASE_URL = "YOUR_BASE_URL"
MODEL_ID = "YOUR_MODEL_ID"
TAVILY_API_KEY="YOUR_Tavily_KEY"
os.environ['TAVILY_API_KEY'] = "YOUR_TAVILY_API_KEY"

llm = OpenAICompatibleClient(
    model=MODEL_ID,
    api_key=API_KEY,
    base_url=BASE_URL
)

# --- 2. 初始化 ---
user_prompt = "你好，請幫我查詢一下今天北京的天氣，然後根據天氣推薦一個合適的旅遊景點。"
prompt_history = [f"用户請求: {user_prompt}"]

print(f"用户輸入: {user_prompt}\n" + "="*40)

# --- 3. 運行主循環 ---
for i in range(5): # 設置最大循環次數
    print(f"--- 循環 {i+1} ---\n")
    
    # 3.1. 構建Prompt
    full_prompt = "\n".join(prompt_history)
    
    # 3.2. 調用LLM進行思考
    llm_output = llm.generate(full_prompt, system_prompt=AGENT_SYSTEM_PROMPT)
    print(f"模型輸出:\n{llm_output}\n")
    prompt_history.append(llm_output)
    
    # 3.3. 解析並執行行動
    action_match = re.search(r"Action: (.*)", llm_output, re.DOTALL)
    ifnot action_match:
        print("解析錯誤：模型輸出中未找到 Action。")
        break
    action_str = action_match.group(1).strip()

    if action_str.startswith("finish"):
        final_answer = re.search(r'finish\(answer="(.*)"\)', action_str).group(1)
        print(f"任務完成，最終答案: {final_answer}")
        break
    
    tool_name = re.search(r"(\w+)\(", action_str).group(1)
    args_str = re.search(r"\((.*)\)", action_str).group(1)
    kwargs = dict(re.findall(r'(\w+)="([^"]*)"', args_str))

    if tool_name in available_tools:
        observation = available_tools[tool_name](**kwargs)
    else:
        observation = f"錯誤：未定義的工具 '{tool_name}'"

    # 3.4. 記錄觀察結果
    observation_str = f"Observation: {observation}"
    print(f"{observation_str}\n" + "="*40)
    prompt_history.append(observation_str)

通過以上步驟，我們構建了一個完整的、由真實LLM驅動的智能體。其核心在於“工具”和“提示工程”的結合，這正是當前主流智能體框架（如LangChain、LlamaIndex等）的設計精髓。

1.3.4 運行案例分析

以下輸出完整地展示了一個成功的智能體執行流程。通過對這個三輪循環的分析，我們可以清晰地看到智能體解決問題的核心能力。

用户輸入: 你好，請幫我查詢一下今天北京的天氣，然後根據天氣推薦一個合適的旅遊景點。
========================================
--- 循環 1 ---

正在調用大語言模型...
大語言模型響應成功。
模型輸出:
Thought: 首先需要獲取北京今天的天氣情況，之後再根據天氣情況來推薦旅遊景點。
Action: get_weather(city="北京")

Observation: 北京當前天氣：Sunny，氣温26攝氏度
========================================      
--- 循環 2 ---

正在調用大語言模型...
大語言模型響應成功。
模型輸出:
Thought: 現在已經知道了北京今天的天氣是晴朗且温度適中，接下來可以基於這個信息來推薦一個適合的旅遊景點了。
Action: get_attraction(city="北京", weather="Sunny")

Observation: 北京在晴天最值得去的旅遊景點是頤和園，因其美麗的湖景和古建築。另一個推薦是長城，因其壯觀的景觀和歷史意義。
========================================
--- 循環 3 ---

正在調用大語言模型...
大語言模型響應成功。
模型輸出:
Thought: 已經獲得了兩個適合晴天遊覽的景點建議，現在可以根據這些信息給用户提供滿意的答覆。
Action: finish(answer="今天北京的天氣是晴朗的，氣温26攝氏度，非常適合外出遊玩。我推薦您去頤和園欣賞美麗的湖景和古建築，或者前往長城體驗其壯觀的景觀和深厚的歷史意義。希望您有一個愉快的旅行！
")

任務完成，最終答案: 今天北京的天氣是晴朗的，氣温26攝氏度，非常適合外出遊玩。我推薦您去頤和園欣賞美麗的湖景和古建築，或者前往長城體驗其壯觀的景觀和深厚的歷史意義。希望您有一個愉快的旅行！

這個簡單的旅行助手案例，集中演示了基於Thought-Action-Observation範式的智能體所具備的四項基本能力：任務分解、工具調用、上下文理解和結果合成。正是通過這個循環的不斷迭代，智能體才得以將一個模糊的用户意圖，轉化為一系列具體、可執行的步驟，並最終達成目標。

1.4 智能體應用的協作模式

上一節，我們通過親手構建一個智能體，深入理解了其內部的運作循環。不過在更廣泛的應用場景中，我們的角色正越來越多地轉變為使用者與協作者。基於智能體在任務中的角色和自主性程度，其協作模式主要分為兩種：一種是作為高效工具，深度融入我們的工作流；另一種則是作為自主的協作者，與其他智能體協作完成複雜目標。

1.4.1 作為開發者工具的智能體

在這種模式下，智能體被深度集成到開發者的工作流中，作為一種強大的輔助工具。它增強而非取代開發者的角色，通過自動化處理繁瑣、重複的任務，讓開發者能更專注於創造性的核心工作。這種人機協同的方式，極大地提升了軟件開發的效率與質量。

目前，市場上涌現了多款優秀的AI編程輔助工具，它們雖然均能提升開發效率，但在實現路徑和功能側重上各有千秋：

• GitHubCopilot: 作為該領域最具影響力的產品之一，Copilot 由 GitHub 與 OpenAI 聯合開發。它深度集成於 Visual Studio Code等主流編輯器中，以其強大的代碼自動補全能力而聞名。開發者在編寫代碼時，Copilot 能實時提供整行甚至整個函數塊的建議。近年來，它也通過 Copilot Chat 擴展了對話式編程的能力，允許開發者在編輯器內通過聊天解決編程問題。
• Claude Code: Claude Code 是由 Anthropic 開發的 AI 編程助手，旨在通過自然語言指令幫助開發者在終端中高效地完成編碼任務。它能夠理解完整的代碼庫結構，執行代碼編輯、測試和調試等操作，支持從描述功能到代碼實現的全流程開發。Claude Code 還提供了無交互（headless）模式，適用於 CI、pre-commit hooks、構建腳本和其他自動化場景，為開發者提供了強大的命令行編程體驗。
• Trae: 作為新興的 AI 編程工具，Trae 專注於為開發者提供智能化的代碼生成和優化服務。它通過深度學習技術分析代碼模式，能夠為開發者提供精準的代碼建議和自動化重構方案。Trae 的特色在於其輕量級的設計和快速響應能力，特別適合需要頻繁迭代和快速原型開發的場景。
• Cursor: 與上述主要作為插件或集成功能存在的工具不同，Cursor 則選擇了一條更具整合性的路徑，它本身就是一個AI原生的代碼編輯器。它並非在現有編輯器上增加AI功能，而是在設計之初就將AI交互作為核心。除了具備頂級的代碼生成和聊天能力外，它更強調讓AI理解整個代碼庫的上下文，從而實現更深層次的問答、重構和調試。

當然還有許多優秀的工具沒有例舉，不過它們共同指向了一個明確的趨勢：AI 正在深度融入軟件開發的全生命週期，通過構建高效的人機協同工作流，深刻地重塑着軟件工程的效率邊界與開發範式。

1.4.2 作為自主協作者的智能體

與作為工具輔助人類不同，第二種交互模式將智能體的自動化程度提升到了一個全新的層次，自主協作者。在這種模式下，我們不再是手把手地指導AI完成每一步，而是將一個高層級的目標委託給它。智能體會像一個真正的項目成員一樣，獨立地進行規劃、推理、執行和反思，直到最終交付成果。這種從助手到協作者的轉變，使得LLM智能體更深的進入了大眾的視野。它標誌着我們與AI的關係從“命令-執行”演變為“目標-委託”。智能體不再是被動的工具，而是主動的目標追求者。

當前，實現這種自主協作的思路百花齊放，涌現了大量優秀的框架和產品，從早期的 BabyAGI、AutoGPT，到如今更為成熟的 CrewAI、AutoGen、MetaGPT、LangGraph 等優秀框架，共同推動着這一領域的高速發展。雖然具體實現千差萬別，但它們的架構範式大致可以歸納為幾個主流方向：

1. 單智能體自主循環：這是早期的典型範式，如 AgentGPT 所代表的模式。其核心是一個通用智能體通過“思考-規劃-執行-反思”的閉環，不斷進行自我提示和迭代，以完成一個開放式的高層級目標。
2. 多智能體協作：這是當前最主流的探索方向，旨在通過模擬人類團隊的協作模式來解決複雜問題。它又可細分為不同模式： 角色扮演式對話：如 CAMEL 組織化工作流：如 MetaGPT 和 CrewAI，它們模擬一個分工明確的“虛擬團隊”（如軟件公司或諮詢小組）。每個智能體都有預設的職責和工作流程（SOP），通過層級化或順序化的方式協作，產出高質量的複雜成果（如完整的代碼庫或研究報告）。AutoGen 和 AgentScope 則提供了更靈活的對話模式，允許開發者自定義智能體間的複雜交互網絡。
3. 高級控制流架構：諸如 LangGraph 等框架，則更側重於為智能體提供更強大的底層工程基礎。它將智能體的執行過程建模為狀態圖（State Graph），從而能更靈活、更可靠地實現循環、分支、回溯以及人工介入等複雜流程。

這些不同的架構範式，共同推動着自主智能體從理論構想走向更廣泛的實際應用，使其有能力應對日益複雜的真實世界任務。在我們的後續章節中，也會感受不同類型框架之間的差異和優勢。

1.4.3 Workflow和Agent的差異

在理解了智能體作為“工具”和“協作者”兩種模式後，我們有必要對Workflow和Agent的差異展開討論，儘管它們都旨在實現任務自動化，但其底層邏輯、核心特徵和適用場景卻截然不同。

簡單來説，Workflow 是讓 AI 按部就班地執行指令，而 Agent 則是賦予 AI 自由度去自主達成目標。

圖 1.6 Workflow和Agent的差異

如圖1.6所示，工作流是一種傳統的自動化範式，其核心是對一系列任務或步驟進行預先定義的、結構化的編排。它本質上是一個精確的、靜態的流程圖，規定了在何種條件下、以何種順序執行哪些操作。一個典型的案例：某企業的費用報銷審批流程。員工提交報銷單（觸發）-> 如果金額小於500元，直接由部門經理審批 -> 如果金額大於500元，先由部門經理審批，再流轉至財務總監審批 -> 審批通過後，通知財務部打款。整個過程的每一步、每一個判斷條件都被精確地預先設定。

與工作流不同，基於大型語言模型的智能體是一個具備自主性的、以目標為導向的系統。它不僅僅是執行預設指令，而是能夠在一定程度上理解環境、進行推理、制定計劃，並動態地採取行動以達成最終目標。LLM在其中扮演着“大腦”的角色。一個典型的例子，便是我們在1.3節中寫的智能旅行助手。當我們向它下達一個新指令，例如：“你好，請幫我查詢一下今天北京的天氣，然後根據天氣推薦一個合適的旅遊景點。” 它的處理過程充分展現了其自主性：

1. 規劃與工具調用：Agent首先會把任務拆解為兩個步驟：① 查詢天氣；② 基於天氣推薦景點。隨即，它會自主選擇並調用“天氣查詢API”，並將“北京”作為參數傳入。
2. 推理與決策：假設API返回結果為“晴朗，微風”。Agent的LLM大腦會基於這個信息進行推理：“晴天適合户外活動”。接着，它會根據這個判斷，在它的知識庫或通過搜索引擎這個工具中，篩選出北京的户外景點，如故宮、頤和園、天壇公園等。
3. 生成結果：最後，Agent會綜合信息，給出一個完整的、人性化的回答：“今天北京天氣晴朗，微風，非常適合户外遊玩。為您推薦前往【頤和園】，您可以在昆明湖上泛舟，欣賞美麗的皇家園林景色。”

在這個過程中，沒有任何寫死的if天氣=晴天 then 推薦頤和園的規則。如果天氣是“雨天”，Agent會自主推理並推薦國家博物館、首都博物館等室內場所。這種基於實時信息進行動態推理和決策的能力，正是Agent的核心價值所在。

1.5 本章小結

在本章中，我們共同踏上了探索智能體的初識之旅。我們的旅程從最基本的問題開始：

• 什麼是大語言模型驅動的智能體？我們首先明確了其定義，理解了現代智能體是具備了能力的實體。它不再僅僅是執行預設程序的腳本，而是能夠自主推理和使用工具的決策者。
• 智能體如何工作？我們深入探討了智能體與環境交互的運行機制。我們瞭解到，這個持續的閉環是智能體處理信息、做出決策、影響環境並根據反饋調整自身行為的基礎。
• 如何構建智能體？這是本章的實踐核心。我們以“智能旅行助手”為例，親手構建了一個完整的、由真實LLM驅動的智能體。
• 智能體有哪些主流的應用範式？最後，我們將視野投向了更廣闊的應用領域。我們探討了兩種主流的智能體交互模式：一是以GitHub Copilot和Cursor等為代表的、增強人類工作流的“開發者工具”；二是以CrewAI、MetaGPT和AgentScope等框架為代表的、能夠獨立完成高層級目標的“自主協作者”。同時講解了Workflow與Agent的差異。

通過本章的學習，我們建立了一個關於智能體的基礎認知框架。那麼，它是如何一步步從最初的構想演進至今的呢？在下一章中，我們將探索智能體的發展歷史，一段追本溯源的旅程即將開始！