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