做了三年大模型落地項目我最大的感受是2026年討論的東西和兩年前完全不是一回事了。2024年大家問“大模型能做什么”2025年問“怎么讓它答得更準”到了現(xiàn)在的節(jié)點所有人都在問同一句話——“怎么讓大模型真正幫我干活”。大模型落地應用2026的關鍵詞已經(jīng)從單純的模型能力比拼轉(zhuǎn)移到了“智能體平臺工程化能力業(yè)務場景”。聰明的大模型遍地都是真正稀缺的是把它變成能穩(wěn)定執(zhí)行任務、能接入企業(yè)系統(tǒng)、能控制成本和風險的那套落地方法論。這篇文章就是我基于多個真實項目整理的一手經(jīng)驗聊清楚智能體平臺怎么選、開發(fā)怎么上手、行業(yè)案例的坑在哪里爭取讓剛?cè)腴T的團隊少走三個月彎路。1. 大模型落地應用2026為什么智能體會成為標配1.1 從聊天機器到生產(chǎn)系統(tǒng)這一年到底變了什么我觀察到一個特別明顯的變化客戶的需求從“給我一個會說話的機器人”變成了“把這個流程里的人工操作替換掉”。之前很多人理解的“大模型落地”就是在網(wǎng)頁上掛一個對話框用戶問一句它答一句。這種模式的共同特征是只能“說”不能“做”所以2024年那一批客服機器人、智能問答Demo大部分做完就爛尾了。到了2026年行業(yè)共識基本形成了大模型如果只是聊天價值非常有限只有把模型放進一套能“感知-決策-執(zhí)行-反饋”的系統(tǒng)里它才真正算生產(chǎn)力。而這套系統(tǒng)就是智能體。換句話說2026年的大模型落地應用幾乎等于智能體應用。你可以沒有自己的基座模型但你不能沒有自己的智能體平臺和開發(fā)能力。今年我經(jīng)手的項目里凡是跑出實際業(yè)務價值的無一例外都是智能體形態(tài)有的是客服工單閉環(huán)有的是企業(yè)內(nèi)部知識助手有的是數(shù)據(jù)分析Agent有的是流程自動化機器人。它們的大模型底層可能長得差不多但工程架構(gòu)、平臺選型、評測方式完全不同這也直接決定了項目是穩(wěn)定賺錢還是反復返工。1.2 智能體的本質(zhì)“模型記憶工具執(zhí)行”四件套很多人對智能體有誤解以為像科幻片里那種全知全能數(shù)字人。實際上生產(chǎn)環(huán)境里的智能體拆開來看只有四個部分模型承擔理解和生成的核心能力決定智商上限記憶短期對話記憶加長期用戶畫像決定它“是不是記得之前說過的話”工具調(diào)用API、查數(shù)據(jù)庫、發(fā)郵件、操作業(yè)務系統(tǒng)決定它“能不能干活”執(zhí)行與反饋決策要不要調(diào)用工具、調(diào)用失敗怎么處理、要不要問用戶確認決定它“靠不靠譜”這個結(jié)構(gòu)非常重要因為所有項目里遇到的“智能體不聽話”“亂調(diào)用工具”“答非所問”根因幾乎都在四件套的銜接上而不在模型本身。大模型本身只是一個推理和生成的引擎真正要落地的是把記憶、工具、執(zhí)行策略像流水線一樣編排起來。這也是為什么行業(yè)里冒出一堆智能體平臺——大家發(fā)現(xiàn)從零搭這套流水線太費勁了需要有人把基礎設施做掉。2. 智能體平臺選型先別寫代碼先想清楚這五層2.1 平臺五層架構(gòu)拆解這幾年國內(nèi)外涌現(xiàn)了大量智能體平臺名字五花八門但底層架構(gòu)大差不差。我一般會把一個合格的智能體平臺拆成五層來考察不管選哪種產(chǎn)品這五層一個都不能少。層級核心能力常見問題如果缺了會怎樣模型接入層統(tǒng)一封裝不同模型API支持切換、降級、負載均衡換模型要改邏輯單點故障直接癱編排層工作流定義、多Agent協(xié)作、條件分支、循環(huán)只能做單輪對話沒法處理復雜業(yè)務知識與記憶層向量存儲、文檔召回、短期/長期記憶管理回答全靠模型發(fā)揮壓根沒有企業(yè)記憶工具與插件層API工具注冊、MCP協(xié)議、工具調(diào)用管理與權限控制智能體只會說話不會干活可觀測與運營層日志追蹤、評測集、成本分析、人審回放出了問題找不到原因上線等于裸奔這五層里面最容易翻車的不是模型接入而是“可觀測與運營層”。我見過好幾個項目智能體功能都調(diào)通了一上線就出亂子結(jié)果平臺連完整的調(diào)用鏈路日志都沒有排了兩天查不出是檢索召回錯了還是模型決策錯了。所以選平臺第一條日志和追蹤能力必須強寧可選功能少一點但看得清的平臺也別選什么都行但黑盒的平臺。2.2 四類典型平臺與適用人群不同團隊基礎不一樣平臺選型其實沒有標準答案。我把市面上的解決方案歸納成四類開源編排框架型重視靈活性和定制能力適合有研發(fā)團隊的科技公司。優(yōu)點是代碼都在自己手里數(shù)據(jù)和流程完全可控缺點是需要自己部署和運維平臺能力是靠搭積木搭出來的工作量大。低代碼托管型主打快速驗證和業(yè)務自助業(yè)務運營也能上手搭Agent。典型特征是可視化編排、內(nèi)置知識庫和工具市場。適合中小團隊快速跑通業(yè)務閉環(huán)缺點是深度定制受限復雜邏輯需要妥協(xié)。云廠商整合型深度綁定云底座適合已經(jīng)上了某朵云、大量使用云上中間件的企業(yè)。好處是和現(xiàn)有賬號體系、數(shù)據(jù)庫、消息隊列打通順暢壞處是會在無形中被生態(tài)綁定。垂直場景型面向客服、營銷、HR等具體領域做好的開箱即用方案。業(yè)務匹配度最高但擴展能力往往比較弱很難跳出它預設的場景。2.3 選型清單與我的組合建議團隊找我咨詢平臺選型時我通常會讓他們先過一遍下面這份清單每一條都直接關系到后面的開發(fā)體驗和項目壽命部署方式數(shù)據(jù)能不能落私有化環(huán)境涉不涉及跨境傳輸擴展邊界能不能寫自定義代碼能不能接入企業(yè)內(nèi)網(wǎng)API工具協(xié)議是否支持MCP這類標準工具協(xié)議還是只能用內(nèi)置插件并發(fā)與性能壓測時能達到多少Q(mào)PS排隊機制怎么樣成本模型按調(diào)用量計費還是按實例計費token緩存怎么算生態(tài)與迭代速度平臺多久更新一次社區(qū)活躍度如何我目前比較順手的一套組合是把“知識密集型的對內(nèi)助手”放在低代碼托管平臺上快速迭代業(yè)務人員也能自己維護知識庫把“直接對客、對生產(chǎn)系統(tǒng)操作的鏈路”放在開源編排框架上自己定制核心邏輯完全掌控。兩個平臺統(tǒng)一走同一個模型網(wǎng)關這樣模型替換、成本監(jiān)控都是收口在一處的。別指望一個平臺吃遍所有場景做技術選型最忌諱的就是“一把梭”。3. 智能體開發(fā)指南從0到1搭建生產(chǎn)級智能體3.1 第一步定義邊界與評估指標開發(fā)智能體第一步不是寫Prompt也不是選模型而是先確定“這件事值不值得用智能體做”。我常用的判斷標準有四個流程是否高頻、規(guī)則是否可描述、是否有明確輸入輸出、錯誤代價是否可控。四項中至少占三項才值得做。確定場景之后緊接著要定義評估指標。這里我吃過一個虧第一個項目只盯了“回答準確率”結(jié)果準確率一路漲到90%業(yè)務方還是不買賬。后來才知道他們真正關心的是“首輪解決率”和“人工介入率”而這些指標不在我的評測體系里等于我做了個自嗨的Demo。生產(chǎn)級智能體建議至少同時追蹤五個指標任務完成率、工具調(diào)用成功率、單輪平均Token消耗、首響延遲分位數(shù)、人工兜底率。其中工具調(diào)用成功率是最容易被忽略但最影響體驗的指標。我一直要求團隊把這個數(shù)做到95%以上再考慮上線低于90%基本就是天天被用戶投訴工具不生效。3.2 第二步搭骨架模型配置與工作流設計選好平臺后的第一個動作永遠是搭一個“能跑通的最小閉環(huán)”也就是一條用戶消息進來模型能調(diào)一個工具、返回一個結(jié)果再做一次格式化輸出。這個閉環(huán)通了后面不過是往里面加工具、加知識、加分支。模型配置我一般用這套初始參數(shù)溫度設0.1到0.2不要超過0.3打開工具調(diào)用開關上下文拿不準就選支持長上下文的模型關閉“流式輸出”不等于不用線上再按體驗需求打開。很多人喜歡把溫度調(diào)高想讓模型“更有創(chuàng)造性”生產(chǎn)環(huán)境里創(chuàng)造性和幻覺只有一線之隔業(yè)務系統(tǒng)里要的是穩(wěn)不是創(chuàng)意。工作流方面我強烈建議先從“單Agent工具”開始不要一上來就設計多Agent協(xié)作。多Agent意味著多次模型調(diào)用延遲翻倍、成本翻倍、錯誤點也翻倍。真實的業(yè)務場景里大概20%需要多Agent80%用單Agent加清晰的工作流就能解決。先跑通再優(yōu)化最后才考慮拆Agent。3.3 第三步工具設計與注冊工具是智能體從“嘴炮”變成“打工人”的關鍵。現(xiàn)在主流的做法是用MCP標準來定義工具本質(zhì)上就是一個統(tǒng)一協(xié)議讓模型能夠發(fā)現(xiàn)工具、理解工具入?yún)?、并調(diào)用執(zhí)行。工具開發(fā)本身不復雜兩步定義Schema、寫執(zhí)行函數(shù)。{ name: create_crm_ticket, description: 在CRM系統(tǒng)中創(chuàng)建一條工單記錄適用于客戶問題轉(zhuǎn)人工處理場景。必須在客戶已經(jīng)明確描述問題且當前智能體無法解決時調(diào)用。, input_schema: { type: object, properties: { customer_id: {type: string, description: 客戶唯一標識}, problem_desc: {type: string, description: 問題詳細描述}, priority: {type: string, enum: [low, medium, high]} }, required: [customer_id, problem_desc] } }工具這塊有兩條血淚經(jīng)驗。第一條工具的“描述”寫得越清楚模型調(diào)用就越準。很多團隊把工具描述寫成“創(chuàng)建工單”三個字模型根本不知道什么時候該用于是亂調(diào)。我會要求每條描述里寫清楚“什么時候用、什么時候不用、參數(shù)怎么填”。第二條單個Agent的工具數(shù)量控制在20到30個以內(nèi)超過這個數(shù)量模型容易出現(xiàn)選擇困難準確率肉眼可見下滑這時候要做的不是繼續(xù)加工具而是拆Agent或者把工具分組。3.4 第四步知識庫與記憶管理知識庫是智能體落地里出錯率最高的部分。很多人以為把文檔切一切扔進向量庫配個RAG就算完事但上線之后發(fā)現(xiàn)回答還是亂七八糟。問題通常出在檢索質(zhì)量上。我目前的實踐是“稀疏檢索向量檢索”雙路召回先用BM25做關鍵詞精確匹配再過向量相似度召回最后把兩路結(jié)果合并去重重排。單靠向量召回遇到專有名詞、編號、型號這種場景必翻車。文檔處理也不能一刀切。先把文本清洗干凈去掉頁眉頁腳、表格噪點然后按章節(jié)語義切塊每塊留足重疊區(qū)切完以后給每塊打上元數(shù)據(jù)包括來源、章節(jié)、更新時間、權限組。這些元數(shù)據(jù)不是為了好看是為了后面做權限過濾和溯源的沒有它你根本不敢把知識庫開放給全員。記憶管理這塊建議把短期記憶和長期記憶分開。短期記憶存在會話上下文里用摘要壓縮控制長度長期記憶關注用戶偏好、歷史決策寫之前要做抽象。比如用戶說“我是華東區(qū)的預算小于10萬”你存進長期記憶的不該是原文而是“區(qū)域華東預算閾值10萬”這種結(jié)構(gòu)化字段。我見過團隊把所有對話原文直接存庫里結(jié)果一百萬條對話把成本抬上天這就不叫記憶叫垃圾場。3.5 第五步Prompt設計實戰(zhàn)Prompt設計在智能體時代依然重要但寫法和純聊天不同。智能體的System Prompt我一般固定四段結(jié)構(gòu)角色與邊界、任務列表、行為約束、輸出格式。角色與邊界寫清楚“你是誰、你能做什么、不能做什么”最重要的約束是“不知道的不要說寧可讓用戶轉(zhuǎn)人工也不要編”。任務列表告訴模型它今天要處理哪幾類請求。行為約束主要規(guī)范工具調(diào)用的前提條件比如“只有用戶明確要求查詢物流時才調(diào)用物流接口不允許猜測用戶意圖”。輸出格式則保證返回給上層是結(jié)構(gòu)化數(shù)據(jù)不要一堆廢話。這里有個進階技巧工具說明放在工具Schema里而不是塞進Prompt。讓模型通過工具定義了解調(diào)用方式比在Prompt里拿自然語言念三遍管用得多。另外不要堆砌一堆泛泛的規(guī)則要放幾個高質(zhì)量示例這個比“不要亂說話”這種空話有效十倍。SYSTEM_PROMPT 你是某公司的智能客服助手負責解答售前咨詢和基礎售后問題。 你能調(diào)用商品查詢、庫存查詢、訂單查詢、物流查詢、創(chuàng)建工單五個工具。 約束 1. 只回答與公司業(yè)務相關的問題不相關時禮貌拒絕。 2. 不確定的信息必須查詢工具后回答禁止憑記憶編造價格和庫存。 3. 用戶情緒激烈或連續(xù)三次無法解決時主動推薦人工服務。 4. 所有涉及用戶隱私的信息不得外泄。 輸出格式先給結(jié)論再給依據(jù)需要工具調(diào)用時按工具Schema輸出。 3.6 第六步評測、灰度與上線上線前最后一道關卡是評測?；〞r間搭一個回歸集把自己業(yè)務里真實會遇到的問題整理成50到200條測試用例這個投入非常值得。每條用例包含輸入、期望行為、期望工具調(diào)用、允許的拒絕類型。每次改Prompt、換模型、調(diào)參數(shù)先跑一遍回歸集對比工具調(diào)用匹配率和輸出合規(guī)率。評測集沒建好之前不要隨意更新Prompt也不要隨意換模型。我見過太多團隊上線后憑感覺調(diào)Prompt結(jié)果改一個問題壞三個功能就是因為沒有回歸保護。評測跑完后走灰度上線先內(nèi)部員工用一周再放5%外部流量最后全量?；叶绕陂g收集bad case人工review模型決策日志尤其是“該調(diào)工具沒調(diào)”“不該調(diào)工具亂調(diào)”這兩類基本能覆蓋80%的問題。上線不是終點是運營的起點。我會在后端掛一個“這個回答是否滿意”的埋點每天看一次滿意率每周拉一次bad case列表人工復盤。很多團隊做完評測就不管了第一周還不錯第三周業(yè)務數(shù)據(jù)一變就開始瞎答因為Prompt和知識庫沒有跟著業(yè)務走。智能體是需要持續(xù)喂養(yǎng)的系統(tǒng)三天不看就會給你驚喜。4. 行業(yè)案例四個方向從Demo到上線的復盤4.1 智能客服準確率之外還要看一次解決率某消費品牌企業(yè)找我做客服智能體時已經(jīng)有一套傳統(tǒng)的FAQ檢索系統(tǒng)但用戶滿意度一直上不去。復盤發(fā)現(xiàn)用戶問“我訂單還沒到”這種問題時舊系統(tǒng)只會把物流規(guī)則長篇大論丟給用戶根本不解實際問題。后來我們把智能體定位成“能查能辦的前臺接線員”工作流設計成先接住問題做意圖識別分三類——售前咨詢、售后查詢、投訴抱怨然后分別走三個Agent子流程。售后查詢直接調(diào)訂單和物流接口把結(jié)果用自然語言組織好投訴抱怨的判斷情緒激烈就直接引導人工不要硬答。整體架構(gòu)還是單入口沒有搞一堆花哨的多Agent只是按路由做分支處理。上線三個月一次解決率從原來的35%提到62%人工介入率降低了接近四成。但真正讓我覺得值錢的不是指標是用戶說了句“它至少知道我在問什么了”。傳統(tǒng)FAQ和智能客服最大的差距就在這里前者是搜索引擎后者是一位知道自己權限邊界的實習生。這里要特別提一個坑上線初期有個投訴場景智能體為了安撫用戶會擅自承諾“給您補償10元優(yōu)惠券”但實際后臺根本沒有這個授權工具結(jié)果用戶去兌現(xiàn)時炸了。后來我在Prompt和行為約束里加了硬性條款任何涉及賠償、退款、承諾的事項必須轉(zhuǎn)人工工具集里根本不給它開放發(fā)券權限。能力邊界這件事靠Prompt限制只是第一層權限上直接封死才是第二層兩層都要做。4.2 企業(yè)知識助手RAG不是難點權限才是某研發(fā)團隊想把沉淀了幾年的項目文檔、技術方案、會議紀要統(tǒng)一做成企業(yè)內(nèi)部知識助手這個場景很有代表性。當時我們評估了很多RAG方案發(fā)現(xiàn)純技術難度不大真正麻煩的是權限模型。他們內(nèi)部文檔分為公開、部門可見、機密三個級別不同角色的員工只能看到不同內(nèi)容。如果簡單把所有文檔切片進同一個索引會出現(xiàn)越權檢索的巨大風險——模型回答沒問題但泄露了不該看的資料才是致命問題。最終方案是在向量數(shù)據(jù)庫的每個切片上都打上權限標簽檢索時強制用當前用戶的部門信息過濾后再執(zhí)行召回應用層再做二次鑒權。兩條線缺一條都不行。這個項目讓我確定了一個原則知識助手的權限控制必須“入庫前按文檔打標檢索時按用戶過濾返回前按級別兜底”三道缺一不可。很多團隊只做第一道以為索引里帶權限字段就行但模型生成時是有上下文拼接的很容易把不該說的內(nèi)容順帶說出去。所以還要在系統(tǒng)提示詞里補一句“如果檢索到的信息不在你的可見權限范圍直接拒絕回答不要嘗試推理”。上線后效果也確實明顯新員工找資料時間從平均兩小時縮到五分鐘但這些都是副產(chǎn)品。真正讓管理層滿意的是所有回答都帶來源引用點開就能看到原文段落出了問題可以追溯。帶引用的RAG和帶著自信亂編的RAG在企業(yè)內(nèi)部的信任度差別是天上地下。4.3 數(shù)據(jù)分析智能體NL2SQL要配語義層數(shù)據(jù)分析場景是大模型落地的一個熱門方向但也是翻車重災區(qū)。某制造企業(yè)的老板想做一個“能用自然語言查數(shù)”的助手業(yè)務負責人直接說“能不能我問一句上季度華東區(qū)退貨率它就給我數(shù)字”聽起來簡單做起來遠沒有那么簡單。我們第一版直接讓模型寫SQL查數(shù)據(jù)庫上線一周翻車了三次。不是SQL語法錯而是模型把“退貨率”理解成了“退貨數(shù)量除以總訂單數(shù)”但業(yè)務口徑里退貨率其實只算“已發(fā)貨再退回”的訂單不含發(fā)貨前取消的。模型不會知道這種業(yè)務隱含口徑于是數(shù)字總能算出來但不對。后來我們學乖了在模型和數(shù)據(jù)倉庫之間加了一層“語義層”。把常用的業(yè)務指標、口徑定義、表關系、篩選條件全部提前配置好模型的任務從“寫SQL”降級成“從語義層里選指標、匹配條件、生成查詢”。這本質(zhì)上就是把口徑判斷從模型手里收回到人手里模型只做匹配和參數(shù)填充。改造完以后查詢準確率從78%提到96%而且維護成本很低口徑變了只改語義層配置。數(shù)據(jù)分析智能體落地有一條鐵律永遠不要直接讓模型裸寫SQL必須加語義層并且給數(shù)據(jù)庫連只讀賬號查詢語句全部走審計日志。業(yè)務數(shù)據(jù)的口誤、歧義、權限靠模型自覺是靠不住的要靠架構(gòu)設計去兜底。4.4 運營流程自動化讓人在審批環(huán)里而不是流程外另一個方向的案例是運營自動化。某企業(yè)每天要處理大量合同初審和采購申請原來兩個運營專員專職處理每天加班到晚上九點而且審漏過幾次關鍵條款。后來我們用智能體做“初審員整理員”它讀取上傳的合同附件、按審核清單抽取關鍵字段、比對歷史合同異常點、輸出風險提示最后把結(jié)論整理成一個人工審批工單。這個設計中最重要的不是模型有多強而是“人工審批節(jié)點”的位置。自動化的目標應該是讓人更容易決策而不是替人決策。高風險操作比如簽合同、批款項、發(fā)客戶函件一律要求最終由人點擊確認。智能體可以準備材料、標出風險、給出建議但按鈕永遠握在人類手里。這個分工讓項目推進特別順利運營團隊不但沒有抵觸反而主動提需求。上線后一審材料準備時間從人均40分鐘縮到6分鐘專員從“打字員”變成了“復核員”效率提升的同時員工滿意度也上來了。我后來復盤時總跟客戶說做智能體不要總想著替代人更多時候它的價值是把人從重復勞動里釋放出來去做只有人才能做的判斷。5. 踩坑實錄智能體實戰(zhàn)的常見問題與排查5.1 高頻問題速查表智能體開發(fā)過程中團隊遇到的大部分問題其實都可以歸到幾個固定的模式里。這里整理了一份排查速查表我基本上把它當成智能體的體檢清單用。癥狀最常見根因排查方向解決方案答非所問、幻覺嚴重檢索召回質(zhì)量差或Prompt邊界過寬檢查召回結(jié)果相關性和排序雙路召回、加元數(shù)據(jù)過濾、Prompt里加“不知道就說不知道”該調(diào)工具時不調(diào)工具描述不清晰模型不知道工具存在查看模型決策日志看它有沒有讀工具定義重寫工具description加觸發(fā)條件和示例不該調(diào)工具時亂調(diào)Prompt邊界不夠硬模型在猜用戶意圖檢查是否系統(tǒng)提示里約束缺失加“只有用戶明確要求時才調(diào)用”這類前綴條件上下文超長、報錯單輪塞了太多歷史或超長文檔看tracer里每輪歷史長度歷史摘要壓縮、分段處理、必要時把長期記憶外置延遲太高多Agent串行調(diào)用或單Agent多次循環(huán)看鏈路里模型調(diào)用次數(shù)預取結(jié)果、并行調(diào)用工具、減少無意義的反思循環(huán)成本失控每輪都塞滿了系統(tǒng)提示和大段歷史統(tǒng)計單輪token消耗精簡System Prompt、別把長文檔全塞上下文、加緩存層上線后效果滑坡知識庫沒更新、業(yè)務環(huán)境變了檢查bad case趨勢圖建立周度知識刷新和bad case復盤機制5.2 幻覺與工具調(diào)用不穩(wěn)定的根治思路幻覺問題在智能體里和純聊天場景不一樣。純聊天里幻覺是“編瞎話”智能體里幻覺往往以更隱蔽的形式出現(xiàn)編造一個不存在的API參數(shù)、虛構(gòu)一個工具返回值、或者用想當然的數(shù)據(jù)填充報表。所以我的處理思路是不給模型編造的機會。具體做法有幾個層面第一把關鍵事實從模型的知識依賴里拆出來放到知識庫或系統(tǒng)接口里模型只做格式化和轉(zhuǎn)述不做事實記憶第二工具調(diào)用失敗時強制模型返回“工具不可用”的明確狀態(tài)并引導用戶換一種方式或轉(zhuǎn)人工絕不能讓它基于猜測重試第三所有依賴工具才能回答的問題在Prompt里寫死前提“沒有工具返回值禁止輸出結(jié)論”。這三板斧下來業(yè)務場景里的幻覺能從不可控降到個位數(shù)比例。要想徹底歸零是不可能的但只要不把模型當事實存儲器幻覺的危害就小得多。工具調(diào)用不穩(wěn)定還有一個容易被忽視的原因工具Schema本身和模型能力不匹配。有的模型對嵌套JSON參數(shù)的解析能力差你偏要用復雜的嵌套結(jié)構(gòu)它就老是漏填字段。遇到這種情況別死磕模型直接把參數(shù)拍平把嵌套對象拆成多個平鋪字段成功率能立刻上來。模型不擅長寫JSON我們就別讓它寫復雜JSON這是API設計和模型能力之間的調(diào)和。5.3 上下文與成本平衡別讓每一輪對話都“背全書”很多團隊做智能體時習慣把系統(tǒng)提示寫得又長又全再把每個工具的超長返回值一股腦丟進上下文美其名曰“給模型更多信息”。最后的結(jié)果是每輪對話消耗上萬Token成本飆升響應還慢。而且信息太多了模型反而抓不住重點。我對上下文長度的控制原則是“按需注入”。系統(tǒng)提示壓到最短可運行的程度工具調(diào)用只傳必要的參數(shù)工具返回值只保留關鍵字段歷史對話做滾動摘要而不是全文累積。評估要不要保留一段上下文標準只有一個這輪回答是否真的還需要它。不需要就果斷丟棄需要就壓縮后再留。這里有個真實數(shù)據(jù)供參考我經(jīng)手的項目里做了上下文按需注入和緩存之后單輪成本普遍降到原來的四分之一到三分之一而業(yè)務指標基本沒變化。有些團隊給模型配了很大的上下文窗口就一直往上塞內(nèi)容覺得“反正裝得下”這是一種隱蔽的成本浪費。上下文窗口大不代表你應該把它填滿。用最少的Token達到同樣的任務效果這才是工程能力不是摳門是底線。6. 一點個人經(jīng)驗最后聊點實在的。做了這么多個智能體項目我最大的體會是不要把智能體當成一個“一次性交付的軟件”它更像一個需要持續(xù)運營的業(yè)務崗位。你招一個新員工不會頭一天就讓它獨立接待客戶、審批合同智能體也一樣。先做邊界最小的單點任務跑順了再擴權限、擴范圍每一步都留人工兜底這是最穩(wěn)的落地路徑。還有一個經(jīng)驗是要把“反饋閉環(huán)”當成基礎設施來做。很多項目上線后滿意率是黑盒用戶回答得對不對沒有人知道。我后來堅持在每個智能體回答的尾部加一個“解決了嗎”的反饋按鈕就這個簡單的動作讓bad case的收集成本降了一個量級。每天看用戶的抱怨比你自己坐在那里猜一百遍“它可能哪里不對”都管用。做過幾個項目之后你會明白智能體開發(fā)里最稀缺的不是模型能力不是平臺參數(shù)是真實業(yè)務反饋。把反饋回路建好比堆任何高級技巧都重要。