2025年，擁抱AI Agent！
嘿，大家好！這里是一個專注于AI智能體的頻道~
在a16z預測2025年的發展中，Agent占據了很重要的一個環節。昨天中金也發研報，表示看好Agent的發展趨勢。包括langchain發布的24年總結報告，Agent是持續保持增長的。
所以25年，Agent或許值得期待？今天給家人們完全梳理一下Agent 智能體的系統，作為Agent入門指南（超長超長）！
這篇文章會幫你理清頭緒，明確地告訴你智能體到底是什么，以及它們是怎么工作的。我們會拆解智能體的關鍵組成部分，包括“工具”這個重要角色。
同時，也會分享一些實用的經驗，教你如何構建和部署智能體，從簡單的單次交互，到復雜的多智能體系統。
我們還會探討如何在企業環境中應用多智能體架構，并將其與微服務進行對比。在后續的文章中，我們會更深入地研究智能體和運營（AgentOps），以及如何搭建一個企業級多智能體系統的平臺。
什么是Agent智能體？
簡單來說，“智能體就是一個prompt，它指示基礎模型去和特定的工具互動。”
生成式 AI 智能體通過一個設計好的prompt，協調基礎模型（大模型）與外部工具之間的互動。這個prompt告訴 LLM 何時以及如何使用這些工具。
每一個“工具”本質上都包含了一組函數規范（或者我們叫它“聲明”）。這些聲明包括：
- 函數名稱：工具的唯一標識符。
- 描述：詳細解釋工具的用途、能解決什么問題，以及在什么情況下可以使用它。
- 參數：列出工具需要的輸入參數，并解釋每個參數的含義、類型和期望值。
- 輸出（可選）：描述工具返回結果的格式和內容。
為了讓這些聲明標準化，市面上通常使用基于 JSON 的 OpenAPI 格式。這種標準化格式可以清晰、機器可讀地描述 API，方便與生成式 AI 模型無縫集成。舉個例子，下面是用 OpenAPI 格式聲明一個可以獲取股票價格的工具：
{
"tools": [
{
"functionDeclarations": [
{
"name": "get_stock_price",
"description": "獲取指定公司的當前股票價格。",
"parameters": {
"type": "object",
"properties": {
"ticker": {
"type": "string",
"description": "股票代碼（如，AAPL, MSFT）。"
}
},
"required": ["ticker"]
},
"returns": {
"type": "number",
"description": "當前股票價格。"
}
}
]
}
]
}我們也可以用 Python SDK 以編程方式創建相同的函數聲明，比如 Vertex AI 提供的 SDK。這樣做可以更靈活地創建和管理工具規范：
from vertexai.generative_models import (
FunctionDeclaration,
GenerationConfig,
GenerativeModel,
Part,
Tool,
)
# 創建函數聲明
get_stock_price = FunctionDeclaration(
name="get_stock_price",
descriptinotallow="獲取指定公司的當前股票價格",
parameters={
"type": "object",
"properties": {
"ticker": {
"type": "string",
"description": "公司的股票代碼",
}
},
"required": ["ticker"]
},
returns={ # 添加 returns 字段！
"type": "number",
"description": "當前股票價格。"
}
)
# ... 可以添加更多的函數聲明
# 定義一個工具，包含可以被 FM 使用的函數列表
company_insights_tool = Tool(
function_declaratinotallow=[
get_stock_price,
# ... 其他函數聲明
],
)為了更直觀地展示這些概念，我們將在下面的例子中使用 Vertex AI SDK 和 Gemini 的函數調用功能。這些例子基于這個代碼倉庫，推薦去看看（https://github.com/GoogleCloudPlatform/generative-ai/blob/main/gemini/function-calling/use_case_company_news_and_insights.ipynb）。這種方法能讓你從更底層的角度理解智能體的工作原理。一旦你掌握了這些基礎知識，就可以更輕松地使用 LangChain 等更高級的智能體框架了。
到目前為止，我們主要關注如何用 JSON 定義工具結構，以及如何用 Vertex AI SDK 以編程方式創建這些定義。這些工具定義最終會被轉換成文本，并附加到指令提示中。這讓模型可以判斷，為了滿足用戶的請求，是否需要使用工具，如果要用，該用哪個，以及應該使用哪些參數。
下面這個例子演示了工具、模型和指令是如何一起工作的：
# 選擇 LLM，配置參數，并提供可用的工具
gemini_model = GenerativeModel(
"gemini-2.0-flash-exp",
generation_cnotallow=GenerationConfig(temperature=0),
tools=[company_insights_tool],
)
# 為 LLM 準備指令
instruction = """
給出一個簡潔、高層次的總結。只使用你從 API 響應中獲取的信息。
"""
agent = gemini_model.start_chat()接下來，就可以開始向模型發送新的輸入了：
# 為 LLM 準備你的查詢/問題
query = "Google當前股票價格是多少？"
# 將指令和查詢一起發送給 LLM
prompt = instruction + query
response = agent.send_message(prompt)你覺得模型會怎么回應？它會調用真實的函數嗎？
如果 ??company_insights_tool??? 定義正確（包括帶有 ??ticker??? 參數和 ??returns??? 字段的 ??get_stock_price??? 函數，就像前面的例子那樣），Gemini 應該能識別出它有一個可以回答這個問題的工具。它很可能會生成一個結構化的請求，調用 ??get_stock_price??? 函數，并將 ??ticker?? 參數設為 "GOOG" （或者 "GOOGL"，取決于你如何處理谷歌的兩類股票）。
這里要注意的是，Gemini 本身不會直接執行外部代碼或者實時調用股票價格 API。相反，它會生成一個結構化的請求，讓你（開發者）來執行。運行下面的代碼：
# LLM 檢查可用的工具聲明
# LLM 返回最適用的函數和參數
function_call = response.candidates[0].content.parts[0].function_call響應大概會像這樣（簡化版）：
name: "get_stock_price"
args {
fields
{ key: "ticker"
value {string_value: "Google"}
}
}那么，你該如何真正獲取股票價格呢？這就輪到你的代碼出場了：
也就是說，用戶（更常見的情況是你的代碼）需要負責根據模型的響應觸發正確的代碼。為了做到這一點，我們需要為每一個工具聲明都實現一個單獨的 Python 函數。下面是 ??get_stock_price?? 函數的例子：
# 為每個聲明實現一個 Python 函數
def get_stock_price_from_api(content):
url = f"https://www.alphavantage.co/query?functinotallow=GLOBAL_QUOTE"
f"&symbol={content['ticker']}&apikey={API_KEY}"
api_request = requests.get(url)
return api_request.text
# ... 其他函數實現為了簡化函數調用的觸發過程，我們建議創建一個函數處理器（也就是一個 Python 字典），把函數聲明中的函數名稱和實際的代碼函數對應起來：
# 將函數聲明和對應的 Python 函數連接起來
function_handler = {
"get_stock_price": get_stock_price_from_api,
# ...,
}現在，有了 Python 函數，并且能夠從模型的響應中拿到函數名稱和參數，下一步就是執行相應的函數：
# LLM 檢查可用的工具聲明
# LLM 返回最適用的函數和參數
function_call = response.candidates[0].content.parts[0].function_call
function_name = function_call.name
params = {key: value for key, value in function_call.args.items()}
# 調用對應的 Python 函數 (或者 API)
function_api_response = function_handler[function_name](params)[:20000]API 調用的輸出大概是這樣：
{
"Global Quote": {
"01. symbol": "GOOG",
"02. open": "179.7500",
"03. high": "180.4450",
"04. low": "176.0300",
"05. price": "177.3500",
"06. volume": "17925763",
"07. latest trading day": "2024-11-14",
"08. previous close": "180.4900",
"09. change": "-3.1400",
"10. change percent": "-1.7397%"
}
}接下來，就可以把結果發送回模型進行最終處理和響應生成了：
# 將函數的返回值發送給 LLM，生成最終答案
final_response = agent.send_message(
Part.from_function_response(
name=function_name,
respnotallow={"content": function_api_response},
),
)把函數的響應傳遞給 LLM 后，我們就能得到最終的答案：
谷歌 (GOOG) 的股價目前為 177.35 美元，相比昨天的 180.49 美元收盤價下跌了 1.74%。這才是最終用戶期望得到的答案。
簡單總結一下，這個過程包含五個步驟：
- 用戶提問：用戶向模型提問（“谷歌的當前股票價格是多少？”）。
- 模型請求函數調用：模型生成一個請求，指出應該調用哪個函數（“get_stock_price”），以及應該使用哪個參數值（“谷歌”）。
- 開發者執行函數：你的代碼從響應中提取函數調用信息，并用對應的參數值運行相應的 Python 函數（“get_stock_price_from_api”）。這個函數會從外部 API 獲取真實的股票價格數據。
- 將函數結果發回模型：從外部 API 得到的結果（股票價格數據）被發送回 LLM。
- 模型生成最終響應：模型使用得到的數據，生成最終的、人類可以理解的響應。
我們剛才描述的流程是智能體的基礎。具體來說，我們展示的流程是單輪智能體的核心邏輯：一個輸入觸發一個函數調用，并產生一個響應。這種模塊化設計非常適合云部署和擴展。你可以把這個邏輯容器化，然后部署在 Google Cloud Run 等服務上。這樣，你就可以創建一個穩定、無服務器的智能體，它可以通過 API 訪問，并且可以在你的 VPC 內或者更廣闊的網絡中使用。
邁向多輪智能體
雖然單輪模型奠定了基礎，但大多數現實世界的生成式 AI 應用需要更復雜的交互。用戶往往不能通過一次問答就得到所有需要的信息。所以接下來，我們來探索多輪智能體。這種智能體可以記住上下文，處理后續問題，并且協調多個函數調用來實現更復雜的目標。
為了說明這個概念，我們用一個受這個代碼倉庫啟發的例子（https://github.com/google-gemini/cookbook/blob/main/quickstarts/Function_calling.ipynb）。我們的目標是創建一個可以回答特定區域電影和影院相關問題的生成式 AI 智能體。和單輪智能體一樣，我們首先需要定義智能體可以使用的函數。為了簡單起見，我們直接在代碼中提供函數簽名和描述：
def find_movies(description: str, location: str = ""):
"""根據任何描述（類型、標題詞等）查找當前正在影院上映的電影。參數：description：任何類型的描述，包括類別或類型、標題詞、屬性等。location：城市和州，例如舊金山，CA，或者郵政編碼，例如 95616"""
...
return ["Barbie", "Oppenheimer"]
def find_theaters(location: str, movie: str = ""):
"""查找特定地點，以及可選的正在上映的電影的影院。參數：location：城市和州，例如舊金山，CA，或者郵政編碼，例如 95616。movie：任何電影標題"""
...
return ["Googleplex 16", "Android Theatre"]
def get_showtimes(location: str, movie: str, theater: str, date: str):
"""查找特定影院上映電影的開始時間。參數：location：城市和州，例如舊金山，CA，或者郵政編碼，例如 95616。movie：任何電影標題。theater：影院名稱。date：請求放映時間的日期"""
...
return ["10:00", "11:00"]下一步是在循環中運行函數識別、執行（使用函數處理器）和響應生成，直到模型擁有足夠的信息來完全響應用戶的請求。為了實現多輪交互，Gemini 支持自動函數調用，我們可以使用以下代碼自動完成：
chat = model.start_chat(enable_automatic_function_calling=True)
response = chat.send_message(
"今晚在山景城上映哪些喜劇電影？什么時間？")
for content in chat.history:
print(content.role, "->", [type(part).to_dict(part) for part in content.parts])
print("-" * 80)下面的交互展示了，當代碼使用用戶查詢“今晚在山景城上映哪些喜劇電影？什么時間？”執行時，模型的行為：
user -> [{'text': '今晚在山景城上映哪些喜劇電影？什么時間？'}]
--------------------------------------------------------------------------------
model -> [{'function_call': {'name': 'find_movies', 'args': {'location': '山景城, CA', 'description': '喜劇'}}}]
--------------------------------------------------------------------------------
user -> [{'function_response': {'name': 'find_movies', 'response': {'result': ['Barbie', 'Oppenheimer']}}}]
--------------------------------------------------------------------------------
model -> [{'function_call': {'name': 'find_theaters', 'args': {'movie': 'Barbie', 'location': '山景城, CA'}}}]
--------------------------------------------------------------------------------
user -> [{'function_response': {'name': 'find_theaters', 'response': {'result': ['Googleplex 16', 'Android Theatre']}}}]
--------------------------------------------------------------------------------
model -> [{'function_call': {'name': 'get_showtimes', 'args': {'date': '今晚', 'location': '山景城, CA', 'theater': 'Googleplex 16', 'movie': 'Barbie'}}}]
--------------------------------------------------------------------------------
user -> [{'function_response': {'name': 'get_showtimes', 'response': {'result': ['10:00', '11:00']}}}]
--------------------------------------------------------------------------------
model -> [{'text': '喜劇電影《Barbie》今晚在 Googleplex 16 的放映時間是 10:00 和 11:00。'}]
--------------------------------------------------------------------------------這個交互表明，模型在每一輪中都會使用完整的對話歷史，以此來判斷還需要哪些信息，應該使用哪個工具，以及如何組織自己的響應。這種記錄過去的交互信息的方式，對多輪對話來說至關重要，我們稱之為短期記憶。此外，除了對話歷史記錄，存儲一些操作指標也很重要，例如每個模型交互的執行時間、延遲和內存等，方便我們進一步實驗和優化。
下面是圖中描述的多輪智能體執行過程的 7 步驟摘要：
- 新查詢：用戶發起新的交互，提出新的查詢或問題。
- 函數識別：基礎模型 (FM) 會分析查詢，結合可用的工具和指令，判斷是否需要進行函數調用。如果需要，它會識別出合適的函數名稱和需要的參數。
- 準備函數調用：FM 會生成一個結構化的函數調用請求，指定函數名稱和要傳遞的參數。
- 執行函數調用：這一步由開發者的代碼執行，而不是 FM 本身（但是 Gemini 支持自動函數調用，方便實現）。代碼會接收函數調用請求，執行對應的函數（例如，調用 API），并獲取結果。
- 中間響應：函數執行的結果（函數獲取的數據）會被發送回 FM，作為中間響應。
- 更新上下文（對話歷史）：FM 會使用中間響應更新其對話歷史（在圖中被稱為“短期記憶”）。然后，FM 會使用更新后的上下文，來決定是否需要進一步的函數調用，或者是否已經收集到足夠的信息來生成最終響應。如果需要更多信息，過程會循環回到步驟 2。
- 最終響應：一旦 FM 認為它已經掌握所有必要的信息（或者達到了為避免無限循環而設定的最大步驟數），它會生成最終的響應，發送給用戶。這個響應會整合從所有函數調用中獲取的信息。
這個多輪交互比較真實地展示了，生成式 AI 智能體是如何處理單個用戶請求的。然而，在現實世界中，我們經常會多次重復使用智能體。想象一下，用戶這周用智能體查找電影放映時間，下周又回來提出類似的要求。如果智能體能夠記住過去交互的長期記憶，它就可以提供更有針對性的推薦，比如推薦用戶之前感興趣的電影或者影院。這種長期記憶會存儲每次交互的短期對話歷史的摘要或完整記錄。
短期和長期記憶都在實現有效的多輪智能體交互中起著至關重要的作用。下面是它們各自的說明和實現方式：
短期記憶（對話歷史）：存儲在單個用戶會話中正在進行的對話。這包括用戶的查詢、模型的函數調用以及來自這些函數調用的響應。這種上下文對于模型理解后續問題，以及在整個交互中保持連貫性至關重要。實現選項：
- 日志（小文本日志）：對于對話比較短的簡單應用，可以將交互歷史記錄存儲為純文本日志。這種方式實現簡單，但是對于長對話或高流量，效率可能會降低。
- 云存儲/數據庫（大型非文本日志）：對于更復雜的應用（例如，利用多模態模型處理圖像或者音頻輸入），云存儲服務或者數據庫會是更好的選擇。這種方式能更結構化地存儲，并高效地檢索對話歷史。
- API 會話（客戶端存儲）：對話歷史也可以在客戶端（例如，網頁瀏覽器或者手機應用）使用 API 會話管理。這種方式能減少服務器端的存儲壓力，但存儲的數據量可能會有限制。
- 以上所有方式的組合：可以混合使用不同的存儲方式，根據應用的特定需求來選擇合適的方案。
長期記憶：存儲用戶在多個會話中的歷史交互信息。這使得智能體能夠學習用戶的偏好，提供個性化的推薦，并在長期使用中提供更高效的服務。實現選項：
- 向量數據庫（用于 RAG - 檢索增強生成）：向量數據庫特別適合在智能體應用中進行長期記憶存儲。它們將數據存儲為向量嵌入，從而捕捉數據的語義含義。這使得智能體可以高效地進行相似性搜索，從而根據當前用戶查詢，從過去的交互中檢索相關信息。這通常用于檢索增強生成（RAG）流程中。
- 元數據存儲/圖（會話 ID、其他元數據）：元數據存儲（如圖形數據庫或鍵值存儲）可以用來存儲關于用戶會話的信息，例如會話 ID、時間戳和其他相關元數據。這可以用來組織和檢索過去的對話歷史和交互關系。
- 云存儲/數據庫（實際日志）：過去的對話完整日志可以存儲在云存儲或數據庫中。這種方式提供了所有交互的完整記錄，但可能需要更多的存儲空間和更復雜的檢索機制。
- 以上所有方式的組合：和短期記憶類似，可以使用多種存儲機制的組合來優化性能和存儲效率。例如，摘要信息可以存儲在向量數據庫中以便快速檢索，而完整日志可以存儲在成本更低的云存儲中，用于審計或者更詳細的分析。
智能體調用智能體：多智能體系統的力量
雖然單個智能體可以處理復雜的任務，但有些問題需要協同努力才能解決。多智能體系統通過讓多個智能體一起工作來解決這個問題，每個智能體負責一個特定的子任務。這種協作方法允許將復雜問題分解為更小的、更易于管理的部分，從而實現更高效、更強大的解決方案。
多智能體系統的一個關鍵概念是把智能體當作工具：就像一個智能體可以使用外部 API 或者函數一樣，它也可以使用其他的智能體來執行特定的子任務。這種“智能體即工具”的模式允許我們創建分層系統，由一個智能體來協調其他智能體的工作。
下面是一些最常見的多智能體模式：
- 路由智能體（逐一）：在這種模式中，一個中央的“路由器”智能體接收初始請求，然后把它逐一委派給其他的智能體。路由器充當協調者的角色，決定哪個智能體最適合處理任務的哪個部分。當一個智能體完成它的子任務后，結果會返回給路由器，然后路由器會決定下一步的操作。這種模式適用于那些可以分解成順序步驟的任務，其中一個步驟的輸出會影響到下一個步驟。
- 并行（一對多）：在這種模式中，一個智能體會把子任務同時分發給多個智能體。當子任務彼此獨立并且可以并行執行時，這種模式很有效，可以顯著減少整體處理時間。一旦所有的智能體都完成了它們的工作，它們的結果會被匯總起來，通常由分發任務的初始智能體來完成。
- 順序（預定義順序）：這種模式涉及到智能體之間預定義的信息流。一個智能體的輸出會直接作為輸入，傳遞給固定序列中的下一個智能體。這種模式適用于那些有明確線性工作流程的任務。
- 循環流（預定義順序）：和順序模式類似，但信息流形成一個循環。序列中最后一個智能體的輸出會被傳遞回第一個智能體，形成一個循環。這對于迭代過程來說很有用，在這種過程中，智能體會根據循環中其他智能體的反饋來改進自己的輸出。
- 動態（全對全）：在這種更復雜的模式中，任何智能體都可以與其他任何智能體通信。沒有中央協調器或者預定義的信息流。智能體可以動態地交換信息，并且相互協商以實現共同的目標。這種模式更靈活，但管理起來也更復雜，需要復雜的通信和協調機制。
總結一下，你可以這樣理解：
- 在路由器模式中，路由器智能體把其他的智能體當作專門的工具來使用，根據需要逐一調用它們。
- 在并行模式中，初始智能體同時使用多個智能體作為工具，來加速整個過程。
- 在順序和循環流模式中，智能體在一個預定義的流程或循環中使用，像工具一樣。
- 在動態模式中，智能體的互動更像是一個團隊，每個智能體都同時充當其他智能體的用戶和工具，具體情況而定。
這些模式提供了不同的方式來構建多智能體交互，開發者可以根據應用的特定需求，選擇最合適的方式。
在了解了多智能體協作的概念后，下一個問題自然是如何在企業環境中實踐。上圖展示了一個基于微服務方法的企業級架構。這種方法把每個智能體都視為一個獨立的微服務，就像微服務把大型應用分解成可以獨立部署的組件一樣。這個類比非常有用，因為它允許我們利用現有的微服務最佳實踐：每個業務部門可以獨立開發和部署自己的智能體，作為獨立的微服務，并根據自己的特定需求進行定制。這種分散式的方法可以提高靈活性，并加快開發周期，因為團隊可以獨立工作，而不會影響系統的其他部分。就像微服務通過 API 進行通信一樣，多智能體系統中的智能體也通過交換消息進行通信，消息通常使用 JSON 等結構化格式。為了確保互操作性并避免重復開發，一個中央工具注冊表會提供對共享工具的訪問，而一個智能體模板目錄會提供可重用的代碼和最佳實踐。這種方法可以促進協作，加快開發速度，并提高整個組織的一致性。我們會在后續的文章中，更深入地探討這個架構。
結論
這篇文章的關鍵要點包括：
- 生成式 AI 模型依賴智能體通過定義良好的函數聲明，與外部工具進行交互。
- 智能體本質上是一個提示，它指示基礎模型與特定工具進行交互。
- 多輪智能體通過動態調用各種函數，并在整個交互過程中維護上下文，來處理復雜的用戶請求。
- 多智能體系統使智能體能夠通過委派子任務和協調彼此的工作，來協作解決復雜的問題。
本文轉載自 ??探索AGI??，作者： 獼猴桃
