最近一年多我大部分業(yè)余時(shí)間都花在了AI智能體開發(fā)上。原因很簡單模型能力已經(jīng)很能打了但把它做成一個(gè)真正能用的應(yīng)用還有不少“最后一公里”的事要做。市面上聊智能體的內(nèi)容非常多可大多數(shù)不是偏概念就是講單點(diǎn)技巧能把“怎么從一行模型API調(diào)用逐步做成一套能上線的業(yè)務(wù)系統(tǒng)”講透的資料確實(shí)不多。我花了幾周時(shí)間跟進(jìn)了一門實(shí)操向的AI智能體開發(fā)課程講師是一位做AI落地多年的工程師。課程從最基礎(chǔ)的工程準(zhǔn)備開始一路講到帶記憶、帶外部知識庫、能自動(dòng)拆解任務(wù)的多Agent系統(tǒng)整體走下來收獲非常大。這篇文章就結(jié)合我對課程內(nèi)容的理解再加上自己實(shí)操過程中的真實(shí)感受把一條完整的智能體全棧開發(fā)路徑拆開講清楚。如果你正準(zhǔn)備進(jìn)入這個(gè)方向或者已經(jīng)在寫Agent但總覺得哪里不踏實(shí)這篇應(yīng)該能幫你補(bǔ)上一些關(guān)鍵拼圖。1. 課程主線復(fù)盤一套能落地的全棧智能體思路1.1 到底什么是“全棧智能體開發(fā)”先說一個(gè)容易混淆的點(diǎn)。這里說的“全?！辈皇乔岸思雍蠖四翘兹珬６侵赴涯Ｐ湍芰?、業(yè)務(wù)邏輯、外部工具、數(shù)據(jù)存儲(chǔ)、線上部署這幾層全部打通。很多教程只教你調(diào)接口拿到結(jié)果就結(jié)束了但實(shí)際業(yè)務(wù)里模型輸出只是一個(gè)中間產(chǎn)物怎么讓任務(wù)被正確拆解、工具被可靠調(diào)用、結(jié)果被結(jié)構(gòu)化保存、服務(wù)能穩(wěn)定跑在線上這些問題才是真正消磨時(shí)間的地方。課程的主線可以用一句話概括讓AI真正“做事”而不只是“說話”。這句話聽起來簡單實(shí)際拆開有四個(gè)層次。第一層是模型接入解決“模型怎么被調(diào)用”的問題包括接口參數(shù)、上下文管理、輸出格式控制。第二層是能力擴(kuò)展給模型配工具包括函數(shù)定義、外部API對接、結(jié)構(gòu)化返回解決“模型能調(diào)用什么”的問題。第三層是任務(wù)編排對應(yīng)多步推理、狀態(tài)管理、記憶持久化解決“復(fù)雜任務(wù)怎么被逐步完成”的問題。第四層是應(yīng)用工程化包括部署、監(jiān)控、日志、成本控制解決“這套東西怎么穩(wěn)定跑起來”的問題。課程整條鏈路都是按這四個(gè)層次組織的。它不是一上來直接丟概念而是從最普通的對話接口講起每個(gè)階段都有能跑的代碼例子然后逐步替換成更復(fù)雜的結(jié)構(gòu)。這樣的編排有一個(gè)很實(shí)際的好處你在任何一步卡住了都能從上一階段找到對應(yīng)的調(diào)試方法而不是面對一個(gè)黑盒。1.2 課程內(nèi)容編排背后的邏輯我最初有點(diǎn)不理解為什么課程要在“工程規(guī)范”上花那么多時(shí)間很枯燥但后來發(fā)現(xiàn)這恰恰是關(guān)鍵。拿我自己踩過的坑舉例早期寫Agent腳本所有參數(shù)直接寫在代碼里日志用print代替模型版本也不記錄。后來有一天模型服務(wù)升級了輸出風(fēng)格變了同樣的提示詞得到的調(diào)參結(jié)果完全對不上我花了兩個(gè)晚上排查最后才發(fā)現(xiàn)是上游模型行為變化。講師在第一周就強(qiáng)制要求了一套工程基線配置文件獨(dú)立、日志結(jié)構(gòu)化、所有prompt和模型版本進(jìn)版本庫。聽起來像老生常談但做過的人都知道這些小習(xí)慣在Agent開發(fā)里比傳統(tǒng)Web開發(fā)更重要因?yàn)锳I行為有不確定性沒有記錄就沒法復(fù)盤。課程的進(jìn)階部分也沒有直接講“多Agent多?！倍窍劝褑蜛gent的能力邊界講清楚。它反復(fù)強(qiáng)調(diào)一個(gè)觀點(diǎn)一個(gè)Agent如果連工具調(diào)用都會(huì)出錯(cuò)、上下文都管不好那么多Agent只是把錯(cuò)誤復(fù)制多份。這種從單點(diǎn)能力到系統(tǒng)能力的遞進(jìn)才是“從實(shí)操到進(jìn)階”的正確路徑而不是一上來就畫出宏大的架構(gòu)圖。1.3 適合誰學(xué)怎么學(xué)最有效按我的體驗(yàn)最適合這門課的有兩類人。一類是有Python基礎(chǔ)、做過業(yè)務(wù)后端或數(shù)據(jù)處理開發(fā)的工程師想把大模型接入現(xiàn)有系統(tǒng)但缺少一套成體系的思路。另一類是產(chǎn)品經(jīng)理或獨(dú)立開發(fā)者已經(jīng)用現(xiàn)成Agent產(chǎn)品做過一些自動(dòng)化現(xiàn)在想理解底層實(shí)現(xiàn)自己定制流程。零基礎(chǔ)能不能學(xué)能但要付出更多額外成本。課程默認(rèn)你會(huì)寫Python、能理解HTTP接口和JSON這些前置能力如果不足聽課會(huì)很吃力。畢竟這不是科普視頻而是實(shí)打?qū)崒懘a的工程課。學(xué)習(xí)方法上我的建議是“一邊看一邊寫寫完第二遍再獨(dú)立寫一遍”。第一遍照著跑通知道鏈路是怎么串起來的第二遍關(guān)掉參考答案憑理解和文檔自己實(shí)現(xiàn)同功能你會(huì)發(fā)現(xiàn)很多第一遍以為看懂了的細(xì)節(jié)其實(shí)是模糊的。這個(gè)課程練習(xí)量不小但把它當(dāng)成“帶源碼的實(shí)戰(zhàn)項(xiàng)目”而不是“可看視頻”收獲會(huì)翻倍。2. 動(dòng)手之前2025年做智能體開發(fā)先解決這4件事2.1 開發(fā)語言與運(yùn)行環(huán)境怎么定Python 在AI生態(tài)里的統(tǒng)治地位暫時(shí)沒被撼動(dòng)模型SDK、數(shù)據(jù)處理、工具生態(tài)都最成熟所以課程默認(rèn)使用Python。但有幾個(gè)環(huán)境層面的細(xì)節(jié)新手很容易忽略。首先是用虛擬環(huán)境隔離依賴。同一個(gè)系統(tǒng)里可能同時(shí)存在多個(gè)項(xiàng)目各自依賴不同版本的模型SDK或工具庫混在一起遲早出問題。起步就建獨(dú)立虛擬環(huán)境可以省掉后期很多“為什么別人能跑我不能跑”的麻煩。其次是配置管理。API密鑰、模型名稱、溫度參數(shù)、超時(shí)時(shí)間等不應(yīng)該硬編碼在代碼里應(yīng)該統(tǒng)一放在配置文件或環(huán)境變量中。我習(xí)慣維護(hù)一個(gè)全局配置模塊所有參數(shù)只在這個(gè)模塊里定義其他代碼統(tǒng)一引用。這樣調(diào)整模型或參數(shù)時(shí)不需要?jiǎng)訕I(yè)務(wù)邏輯風(fēng)險(xiǎn)小很多。第三是本地緩存層。Agent開發(fā)中經(jīng)常出現(xiàn)重復(fù)調(diào)用模型做相似處理的情況比如同一份報(bào)告反復(fù)摘要、同一段知識反復(fù)向量化。提前引入緩存方案能大幅節(jié)省成本后面章節(jié)我會(huì)單獨(dú)講。2.2 Agent框架到底要不要用這是每個(gè)新手都會(huì)糾結(jié)的問題。市面上有很多成熟的Agent編排框架它們提供了工具調(diào)用、任務(wù)循環(huán)、記憶管理等現(xiàn)成模塊可以讓你在很短時(shí)間拼出一個(gè)能跑的Agent。但課程的立場很明確先用裸的模型接口跑通一個(gè)最小案例再?zèng)Q定要不要引入框架。原因是框架會(huì)隱藏很多細(xì)節(jié)。以“模型自己決定調(diào)用哪個(gè)工具”為例看起來只是配置幾個(gè)函數(shù)名但當(dāng)你遇到參數(shù)格式錯(cuò)誤、工具結(jié)果回傳方式不正確、模型循環(huán)調(diào)用工具停不下來這類問題時(shí)如果不懂底層協(xié)議你連排查的方向都沒有。先徒手寫一遍理解四件事系統(tǒng)提示詞怎么約束行為、函數(shù)描述怎么影響模型判斷、工具返回值怎么進(jìn)入下一輪推理、上下文怎么截?cái)?。有了這些底層認(rèn)知再上手框架你會(huì)知道它幫你解決了什么、又可能在哪些地方坑你。我的個(gè)人選擇是普通工具型Agent徒手寫并不復(fù)雜反而更容易控制細(xì)節(jié)需要復(fù)雜編排、多Agent協(xié)作或大量插件時(shí)再引入框架。沒必要為了“顯得專業(yè)”而強(qiáng)行加一層依賴。2.3 工程規(guī)范日志、版本、可觀測性課程里有一句話讓我印象深刻“AI應(yīng)用出bug的第一步是確定這個(gè)bug是模型問題、代碼問題還是數(shù)據(jù)問題?！毕牖卮疬@個(gè)問題必須有分層日志。我在實(shí)操中的具體做法是這樣分的。模型調(diào)用日志記錄發(fā)送的提示詞、返回內(nèi)容、token消耗和耗時(shí)工具執(zhí)行日志記錄哪個(gè)工具被調(diào)用、輸入?yún)?shù)是什么、返回結(jié)果是什么業(yè)務(wù)邏輯日志記錄當(dāng)前任務(wù)狀態(tài)、上下文長度、分支判斷依據(jù)。三層分開記錄排查問題的時(shí)候能迅速定位鏈條上哪一環(huán)出了問題。另外每一次可復(fù)現(xiàn)的實(shí)驗(yàn)都要產(chǎn)出一份“配方”模型版本、提示詞內(nèi)容、參數(shù)、輸入數(shù)據(jù)、輸出結(jié)果。這份配方聽起來很簡單但人在緊急趕工的時(shí)候很容易省略。省略一次下一次調(diào)優(yōu)就沒有對照基礎(chǔ)效果好壞全靠感覺非常危險(xiǎn)。至于可觀測性不必一上來就搭建監(jiān)控平臺(tái)最低限度是把日志結(jié)構(gòu)化輸出讓它能被日志工具檢索。達(dá)到“出問題能搜到對應(yīng)上下文”這個(gè)標(biāo)準(zhǔn)就足夠了早期項(xiàng)目沒必要過度設(shè)計(jì)。3. 核心概念拆解Agent是怎么“長出手腳”的3.1 提示詞不是玄學(xué)是一套約束系統(tǒng)很多同學(xué)對提示詞工程的理解停留在“把話說明白”但真正做過Agent就會(huì)發(fā)現(xiàn)提示詞在設(shè)計(jì)上有一套工作流。系統(tǒng)提示詞用來定義角色、能力和限制范圍用戶提示詞負(fù)責(zé)輸入本次任務(wù)內(nèi)容輸出約束則告訴模型返回什么格式、遵循什么結(jié)構(gòu)。在Agent開發(fā)中我特別強(qiáng)調(diào)“結(jié)構(gòu)化輸出約束”。比如讓模型返回一個(gè)工具調(diào)用結(jié)果我會(huì)要求它返回一個(gè)JSON對象包含狀態(tài)、結(jié)果、錯(cuò)誤信息三個(gè)字段。模型本身不一定每句都理解你的中文注釋但JSON Schema這種結(jié)構(gòu)性約束它大概率能遵循。實(shí)操中還要做好兜底用代碼解析模型輸出解析失敗就觸發(fā)重試而不是默認(rèn)相信模型每次都返回合法JSON否則后面流程隨時(shí)會(huì)崩。還有一個(gè)常用技巧是“少樣本”補(bǔ)充。如果抽象約束無法讓模型穩(wěn)定輸出某種風(fēng)格就給一兩個(gè)輸入輸出對作為示例。我試過最典型的情況讓模型從對話文本里抽取結(jié)構(gòu)化字段只寫規(guī)則時(shí)它總漏字段加上一個(gè)完整示例后準(zhǔn)確率立刻上升。提示詞不是一次性寫對的按“規(guī)則先行、示例補(bǔ)充、失敗迭代”的方法來效率最高。3.2 工具調(diào)用的設(shè)計(jì)讓模型擁有行動(dòng)力讓Agent調(diào)用工具本質(zhì)上是讓模型在對話過程中輸出一個(gè)“意圖結(jié)構(gòu)”代碼端解析這個(gè)結(jié)構(gòu)并執(zhí)行具體函數(shù)。因此工具設(shè)計(jì)的好不好直接影響Agent能不能準(zhǔn)確完成工作。這里有幾個(gè)我總結(jié)的關(guān)鍵點(diǎn)。工具描述要寫“什么時(shí)候用”和“什么時(shí)候不用”。模型不是人它不會(huì)自動(dòng)明白“保存到數(shù)據(jù)庫”和“更新數(shù)據(jù)庫”有什么區(qū)別。描述里明確使用條件和邊界能顯著減少誤調(diào)用。比如一個(gè)“發(fā)送告警通知”工具描述里應(yīng)該寫“當(dāng)用戶明確要求發(fā)送通知或檢測到異常且異常等級為高時(shí)調(diào)用僅做記錄時(shí)不要調(diào)用”。工具數(shù)量寧少勿多。工具越多模型選錯(cuò)的概率越大。能用兩個(gè)工具覆蓋的場景絕不上五個(gè)。課程里常見做法是“收口”把多個(gè)相似操作合并成一個(gè)接受參數(shù)的工具比讓模型在狹窄選項(xiàng)里做語義判斷更可靠。工具入?yún)⒁獓?yán)格定義。每個(gè)參數(shù)的類型、含義、取值范圍都要寫清楚。如果參數(shù)是枚舉值把可選值列出來。模型在生成參數(shù)時(shí)也會(huì)犯錯(cuò)代碼端必須做參數(shù)校驗(yàn)不合法就返回錯(cuò)誤信息讓模型重新修正。我見過最多的問題是模型把日期格式傳錯(cuò)或者把數(shù)字傳成字符串導(dǎo)致下游直接崩潰。3.3 狀態(tài)與記憶多輪任務(wù)為什么難做很多人以為Agent就是“聊天加工具”但真實(shí)業(yè)務(wù)里用戶往往帶著上下文連續(xù)提出多條需求。比如“先幫我查一下三月份訂單再把金額最高的三家客戶整理成表格最后給其中兩個(gè)發(fā)預(yù)熱郵件”。這個(gè)任務(wù)里每一步依賴前一步的結(jié)果而且中間狀態(tài)需要被記住。課程把記憶拆成三個(gè)層次會(huì)話級記憶、用戶級記憶、全局業(yè)務(wù)狀態(tài)。會(huì)話級記憶負(fù)責(zé)當(dāng)前對話的上下文用戶級記憶保存用戶的偏好和歷史關(guān)鍵信息全局業(yè)務(wù)狀態(tài)則是任務(wù)執(zhí)行中產(chǎn)生的中間產(chǎn)物比如查詢結(jié)果、臨時(shí)結(jié)論、待辦列表。作為新手最容易犯錯(cuò)的是把所有內(nèi)容一股腦塞進(jìn)模型上下文。這不只是成本問題也是效果問題上下文堆得越長模型越容易迷失重點(diǎn)、輸出質(zhì)量下降。實(shí)操中要做“有損壓縮”對話開始階段保留原始內(nèi)容隨著對話變長逐步用摘要代替原文只保留與當(dāng)前任務(wù)相關(guān)的事實(shí)。我用過一個(gè)很直接的標(biāo)準(zhǔn)如果某段信息在后續(xù)對話中幾乎不會(huì)被引用就盡快從上下文中移出需要時(shí)再去查。狀態(tài)管理的核心思路是把“模型的思考”和“系統(tǒng)的存儲(chǔ)”分開。模型負(fù)責(zé)推理和決策服務(wù)器負(fù)責(zé)可靠保存狀態(tài)兩者交替協(xié)作而不是讓模型一邊推理一邊記事那既不經(jīng)濟(jì)也不可控。4. 實(shí)操記錄從零搭一個(gè)可以用的會(huì)議紀(jì)要Agent4.1 需求定義一個(gè)具體的場景課程中期有一個(gè)項(xiàng)目練習(xí)目標(biāo)很接地氣給一個(gè)團(tuán)隊(duì)做內(nèi)部的會(huì)議紀(jì)要Agent輸入是會(huì)議語音轉(zhuǎn)出來的文字稿輸出是結(jié)構(gòu)化的會(huì)議紀(jì)要包括議題摘要、關(guān)鍵決策、待辦事項(xiàng)、風(fēng)險(xiǎn)提示。這個(gè)需求看起來簡單其實(shí)非常適合用來練手因?yàn)樗瑫r(shí)用到文本處理、工具調(diào)用、結(jié)構(gòu)化輸出和狀態(tài)管理。我把需求進(jìn)一步細(xì)化了三條。第一輸出必須是結(jié)構(gòu)化數(shù)據(jù)不能是一段大作文因?yàn)楹罄m(xù)要導(dǎo)入任務(wù)表。第二待辦事項(xiàng)需要關(guān)聯(lián)負(fù)責(zé)人和截止時(shí)間如果原文里沒提到要能根據(jù)上下文推斷并標(biāo)記“待確認(rèn)”。第三能處理超過模型上下文上限的長會(huì)議稿要自動(dòng)切分并匯總。這三條要求基本復(fù)現(xiàn)了工作里會(huì)遇到的問題格式需求、信息補(bǔ)全、長文本處理。4.2 核心鏈路設(shè)計(jì)基于這個(gè)需求我設(shè)計(jì)了一條五步主流程。第一步是預(yù)處理。把原始文字稿里的發(fā)言角色、時(shí)間戳、重復(fù)語氣詞做初步清理避免模型被噪聲干擾。第二步是分段。按發(fā)言段落或時(shí)間窗口切分文本每段控制在模型能高質(zhì)量處理的長度。第三步是單段摘要。讓模型分別提取每個(gè)小段的核心觀點(diǎn)、決策和待辦。第四步是聚合。把所有分段摘要合在一起生成全局的結(jié)構(gòu)化紀(jì)要。第五步是校驗(yàn)與導(dǎo)出。檢查輸出的JSON是否符合預(yù)設(shè)格式再寫入數(shù)據(jù)庫并觸發(fā)后續(xù)通知。這套結(jié)構(gòu)本質(zhì)上是用“分而治之”解決上下文長度限制。不用把所有原文塞進(jìn)一次調(diào)用而是讓模型“分段消化再匯總”。缺點(diǎn)是分段邊界可能切斷上下文需要在切分時(shí)保持段落完整性而不是機(jī)械地按字?jǐn)?shù)截?cái)?。我試過更粗暴的固定長度切分結(jié)果同一個(gè)人的發(fā)言被拆成兩段語義割裂導(dǎo)致摘要質(zhì)量明顯下降。4.3 關(guān)鍵實(shí)現(xiàn)要點(diǎn)在實(shí)現(xiàn)這個(gè)Agent時(shí)我沒有用任何現(xiàn)成Agent框架只依靠模型接口和少量膠水代碼核心思路如下。class MeetingAgent: def __init__(self, model_client, store, parser): self.model model_client self.store store self.parser parser def run(self, raw_text, meeting_meta): segments self.preprocess_and_split(raw_text) summaries [] for seg in segments: result self.summarize_segment(seg) if not result.valid: result self.retry_with_fix(seg, result.error) summaries.append(result) final_doc self.aggregate_summaries(summaries, meeting_meta) return self.validate_and_save(final_doc)偽代碼里最關(guān)鍵的是retry_with_fix。這個(gè)函數(shù)的作用是當(dāng)模型某一步返回結(jié)果不通過校驗(yàn)時(shí)不盲目重跑而是把校驗(yàn)錯(cuò)誤信息拼回去讓模型去修正。信息反饋在提示詞里第二輪生成效果一般比單純重試好得多。提示詞部分系統(tǒng)提示詞我會(huì)固定這套邏輯“你是會(huì)議紀(jì)要助手你會(huì)收到會(huì)議文字稿或分段摘要。你的任務(wù)是從中提取信息并嚴(yán)格按JSON結(jié)構(gòu)返回。不要補(bǔ)充原文不存在的信息不確定的內(nèi)容標(biāo)記為待確認(rèn)?！比缓蠼o出目標(biāo)JSON的字段說明再給一條示例。溫度參數(shù)我設(shè)置得很低0到0.2之間。紀(jì)要生成這種任務(wù)需要確定性高不需要?jiǎng)?chuàng)意溫度高只會(huì)帶來無謂的風(fēng)格波動(dòng)。輸出解析我堅(jiān)持“先校驗(yàn)再入庫”的流程用JSON解析和字段存在性檢查作為兜底而不是直接信任文本。4.4 效果驗(yàn)證和調(diào)優(yōu)記錄這個(gè)Agent第一版跑下來問題主要集中在三塊。一是長會(huì)議稿的最后部分經(jīng)常有內(nèi)容丟失原因是分段聚合時(shí)模型傾向于只保留前面信息。我采取的解決辦法是在聚合提示詞里增加一個(gè)“檢查清單”列出會(huì)議中必須覆蓋的幾種信息類型讓模型逐項(xiàng)對照是否都有輸出明顯減少了遺漏。二是負(fù)責(zé)人識別錯(cuò)誤。原文里經(jīng)常出現(xiàn)“這個(gè)讓某某跟進(jìn)”模型有時(shí)會(huì)把“某某”理解成人名但這個(gè)人沒在與會(huì)名單里。我在預(yù)處理階段先做了與會(huì)人員名單匹配然后要求模型只能從名單中選擇負(fù)責(zé)人超出名單則標(biāo)記待確認(rèn)。準(zhǔn)確率提升明顯。三是輸出格式偶發(fā)不合法。這個(gè)靠兩步解決第一步是重試機(jī)制第二次生成時(shí)把解析錯(cuò)誤信息返回給模型第二步是最終兜底如果嘗試三次仍失敗把該段結(jié)果標(biāo)記為失敗保留原文片段存入待人工處理隊(duì)列。我始終堅(jiān)持“寧缺毋濫”寧可讓一段內(nèi)容等待人工確認(rèn)也不能讓錯(cuò)誤數(shù)據(jù)靜默入庫。5. 進(jìn)階方向RAG、持久化記憶與多Agent協(xié)作5.1 檢索增強(qiáng)生成RAG的落地細(xì)節(jié)當(dāng)Agent需要基于私有知識庫回答問題時(shí)RAG是繞不開的方案。課程里沒有只講“把文檔切片、向量化、相似度檢索”的流程而重點(diǎn)講了幾個(gè)容易翻車的細(xì)節(jié)。切片尺寸和策略比模型選擇更影響召回質(zhì)量。切得太大檢索單元里混入很多無關(guān)內(nèi)容模型容易被噪聲干擾切得太小語義不完整同樣檢索不到。我常用的做法是結(jié)構(gòu)感知切分優(yōu)先按標(biāo)題和段落邊界切保持單元在幾百字左右并在切片時(shí)保留來源標(biāo)題、章節(jié)路徑等元信息。這樣不但檢索更準(zhǔn)還能在回答里給出出處方便追溯。向量檢索不是萬能的。它是一個(gè)語義近似匹配工具但很多業(yè)務(wù)問題其實(shí)靠關(guān)鍵詞就能解決得更準(zhǔn)比如型號、編號、專有名詞。我實(shí)戰(zhàn)里比較穩(wěn)的方案是混合檢索先跑一輪關(guān)鍵詞匹配再跑一輪向量召回然后把兩路結(jié)果合起來統(tǒng)一重排。切換到這個(gè)模式之后知識問答的準(zhǔn)確率有肉眼可見的提升。重排環(huán)節(jié)不用太復(fù)雜簡單的按分?jǐn)?shù)加權(quán)就能過濾掉很多不相關(guān)片段。5.2 記憶設(shè)計(jì)不要存儲(chǔ)所有對話持久化記憶是智能體從玩具走向工具的分水嶺。但很多設(shè)計(jì)會(huì)把“記住用戶所有對話”作為默認(rèn)目標(biāo)這是大坑。記憶的價(jià)值在于“下次用得上的信息”而不是“上次發(fā)生的事”。用戶在對話里說的絕大部分內(nèi)容是一次性指令不需要長期保留。我習(xí)慣把記憶分成三層。第一層是最新的若干輪原始對話直接放在上下文里處理短期任務(wù)第二層是當(dāng)前任務(wù)的結(jié)構(gòu)化中間狀態(tài)比如查詢條件、結(jié)果列表、確認(rèn)過的偏好任務(wù)結(jié)束時(shí)保留摘要第三層才是長期事實(shí)比如用戶的身份、常用賬戶、業(yè)務(wù)偏好、歷史關(guān)鍵決策這些才寫入持久化存儲(chǔ)。寫長期記憶也要有準(zhǔn)入規(guī)則。我會(huì)先判斷一條信息是否滿足三個(gè)條件與業(yè)務(wù)目標(biāo)相關(guān)、跨會(huì)話大概率會(huì)被復(fù)用到、不會(huì)頻繁變化。同時(shí)滿足才寫入。否則一律不寫。這樣能最大程度減少記憶污染越到后期你能明顯感受到干凈的記憶會(huì)讓Agent的決策更穩(wěn)定。5.3 多Agent協(xié)作哪些場景真的需要多Agent是這兩年的熱門詞但課程傳遞的一個(gè)重要觀點(diǎn)是“大部分單Agent能解決的問題不要上多Agent”。因?yàn)槊吭黾右粋€(gè)獨(dú)立Agent就意味著增加一次模型調(diào)用、一分延遲、一分失控風(fēng)險(xiǎn)整個(gè)系統(tǒng)的行為邊界也會(huì)更難約束。我自己的判斷標(biāo)準(zhǔn)是這樣的任務(wù)本身可以清晰拆成多個(gè)獨(dú)立子任務(wù)且子任務(wù)之間不需要頻繁同步中間結(jié)果時(shí)適合用多Agent管道如果子任務(wù)之間存在大量共享上下文或者需要從全局視角反復(fù)調(diào)整方案那一個(gè)Agent扮演多個(gè)角色反而更合適。最簡單的“主管-工人”模式最容易落地主管負(fù)責(zé)理解目標(biāo)、拆分任務(wù)、驗(yàn)收結(jié)果工人專注執(zhí)行單項(xiàng)任務(wù)。把上下文的全局視野集中在主管一側(cè)工人只接收清晰指令、返回固定結(jié)構(gòu)結(jié)果這樣既降低復(fù)雜度又保留并行能力。我也測過辯論模式讓兩個(gè)Agent互相提意見來提升輸出質(zhì)量。效果并不穩(wěn)定常常是觀點(diǎn)互相“說服”后得到一個(gè)保守平庸的結(jié)果消耗的token還翻倍?，F(xiàn)在我對這類花哨協(xié)作方式的態(tài)度是先想清楚收益在哪再?zèng)Q定用不用。6. 從腳本到服務(wù)部署與運(yùn)維繞不開的那些事6.1 服務(wù)化改造的三個(gè)基礎(chǔ)問題開發(fā)階段的Agent是腳本形態(tài)寫完了能跑但距離變成一個(gè)可被多個(gè)用戶同時(shí)訪問的服務(wù)還差三步異步化、限流、容錯(cuò)。第一個(gè)問題是慢。單個(gè)Agent任務(wù)少則幾秒多則幾十秒甚至幾分鐘。如果接口是同步等待模型返回很容易把服務(wù)線程占滿請求一多就整體卡死。我的做法是任務(wù)進(jìn)來后立即返回一個(gè)任務(wù)ID后臺(tái)異步執(zhí)行前端再輪詢或等推送結(jié)果。對用戶體驗(yàn)而言稍微復(fù)雜一點(diǎn)但換來的是服務(wù)基本不會(huì)被打掛。第二個(gè)問題是限流。模型服務(wù)有配額限制在高并發(fā)時(shí)會(huì)返回限流錯(cuò)誤。就算沒有配額限制無限量并發(fā)也會(huì)把成本快速抬高。我習(xí)慣在應(yīng)用層加一層并發(fā)控制只允許固定數(shù)量任務(wù)同時(shí)執(zhí)行其余排隊(duì)避免突發(fā)流量直接把預(yù)算沖爆。第三個(gè)問題是容錯(cuò)。模型調(diào)用總有失敗、超時(shí)、返回異常的可能。服務(wù)端必須把每一次失敗都當(dāng)作預(yù)期情況處理設(shè)置超時(shí)時(shí)間、失敗退避重試、連續(xù)失敗后熔斷。我曾遇到一次模型服務(wù)波動(dòng)Agent連續(xù)重試同一個(gè)失敗任務(wù)既浪費(fèi)時(shí)間又浪費(fèi)token。后來增加了失敗次數(shù)上限和人工介入隊(duì)列問題才算真正解決。6.2 成本控制與可觀測性模型API按token計(jì)費(fèi)貴不貴完全取決于你有沒有控制住上下文。我在上線后會(huì)給Agent的每次調(diào)用記錄上下文消耗并設(shè)置一個(gè)預(yù)算警戒線。當(dāng)某類任務(wù)的上下文消耗異常升高時(shí)優(yōu)先檢查是不是歷史記錄積壓多了、工具返回值被完整塞進(jìn)上下文了、或者同一個(gè)任務(wù)被重復(fù)循環(huán)調(diào)用。緩存是降本最直接的手段。相同或高度相似的輸入沒有必要每次都調(diào)用模型。我在前面加了基于指紋的緩存層只要輸入模板和關(guān)鍵參數(shù)完全一致直接返回緩存結(jié)果。對會(huì)議紀(jì)要、知識問答這類場景命中率很高成本能下降一個(gè)量級。日志這塊我額外強(qiáng)調(diào)記錄“決策路徑”。一個(gè)Agent任務(wù)完成后能把“它看到了什么、選擇了哪個(gè)工具、為什么選擇”完整回放出來。這個(gè)日志的價(jià)值在排障時(shí)才會(huì)體現(xiàn)出來。沒有它模型表現(xiàn)異常時(shí)你只能靠猜有了它大多數(shù)問題都能定位到具體環(huán)節(jié)。6.3 小步迭代用評估集避免“改壞”模型AI應(yīng)用上線后不是一勞永逸會(huì)持續(xù)調(diào)提示詞、換模型、調(diào)工具。最大的風(fēng)險(xiǎn)在于你修了A問題結(jié)果B場景變差了而你在當(dāng)前測試?yán)锔緵]覆蓋到B場景。應(yīng)對方案是建一個(gè)小型評估集把線上常見場景的輸入和期望行為固化下來。每次改動(dòng)上線前都拿評估集跑一遍對比改動(dòng)前后的輸出質(zhì)量。這個(gè)做法在傳統(tǒng)開發(fā)中相當(dāng)于回歸測試在Agent開發(fā)里不可或缺。我見過一些團(tuán)隊(duì)改了提示詞上線當(dāng)下任務(wù)變好了但過幾天不斷收到老用戶反饋“怎么變笨了”就是因?yàn)闆]有做回歸驗(yàn)證。評估集不用大二十到五十個(gè)真實(shí)用例就能擋住大部分回歸問題。7. 常見問題與排查技巧實(shí)錄7.1 模型輸出格式不穩(wěn)定怎么辦輸出格式不穩(wěn)定是Agent開發(fā)里出現(xiàn)頻率最高的問題。直接原因有三個(gè)沒有寫清楚輸出約束、溫度設(shè)置過高、沒加兜底解析。我的排查順序是固定的。先看系統(tǒng)提示詞里是否明確指定返回結(jié)構(gòu)光要求“返回JSON”不夠要給出具體字段含義和示例。再看溫度參數(shù)查查是不是被人誤設(shè)成了0.7甚至更高生成任務(wù)和創(chuàng)意任務(wù)完全是兩個(gè)參數(shù)區(qū)間。最后檢查代碼端解析是不是只做了最簡單的字符串匹配稍微有點(diǎn)前后空格或Markdown標(biāo)記就解析失敗。堅(jiān)持“約束、降參、兜底重試”三步走之后格式穩(wěn)定性會(huì)大幅提升。7.2 工具調(diào)用參數(shù)怎么老出錯(cuò)模型生成工具參數(shù)出錯(cuò)最常見的是枚舉值理解錯(cuò)誤、時(shí)間格式不統(tǒng)一、以及可選參數(shù)被漏填。這里不要指望模型變聰明靠工程手段更可靠。第一工具定義里的參數(shù)描述把每個(gè)字段的取值范圍寫清楚。第二代碼側(cè)做嚴(yán)格校驗(yàn)不合法就返回一個(gè)包含正確取值要求的錯(cuò)誤信息讓模型根據(jù)錯(cuò)誤提示自行修正。第三涉及多個(gè)相似工具時(shí)合并成帶不同類型參數(shù)的統(tǒng)一工具降低選擇歧義。另外在調(diào)用工具前記錄“模型本來的意圖”如果重試多次仍失敗可以回退到一個(gè)更保守的默認(rèn)策略而不是無限循環(huán)。7.3 上下文變長后效果明顯下降上下文過長會(huì)造成兩個(gè)問題推理質(zhì)量衰減和響應(yīng)延遲增大。不要指望模型能自動(dòng)處理長度問題應(yīng)該在應(yīng)用層做生命周期管理。我常用三種策略。第一種是摘要在前、原文在后把已經(jīng)處理過的長文本壓縮成摘要只在需要精確引用時(shí)才保留原文。第二種是窗口截?cái)嘀槐Ａ襞c當(dāng)前節(jié)點(diǎn)最近的相關(guān)消息更早的全部丟棄。第三種是外置檢索當(dāng)業(yè)務(wù)需要引用大段歷史內(nèi)容時(shí)不把整篇?dú)v史塞進(jìn)上下文只把檢索到的相關(guān)段落放進(jìn)去。實(shí)測最有效的是三種策略同時(shí)使用按場景動(dòng)態(tài)切換而不是用單一方式處理所有對話。7.4 多步任務(wù)執(zhí)行到一半失敗怎么恢復(fù)Agent執(zhí)行多步任務(wù)時(shí)任何一步失敗都可能讓后續(xù)步驟失去前置條件導(dǎo)致整個(gè)任務(wù)白跑。我的做法是給每個(gè)子任務(wù)建立獨(dú)立狀態(tài)明確標(biāo)記為待執(zhí)行、執(zhí)行中、成功、失敗待處理。失敗時(shí)不立即放棄而是基于錯(cuò)誤信息做定向重試。超過重試次數(shù)就把子任務(wù)放入人工處理隊(duì)列同時(shí)保留它所需的上下文。主任務(wù)的狀態(tài)只在所有關(guān)鍵子任務(wù)完成后才將變更為成功否則保持為進(jìn)行中。這個(gè)設(shè)計(jì)能讓長時(shí)間任務(wù)在偶發(fā)失敗后有機(jī)會(huì)修復(fù)而不是接到一個(gè)“整體失敗”的壞消息卻不知道從哪恢復(fù)。7.5 成本突然超支怎么定位成本突然上漲先別急著優(yōu)化提示詞按這三步排查。第一步看是不是出現(xiàn)了工具死循環(huán)模型反復(fù)調(diào)用同一個(gè)工具停不下來這種情況要立刻給調(diào)用次數(shù)加硬性上限。第二步檢查上下文膨脹查看日志里最后一輪請求攜帶的歷史消息量是否持續(xù)攀升如果是說明截?cái)嗖呗允?。第三步檢查緩存命中率如果大量相同輸入都在重復(fù)調(diào)模型則緩存邏輯有問題。定位到現(xiàn)象再優(yōu)化不要憑感覺瞎調(diào)。最后說一個(gè)我自己體會(huì)最深的事。做AI智能體開發(fā)和傳統(tǒng)軟件開發(fā)最大的差別在于你面對的是一個(gè)概率系統(tǒng)不可能每時(shí)每刻都按預(yù)期工作。剛?cè)胄袝r(shí)我總想把一切控制到百分百穩(wěn)定后來發(fā)現(xiàn)這既不現(xiàn)實(shí)也沒必要。真正有效的思路是理解模型的不確定性然后用結(jié)構(gòu)化的工程手段把失敗留在可控范圍里再通過日志和評估去持續(xù)逼近更高穩(wěn)定性。想清楚這一點(diǎn)后面很多問題處理起來心態(tài)都會(huì)穩(wěn)很多。