這一周我基本被三件事釘在鍵盤前token用量、模型選型、agent治理。不是我在給自己找課題是線上一個(gè)跑了半年的AI客服項(xiàng)目突然在同一周里把這三個(gè)問題同時(shí)暴露到臺(tái)面上。報(bào)表一拉token成本環(huán)比漲了37%測(cè)試集上老模型的表現(xiàn)開始被新模型碾壓而agent的自主調(diào)用在處理復(fù)雜工單時(shí)開始出現(xiàn)失控征兆。這篇文章就復(fù)盤這一周的實(shí)際觀測(cè)和操作為什么token會(huì)突然成為工程瓶頸、升級(jí)更強(qiáng)模型時(shí)該做什么功課、以及agent越能干活我們?cè)揭涯男╅l門裝上。如果你也在做RAG應(yīng)用、智能客服、自動(dòng)化流程或Agent平臺(tái)這篇應(yīng)該能幫你少踩幾個(gè)坑。我不做理論推演只講這周實(shí)際動(dòng)手時(shí)看到的東西。標(biāo)題里那九個(gè)字不是我故意總結(jié)的是線上業(yè)務(wù)真實(shí)感受到的變化——AI產(chǎn)品從demo走向生產(chǎn)環(huán)境之后成本、效果和管控三件事會(huì)同時(shí)發(fā)酵而且發(fā)酵速度比你想象中快得多。1. 為什么這三件事會(huì)同時(shí)壓到工程團(tuán)隊(duì)頭上1.1 token效率不再是省錢問題而是性能問題很多團(tuán)隊(duì)對(duì)token的第一反應(yīng)是價(jià)格太貴了要省。但如果你把線上日志拉出來看會(huì)發(fā)現(xiàn)更扎心的事實(shí)——不是用得太貴而是用得太多。我有一次追蹤一個(gè)客服機(jī)器人的會(huì)話發(fā)現(xiàn)一次普通咨詢平均消耗2.1萬token其中真正用于回答的只有千把字剩下全是被反復(fù)塞進(jìn)上下文的歷史消息、工具返回結(jié)果、以及模型自己生成的中間步驟。token膨脹侵蝕的不只是成本還有響應(yīng)速度。輸入越長(zhǎng)首字延遲越高用戶體驗(yàn)直接崩。我們一個(gè)節(jié)點(diǎn)首字延遲從800ms漲到4s根因就是上下文越滾越大。所以省token不是財(cái)務(wù)行為是性能優(yōu)化。這句話值得寫在監(jiān)控大屏上。1.2 模型變強(qiáng)工程架構(gòu)要跟著重算這個(gè)月各家的模型發(fā)布節(jié)奏明顯加快谷歌新模型也傳出了暫不面向普通用戶的消息——不管產(chǎn)品策略怎么定釋放出來的信號(hào)都一樣模型能力的天花板又被抬高了一截。我們的應(yīng)用在這個(gè)時(shí)間點(diǎn)做了模型升級(jí)明顯感覺到推理質(zhì)量的提升不用再堆大量few-shot指令也更聽話了復(fù)雜的工具調(diào)用鏈條成功率上來了。但變強(qiáng)是有代價(jià)的。原來靠prompt技巧兜底的路子要改原來的模型行為假設(shè)要重新測(cè)?！澳Ｐ驮綇?qiáng)prompt越簡(jiǎn)單”這句話聽起來很爽實(shí)際落地時(shí)你會(huì)發(fā)現(xiàn)評(píng)估體系、剔除邏輯、重試策略全都要跟著變。不然新模型會(huì)在你沒預(yù)料到的地方自作主張看起來聰明實(shí)際上是在給下游埋雷。1.3 agent的跨度越大失控面越大再說agent。業(yè)內(nèi)這兩周對(duì)agent的關(guān)注點(diǎn)已經(jīng)從“能跑通多復(fù)雜的任務(wù)”轉(zhuǎn)向“怎么讓它不至于跑飛”。這不是悲觀是生產(chǎn)系統(tǒng)必須面對(duì)的現(xiàn)實(shí)。一個(gè)能自主調(diào)用工具、多步驟推理的agent本質(zhì)上是一個(gè)有執(zhí)行能力的分布式子系統(tǒng)它的權(quán)限半徑、token預(yù)算、狀態(tài)一致性、失敗恢復(fù)每一件都要有人管。我見過不少團(tuán)隊(duì)被“agent很酷”吸引直接上了多agent協(xié)作結(jié)果一周后連“這個(gè)任務(wù)為什么花了3萬token”都答不上來。這叫跨度過大、治理沒跟上。把這三個(gè)趨勢(shì)放到一起看你會(huì)發(fā)現(xiàn)它們其實(shí)是同一個(gè)問題的三個(gè)階段模型越強(qiáng)agent能做的事越多系統(tǒng)需要付出的治理成本就越高。2. 更少 token四個(gè)實(shí)測(cè)有效的省 token 打法2.1 先別急著調(diào)prompt把優(yōu)化拆成四個(gè)方向很多人一聽說省token第一反應(yīng)就是把系統(tǒng)提示詞寫短一點(diǎn)。這當(dāng)然有效但天花板很低。我把token優(yōu)化拆成四個(gè)可以實(shí)際落地的動(dòng)作prompt瘦身、緩存復(fù)用、結(jié)構(gòu)化輸出、模型側(cè)優(yōu)化。這四個(gè)方向不是用來背的是要放進(jìn)自己系統(tǒng)里的下面逐個(gè)說實(shí)操。先說一個(gè)判斷標(biāo)準(zhǔn)任何優(yōu)化動(dòng)作上線前先在灰度環(huán)境跑300條真實(shí)請(qǐng)求對(duì)比回答質(zhì)量和token用量。只降token不保質(zhì)量等于白忙。我見過有人把prompt壓到極致結(jié)果模型頻繁漏掉關(guān)鍵指令回答質(zhì)量肉眼可見地下降這種優(yōu)化是負(fù)資產(chǎn)。2.2 prompt瘦身一份實(shí)測(cè)對(duì)比數(shù)據(jù)我們團(tuán)隊(duì)有一條代碼檢索助手基線prompt里塞了系統(tǒng)說明、歷史問題、全量檢索結(jié)果跑一次穩(wěn)定破萬token。我把系統(tǒng)說明壓成三句話歷史問題截?cái)酁樽罱鼉奢啓z索結(jié)果只保留Top5片段并且每個(gè)片段都截到命中位置前后200字。改完之后一次調(diào)用從1.4萬token降到4300回答質(zhì)量基本沒有回落。對(duì)比項(xiàng)改前改后說明平均單次調(diào)用token140004300降幅約70%系統(tǒng)提示詞量800字100字以內(nèi)只保留角色、任務(wù)、邊界歷史對(duì)話全量最近2輪更早的只保留摘要檢索結(jié)果全量段落Top5命中片段命中位置前后各200字回答質(zhì)量基線持平灰度對(duì)比300條這里有一個(gè)容易被忽略的細(xì)節(jié)省token是從檢索環(huán)節(jié)就開始省不是在prompt拼接階段才裁剪。很多RAG實(shí)現(xiàn)把全量段落塞進(jìn)prompt再靠模型“忽略無關(guān)內(nèi)容”這是最貴的做法。應(yīng)該先在檢索階段把不相關(guān)的段落過濾掉只把真正命中的片段送去給模型。我在這周調(diào)參時(shí)發(fā)現(xiàn)檢索閾值從0.75提到0.82回答質(zhì)量幾乎不變但送入模型的token量直接少了三分之一。2.3 三層緩存KV Cache、語義緩存、結(jié)果緩存緩存是省token的最大杠桿但很多人只盯著模型側(cè)的KV Cache忽略了應(yīng)用側(cè)更值錢的部分。我實(shí)測(cè)下來token緩存應(yīng)該分三層來設(shè)計(jì)。層級(jí)位置作用工程注意點(diǎn)KV Cache推理引擎加速模型推理避免重復(fù)計(jì)算歷史token盡量讓固定前綴保持一致不要頻繁改動(dòng)系統(tǒng)提示詞語義緩存應(yīng)用網(wǎng)關(guān)相似query直接復(fù)用結(jié)果embedding相似度閾值建議0.92~0.95結(jié)果緩存業(yè)務(wù)層高頻精確查詢直接返回必須帶TTL價(jià)格、庫存類數(shù)據(jù)不能長(zhǎng)時(shí)間復(fù)用語義緩存是這周收益最大的一個(gè)動(dòng)作。我們給高頻問題做了embedding緩存用余弦相似度做匹配命中率大概在25%左右直接砍掉了這部分請(qǐng)求的全部模型調(diào)用成本。但閾值要小心太高緩存命中率太低太低容易答非所問。我實(shí)測(cè)0.92到0.95之間比較合適但最終還是要根據(jù)你的業(yè)務(wù)數(shù)據(jù)分布去標(biāo)定不要迷信網(wǎng)上給的默認(rèn)值。2.4 模型側(cè)的省token打法蒸餾與量化模型側(cè)的省token打法最直接的是兩件事蒸餾和量化。線上如果只有三五條核心路徑完全可以通過蒸餾出一個(gè)專用的小模型來承接高頻場(chǎng)景。我們現(xiàn)在把意圖識(shí)別、格式抽取這類“簡(jiǎn)單但量大”的任務(wù)單獨(dú)交給一個(gè)蒸餾后的小模型單次調(diào)用成本降為原來的十分之一效果也不差。蒸餾的關(guān)鍵是數(shù)據(jù)質(zhì)量拿大模型的高質(zhì)量輸出做訓(xùn)練語料比拿原始用戶數(shù)據(jù)要穩(wěn)得多。量化則是部署層的優(yōu)化。如果你想在本地部署模型現(xiàn)在Windows上通過GPUSTack這類工具跑量化模型已經(jīng)很成熟GGUF、AWQ這些格式的模型可以直接用。量化模型主要損失的是復(fù)雜推理能力但放在預(yù)篩、分類這些場(chǎng)景里性價(jià)比極高。我這周把幾個(gè)非核心分類任務(wù)遷移到量化模型上之后線上token消耗曲線明顯平滑了。3. 更強(qiáng)模型升級(jí)前后工程側(cè)要做哪些功課3.1 模型變強(qiáng)直接影響這三個(gè)設(shè)計(jì)點(diǎn)模型能力躍遷之后第一波要重新設(shè)計(jì)的是上下文管理。過去我們?yōu)榱藨?yīng)對(duì)模型“記不住”設(shè)計(jì)了各種記憶機(jī)制、摘要壓縮、消息裁剪?，F(xiàn)在窗口從幾千擴(kuò)到幾十萬甚至百萬級(jí)很多緩解方案確實(shí)可以拿掉了。但注意這不等于讓你把全量?jī)?nèi)容直接塞進(jìn)去——模型對(duì)長(zhǎng)上下文的注意力是會(huì)和位置相關(guān)的長(zhǎng)上下文里中段信息最容易丟這個(gè)現(xiàn)象在處理超長(zhǎng)文檔時(shí)很明顯。第二是少樣本依賴下降。我刪掉了不少few-shot樣例模型在零樣本下就能完成任務(wù)這意味著prompt維護(hù)成本低了。但不要把刪掉的樣例直接扔進(jìn)回收站它們是你的回歸測(cè)試語料下次換模型時(shí)還要用它們來驗(yàn)證。第三是工具調(diào)用能力的提升。更強(qiáng)模型在“什么時(shí)候該調(diào)工具、參數(shù)怎么傳”上明顯更靠譜這對(duì)agent場(chǎng)景是重大利好但也會(huì)讓模型更愿意主動(dòng)調(diào)用工具——一旦給了它錯(cuò)誤工具破壞力也跟著上來了。3.2 大上下文把架構(gòu)變簡(jiǎn)單也把新坑帶進(jìn)來大上下文帶來的第一個(gè)新坑是token成本非線性上升。輸入token是每個(gè)請(qǐng)求都要算的prompt越長(zhǎng)單次成本越貴而且這種成本會(huì)隨著用戶使用頻次形成復(fù)利。我見過一個(gè)團(tuán)隊(duì)把整本產(chǎn)品手冊(cè)塞進(jìn)system prompt單次調(diào)用沖到6萬token看起來“很智能”實(shí)際一個(gè)月的API賬單夠買一臺(tái)開發(fā)機(jī)。第二個(gè)新坑是模型更容易“自作主張”。升級(jí)后的模型會(huì)在沒有明確指令的情況下擅自補(bǔ)全用戶沒說出口的意圖。這在開放域閑聊里是亮點(diǎn)但在金融、醫(yī)療這類強(qiáng)約束場(chǎng)景里這個(gè)“自作主張”必須用system prompt里的邊界描述和輸出約束控住。順帶一提Longformer這類當(dāng)年為了拉長(zhǎng)窗口而設(shè)計(jì)的架構(gòu)在原生大上下文模型面前已經(jīng)慢慢變成歷史名詞了新項(xiàng)目不必再為“窗口不夠”而刻意選型。3.3 換模型必須帶著評(píng)估集上路換模型不是改個(gè)API Key就完事。我們的做法是建一個(gè)100條左右的回歸問題集覆蓋意圖識(shí)別、格式抽取、事實(shí)問答、糾錯(cuò)處理升級(jí)前后各跑一遍對(duì)比準(zhǔn)確率和關(guān)鍵字段。沒跑回歸就換模型我吃過虧新模型把某個(gè)老用戶場(chǎng)景直接答偏了而且是在上線兩天后才被發(fā)現(xiàn)。評(píng)估集不要只放“正確樣本”。至少要包含四類常見問題、邊界案例、對(duì)抗樣本、歷史badcase。其中歷史badcase最重要——它們是過去幾個(gè)月用真金白銀踩出來的換模型后如果舊錯(cuò)重現(xiàn)說明新模型并沒有真正解決問題。我強(qiáng)烈建議把評(píng)估集納入CI/CD每次換模型、改prompt都自動(dòng)跑一遍結(jié)果直接發(fā)到群里誰改壞了誰負(fù)責(zé)。4. 更難管的 agent從“能跑”到“可控”的治理清單4.1 框架選型原生Agent SDK與Harness編排怎么分工現(xiàn)在各家都在推Agent框架和SDK選型時(shí)很容易踩“框架越重越好”的坑。我的觀點(diǎn)是先用最簡(jiǎn)單的方案自己維護(hù)循環(huán)也就是LLM調(diào)用、工具注冊(cè)、結(jié)果回填這個(gè)最基本的loop先跑出原型再回頭看要不要上框架?？蚣芙鉀Q的是狀態(tài)管理和編排但也會(huì)把你的復(fù)雜度鎖進(jìn)去一旦出了問題排查成本遠(yuǎn)高于手工實(shí)現(xiàn)。這里要分清一個(gè)概念Harness和Agent不是一個(gè)東西。Harness是編排控制層負(fù)責(zé)任務(wù)的分解、調(diào)度、狀態(tài)流轉(zhuǎn)Agent是執(zhí)行層負(fù)責(zé)具體某一步的推理和工具調(diào)用。很多團(tuán)隊(duì)把這兩層混在一起導(dǎo)致“指令該誰下、結(jié)果該誰收”完全沒邊界agent跑著跑著就開始失控。把這兩層分清楚治理會(huì)好做很多。4.2 agent并發(fā)先限流再編排最后談多AI協(xié)作“AI agent怎么扛并發(fā)”是這兩周被問得最多的問題?？覆l(fā)不是讓agent跑得快而是讓agent別擠爆下游。凡是agent要調(diào)用外部API或者寫數(shù)據(jù)庫的場(chǎng)景我建議接入三層保護(hù)信號(hào)量限制并發(fā)數(shù)、隊(duì)列削峰、熔斷降級(jí)。我先用最簡(jiǎn)單的信號(hào)量把并發(fā)壓到8相當(dāng)于給系統(tǒng)加了個(gè)護(hù)欄結(jié)果下游接口的錯(cuò)誤率直接歸零。然后再看瓶頸在哪逐個(gè)加隊(duì)列和重試策略。多AI協(xié)作更要謹(jǐn)慎。多個(gè)agent同時(shí)操作同一份數(shù)據(jù)時(shí)的沖突問題必須在編排層解決靠agent自己避讓是不現(xiàn)實(shí)的。這周我們做了一次雙agent協(xié)作實(shí)驗(yàn)一個(gè)負(fù)責(zé)信息收集一個(gè)負(fù)責(zé)結(jié)果匯總結(jié)果兩個(gè)agent同時(shí)去寫同一個(gè)訂單狀態(tài)字段把數(shù)據(jù)都搞亂了。后來在編排層加了沖突檢測(cè)才把問題按住。4.3 權(quán)限治理給agent發(fā)最小可用權(quán)限agent能做的事情越多越要收斂權(quán)限。查訂單的agent不該有刪除權(quán)限生成文案的agent不該能訪問生產(chǎn)環(huán)境數(shù)據(jù)庫。這個(gè)道理誰都懂但實(shí)現(xiàn)時(shí)很容易圖省事給一把通用工具鑰匙——我就犯過這個(gè)錯(cuò)agent借著測(cè)試環(huán)境的“萬能工具”改了線上配置表。所以權(quán)限治理必須做工具白名單所有agent能調(diào)的tool都顯式注冊(cè)外部操作默認(rèn)拒絕。審計(jì)日志必開。每次工具調(diào)用都要能追溯到是哪個(gè)任務(wù)觸發(fā)的、參數(shù)是什么、返回了什么。不然agent出了問題你連“它到底干了什么”都說不清楚。我建議至少保留30天的審計(jì)日志關(guān)鍵業(yè)務(wù)場(chǎng)景延長(zhǎng)到180天。這不是為了追責(zé)是為了能在事故發(fā)生后快速定位問題邊界別讓一次agent誤操作變成全鏈路故障。4.4 可觀測(cè)性與失敗恢復(fù)把a(bǔ)gent當(dāng)成24小時(shí)在線的分布式服務(wù)agent一次任務(wù)可能有幾十個(gè)步驟出錯(cuò)了要能定位是哪一步。我現(xiàn)在的做法是每一步工具調(diào)用都記錄一個(gè)trace狀態(tài)機(jī)事件全部落日志關(guān)鍵節(jié)點(diǎn)做里程碑檢查點(diǎn)。失敗恢復(fù)就按狀態(tài)機(jī)重放而不是整個(gè)任務(wù)重啟。比如agent在第三步調(diào)支付接口失敗了重放時(shí)直接從第三步開始而不是把第一步到第二步重新跑一遍那樣既浪費(fèi)token又可能在第二步產(chǎn)生副作用。給agent設(shè)預(yù)算也屬于可觀測(cè)性的一部分。我建議給每個(gè)agent任務(wù)設(shè)token上限比如單任務(wù)最大5萬token超過就強(qiáng)制中斷進(jìn)入人工審批。這個(gè)數(shù)字聽起來很粗暴但它能有效防止“agent跑飛”造成的失控。實(shí)測(cè)下來設(shè)置上限后異常任務(wù)占比從7%降到1%而且絕大多數(shù)正常任務(wù)根本碰不到這個(gè)上限。5. 本周踩坑實(shí)錄從“演示可用”到“生產(chǎn)可用”的最后一公里5.1 最典型的三個(gè)坑這一周線上最典型的三個(gè)坑第一個(gè)是上下文越滾越大。agent多輪對(duì)話后把歷史消息全量回填首字延遲從800ms漲到4s用戶直接投訴“變笨了”。解決方式是滑動(dòng)窗口裁剪只保留最近N輪對(duì)話更早的內(nèi)容壓縮成摘要必要時(shí)再做核心事實(shí)抽取。用滑動(dòng)窗口在消息隊(duì)列上做上下文管理是控制token膨脹最直接的手段。第二個(gè)坑是agent循環(huán)調(diào)用不退出。一個(gè)bug讓agent連續(xù)調(diào)用工具幾十次燒掉了幾萬個(gè)token最后是觸發(fā)了我們剛設(shè)的token上限才停下來。排查后發(fā)現(xiàn)是工具返回的錯(cuò)誤信息沒有被agent正確理解它以為是臨時(shí)失敗于是一次次重試。解決方式是給工具調(diào)用加上最大步數(shù)和循環(huán)檢測(cè)同一工具連續(xù)調(diào)用超過3次就自動(dòng)中斷并要求agent重新規(guī)劃。第三個(gè)坑是多agent共享數(shù)據(jù)庫連接池。聽起來是個(gè)基礎(chǔ)設(shè)施問題但真正發(fā)生的時(shí)候你根本看不出是agent引起的——只見鎖等待暴漲把整個(gè)服務(wù)拖到超時(shí)。最后是把連接池按agent任務(wù)維度隔離不同任務(wù)默認(rèn)用不同的連接通道。5.2 token失效與401/403報(bào)錯(cuò)的排查順序很多同學(xué)會(huì)在日志里看到token exchange failed或者401/403第一反應(yīng)是網(wǎng)絡(luò)問題然后就開始查DNS、查防火墻、查代理浪費(fèi)時(shí)間。按我的排查順序走大部分都能在自己系統(tǒng)里解決。首先看refresh_token是否過期。JWT續(xù)簽機(jī)制里access_token生命周期短refresh_token在服務(wù)端保管時(shí)要單獨(dú)建存儲(chǔ)不要把a(bǔ)ccess_token的生命周期拖長(zhǎng)來“省事”。其次看client_id和client_secret是否匹配我遇到過開發(fā)環(huán)境切到生產(chǎn)環(huán)境時(shí)密鑰沒換導(dǎo)致認(rèn)證失敗的情況。再看系統(tǒng)時(shí)間是否正確JWT的exp校驗(yàn)依賴服務(wù)器時(shí)間時(shí)間漂移超過幾分鐘就會(huì)出現(xiàn)偶發(fā)401。最后才是權(quán)限scope確認(rèn)申請(qǐng)token時(shí)帶的scope覆蓋了要調(diào)用的資源。這個(gè)順序能覆蓋90%的token相關(guān)認(rèn)證問題。實(shí)在排查不出來把日志補(bǔ)全再重放一次讓報(bào)錯(cuò)信息里帶上具體的錯(cuò)誤碼和請(qǐng)求ID比對(duì)著黑盒瞎猜高效得多。cookie、session、token這三類機(jī)制各有適用場(chǎng)景在AI工程里token用得最多但本質(zhì)都是“證明你是誰、能干什么”的憑證安全性和時(shí)效性永遠(yuǎn)要放在第一位。5.3 可以直接抄的落地清單給你一份可以直接照著做的清單。第一每周四下午更新一次token用量報(bào)表按業(yè)務(wù)線拆粒度誰漲了誰解釋。第二所有prompt模板加版本號(hào)改模板要過diff防止有人悄悄改壞線上效果。第三agent工具調(diào)用全部加上限、超時(shí)和冪等鍵同一操作重復(fù)執(zhí)行不能產(chǎn)生副作用。第四上線前必跑評(píng)估集評(píng)估結(jié)果自動(dòng)通知。第五把“會(huì)話上下文長(zhǎng)度”和“單任務(wù)token用量”作為核心監(jiān)控指標(biāo)閾值超了就告警。這份清單沒有一條是“高投入高難度”的但它能把大多數(shù)團(tuán)隊(duì)從被動(dòng)救火狀態(tài)里拉出來。我自己的感受是AI工程里的每一個(gè)“高級(jí)問題”最后都會(huì)落到這些最基礎(chǔ)的工程紀(jì)律上。6. token、模型、agent問題速查把這一周遇到的高頻問題整理成一張速查表建議直接收藏。癥狀排查思路解決建議token用量突然激增看是否上下文全量回填、工具是否循環(huán)調(diào)用滑動(dòng)窗口裁剪工具調(diào)用加最大步數(shù)token exchange failed / 401 / 403refresh_token是否過期、client_id/secret是否匹配、系統(tǒng)時(shí)間是否漂移、scope是否覆蓋更新憑證加自動(dòng)續(xù)期機(jī)制補(bǔ)全日志上下文agent卡在循環(huán)里出不來看工具調(diào)用鏈?zhǔn)欠裰貜?fù)、錯(cuò)誤信息是否被正確理解最大步數(shù)限制循環(huán)檢測(cè)失敗重試策略并發(fā)一高就報(bào)錯(cuò)看下游API限流和數(shù)據(jù)庫鎖等待信號(hào)量限流、隊(duì)列削峰、熔斷降級(jí)升級(jí)模型后回答質(zhì)量下降跑回歸集對(duì)比歷史badcase建立評(píng)估集并納入CI/CD多agent協(xié)作數(shù)據(jù)沖突看多個(gè)agent是否操作同一份數(shù)據(jù)編排層做沖突檢測(cè)或加鎖最后說點(diǎn)個(gè)人體會(huì)。這一周整理下來我發(fā)現(xiàn)“更少token、更強(qiáng)模型、更難管的agent”其實(shí)不是三個(gè)獨(dú)立問題而是同一個(gè)問題的三個(gè)階段模型的執(zhí)行力越強(qiáng)系統(tǒng)需要付出的治理成本就越高。省token、上評(píng)估、管agent這些聽起來不性感的東西反而是這一輪AI工程里最該花時(shí)間的部分。如果你現(xiàn)在什么都不缺缺的只是一個(gè)下周可以開始的動(dòng)作我的建議是先把a(bǔ)gent的工具調(diào)用日志打開再給token用量畫個(gè)趨勢(shì)表一周之后你會(huì)發(fā)現(xiàn)問題自己就浮出來了。