在實際 AI 項目開發(fā)中我們常常遇到這樣的困境大語言模型LLM本身能力強大能說會道但讓它獨立完成一個復(fù)雜的、多步驟的任務(wù)時卻常常表現(xiàn)得像個“健忘的專家”——它可能忘記上一步的指令無法調(diào)用外部工具或者在需要決策時陷入循環(huán)。這正是智能體工程Agent Engineering要解決的核心問題。它不是一個單一的工具或庫而是一套工程化的設(shè)計模式與架構(gòu)思想旨在將 LLM 從一個“聊天大腦”升級為一個能夠自主感知、規(guī)劃、決策和執(zhí)行的“智能體”。本文面向希望將 LLM 能力真正融入業(yè)務(wù)流程的開發(fā)者、架構(gòu)師和技術(shù)決策者。我們將從零開始構(gòu)建一個能夠理解復(fù)雜任務(wù)、拆解步驟、調(diào)用工具并持續(xù)學(xué)習(xí)的智能體系統(tǒng)。整個過程不依賴任何單一商業(yè)平臺而是聚焦于可復(fù)現(xiàn)的開源框架和設(shè)計模式。你將理解智能體的核心組件如規(guī)劃器、工具集、記憶模塊掌握如何用代碼實現(xiàn)一個具備基本能力的智能體并學(xué)會在生產(chǎn)環(huán)境中部署、監(jiān)控和優(yōu)化它。最終你將獲得一套可應(yīng)用于客服自動化、數(shù)據(jù)分析、代碼生成等場景的實戰(zhàn)能力。1. 智能體工程的核心從“聊天”到“行動”的范式轉(zhuǎn)變在深入代碼之前必須厘清智能體Agent與普通 LLM 應(yīng)用的本質(zhì)區(qū)別。普通應(yīng)用是“一問一答”的靜態(tài)模式用戶輸入模型輸出交互結(jié)束。而智能體是“目標(biāo)驅(qū)動”的動態(tài)系統(tǒng)它擁有持續(xù)的目標(biāo)、內(nèi)部狀態(tài)和與外界交互的能力。1.1 智能體的基本架構(gòu)ReAct 模式與思考-行動-觀察循環(huán)當(dāng)前最主流的智能體架構(gòu)思想源于 ReActReasoning Acting模式。其核心是一個循環(huán)智能體接收任務(wù)進行內(nèi)部“思考”Reasoning決定下一步“行動”Acting通常是調(diào)用一個工具然后“觀察”O(jiān)bservation行動的結(jié)果并基于此進行下一輪思考直到任務(wù)完成或無法繼續(xù)。這個循環(huán)由幾個關(guān)鍵組件支撐規(guī)劃器Planner通常是 LLM 本身負(fù)責(zé)理解任務(wù)并將其分解為一系列可執(zhí)行的子步驟。例如任務(wù)“幫我分析上個月的銷售數(shù)據(jù)并生成報告”規(guī)劃器可能將其分解為1. 連接數(shù)據(jù)庫2. 查詢上月銷售數(shù)據(jù)3. 計算關(guān)鍵指標(biāo)4. 調(diào)用圖表生成工具5. 匯總成報告文檔。工具集Tools智能體可以調(diào)用的外部函數(shù)或 API。這是智能體突破 LLM 知識截止日期和無法執(zhí)行操作限制的關(guān)鍵。工具可以是搜索引擎、計算器、數(shù)據(jù)庫查詢、代碼執(zhí)行環(huán)境、文件操作等。記憶模塊Memory分為短期記憶會話歷史和長期記憶向量數(shù)據(jù)庫存儲的知識。它讓智能體記住之前的對話、工具調(diào)用結(jié)果和學(xué)到的知識避免重復(fù)工作和上下文遺忘。執(zhí)行引擎Agent Core協(xié)調(diào)以上所有組件管理 ReAct 循環(huán)的執(zhí)行流程處理異常并決定何時終止。1.2 主流智能體框架選型LangChain vs. LlamaIndex vs. 自研對于初學(xué)者和快速原型開發(fā)使用成熟框架是最高效的選擇。下表對比了兩個最流行的開源框架特性LangChainLlamaIndex核心定位構(gòu)建由LLM驅(qū)動的應(yīng)用程序的全功能框架鏈Chains、智能體Agents是其重要組成部分。專注于數(shù)據(jù)索引與檢索的數(shù)據(jù)框架其智能體能力建立在強大的數(shù)據(jù)連接之上。智能體支持原生、強大提供多種智能體類型如 ReAct, OpenAI Functions, Plan-and-Execute。工具集成極其豐富。提供智能體接口但其設(shè)計更傾向于讓智能體基于檢索到的上下文數(shù)據(jù)進行推理和操作。上手難度中等偏高概念多抽象層次高靈活性極強。中等如果你核心需求是讓LLM與你的數(shù)據(jù)對話它更直接。適用場景需要復(fù)雜工作流、多工具協(xié)調(diào)、自定義邏輯的通用型智能體應(yīng)用。以企業(yè)私有數(shù)據(jù)問答、文檔分析為核心并需要在此基礎(chǔ)上執(zhí)行簡單動作的場景。代碼風(fēng)格聲明式與編程式結(jié)合通過組合鏈、智能體、工具等組件來構(gòu)建應(yīng)用。更偏向于圍繞“索引”和“查詢引擎”構(gòu)建智能體作為上層抽象。對于本文的實戰(zhàn)我們將選擇LangChain因為它提供了最標(biāo)準(zhǔn)、最完整的智能體抽象其設(shè)計思想也最具普適性。理解了 LangChain 的智能體再遷移到其他框架或自研都會非常容易。2. 環(huán)境準(zhǔn)備與項目初始化構(gòu)建智能體的工作臺我們將構(gòu)建一個“數(shù)據(jù)分析智能體”它能夠理解用戶對數(shù)據(jù)的需求自動編寫并執(zhí)行 Python 代碼如 pandas 操作進行分析最后總結(jié)結(jié)果。這個場景涵蓋了規(guī)劃理解需求、拆解步驟、工具使用代碼執(zhí)行和記憶保留數(shù)據(jù)上下文。2.1 基礎(chǔ)環(huán)境與依賴安裝首先確保你的開發(fā)環(huán)境已安裝 Python推薦 3.9 以上版本。我們將創(chuàng)建一個干凈的虛擬環(huán)境并安裝核心依賴。# 創(chuàng)建并進入項目目錄 mkdir ai_agent_project cd ai_agent_project # 創(chuàng)建虛擬環(huán)境以 conda 為例也可使用 venv conda create -n agent_env python3.10 -y conda activate agent_env # 安裝 LangChain 及其相關(guān)依賴。我們使用 OpenAI 的模型作為智能體的“大腦”。 # 注意你需要準(zhǔn)備一個有效的 OPENAI_API_KEY。 pip install langchain langchain-openai langchain-experimental # 安裝代碼執(zhí)行工具所需的依賴 pip install pandas numpy matplotlib # 安裝 Jupyter 內(nèi)核工具用于安全執(zhí)行生成的代碼 pip install ipykernel關(guān)鍵解釋langchain: 核心框架。langchain-openai: OpenAI 模型的官方 LangChain 集成。langchain-experimental: 包含一些尚在實驗階段但非常有用的組件如高級智能體類型。pandas, numpy, matplotlib: 我們的智能體將用來進行數(shù)據(jù)分析的庫。ipykernel: 提供一個相對隔離的代碼執(zhí)行環(huán)境比直接使用exec()更安全。2.2 項目結(jié)構(gòu)設(shè)計一個清晰的目錄結(jié)構(gòu)有助于管理智能體的各個模塊。建議如下ai_agent_project/ ├── agents/ # 智能體核心定義 │ ├── __init__.py │ └── data_analyst_agent.py ├── tools/ # 自定義工具集 │ ├── __init__.py │ └── code_executor.py ├── memory/ # 記憶模塊如自定義記憶后端 │ └── __init__.py ├── config/ # 配置文件 │ └── settings.py ├── data/ # 示例數(shù)據(jù)文件 │ └── sample_sales.csv ├── logs/ # 運行日志 ├── main.py # 應(yīng)用主入口 └── requirements.txt現(xiàn)在在config/settings.py中配置你的 API 密鑰和環(huán)境變量# config/settings.py import os from dotenv import load_dotenv load_dotenv() # 從 .env 文件加載環(huán)境變量 OPENAI_API_KEY os.getenv(OPENAI_API_KEY) # 你可以在這里添加其他配置如模型名稱、溫度等 MODEL_NAME gpt-4o-mini # 或 gpt-3.5-turbo創(chuàng)建一個.env文件在項目根目錄注意不要提交到版本控制OPENAI_API_KEYyour_openai_api_key_here3. 構(gòu)建核心組件工具、記憶與智能體實例智能體的強大與否很大程度上取決于其“工具包”的豐富程度和設(shè)計合理性。3.1 創(chuàng)建自定義代碼執(zhí)行工具LangChain 提供了BaseTool抽象類。我們將創(chuàng)建一個安全的代碼執(zhí)行工具它允許智能體運行 Python 代碼來處理數(shù)據(jù)。# tools/code_executor.py import ast import sys import traceback from io import StringIO from typing import Type, Optional from langchain.tools import BaseTool from pydantic import BaseModel, Field class CodeExecutionInput(BaseModel): 代碼執(zhí)行工具的輸入模型。 code: str Field(description需要被執(zhí)行的 Python 代碼字符串。) class SafeCodeExecutorTool(BaseTool): name python_code_executor description 用于執(zhí)行 Python 代碼以進行數(shù)據(jù)分析、計算或繪圖。 輸入必須是有效的 Python 代碼字符串。 代碼應(yīng)盡可能自包含避免依賴未定義的變量。 工具會返回代碼的標(biāo)準(zhǔn)輸出、錯誤信息或最后一個表達(dá)式的值。 args_schema: Type[BaseModel] CodeExecutionInput return_direct: bool False # 執(zhí)行后繼續(xù)循環(huán)不直接返回給用戶 def _run(self, code: str) - str: 執(zhí)行代碼并捕獲輸出。 # 1. 安全檢查嘗試解析代碼語法 try: ast.parse(code) except SyntaxError as e: return f語法錯誤: {e} # 2. 準(zhǔn)備一個干凈的執(zhí)行環(huán)境 local_vars { pd: __import__(pandas), np: __import__(numpy), plt: __import__(matplotlib.pyplot), __builtins__: __builtins__, } global_vars {} # 3. 重定向標(biāo)準(zhǔn)輸出和錯誤 old_stdout sys.stdout old_stderr sys.stderr sys.stdout captured_output StringIO() sys.stderr captured_error StringIO() result None try: # 4. 執(zhí)行代碼 exec(code, global_vars, local_vars) # 嘗試獲取最后一個表達(dá)式的值非賦值語句 tree ast.parse(code) if tree.body and isinstance(tree.body[-1], ast.Expr): last_expr ast.unparse(tree.body[-1]) result eval(last_expr, global_vars, local_vars) except Exception as e: # 5. 捕獲運行時異常 captured_error.write(traceback.format_exc()) finally: # 6. 恢復(fù)標(biāo)準(zhǔn)輸出/錯誤 sys.stdout old_stdout sys.stderr old_stderr output captured_output.getvalue() error captured_error.getvalue() # 7. 構(gòu)造返回信息 if error: return f執(zhí)行出錯:\n{error} else: response f代碼執(zhí)行成功。\n標(biāo)準(zhǔn)輸出:\n{output} if result is not None: response f\n最后一個表達(dá)式的結(jié)果: {repr(result)} return response async def _arun(self, code: str) - str: 異步版本本例中暫不實現(xiàn)。 raise NotImplementedError(此工具不支持異步執(zhí)行。)關(guān)鍵解釋與安全考量輸入驗證使用args_schema定義強類型輸入確保智能體傳入的是代碼字符串。語法檢查使用ast.parse提前檢查代碼語法避免明顯的惡意代碼結(jié)構(gòu)。沙箱環(huán)境我們創(chuàng)建了一個local_vars字典作為執(zhí)行命名空間只預(yù)先導(dǎo)入了pandas、numpy和matplotlib.pyplot。這在一定程度上限制了可訪問的模塊。注意這并非完全安全的沙箱生產(chǎn)環(huán)境需要考慮更嚴(yán)格的隔離方案如 Docker 容器、專用沙箱服務(wù)。輸出捕獲重定向sys.stdout和sys.stderr來捕獲打印信息和錯誤。結(jié)果提取嘗試解析代碼的最后一個表達(dá)式并求值將結(jié)果返回給智能體這有助于鏈?zhǔn)接嬎?。錯誤處理完整捕獲并返回異常堆棧幫助智能體理解哪里出錯了。3.2 配置智能體使用 LangChain 的 ReAct 模式現(xiàn)在我們將工具、LLM 和記憶組合起來創(chuàng)建一個 ReAct 智能體。# agents/data_analyst_agent.py import os import sys sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__)))) from langchain.agents import AgentExecutor, create_react_agent from langchain_openai import ChatOpenAI from langchain.prompts import PromptTemplate from langchain.memory import ConversationBufferMemory from tools.code_executor import SafeCodeExecutorTool from config.settings import OPENAI_API_KEY, MODEL_NAME def create_data_analyst_agent(): 創(chuàng)建并返回一個數(shù)據(jù)分析智能體執(zhí)行器。 # 1. 初始化 LLM llm ChatOpenAI( openai_api_keyOPENAI_API_KEY, model_nameMODEL_NAME, temperature0, # 對于執(zhí)行任務(wù)低溫度保證穩(wěn)定性 streamingFalse, ) # 2. 準(zhǔn)備工具列表 tools [SafeCodeExecutorTool()] # 3. 創(chuàng)建 ReAct 提示模板 # LangChain 有內(nèi)置的 ReAct 模板但我們可以微調(diào)以更適合數(shù)據(jù)分析場景 prompt_template 你是一個專業(yè)的數(shù)據(jù)分析助手。你可以使用工具來執(zhí)行 Python 代碼以分析數(shù)據(jù)、計算統(tǒng)計量或生成圖表。 請嚴(yán)格遵循以下格式 問題用戶提出的問題 思考你需要分析問題并決定是否需要使用工具。如果需要請解釋原因和計劃。 行動需要調(diào)用的工具名稱必須是以下之一[{tool_names}] 行動輸入工具的輸入必須是一個格式正確的 JSON 字符串例如 {{code: import pandas as pd; df pd.read_csv(data.csv)}} 觀察工具返回的結(jié)果 ... (這個 思考/行動/行動輸入/觀察 循環(huán)可以重復(fù)多次) 思考我現(xiàn)在知道了最終答案 最終答案對用戶問題的清晰、完整的回答包含數(shù)據(jù)、結(jié)論或圖表描述。 開始 之前的對話歷史 {history} 問題{input} 思考{agent_scratchpad} prompt PromptTemplate.from_template(prompt_template) # 4. 初始化記憶 memory ConversationBufferMemory(memory_keyhistory, return_messagesTrue) # 5. 創(chuàng)建 ReAct 智能體 agent create_react_agent(llm, tools, prompt) # 6. 創(chuàng)建智能體執(zhí)行器它負(fù)責(zé)運行循環(huán) agent_executor AgentExecutor( agentagent, toolstools, memorymemory, verboseTrue, # 打印詳細(xì)的思考過程便于調(diào)試 handle_parsing_errorsTrue, # 優(yōu)雅處理解析錯誤 max_iterations10, # 防止無限循環(huán) early_stopping_methodgenerate, # 當(dāng)智能體輸出最終答案時停止 ) return agent_executor if __name__ __main__: # 快速測試 agent create_data_analyst_agent() test_query 我有一個CSV文件在 data/sample_sales.csv請用pandas加載它并告訴我總銷售額是多少。 result agent.invoke({input: test_query}) print(\n 智能體最終回答 ) print(result[output])關(guān)鍵參數(shù)說明temperature0對于執(zhí)行具體任務(wù)的智能體將“創(chuàng)造性”降至最低保證輸出和工具調(diào)用的穩(wěn)定性。verboseTrue在開發(fā)階段至關(guān)重要它會打印出智能體完整的“思考”、“行動”、“觀察”過程是調(diào)試智能體邏輯的主要依據(jù)。handle_parsing_errorsTrue當(dāng)智能體輸出的動作格式不符合預(yù)期時嘗試讓 LLM 重新生成而不是直接崩潰。max_iterations10安全閥強制限制 ReAct 循環(huán)的最大次數(shù)防止因邏輯錯誤導(dǎo)致無限循環(huán)和 API 費用失控。prompt_template我們自定義的提示詞明確了輸出格式并加入了{(lán)history}和{agent_scratchpad}兩個關(guān)鍵變量前者由記憶模塊填充后者由執(zhí)行引擎在每一步填充。4. 運行驗證與結(jié)果分析觀察智能體如何工作準(zhǔn)備一個簡單的數(shù)據(jù)文件data/sample_sales.csvdate,product,region,quantity,unit_price 2024-01-01,Product_A,North,10,100 2024-01-02,Product_B,South,5,150 2024-01-03,Product_A,East,8,100 2024-01-04,Product_C,North,12,80 2024-01-05,Product_B,West,6,150運行python agents/data_analyst_agent.py。由于設(shè)置了verboseTrue你將在控制臺看到類似以下的詳細(xì)輸出 進入新的 AgentExecutor 鏈... 思考用戶想讓我分析一個CSV文件。我需要先讀取這個文件。我可以使用 python_code_executor 工具來執(zhí)行讀取CSV的Python代碼。 行動python_code_executor 行動輸入{code: import pandas as pd; df pd.read_csv(data/sample_sales.csv); print(df.head()); print(\\n數(shù)據(jù)形狀, df.shape)} 觀察代碼執(zhí)行成功。 標(biāo)準(zhǔn)輸出: date product region quantity unit_price 0 2024-01-01 Product_A North 10 100 1 2024-01-02 Product_B South 5 150 2 2024-01-03 Product_A East 8 100 3 2024-01-04 Product_C North 12 80 4 2024-01-05 Product_B West 6 150 數(shù)據(jù)形狀 (5, 5) 最后一個表達(dá)式的結(jié)果: None 思考數(shù)據(jù)已成功加載。用戶要求計算總銷售額。我需要先計算每行的銷售額quantity * unit_price然后求和。 行動python_code_executor 行動輸入{code: import pandas as pd; df pd.read_csv(data/sample_sales.csv); df[sales] df[quantity] * df[unit_price]; total_sales df[sales].sum(); print(f總銷售額為: {total_sales})} 觀察代碼執(zhí)行成功。 標(biāo)準(zhǔn)輸出: 總銷售額為: 4460 最后一個表達(dá)式的結(jié)果: None 思考我已經(jīng)計算出了總銷售額并打印了出來?，F(xiàn)在可以給出最終答案了。 最終答案已成功加載 data/sample_sales.csv 文件。數(shù)據(jù)包含5行5列。計算得到的總銷售額為 **4460**。結(jié)果分析規(guī)劃與分解智能體正確理解了任務(wù)并將其分解為兩個子步驟1. 加載并查看數(shù)據(jù)2. 計算總銷售額。工具調(diào)用在每一步“思考”后它都正確地選擇了python_code_executor工具并傳入了格式正確的 JSON 輸入。狀態(tài)保持在第二步的代碼中它直接使用了df變量這依賴于上一步代碼在同一執(zhí)行環(huán)境中運行的結(jié)果。這得益于我們的工具設(shè)計local_vars在單次調(diào)用內(nèi)是持續(xù)的。更復(fù)雜的場景可能需要智能體顯式地將數(shù)據(jù)保存到變量或上下文中。循環(huán)終止在得到計算結(jié)果后智能體判斷任務(wù)完成輸出“最終答案”并結(jié)束了循環(huán)。5. 常見問題排查當(dāng)智能體“失靈”時怎么辦智能體開發(fā)中90%的問題集中在提示詞、工具定義和循環(huán)邏輯上。以下是典型問題及排查路徑。5.1 問題智能體陷入無限循環(huán)或重復(fù)調(diào)用同一工具現(xiàn)象控制臺不斷打印相似的“思考-行動-觀察”循環(huán)無法輸出最終答案直到達(dá)到max_iterations限制?？赡茉蚺c排查工具描述不清檢查工具的description字段是否清晰、無歧義地說明了工具的用途、輸入格式和輸出。模糊的描述會導(dǎo)致 LLM 誤用工具。觀察結(jié)果不具信息量工具返回的結(jié)果observation可能太簡單如只返回“成功”或太復(fù)雜如大段錯誤堆棧導(dǎo)致 LLM 無法基于此做出有效決策。確保工具返回的信息能明確指導(dǎo)下一步行動。提示詞缺少終止條件在提示詞模板中必須明確告知智能體“何時”以及“如何”給出最終答案。強化“最終答案”部分的描述。LLM 溫度過高將temperature設(shè)為 0 或一個很低的值如 0.1以增加決策的確定性。解決方案優(yōu)化工具描述description “用于執(zhí)行Python代碼。輸入必須是包含有效Python代碼的JSON對象鍵為‘code’。工具將返回執(zhí)行后的打印輸出或錯誤信息?！弊尮ぞ叻祷亟Y(jié)構(gòu)化信息例如“成功。輸出[...]。計算結(jié)果是xxx。”在提示詞中增加約束“如果你已經(jīng)獲得了足夠的信息來回答問題請直接輸出‘最終答案’不要再調(diào)用工具。”5.2 問題智能體無法正確解析工具輸入格式現(xiàn)象日志中出現(xiàn)“Could not parse LLM output: ...”或智能體輸出的行動輸入不是有效的 JSON?？赡茉蚺c排查提示詞格式要求不嚴(yán)格檢查提示詞模板中關(guān)于行動輸入的說明。必須明確要求是JSON字符串并給出精確示例。LLM 能力不足過于復(fù)雜或嵌套的工具輸入格式可能讓某些模型困惑。盡量簡化輸入結(jié)構(gòu)。未啟用錯誤處理確保AgentExecutor初始化時設(shè)置了handle_parsing_errorsTrue。這會讓框架在解析失敗時嘗試讓 LLM 重新生成輸出。解決方案在提示詞中使用更明確的示例“行動輸入{{code: print(hello)}}”。使用OpenAI Functions或Structured Tools等更現(xiàn)代的智能體類型它們利用模型的原生函數(shù)調(diào)用能力格式錯誤率大大降低。5.3 問題工具執(zhí)行失敗但智能體無法從錯誤中恢復(fù)現(xiàn)象工具返回了錯誤信息如“執(zhí)行出錯: NameError: name pd is not defined”但智能體在下一輪思考中要么無視錯誤要么做出了錯誤的決策?？赡茉蚺c排查錯誤信息不友好工具返回的原始異常堆棧對 LLM 來說可能難以理解。需要在工具層面對錯誤進行提煉和轉(zhuǎn)譯。缺乏錯誤處理指導(dǎo)提示詞中沒有教導(dǎo)智能體如何處理工具錯誤。它可能不知道“遇到 NameError 意味著需要導(dǎo)入模塊”。解決方案在工具的_run方法中將捕獲的異常轉(zhuǎn)換為更自然的語言return f“代碼執(zhí)行失敗錯誤類型是‘{type(e).__name__}’。具體信息{str(e)}。請檢查變量名是否正確或是否缺少必要的導(dǎo)入語句?！痹谔崾驹~的思考部分加入引導(dǎo)“如果觀察結(jié)果顯示工具執(zhí)行出錯請分析錯誤原因修正你的代碼然后再次嘗試?！?.4 智能體開發(fā)調(diào)試清單當(dāng)智能體行為不符合預(yù)期時請按此順序檢查日志是否開啟了verboseTrue仔細(xì)閱讀每一步的“思考”、“行動”、“觀察”。提示詞復(fù)制完整的提示詞包含被填充的變量到 OpenAI Playground看模型是否能按格式響應(yīng)。工具單獨測試你的工具輸入智能體試圖調(diào)用的參數(shù)看是否能返回預(yù)期結(jié)果。記憶檢查memory中存儲的歷史消息看是否有干擾信息或信息丟失。LLM 調(diào)用檢查 API 密鑰、網(wǎng)絡(luò)、模型名稱是否正確以及是否觸發(fā)了速率限制。6. 進階優(yōu)化與生產(chǎn)實踐從原型到可用的系統(tǒng)一個能在學(xué)習(xí)環(huán)境跑通的智能體距離生產(chǎn)可用還有很大差距。以下是關(guān)鍵的優(yōu)化方向。6.1 增強工具能力與安全性基礎(chǔ)的代碼執(zhí)行工具風(fēng)險極高。生產(chǎn)環(huán)境必須強化嚴(yán)格沙箱使用Docker容器或在安全的云函數(shù)中執(zhí)行代碼限制 CPU、內(nèi)存、網(wǎng)絡(luò)和文件系統(tǒng)訪問。超時控制為工具執(zhí)行設(shè)置超時如 30 秒防止惡意或低效代碼長期占用資源。代碼審查在執(zhí)行前用規(guī)則引擎或另一個輕量級 LLM 對代碼進行安全檢查過濾危險操作如os.system,__import__(‘os’)。專用工具與其提供一個萬能的代碼執(zhí)行器不如為常見操作創(chuàng)建專用工具如query_database_tool,generate_chart_tool,send_email_tool。專用工具更安全、更易控制。6.2 優(yōu)化記憶與上下文管理ConversationBufferMemory會無限制地增長很快會耗盡 LLM 的上下文窗口。摘要式記憶使用ConversationSummaryMemory或ConversationSummaryBufferMemory定期將長對話壓縮成摘要。向量記憶將重要的對話片段或工具執(zhí)行結(jié)果存入向量數(shù)據(jù)庫如Chroma,Weaviate。當(dāng)需要相關(guān)信息時通過檢索增強生成RAG的方式動態(tài)注入上下文。分層記憶區(qū)分短期會話記憶和長期知識記憶。將學(xué)到的通用知識如“用戶偏好圖表類型為折線圖”存入長期記憶供后續(xù)會話使用。6.3 引入規(guī)劃與驗證機制復(fù)雜任務(wù)需要更高級的規(guī)劃。Plan-and-Execute 架構(gòu)使用一個“規(guī)劃者”LLM 先制定詳細(xì)的步驟計劃再由一個“執(zhí)行者”LLM 或智能體按步驟調(diào)用工具。這比單一的 ReAct 循環(huán)更適合長流程任務(wù)。子智能體多智能體創(chuàng)建多個各司其職的智能體如“數(shù)據(jù)獲取智能體”、“分析智能體”、“報告生成智能體”由一個“主管智能體”進行協(xié)調(diào)。這符合單一職責(zé)原則也便于調(diào)試。輸出驗證在智能體給出最終答案前引入一個“驗證”步驟?？梢允且?guī)則校驗如數(shù)字是否在合理范圍也可以是讓另一個 LLM 進行邏輯審查。6.4 監(jiān)控、評估與持續(xù)改進沒有監(jiān)控的智能體上線是危險的。鏈路追蹤記錄每個用戶會話的完整軌跡包括所有的思考、行動、觀察。這對于復(fù)現(xiàn)問題和優(yōu)化提示詞至關(guān)重要。關(guān)鍵指標(biāo)定義并監(jiān)控成功率、任務(wù)完成步數(shù)、工具調(diào)用錯誤率、用戶滿意度等指標(biāo)。A/B測試對提示詞、工具集或模型進行 A/B 測試用數(shù)據(jù)驅(qū)動優(yōu)化。人工審核與強化學(xué)習(xí)對于關(guān)鍵任務(wù)初期引入人工審核環(huán)節(jié)。將人工糾正的案例作為新的訓(xùn)練數(shù)據(jù)微調(diào) LLM 或優(yōu)化提示詞實現(xiàn)智能體的持續(xù)進化。智能體工程是將 LLM 從“玩具”變?yōu)椤吧a(chǎn)力工具”的關(guān)鍵橋梁。它要求開發(fā)者不僅懂 prompt 技巧更要具備系統(tǒng)設(shè)計、安全編程和運維思維。從構(gòu)建一個簡單的 ReAct 智能體開始逐步為其添加更強大的工具、更可靠的記憶和更嚴(yán)謹(jǐn)?shù)墓芸亓鞒棠憔湍艽蛟斐稣嬲鉀Q實際業(yè)務(wù)問題的 AI 應(yīng)用。下一步你可以嘗試集成更多類型的工具如網(wǎng)絡(luò)搜索、API 調(diào)用或者探索更復(fù)雜的多智能體協(xié)作架構(gòu)例如讓一個智能體專門負(fù)責(zé)代碼生成另一個負(fù)責(zé)代碼審查和安全檢查。