先說(shuō)結(jié)論大模型Agent開發(fā)本質(zhì)上就是把“能說(shuō)會(huì)道”的大模型變成“能動(dòng)手干活”的智能體。這兩年AI圈最熱的關(guān)鍵詞除了大模型微調(diào)、RAG這些底層技術(shù)Agents絕對(duì)是最貼近實(shí)際業(yè)務(wù)的一層。你可以不研究怎么訓(xùn)練模型但你只要想用大模型解決實(shí)際問題就繞不開Agent。這篇文章不聊虛的直接從我踩過的坑出發(fā)講清楚Agent到底是什么、一個(gè)能用的Agent框架里都有哪些零件、怎么從零搭一個(gè)能跑的Demo以及我在真實(shí)項(xiàng)目里遇到的那些“文檔里不會(huì)寫”的問題。我見過太多人把Agent理解為“調(diào)API寫Prompt”這個(gè)認(rèn)知在大方向沒錯(cuò)但實(shí)操起來(lái)會(huì)發(fā)現(xiàn)真正復(fù)雜的不是讓模型說(shuō)一句話而是讓它安安穩(wěn)穩(wěn)地走完一個(gè)多步驟流程、在出錯(cuò)時(shí)能自己糾正、在需要外部信息時(shí)知道去查工具。這才是Agent開發(fā)的核心難點(diǎn)。1. 先用大白話拆清楚Agent和普通大模型調(diào)用有什么本質(zhì)區(qū)別1.1 普通API調(diào)用是“一問一答”Agent是“自主執(zhí)行”很多人第一次接觸大模型都是從一個(gè)聊天窗開始的輸入問題模型輸出答案。這個(gè)過程本質(zhì)上是“單輪對(duì)話”你問什么它答什么上下文結(jié)束后就斷了。但Agent不是這樣它面對(duì)的是一個(gè)“目標(biāo)”而不是“問題”。舉個(gè)例子普通API調(diào)用相當(dāng)于你雇了一個(gè)顧問你問“這個(gè)方案預(yù)算多少”他直接回答你。Agent則相當(dāng)于你雇了一個(gè)項(xiàng)目經(jīng)理你跟他說(shuō)“幫我做一份項(xiàng)目預(yù)算方案”他會(huì)自己去拆分任務(wù)查資料、選模板、算成本、排版、輸出——每一步都可能調(diào)用不同工具中間還可能自己發(fā)現(xiàn)“資料不夠得再找找”然后主動(dòng)調(diào)整策略繼續(xù)干活。這個(gè)“自主性”就是Agent和普通大模型調(diào)用最核心的區(qū)別Agent擁有目標(biāo)導(dǎo)向的規(guī)劃能力、工具調(diào)用能力和自我糾錯(cuò)能力。它不是一個(gè)被動(dòng)的回答者而是一個(gè)主動(dòng)的任務(wù)執(zhí)行者。1.2 Agent的“會(huì)干活”靠的是什么感知—規(guī)劃—行動(dòng)—反思我在實(shí)際開發(fā)中總結(jié)了一個(gè)比較好記的Agent工作模型四步循環(huán)感知接收用戶指令理解當(dāng)前狀態(tài)和可用的上下文信息。規(guī)劃把大目標(biāo)拆解為子任務(wù)決定每一步做什么、用什么工具、按什么順序執(zhí)行。行動(dòng)調(diào)用外部工具、API、數(shù)據(jù)庫(kù)或者生成中間結(jié)果。反思觀察行動(dòng)結(jié)果判斷是否達(dá)成目標(biāo)如果沒有修正計(jì)劃再走一遍。這四步構(gòu)成了Agent的“工作循環(huán)”。實(shí)際開發(fā)中最容易忽略的是“反思”這一步。很多初學(xué)者做出來(lái)的Agent看起來(lái)能跑但一遇到稍微復(fù)雜的任務(wù)就翻車原因就是沒有讓模型在行動(dòng)后自行檢查輸出是否符合預(yù)期。沒有反思機(jī)制的Agent就像一個(gè)悶頭干活不回頭看的員工做錯(cuò)了也不知道直到最后交付才發(fā)現(xiàn)問題。1.3 為什么說(shuō)“大模型只負(fù)責(zé)思考不負(fù)責(zé)記憶”另外一個(gè)必須從一開始就理解的概念是大模型本身不攜帶外部記憶。它的上下文窗口只是“臨時(shí)工作臺(tái)”對(duì)話一結(jié)束工作臺(tái)上的東西就沒了。Agent要解決“記憶”問題一般要引入兩類存儲(chǔ)短期記憶對(duì)話歷史、上下文緩存和長(zhǎng)期記憶向量數(shù)據(jù)庫(kù)、知識(shí)庫(kù)、用戶畫像。這個(gè)區(qū)別決定了Agent開發(fā)的整體架構(gòu)模型負(fù)責(zé)推理外部系統(tǒng)負(fù)責(zé)記憶與數(shù)據(jù)。我自己在架構(gòu)設(shè)計(jì)上一直堅(jiān)持一個(gè)原則——模型越簡(jiǎn)單存儲(chǔ)越可靠。不要指望靠提示詞把大段業(yè)務(wù)邏輯塞給模型而是把業(yè)務(wù)狀態(tài)、歷史記錄放在外部存儲(chǔ)里需要時(shí)再檢索給模型看。這樣不僅能省Token還能大幅提高Agent的穩(wěn)定性。2. Agent架構(gòu)拆解一個(gè)能落地的Agent框架里都有哪些核心零件2.1 核心組件之一大模型底座LLM——怎么選、怎么定參數(shù)Agent是建立在LLM之上的。選哪個(gè)模型直接決定了Agent能力的上限和成本下限。我做Agent開發(fā)一般分三檔來(lái)選輕量任務(wù)如意圖分類、實(shí)體抽取、簡(jiǎn)單問答選小參數(shù)模型比如各類7B~14B的開源模型速度快成本低中等任務(wù)需要多輪推理、代碼生成、結(jié)構(gòu)化輸出的選70B級(jí)模型或頂級(jí)商業(yè)模型的中檔版本復(fù)雜多步驟任務(wù)需要自主規(guī)劃、調(diào)用多種工具、長(zhǎng)上下文理解的必須選當(dāng)前最強(qiáng)檔次的模型因?yàn)橐?guī)劃能力弱的小模型會(huì)直接把流程跑散。參數(shù)設(shè)置同樣有講究。做Agent時(shí)temperature溫度參數(shù)跟做聊天問答時(shí)完全不同。聊天場(chǎng)景想要多樣性和創(chuàng)意溫度可以調(diào)高Agent場(chǎng)景要的是確定性和穩(wěn)定性溫度最好調(diào)低一般0.1~0.3之間甚至0。我見過不少團(tuán)隊(duì)Agent頻繁出錯(cuò)的根因就是temperature設(shè)太高導(dǎo)致模型每次輸出的JSON格式都變樣后續(xù)解析直接崩盤。2.2 核心組件之二工具調(diào)用Function Calling——Agent的“手腳”如果說(shuō)LLM是Agent的大腦工具就是Agent的手腳。一個(gè)不會(huì)調(diào)用工具的Agent本質(zhì)上就是一個(gè)高級(jí)聊天機(jī)器人只能在腦子里轉(zhuǎn)圈。工具調(diào)用的實(shí)現(xiàn)主流有兩種方式原生Function Calling像OpenAI系列模型、國(guó)內(nèi)多個(gè)商業(yè)大模型都原生支持函數(shù)調(diào)用能力模型會(huì)輸出結(jié)構(gòu)化的函數(shù)調(diào)用指令框架負(fù)責(zé)執(zhí)行并把結(jié)果返回給模型提示詞驅(qū)動(dòng)的工具調(diào)用把工具描述name、description、參數(shù)schema寫進(jìn)Prompt讓模型自己決定是否調(diào)用、以什么參數(shù)調(diào)用。這種方式兼容任何文本模型但穩(wěn)定性差一些需要更強(qiáng)的提示詞約束。我自己在項(xiàng)目里的經(jīng)驗(yàn)是只要選到的模型支持原生的Function Calling優(yōu)先用原生方案。原因是原生方案把工具選擇的決策過程跟文本生成分開了模型輸出完函數(shù)調(diào)用參數(shù)就會(huì)“停下來(lái)”框架拿到參數(shù)執(zhí)行完再把結(jié)果喂回去。這種機(jī)制天然防止模型“一邊編工具結(jié)果一邊聊”的問題。2.3 核心組件之三規(guī)劃與編排Planning Orchestration——Agent的“大腦皮層”規(guī)劃能力是Agent能否完成復(fù)雜任務(wù)的勝負(fù)手。早期大家做Agent都是“一根筋”模型輸出一步執(zhí)行一步再輸出一步。這種線性編排應(yīng)對(duì)簡(jiǎn)單任務(wù)沒問題但遇到分支邏輯就麻煩了。后來(lái)社區(qū)流行兩種規(guī)劃范式ReActReasoning Acting推理與行動(dòng)交替和Plan-and-Execute先計(jì)劃后執(zhí)行。我個(gè)人的體會(huì)是ReAct適合任務(wù)路徑不明、需要探索的場(chǎng)景模型每走一步都結(jié)合當(dāng)前觀察做判斷靈活但Token開銷大Plan-and-Execute適合任務(wù)流程相對(duì)清晰、可以預(yù)先把步驟拆好的場(chǎng)景先用模型做一次規(guī)劃然后按步驟執(zhí)行效率高、可控性強(qiáng)。實(shí)操中的常用技巧是在Prompt中顯式要求模型“先輸出思考過程再輸出行動(dòng)計(jì)劃最后執(zhí)行”也就是把思維鏈和行動(dòng)計(jì)劃分離。這樣做的好處是后續(xù)排查問題的時(shí)候你看到的是一張清晰的“執(zhí)行路線圖”而不是一團(tuán)亂麻的對(duì)話流水賬。2.4 核心組件之四記憶與上下文管理——你最容易忽視也最容易爆雷的地方我在前面說(shuō)了模型沒有天然記憶記憶必須靠外部存儲(chǔ)。Agent的上下文管理要做兩件事窗口內(nèi)的上下文組裝和窗口外的記憶持久化。窗口內(nèi)的組裝要注意“裁剪”和“排序”。我見過不少Agent跑著跑著爆內(nèi)存Token超限就是因?yàn)榘衙枯啔v史都原封不動(dòng)往Prompt里塞。正確的做法是歷史記錄按相關(guān)性過濾只把最近幾輪和關(guān)鍵結(jié)果拼接進(jìn)去。窗口外的記憶一般用向量數(shù)據(jù)庫(kù)存知識(shí)、用KV存儲(chǔ)存會(huì)話狀態(tài)需要時(shí)通過檢索召回。這里有一個(gè)真實(shí)翻車案例我們?cè)缙谧隽艘粋€(gè)企業(yè)知識(shí)庫(kù)Agent用戶問了一個(gè)兩三輪之前提過的問題Agent完全失憶又重復(fù)問了一遍用戶。原因就是上下文裁剪策略把早期對(duì)話全刪了。后來(lái)加了“關(guān)鍵事實(shí)提取”模塊——每一輪對(duì)話結(jié)束后系統(tǒng)會(huì)用模型把用戶偏好、關(guān)鍵決定、未完成事項(xiàng)提取出來(lái)存到結(jié)構(gòu)化存儲(chǔ)里之后再組裝Prompt時(shí)把摘要放進(jìn)去。這個(gè)問題才算根治。3. 開發(fā)環(huán)境與工具選型別被層出不窮的框架晃花了眼3.1 自研框架 vs 使用成熟框架中小團(tuán)隊(duì)怎么選現(xiàn)在Agent開發(fā)框架多如牛毛從功能全面的LangChain類框架到輕量好上手的Coze、Dify這類可視化平臺(tái)再到開源社區(qū)的各種輕量Agent骨架。我的建議非常直接如果你要快速驗(yàn)證業(yè)務(wù)價(jià)值直接上Dify或同類可視化平臺(tái)拖拖拽拽配好工具就能跑Demo不用寫框架代碼如果你要做深度定制、對(duì)接私有業(yè)務(wù)系統(tǒng)就要考慮自研或基于開源框架做二次開發(fā)因?yàn)榭梢暬脚_(tái)的抽象程度高細(xì)節(jié)控不住如果你是想學(xué)習(xí)Agent底層原理我建議別一上來(lái)就上重型框架先拿一個(gè)輕量模型加一個(gè)工具調(diào)用接口自己手寫幾十行代碼實(shí)現(xiàn)一個(gè)最小Agent跑通之后再去研究框架抽象了什么。我自己復(fù)盤時(shí)發(fā)現(xiàn)一個(gè)規(guī)律真正學(xué)到Agent精髓的方式是把現(xiàn)成框架的“封裝層”扒開親手實(shí)現(xiàn)一遍Prompt拼接、工具路由、結(jié)果回填這三個(gè)環(huán)節(jié)。做完這三個(gè)你對(duì)所有Agent框架的理解都能達(dá)到“見了代碼就懂在干啥”的程度。3.2 實(shí)戰(zhàn)推薦一個(gè)最小技術(shù)棧長(zhǎng)什么樣分享一下我現(xiàn)在做項(xiàng)目比較順手的最小技術(shù)棧組合不涉及具體商業(yè)產(chǎn)品偏好只談選型邏輯模型側(cè)優(yōu)先選擇原生支持Function Calling的商用或開源模型便于穩(wěn)定的工具調(diào)度編排層輕量場(chǎng)景直接自己寫狀態(tài)機(jī)或循環(huán)調(diào)度復(fù)雜場(chǎng)景用現(xiàn)成框架的Agent模塊但會(huì)去掉不需要的功能組件工具層用Python或TypeScript寫工具函數(shù)每個(gè)工具一個(gè)函數(shù)輸入輸出都定義JSON Schema這樣模型調(diào)用起來(lái)不迷路記憶層對(duì)話上下文用緩存存儲(chǔ)長(zhǎng)期知識(shí)放向量庫(kù)結(jié)構(gòu)化業(yè)務(wù)狀態(tài)放關(guān)系型數(shù)據(jù)庫(kù)可觀測(cè)性一定要有日志系統(tǒng)把每次模型調(diào)用、工具調(diào)用、入?yún)⒊鰠⑷坑浵聛?lái)。這句話怎么強(qiáng)調(diào)都不過分——沒有日志的Agent項(xiàng)目排查問題等于大海撈針。這個(gè)組合看起來(lái)樸素但勝在每一層都能控制。我經(jīng)歷過“框架炫技”的階段最后發(fā)現(xiàn)穩(wěn)定可靠的Agent系統(tǒng)往往不是靠花哨設(shè)計(jì)而是靠扎扎實(shí)實(shí)的每一層細(xì)節(jié)。4. 實(shí)操案例從零構(gòu)建一個(gè)能查庫(kù)存、能下單的客服Agent4.1 需求拆解把一個(gè)模糊想法變成具體功能為了講清楚全過程我設(shè)計(jì)一個(gè)非常經(jīng)典的實(shí)戰(zhàn)場(chǎng)景做一個(gè)“庫(kù)存查詢與下單客服Agent”。用戶會(huì)問兩類問題查庫(kù)存、下訂單。為了讓Agent“能干活”我們需要提供兩個(gè)工具函數(shù)query_inventory(item_id)和create_order(user_id, item_id, quantity)。這個(gè)場(chǎng)景覆蓋了Agent開發(fā)最核心的三件事意圖理解、參數(shù)抽取、工具調(diào)度。整個(gè)過程不復(fù)雜但足以讓你理解Agent開發(fā)的完整鏈路。先明確需求邊界Agent需要識(shí)別用戶的請(qǐng)求類型從自然語(yǔ)言中抽取結(jié)構(gòu)化參數(shù)比如從“幫我查一下A001的庫(kù)存”里抽出來(lái)item_idA001然后調(diào)用對(duì)應(yīng)工具拿到結(jié)果后再組織成自然語(yǔ)言回答用戶。這是最簡(jiǎn)單也最典型的Agent應(yīng)用場(chǎng)景。4.2 代碼實(shí)現(xiàn)手寫一個(gè)最小Agent循環(huán)下面我給出一個(gè)極簡(jiǎn)實(shí)現(xiàn)用偽代碼配合文字說(shuō)明因?yàn)楸绕鹳N大段代碼我更希望你先理解結(jié)構(gòu)。# 偽代碼最小Agent主循環(huán) def agent_loop(user_input, max_steps5): messages [{role: user, content: user_input}] for step in range(max_steps): # 1. 讓模型決定直接回答還是調(diào)用工具 response llm.chat(messages, toolsTOOLS) # 2. 如果模型沒有要求調(diào)用工具就當(dāng)作最終答案返回 if not response.tool_calls: return response.content # 3. 否則執(zhí)行工具調(diào)用把結(jié)果回填到對(duì)話里 for call in response.tool_calls: result execute_tool(call) messages.append({ role: tool, tool_call_id: call.id, content: result }) return 已達(dá)最大步數(shù)需要人工介入注意看這個(gè)循環(huán)里的關(guān)鍵設(shè)計(jì)每一步都問模型“你是要回答我還是要調(diào)工具”模型自己選擇路徑。工具結(jié)果通過roletool消息回填模型看到結(jié)果后決定下一步。max_steps是個(gè)保險(xiǎn)機(jī)制防止Agent陷入死循環(huán)。我在實(shí)際項(xiàng)目里不加這個(gè)參數(shù)不敢上線。4.3 工具定義怎么寫模型能看懂的JSON Schema工具函數(shù)本身很簡(jiǎn)單但怎么把工具描述給模型看是有講究的。我踩過的大坑是工具描述寫得太模糊模型不知道什么時(shí)候該用這個(gè)工具。比如你把工具描述寫成“查詢庫(kù)存”模型可能遇到任何跟庫(kù)存沾邊的問題都去調(diào)用它。正確的做法是把觸發(fā)條件寫清楚把參數(shù)含義寫清楚把返回值格式寫清楚。比如{ name: query_inventory, description: 當(dāng)用戶詢問某個(gè)商品的庫(kù)存數(shù)量或可用狀態(tài)時(shí)調(diào)用。不要用于價(jià)格或物流查詢。, parameters: { type: object, properties: { item_id: { type: string, description: 商品唯一編號(hào)通常形如A001。如果用戶說(shuō)那款白色的先通過上下文推斷編號(hào)。 } } } }這里有兩個(gè)細(xì)節(jié)值得強(qiáng)調(diào)一是description中的“什么時(shí)候該調(diào)”比“工具是干嘛的”更重要二是參數(shù)描述里要給模型“從模糊表述中抽取參數(shù)”的指引。比如用戶說(shuō)“幫我查一下那個(gè)白色款還有貨嗎”如果參數(shù)描述里沒有提示模型去關(guān)聯(lián)上下文中的商品編號(hào)這一步抽取就極容易失敗。4.4 把工具結(jié)果還給模型格式設(shè)計(jì)決定了穩(wěn)定性工具執(zhí)行完,結(jié)果要格式化成字符串回填給模型。這里有個(gè)常見錯(cuò)誤——直接把數(shù)據(jù)庫(kù)原始返回結(jié)構(gòu)丟給模型看比如{status: 200, data: {stock: 5, warehouse: 華東倉(cāng)}}模型雖然能讀懂但會(huì)在答案里復(fù)述“狀態(tài)碼200”這類沒用的信息。我的做法是在工具函數(shù)里先做一層“面向回答的格式化”只把跟用戶問題相關(guān)的信息提煉出來(lái)。查詢庫(kù)存就返回A001當(dāng)前庫(kù)存為5件所在倉(cāng)庫(kù)華東倉(cāng)。這樣模型組織回答時(shí)不容易跑偏也省Token。還有一個(gè)小技巧是給工具返回值加一個(gè)統(tǒng)一的[工具名]前綴標(biāo)識(shí)比如[query_inventory結(jié)果] A001當(dāng)前庫(kù)存為5件。這樣當(dāng)多輪對(duì)話中混入了多個(gè)工具的結(jié)果時(shí)模型能清楚地分辨哪些是用戶說(shuō)的、哪些是工具返回的減少上下文串?dāng)_。5. 常見問題與排查技巧我在真實(shí)項(xiàng)目里踩過的那些坑5.1 Agent陷入死循環(huán)怎么用“步數(shù)上限”和“循環(huán)檢測(cè)”兜底這是我遇到最多的問題。Agent在復(fù)雜的多工具任務(wù)中經(jīng)常出現(xiàn)這種情況模型反復(fù)調(diào)用同一個(gè)工具、參數(shù)幾乎不變結(jié)果也一致但它就是不結(jié)束。背后的原因多半是模型在“繞圈子”一邊認(rèn)為自己沒拿到答案一邊又不知道換策略。兜底方案有三層層層遞進(jìn)第一層絕對(duì)步數(shù)限制。主循環(huán)里設(shè)置最大迭代次數(shù)5到8步足夠覆蓋絕大多數(shù)任務(wù)超過即停止并給用戶回復(fù)“需要人工處理”第二層重復(fù)行為檢測(cè)。記錄最近N次工具調(diào)用的工具名關(guān)鍵參數(shù)哈希值如果連續(xù)出現(xiàn)相同調(diào)用超過兩次打斷循環(huán)并提示模型“你剛查過這個(gè)請(qǐng)換一種思路”第三層反射提示。在每次工具結(jié)果回填后加一句指令“請(qǐng)基于以上結(jié)果判斷任務(wù)是否已完成如果已完成請(qǐng)直接輸出最終答案不要再調(diào)用工具”。這三層下來(lái)基本能把死循環(huán)率壓到0。第三層尤其有效它逼著模型在每輪工具調(diào)度后做一次“自我審問”而不是機(jī)械地繼續(xù)行動(dòng)。5.2 工具調(diào)用參數(shù)亂抽用戶口語(yǔ)化表達(dá)導(dǎo)致參數(shù)殘缺用戶真實(shí)說(shuō)的話往往非常隨意比如“查下還有貨沒”這個(gè)請(qǐng)求里完全沒有商品編號(hào)。模型面對(duì)缺失參數(shù)時(shí)有兩種處理方式要么瞎猜一個(gè)編號(hào)要么反問用戶。我們?cè)陂_發(fā)時(shí)必須主動(dòng)設(shè)計(jì)好缺失參數(shù)時(shí)的行為策略。我的經(jīng)驗(yàn)是在Prompt里顯式聲明“信息不足時(shí)反問澄清不要猜測(cè)”。剛開始做Agent時(shí)我生怕多問用戶一輪顯得不智能,但實(shí)際運(yùn)營(yíng)下來(lái)寧可多問一句也不能猜猜錯(cuò)了一次用戶信任基本就歸零了。更進(jìn)階一點(diǎn)的做法是設(shè)計(jì)一個(gè)“參數(shù)補(bǔ)全”子循環(huán)。模型發(fā)現(xiàn)參數(shù)不全時(shí)先輸出一個(gè)結(jié)構(gòu)化問題列表系統(tǒng)把這些問題組裝成自然語(yǔ)言發(fā)給用戶拿到用戶補(bǔ)充回復(fù)后再重新走規(guī)劃。這個(gè)流程可以讓Agent在“澄清”和“執(zhí)行”之間靈活切換。5.3 多工具場(chǎng)景下調(diào)度混亂怎么讓模型知道“該用哪個(gè)工具”工具少的時(shí)候還好工具一旦超過五六個(gè)模型就容易分不清邊界。比如你有query_inventory、query_price、query_order_status三個(gè)工具用戶問“我上次買的那款還有嗎”模型極有可能去調(diào)query_inventory而不是query_order_status。我的解法是兩層第一層給每個(gè)工具加“排除條件”。比如query_inventory的描述里寫明“僅查詢當(dāng)前可用庫(kù)存不包含歷史訂單信息訂單狀態(tài)請(qǐng)使用query_order_status”。第二層加一個(gè)“意圖路由”前置模塊用一次輕量模型調(diào)用把用戶意圖粗分成幾個(gè)類別庫(kù)存類、價(jià)格類、訂單類然后只向規(guī)劃模型暴露該類別相關(guān)的工具列表。這相當(dāng)于把一個(gè)巨大的工具選擇空間折疊成幾個(gè)小空間模型的選擇準(zhǔn)確率會(huì)明顯提升。5.4 上下文爆炸與Token超限如何設(shè)計(jì)合理的裁剪策略Agent的上下文消耗速度遠(yuǎn)快于普通聊天因?yàn)槊枯喒ぞ哒{(diào)用、工具結(jié)果、思考過程都會(huì)累積進(jìn)上下文。任務(wù)稍微復(fù)雜一點(diǎn)幾千Token很快就被吃光。我知道有人為了省Token給Agent換了超大上下文窗口的模型但這只是拖延問題不是解決問題。更合理的做法是“分層壓縮”歷史對(duì)話按時(shí)間分段久遠(yuǎn)的對(duì)話通過摘要壓縮成一段簡(jiǎn)介工具結(jié)果只保留結(jié)構(gòu)化要點(diǎn)中間推理過程標(biāo)記為可裁剪片段一旦Agent進(jìn)入下一個(gè)子任務(wù)之前的思考過程就折疊掉。我測(cè)試過這套策略能在保持任務(wù)成功率的前提下把Token開銷降低40%以上。5.5 可觀測(cè)性Agent項(xiàng)目的“行車記錄儀”最后一項(xiàng)也是我強(qiáng)烈建議每個(gè)Agent項(xiàng)目必須做的完整日志。Agent的決策鏈路比傳統(tǒng)程序長(zhǎng)得多一個(gè)錯(cuò)誤可能來(lái)自模型理解、工具編寫、參數(shù)抽取、上下文污染等任意環(huán)節(jié)。沒有日志就只能靠猜。我要求項(xiàng)目里每個(gè)Agent調(diào)用點(diǎn)必須記錄以下字段用戶原始輸入、組裝后的最終Prompt、模型完整輸出包括思考內(nèi)容和工具調(diào)用、工具執(zhí)行結(jié)果、每步耗時(shí)、Token消耗。排查問題時(shí)第一件事就是打開日志看“模型在這一步到底看到了什么”。這個(gè)習(xí)慣幫我在無(wú)數(shù)個(gè)深夜快速定位問題強(qiáng)烈推薦。5.6 快速排查速查表現(xiàn)象可能原因優(yōu)先排查方向Agent反復(fù)調(diào)用同一工具死循環(huán) / 模型認(rèn)為沒拿到答案是否缺少反射提示工具結(jié)果是否明確參數(shù)抽取錯(cuò)誤工具參數(shù)描述不夠清晰 / 上下文信息不足檢查參數(shù)描述是否包含抽取指引Prompt是否有“缺失參數(shù)反問”策略工具選擇錯(cuò)誤多個(gè)工具邊界模糊 / 模型被無(wú)關(guān)工具干擾檢查工具描述排除條件考慮加意圖路由前置模塊回答內(nèi)容偏離工具結(jié)果上下文串?dāng)_ / 工具結(jié)果格式混亂檢查工具結(jié)果是否統(tǒng)一帶前綴標(biāo)識(shí)是否只保留關(guān)鍵信息突然Token超限裁剪策略失效 / 某輪工具結(jié)果過大檢查工具結(jié)果是否原樣回填歷史摘要是否正常折疊模型輸出格式不穩(wěn)定temperature過高 / Prompt約束不足降低temperature增加輸出格式示例必要時(shí)改用結(jié)構(gòu)化輸出模式6. 從Demo到上線給初學(xué)者的幾條忠告6.1 Demo能跑只是開始穩(wěn)定才是門檻大多數(shù)Agent項(xiàng)目死在“Demo很驚艷上線就翻車”這個(gè)階段。原因是Demo通常只覆蓋happy path真實(shí)用戶輸入千奇百怪安全邊界也沒法窮盡。我在項(xiàng)目上線前會(huì)做三件額外的事異常輸入測(cè)試亂碼、惡意指令、方言口語(yǔ)、超時(shí)與限流設(shè)計(jì)、人工兜底方案。6.2 成本控制Agent是真“吞金獸”Agent的Token開銷通常是普通聊天應(yīng)用的數(shù)倍甚至十倍以上因?yàn)槊恳惠喫伎肌⒐ぞ哒{(diào)度都在消耗Token。上線前一定要摸清單次任務(wù)平均成本并設(shè)置單用戶每日成本上限。我見過一個(gè)團(tuán)隊(duì)Agent效果不錯(cuò)但一個(gè)月Token賬單比人力成本還高最后被迫縮減功能。6.3 安全與隱私Agent放大了模型的安全風(fēng)險(xiǎn)Agent能調(diào)用外部工具意味著如果Prompt被注入惡意指令可能觸發(fā)危險(xiǎn)操作。我們必須對(duì)Agent可接觸的工具做最少權(quán)限設(shè)計(jì)能查不能改、能讀不能刪。同時(shí)要對(duì)敏感操作設(shè)置二次確認(rèn)或者人工審批環(huán)節(jié)。我在實(shí)際項(xiàng)目里有一條鐵律凡是寫操作類工具必須從技術(shù)架構(gòu)上保證Agent無(wú)法單方面完成——要么需要用戶二次確認(rèn)要么需要人工審批絕不把完整寫權(quán)限直接暴露給模型。這條原則救過我很多次因?yàn)槟Ｐ捅徽T導(dǎo)誤觸發(fā)刪除類操作的概率比大多數(shù)人想象的要高。6.4 大模型Agent開發(fā)的后續(xù)拓展方向當(dāng)你把最基礎(chǔ)的循環(huán)跑通后可以往幾個(gè)方向深挖給Agent加長(zhǎng)期記憶讓它記住用戶的偏好和歷史接多模態(tài)模型讓Agent能處理圖片、語(yǔ)音等輸入把多個(gè)專業(yè)Agent組合成多Agent協(xié)作系統(tǒng)利用大模型微調(diào)技術(shù)定制屬于自己業(yè)務(wù)領(lǐng)域的小模型底座。每個(gè)方向展開都是一個(gè)深水區(qū)但底層邏輯都是我們?cè)谏厦娌鸾獾哪撬牟窖h(huán)感知、規(guī)劃、行動(dòng)、反思。做Agent開發(fā)這一年多我最大的感受是這個(gè)領(lǐng)域看起來(lái)門檻低好像會(huì)調(diào)Prompt就能上手但真正決定項(xiàng)目成敗的往往是那些不顯眼的工程細(xì)節(jié)——上下文怎么管、工具怎么設(shè)計(jì)、日志怎么記、異常怎么兜底。AI的能力進(jìn)步很快但工程化的基本功永遠(yuǎn)不會(huì)過時(shí)。希望這篇分享能讓你少踩幾個(gè)我踩過的坑把精力放在真正有價(jià)值的事情上。