被“大模型Agent開發(fā)入門”這個(gè)題目吸引進(jìn)來(lái)的朋友估計(jì)和我一樣腦子里已經(jīng)裝了無(wú)數(shù)個(gè)名詞Function Calling、ReAct、LangChain、Dify、記憶、工具調(diào)用……但真正想動(dòng)手的時(shí)候又不知道從哪里下手。我去年底開始做Agent相關(guān)項(xiàng)目從只會(huì)用Python寫死邏輯到今天把一個(gè)能查庫(kù)存、發(fā)通知、自動(dòng)填報(bào)表的Agent跑在測(cè)試環(huán)境里中間踩了不少坑。這篇文章就把我的入門路線、代碼思路和避坑清單整理出來(lái)給準(zhǔn)備入坑的同行一個(gè)參考。不管你是后端開發(fā)、算法工程師、測(cè)試同學(xué)還是產(chǎn)品經(jīng)理只要有一點(diǎn)點(diǎn)Python基礎(chǔ)能裝Python環(huán)境都能順著這條路線把Agent跑起來(lái)。我不打算堆概念而是盡量還原真實(shí)的開發(fā)過(guò)程包括環(huán)境怎么搭、模型怎么選、代碼怎么寫、框架怎么對(duì)比、上線前會(huì)遇到哪些坑。1. Agent到底是什么和普通API調(diào)用有什么區(qū)別1.1 從“聊天機(jī)器人”到“干活小助手”的質(zhì)變很多人一開始會(huì)把“大模型Agent”和“聊天機(jī)器人”劃等號(hào)。如果只是調(diào)API讓大模型回答“今天天氣怎么樣”那是普通的對(duì)話充其量叫LLM應(yīng)用。真正的Agent是把大模型當(dāng)作“大腦”讓它根據(jù)目標(biāo)自主推理、拆解步驟、調(diào)用外部工具然后把結(jié)果反饋給用戶。比如同樣是問天氣一個(gè)普通聊天機(jī)器人只會(huì)回答“我沒辦法獲取實(shí)時(shí)天氣”而一個(gè)Agent會(huì)先去調(diào)用天氣API拿到數(shù)據(jù)后告訴你“北京今天晴氣溫-2℃到6℃”。這個(gè)“思考-行動(dòng)-觀察-再思考”的循環(huán)就是Agent的核心本質(zhì)。業(yè)界經(jīng)常提到ReAct模式Reasoning and Acting正是把推理和行動(dòng)交替執(zhí)行。你可以把它想象成一個(gè)新來(lái)的實(shí)習(xí)生領(lǐng)導(dǎo)交代一件事他不會(huì)傻坐著而是先理解任務(wù)再查資料遇到問題就問然后把結(jié)果整理好交給你。Agent要做的就是這套流程只不過(guò)“查資料”變成了調(diào)用API“問”變成了向模型發(fā)出工具請(qǐng)求“整理結(jié)果”變成了生成最終回答。1.2 一個(gè)最簡(jiǎn)單的Agent循環(huán)是怎么跑的我第一版Agent代碼連框架都沒用就是用Python手寫的一個(gè)while循環(huán)大致長(zhǎng)這樣messages [{role: system, content: 你是一個(gè)樂于助人的助理。}] max_steps 5 for step in range(max_steps): # 1. 把當(dāng)前對(duì)話歷史發(fā)給大模型 response llm_client.chat(messagesmessages) content response[content] # 2. 大模型判斷是否需要調(diào)用工具 if 需要調(diào)用工具 in content: tool_name, tool_args parse_tool_request(content) result run_tool(tool_name, tool_args) # 3. 實(shí)際執(zhí)行外部工具 messages.append({role: assistant, content: content}) messages.append({role: tool, content: result}) continue # 4. 如果不需要工具就當(dāng)作最終回答輸出 print(content) break這一步想清楚之后所有框架都只是把上面這個(gè)循環(huán)包裝得更好用而已。我建議你不管最后用什么框架先把這段邏輯寫一遍理解“Agent 大模型 工具 循環(huán)”這個(gè)本質(zhì)。1.3 幾個(gè)必須搞懂的基礎(chǔ)概念在動(dòng)手之前下面幾個(gè)詞一定要搞明白否則看文檔會(huì)一頭霧水。Function Calling / Tool Calling大模型輸出一個(gè)結(jié)構(gòu)化的“調(diào)用意圖”比如{name: get_weather, arguments: {city: 北京}}。它本身不執(zhí)行函數(shù)只是告訴你的程序“該去調(diào)用哪個(gè)工具了”。System Prompt放在對(duì)話開頭用來(lái)定角色、定規(guī)則。Agent的行為邊界一大半靠它控制。記憶MemoryAgent和用戶的對(duì)話歷史。短期記憶是當(dāng)前上下文窗口內(nèi)的消息長(zhǎng)期記憶則需要外部存儲(chǔ)不知道之前聊了什么就沒法個(gè)性化。上下文長(zhǎng)度Context Length模型能同時(shí)“看到”的token數(shù)量。比如8K、32K、128K超過(guò)這個(gè)量就得截?cái)嗷蛘?。ReAct一種推理模式——模型每完成一次“想”和“做”再結(jié)合觀察結(jié)果繼續(xù)下一步。這些概念不用一下子全看懂但看到時(shí)要能反應(yīng)過(guò)來(lái)后面所有章節(jié)都會(huì)碰到。2. 環(huán)境準(zhǔn)備從零拉起一套可復(fù)現(xiàn)的開發(fā)環(huán)境2.1 硬件與模型選型不是所有人都要上A100很多人被“大模型”三個(gè)字嚇住以為必須買幾千塊的顯卡。其實(shí)Agent開發(fā)初期完全可以不跑本地大模型。三種常見方案方案成本適合人群代表模型云端API按量付費(fèi)幾十塊錢能用很久快速驗(yàn)證想法、不想折騰硬件通義千問、Kimi、DeepSeek、智譜GLM、豆包等本地小模型一臺(tái)8G顯存以上的機(jī)器數(shù)據(jù)敏感、離線環(huán)境、長(zhǎng)期調(diào)優(yōu)Qwen2.5系列1.5B-14B、Llama 3.2本地大模型加速卡中高成本團(tuán)隊(duì)級(jí)私有化部署Qwen2.5-72B、DeepSeek系列我的經(jīng)驗(yàn)是入門階段優(yōu)先用云端API。注冊(cè)一個(gè)平臺(tái)拿到Key就能開始寫代碼。等到需要頻繁測(cè)試、大量調(diào)用再考慮本地部署也不遲。2.2 用Ollama快速拉起本地模型如果你還是想完全本地跑我最推薦的就是Ollama。它支持macOS、Linux、Windows把模型下載、啟動(dòng)、調(diào)用全封裝成一條命令。安裝好之后在終端執(zhí)行ollama pull qwen2.5:7b ollama run qwen2.5:7b一個(gè)可以在本地對(duì)話的模型就跑起來(lái)了。它的接口兼容OpenAI格式Python代碼可以直接這么連import ollama response ollama.chat(modelqwen2.5:7b, messages[ {role: user, content: 你好介紹一下你自己} ]) print(response[message][content])我之前在一臺(tái)16G內(nèi)存的MacBook Pro上跑過(guò)7B模型雖然生成速度不算快但用來(lái)做功能測(cè)試完全夠用。如果是企業(yè)私有化部署建議上帶GPU的服務(wù)器跑14B或更大參數(shù)模型效果差距明顯。2.3 調(diào)API和本地模型怎么選不只是成本問題很多初學(xué)者會(huì)糾結(jié)“用哪個(gè)”。我踩過(guò)一輪坑總結(jié)出來(lái)的選擇邏輯是這樣的開發(fā)調(diào)試階段用云端API。速度快、模型智商高、不用操心環(huán)境先驗(yàn)證流程沒問題。數(shù)據(jù)敏感場(chǎng)景比如企業(yè)內(nèi)部的客戶信息、代碼庫(kù)、財(cái)務(wù)數(shù)據(jù)這類內(nèi)容不能出內(nèi)網(wǎng)。這時(shí)候必須本地部署哪怕犧牲一點(diǎn)模型效果。長(zhǎng)期成本優(yōu)化如果每天調(diào)用百萬(wàn)級(jí)token本地部署的成本邊際遞減更劃算。離線容災(zāi)需求有些場(chǎng)景網(wǎng)絡(luò)不穩(wěn)定或者需要7x24小時(shí)穩(wěn)定運(yùn)行本地部署更可靠。另外真正做生產(chǎn)系統(tǒng)時(shí)很多人會(huì)同時(shí)接多個(gè)模型簡(jiǎn)單任務(wù)用便宜的小模型復(fù)雜推理用強(qiáng)模型。這種“模型路由”的思路可以從一開始就留好接口。2.4 關(guān)鍵參數(shù)上下文長(zhǎng)度、temperature、top_p剛開始我直接照抄別人的代碼完全沒管參數(shù)結(jié)果“nonsense”一堆。后來(lái)才意識(shí)到Agent本身是不確定系統(tǒng)參數(shù)就是它的“性格開關(guān)”。temperature溫度值越低輸出越穩(wěn)定、越保守值越高越有創(chuàng)造性。做Agent我一般設(shè)0.1~0.3寧可讓它無(wú)聊也不能讓它胡編。top_p核采樣控制在候選詞的概率累計(jì)范圍。0.9表示每次只從概率最高的一批詞里選值越小越穩(wěn)定。通常和temperature二選一調(diào)整不要同時(shí)拉滿。max_tokens / max_length單次生成的最大token數(shù)。如果Agent需要輸出代碼、JSON、長(zhǎng)文一定要給足空間否則會(huì)被截?cái)鄬?dǎo)致解析失敗。上下文長(zhǎng)度注意模型的最大上下文限制。對(duì)話歷史太大會(huì)超限太小會(huì)失憶。后面第5章會(huì)細(xì)說(shuō)處理策略。response llm_client.chat( messagesmessages, temperature0.2, top_p0.8, max_tokens1024 )這個(gè)參數(shù)組合適用于絕大多數(shù)Agent場(chǎng)景實(shí)測(cè)下來(lái)既不會(huì)太死板也不會(huì)亂飛。3. 核心環(huán)節(jié)實(shí)現(xiàn)做一個(gè)會(huì)查庫(kù)存、發(fā)通知的Agent3.1 明確需求場(chǎng)景先定一個(gè)能落地的目標(biāo)我建議第一個(gè)Agent不要做“全能助手”而是做一個(gè)“單點(diǎn)任務(wù)助手”。我自己的例子是做一個(gè)查詢庫(kù)存并發(fā)送告警的Agent。它需要知道用戶想問哪個(gè)商品的庫(kù)存如果低于閾值就調(diào)用發(fā)消息的工具通知倉(cāng)庫(kù)管理員。場(chǎng)景越具體后面的Prompt、工具設(shè)計(jì)、測(cè)試預(yù)期就越清晰。你會(huì)很清楚地知道“這個(gè)Agent到底跑通了沒有”而不是玄學(xué)式地“感覺它挺聰明”。3.2 工具注冊(cè)把外部能力變成大模型認(rèn)識(shí)的方法要讓大模型知道可以用你定義的函數(shù)需要在請(qǐng)求里傳入“工具定義”。以O(shè)penAI風(fēng)格接口為例tools [ { type: function, function: { name: get_stock_count, description: 查詢某個(gè)商品的實(shí)時(shí)庫(kù)存, parameters: { type: object, properties: { product_id: { type: string, description: 商品ID例如P10001 } }, required: [product_id] } } }, { type: function, function: { name: send_dingtalk_notice, description: 發(fā)送釘釘通知給倉(cāng)庫(kù)管理員, parameters: { type: object, properties: { message: { type: string, description: 告警內(nèi)容 } }, required: [message] } } } ]關(guān)鍵點(diǎn)在于每個(gè)工具的description要寫得非常具體。我一開始寫的是“查詢庫(kù)存”模型經(jīng)常不知道什么時(shí)候該調(diào)用改成“查詢某個(gè)商品的實(shí)時(shí)庫(kù)存當(dāng)用戶給出商品ID時(shí)調(diào)用”之后識(shí)別率提升一大截。描述文字是模型理解工具用途的重要輸入不要偷懶。3.3 實(shí)現(xiàn)真正的Function Calling用代碼把“動(dòng)作”接上大模型返回一個(gè)類似下面的結(jié)構(gòu)化內(nèi)容{ role: assistant, content: null, tool_calls: [ { id: call_123, type: function, function: { name: get_stock_count, arguments: {\product_id\: \P10001\} } } ] }你的程序需要解析tool_calls把里面的參數(shù)交給注冊(cè)好的Python函數(shù)然后“模擬”一條工具回復(fù)消息傳回去def execute_tool_call(tool_call, tools_map): func_name tool_call[function][name] args json.loads(tool_call[function][arguments]) result tools_map[func_name](**args) return { tool_call_id: tool_call[id], role: tool, content: str(result) }把執(zhí)行結(jié)果附加到對(duì)話歷史再繼續(xù)請(qǐng)求模型模型就會(huì)基于工具的實(shí)際返回內(nèi)容生成最終回答。這一步一定要自己手動(dòng)實(shí)現(xiàn)一遍后面不管用什么框架都不會(huì)變成“只會(huì)改配置的調(diào)包俠”。3.4 給Agent加記憶不能聊完就忘很多人忽略了記憶導(dǎo)致Agent一多輪就“失憶”。最簡(jiǎn)單的短期記憶方案是把歷史消息保存在一個(gè)列表里每次請(qǐng)求都帶上。但列表不能無(wú)限長(zhǎng)否則很快超過(guò)上下文限制。我實(shí)測(cè)了幾種做法滑動(dòng)窗口只保留最近6-8輪消息。簡(jiǎn)單直接適合多數(shù)場(chǎng)景。摘要壓縮每5輪把所有消息丟給模型生成一段摘要然后替換掉舊消息。適合對(duì)話很長(zhǎng)、需要保留細(xì)節(jié)的場(chǎng)景。外部向量存儲(chǔ)把關(guān)鍵信息寫進(jìn)向量數(shù)據(jù)庫(kù)需要時(shí)通過(guò)相似度檢索召回。適合有大量歷史知識(shí)的情況。初期項(xiàng)目用滑動(dòng)窗口就夠了。真正要落地時(shí)我會(huì)同時(shí)用兩種策略滑動(dòng)窗口保短期向量庫(kù)做長(zhǎng)期記憶。3.5 組裝Agent循環(huán)從沒頭沒尾的腳本變成一個(gè)小系統(tǒng)當(dāng)我完成工具注冊(cè)和記憶以后整個(gè)代碼結(jié)構(gòu)會(huì)變得清晰起來(lái)分成四個(gè)模塊agent/ ├── core_loop.py # 主循環(huán)負(fù)責(zé)調(diào)度 ├── tools/ # 所有工具函數(shù) ├── memory.py # 記憶管理 └── config.py # 模型、參數(shù)配置主循環(huán)的核心邏輯依然是“調(diào)模型 - 判斷工具 - 執(zhí)行工具 - 再調(diào)模型”。我建議把最大循環(huán)次數(shù)限制在5~8次。因?yàn)锳gent有時(shí)會(huì)陷入死循環(huán)連續(xù)調(diào)用同一個(gè)工具限制次數(shù)能幫你盡早發(fā)現(xiàn)異常。for step in range(max_steps): response llm.chat(messagesmessages, toolstools) assistant_msg response.choices[0].message if not assistant_msg.tool_calls: return assistant_msg.content messages.append(assistant_msg) for tool_call in assistant_msg.tool_calls: tool_result execute_tool_call(tool_call, tools_map) messages.append(tool_result)這就是一個(gè)最小可用的Agent核心。4. 框架對(duì)比LangChain、Dify還是自研4.1 從零自己寫自由度最高但要控制復(fù)雜度如果你只是寫幾十行Python完全不需要引入框架。自研的好處是所有細(xì)節(jié)都受你控制不會(huì)出現(xiàn)“框架封裝太深出了問題不知道在哪”的窘境。但一旦你要做多Agent協(xié)作、條件分支、并行工具調(diào)用、長(zhǎng)時(shí)間任務(wù)自己寫就容易亂套。我有個(gè)同事用自研代碼做了六個(gè)月后來(lái)發(fā)現(xiàn)維護(hù)成本比業(yè)務(wù)邏輯還高。所以我的建議是前期自研跑通流程復(fù)雜化以后及時(shí)切換框架。4.2 LangChain / LangGraph生態(tài)豐富但不要被“大而全”迷惑LangChain可能是提到Agent最容易被想到的框架。它內(nèi)置了Prompt模板、Memory、Tool、Agent類型等一大堆模塊。優(yōu)點(diǎn)是可以快速拼裝但缺點(diǎn)是抽象層太厚剛?cè)腴T會(huì)踩很多“類名看懂但不知道干什么”的坑。LangGraph是LangChain團(tuán)隊(duì)后來(lái)推出的更底層編排框架核心是“圖”結(jié)構(gòu)節(jié)點(diǎn)是任務(wù)邊是跳轉(zhuǎn)條件。它把Agent循環(huán)可視化了適合做有狀態(tài)、可分支的復(fù)雜任務(wù)。如果你是第一次接觸我的建議是先不急著用LangChain的Agent封裝用它的ChatOpenAI、tool decorator、Memory模塊自己搭一個(gè)幾十行的循環(huán)。這樣既能利用生態(tài)里現(xiàn)成的東西又不至于被它牽著鼻子走。4.3 Dify可視化配置適合產(chǎn)品經(jīng)理快速驗(yàn)證Dify是一個(gè)開源的大模型應(yīng)用開發(fā)平臺(tái)最大的特點(diǎn)是可視化編排。你在網(wǎng)頁(yè)上拖拽節(jié)點(diǎn)開始節(jié)點(diǎn)、大模型節(jié)點(diǎn)、工具節(jié)點(diǎn)、知識(shí)庫(kù)檢索節(jié)點(diǎn)、結(jié)束節(jié)點(diǎn)就能生成一個(gè)Agent應(yīng)用。這種方式特別適合非程序員快速驗(yàn)證也適合團(tuán)隊(duì)里讓產(chǎn)品經(jīng)理先畫流程再由工程師接入真實(shí)代碼。Dify可以接入本地模型和多種云端模型還可以通過(guò)“自定義工具”的方式接入自己的API。不過(guò)它也有代價(jià)一旦流程比較復(fù)雜圖節(jié)點(diǎn)的維護(hù)成本會(huì)比代碼高版本管理也不太方便。我的定位是“原型驗(yàn)證工具”生產(chǎn)鏈路還是用代碼更踏實(shí)。4.4 我的選型建議按階段選擇我個(gè)人的策略是分三步走第1周純Python 云端API手寫ReAct循環(huán)完全理解原理。第2~4周引入LangGraph實(shí)現(xiàn)工具并行、條件分支、多節(jié)點(diǎn)編排。項(xiàng)目需要快速出Demo時(shí)用Dify快速搭界面和流程同步用代碼重構(gòu)底層。這個(gè)路線看起來(lái)“繞路”但實(shí)際學(xué)習(xí)效率最高。你既不會(huì)被框架束縛又能在后續(xù)規(guī)?；瘯r(shí)借助框架的能力。對(duì)比項(xiàng)自研PythonLangGraphDify學(xué)習(xí)成本低中高低靈活度高高中適合階段原理學(xué)習(xí)、輕量場(chǎng)景生產(chǎn)級(jí)復(fù)雜編排原型、低代碼團(tuán)隊(duì)調(diào)試難度低中低模塊復(fù)用自己造輪子生態(tài)豐富內(nèi)置大量工具5. 常見問題與排查技巧實(shí)錄5.1 AI Agent怎么扛并發(fā)從“單線程”到“可擴(kuò)容”很多人第一次做Agent會(huì)遇到性能問題模型返回慢一個(gè)請(qǐng)求要幾秒甚至十幾秒并發(fā)一上來(lái)直接卡死。這里有幾個(gè)建議把大模型調(diào)用放在異步接口里。不要用同步阻塞的方式等待模型返回用FastAPI的async或異步客戶端。給Agent流程設(shè)置超時(shí)時(shí)間。比如單次工具調(diào)用3秒模型調(diào)用15秒整體循環(huán)30秒。寧可超時(shí)返回也不要無(wú)限等。使用消息隊(duì)列削峰。Agent和普通接口不一樣它不是毫秒級(jí)操作。如果業(yè)務(wù)允許把請(qǐng)求放到Redis或RabbitMQ隊(duì)列里異步處理前端輪詢結(jié)果。對(duì)模型API做并發(fā)池整理。不同任務(wù)分配不同并發(fā)上限避免某個(gè)大任務(wù)的慢調(diào)用占滿所有連接。from fastapi import FastAPI from contextlib import asynccontextmanager import asyncio app FastAPI() async def run_agent(query: str): return await asyncio.to_thread(agent.run, query) app.post(/agent) async def agent_endpoint(query: str): # 異步提交避免阻塞 task asyncio.create_task(run_agent(query)) return {task_id: str(task)}5.2 Token超限與上下文截?cái)嘧畛Ｒ姷膱?bào)錯(cuò)就是“This models maximum context length is 8192 tokens”。原因很簡(jiǎn)單你把整個(gè)對(duì)話歷史都塞進(jìn)去了。處理方式我已經(jīng)在前面提過(guò)這里再補(bǔ)充一個(gè)經(jīng)驗(yàn)優(yōu)先提問時(shí)截舊消息不要截尾。尾部是模型最近看到的內(nèi)容對(duì)你的當(dāng)前指令和上下文連續(xù)性影響最大。另外可以在對(duì)話歷史里插入一個(gè)system消息提示“之前的信息已經(jīng)摘要為...”再接入原文模型通常能接受這種“打斷”。還有一種情況是工具返回結(jié)果太長(zhǎng)。比如查詢庫(kù)存接口返回了1000條明細(xì)直接塞進(jìn)消息里很容易撐爆上下文。我在實(shí)踐中的做法是截?cái)嗟角?0行并在后面追加一句“共1000條已展示前50條如需繼續(xù)請(qǐng)指定條件”。5.3 模型“偷懶”不調(diào)用工具怎么調(diào)教新手最容易遇到的問題模型就是不肯調(diào)用工具明明用戶都說(shuō)了“查一下A商品庫(kù)存”它偏偏回答說(shuō)“我無(wú)法查詢實(shí)時(shí)庫(kù)存”。是我的話會(huì)按這個(gè)順序排查檢查工具定義中的description是不是太模糊沒有觸發(fā)條件。改成“當(dāng)用戶詢問任何商品庫(kù)存時(shí)調(diào)用此工具”。給Prompt加先例在系統(tǒng)提示里明確寫“你具備查詢庫(kù)存的能力當(dāng)用戶詢問庫(kù)存時(shí)必須調(diào)用get_stock_count工具”。看模型返回的原始內(nèi)容有時(shí)候模型其實(shí)生成了tool_calls但你的解析代碼沒接住。打印一下原始響應(yīng)確認(rèn)是模型問題還是代碼問題。換更強(qiáng)的模型小模型1B、3B的指令遵循能力弱經(jīng)常聽不懂“工具調(diào)用”要求。換7B及以上問題立刻緩解。5.4 輸出格式不穩(wěn)定JSON解析失敗怎么辦Agent經(jīng)常需要輸出JSON給下游系統(tǒng)解析。但模型有時(shí)會(huì)在JSON前后加json標(biāo)記、加說(shuō)明文字導(dǎo)致json.loads直接報(bào)錯(cuò)。我試過(guò)幾種應(yīng)對(duì)辦法最有效的兩步是在Prompt里指定“只輸出JSON不要包含任何額外說(shuō)明或代碼塊標(biāo)記”。在代碼里寫一個(gè)貪婪解析函數(shù)先用正則找{...}或[...]最外層結(jié)構(gòu)再嘗試解析。import re import json def parse_json_response(content: str): # 去掉可能的json 標(biāo)記 content re.sub(r(?:json)?, , content).strip() try: return json.loads(content) except json.JSONDecodeError: match re.search(r\{.*\}, content, re.DOTALL) if match: return json.loads(match.group(0)) raise ValueError(無(wú)法解析模型輸出為JSON)5.5 多步任務(wù)中的“幻覺”與控制策略AI Agent多步執(zhí)行時(shí)間越長(zhǎng)越容易在某個(gè)中間步驟“自我發(fā)揮”。比如Agent要查庫(kù)存-生成補(bǔ)貨單-發(fā)通知結(jié)果它跳過(guò)了第二步直接發(fā)通知。我的體會(huì)是不要讓模型自己決定“下一步做什么”太開放。給它一個(gè)固定的工作流模板比如第1步根據(jù)用戶問題識(shí)別商品ID。第2步調(diào)用庫(kù)存查詢工具。第3步判斷是否低于閾值。第4步如果低于閾值調(diào)用告警工具。第5步生成總結(jié)回復(fù)。在System Prompt里把步驟一條條寫清楚同時(shí)限制最大步驟數(shù)。對(duì)于關(guān)鍵業(yè)務(wù)動(dòng)作寧可把流程拆成多個(gè)小Agent也不要用一個(gè)Agent自由發(fā)揮到底。6. 從Demo到落地進(jìn)階方向與經(jīng)驗(yàn)分享6.1 企業(yè)私有化部署的取舍最近“企業(yè)大模型私有化部署”這個(gè)詞非常熱。如果你們公司已經(jīng)有內(nèi)網(wǎng)GPU服務(wù)器想部署開源模型我建議按這個(gè)順序做用LM Studio或Ollama在單機(jī)上跑通模型。用vLLM或TensorRT-LLM這樣的推理引擎部署為HTTP服務(wù)吞吐量比Ollama高不少。配置鑒權(quán)、限流、監(jiān)控比如用Prometheus收集請(qǐng)求量、GPU利用率、平均延遲。結(jié)合向量數(shù)據(jù)庫(kù)如Milvus、Qdrant做知識(shí)庫(kù)檢索讓Agent能回答私有文檔問題。另外糾一個(gè)常見認(rèn)知私有化部署不只是“模型放本地”還包括數(shù)據(jù)鏈路、運(yùn)維、升級(jí)。模型版本更新很頻繁你要考慮部署腳本是否可持續(xù)。我建議把模型文件、推理服務(wù)配置、Agent代碼都納入統(tǒng)一的版本管理中。6.2 大模型微調(diào)該不該做什么時(shí)候做被“大模型微調(diào)”吸引進(jìn)來(lái)的人很多但我想潑一點(diǎn)冷水90%的Agent項(xiàng)目不需要微調(diào)。在Agent領(lǐng)域效果提升的第一來(lái)源是“工程”包括Prompt優(yōu)化、工具設(shè)計(jì)、流程編排、記憶策略。微調(diào)是后期手段用來(lái)解決“同樣的問題反復(fù)錯(cuò)、且Prompt已經(jīng)改不動(dòng)”的情況。比如你發(fā)現(xiàn)模型對(duì)某個(gè)專業(yè)名詞理解錯(cuò)位而更換Prompt無(wú)濟(jì)于事這時(shí)才考慮收集幾百條數(shù)據(jù)做LoRA微調(diào)。前期微調(diào)不僅成本高還可能因?yàn)閿?shù)據(jù)量不足導(dǎo)致災(zāi)難性遺忘。6.3 多模態(tài)Agent不只是“看圖說(shuō)話”多模態(tài)大模型最近進(jìn)展很快Agent也開始集成圖像輸入、語(yǔ)音輸入。一個(gè)簡(jiǎn)單場(chǎng)景是用戶拍一張貨架照片Agent識(shí)別商品信息然后查庫(kù)存再發(fā)補(bǔ)貨單。實(shí)現(xiàn)上并不復(fù)雜把圖片經(jīng)過(guò)編碼傳給多模態(tài)模型接口在Prompt里增加“根據(jù)圖片識(shí)別出商品ID”的指令即可。但要注意圖片大小、清晰度、token消耗——一張高分辨率圖片轉(zhuǎn)成token后可能占幾千token記得在對(duì)話里壓縮。6.4 給入坑者的最后建議如果你正在考慮要不要學(xué)Agent開發(fā)我的答案很直接值得但別只學(xué)“調(diào)API”。把這個(gè)領(lǐng)域拆開其實(shí)包含三塊能力大模型使用能力、工程落地能力、產(chǎn)品設(shè)計(jì)能力。三塊缺一不可。我個(gè)人在實(shí)際操作中最深的體會(huì)是Agent開發(fā)百分之六十的時(shí)間花在“讓模型穩(wěn)定聽話”上剩下的時(shí)間才是寫業(yè)務(wù)邏輯。模型本身的不確定性決定了你必須在外部建立各種約束清晰的工具描述、嚴(yán)格的步驟限制、健壯的格式解析、完善的日志追蹤。這些東西不是框架能替你做好的只有自己踩過(guò)坑才能真正理解。如果你現(xiàn)在還沒有環(huán)境我建議從今天開始先注冊(cè)一個(gè)云端模型API的Key用Python寫一個(gè)不到一百行的ReAct循環(huán)跑通“查天氣”這個(gè)例子。一個(gè)小時(shí)后你大概率會(huì)收到第一條“模型成功調(diào)用工具”的回執(zhí)。那瞬間你會(huì)覺得原來(lái)Agent真的沒那么玄乎。