丹米斯·哈薩比斯的新角色讓谷歌AI的“平衡術(shù)”第一次被擺到臺面上看。過去提起DeepMind大家想到的是AlphaGo、蛋白質(zhì)結(jié)構(gòu)預(yù)測這類偏研究型的成果提起谷歌大家想到的是搜索、廣告和云服務(wù)。現(xiàn)在哈薩比斯的職權(quán)范圍被擴(kuò)展到更廣的產(chǎn)品和技術(shù)體系所有AI開發(fā)者都在關(guān)注同一個問題一家長期以“探索前沿”為目標(biāo)的團(tuán)隊(duì)和一個必須按周期交付產(chǎn)品的商業(yè)公司到底怎么在同一個決策鏈里共存。這個問題的答案不只影響谷歌的路線圖也會直接影響很多團(tuán)隊(duì)在做AI應(yīng)用開發(fā)時(shí)的取舍。這篇文章適合三類人看正在做AI Agent開發(fā)的技術(shù)負(fù)責(zé)人、負(fù)責(zé)模型選型和部署的工程師、以及想搞清楚“為什么大廠AI產(chǎn)品看起來很強(qiáng)但落地卻那么慢”的產(chǎn)品經(jīng)理。其實(shí)最值得關(guān)注的不是哈薩比斯本人而是背后那套“約束條件下的最優(yōu)解”思路。所謂平衡不是平庸地各讓一步而是在研發(fā)自由、產(chǎn)品速度、安全邊界和成本預(yù)算之間明確怎么選、為什么選、什么時(shí)候該剎車。下面我按自己的理解把這次行業(yè)討論翻譯成工程實(shí)踐里可以直接用的判斷方法。1. 研究理想與產(chǎn)品節(jié)奏哈薩比斯要面對的不只是技術(shù)問題1.1 DeepMind與谷歌的沖突點(diǎn)到底在哪DeepMind身上一直有一種“實(shí)驗(yàn)室氣質(zhì)”。它的目標(biāo)是攀登AI科學(xué)的前沿很多成果的驗(yàn)證周期是以年為單位計(jì)算的。谷歌產(chǎn)品線則完全不同搜索、廣告、云服務(wù)都面對真實(shí)用戶反饋周期是小時(shí)級甚至分鐘級的。用戶不會因?yàn)椤斑@個模型理論上很先進(jìn)”就容忍糟糕的響應(yīng)速度也不會因?yàn)椤把芯繄F(tuán)隊(duì)需要繼續(xù)探索”就接受反復(fù)出錯的線上功能。當(dāng)哈薩比斯的角色從單純的DeepMind負(fù)責(zé)人變成要統(tǒng)籌整個谷歌AI研發(fā)資源的人沖突點(diǎn)就變得非常具體時(shí)間尺度不同研究團(tuán)隊(duì)愿意花兩個月驗(yàn)證一個新方向產(chǎn)品團(tuán)隊(duì)希望兩周內(nèi)看到可上線的能力。成功標(biāo)準(zhǔn)不同研究人員看論文、基準(zhǔn)分、可復(fù)現(xiàn)性產(chǎn)品團(tuán)隊(duì)看留存、成本、用戶投訴率。風(fēng)險(xiǎn)承受度不同研究允許探索性失敗產(chǎn)品環(huán)境一次嚴(yán)重事故就可能影響大量用戶。我見過很多公司照抄這種“研究院業(yè)務(wù)線”的組合最后幾乎都會踩同一個坑研究團(tuán)隊(duì)和業(yè)務(wù)團(tuán)隊(duì)互相覺得對方不專業(yè)。業(yè)務(wù)方說研究方只做demo不落地研究方說業(yè)務(wù)方只催進(jìn)度不尊重科學(xué)。問題不是誰對誰錯而是沒有在項(xiàng)目啟動前把“誰在哪個階段說了算”寫清楚。1.2 項(xiàng)目內(nèi)的“研究時(shí)間盒”和“交付承諾”谷歌現(xiàn)在的做法本質(zhì)上是在同一個大組織里建立兩類節(jié)奏。一類節(jié)奏負(fù)責(zé)前沿探索允許延遲和失敗另一類節(jié)奏負(fù)責(zé)產(chǎn)品化必須保證穩(wěn)定。這個思路可以直接搬到團(tuán)隊(duì)內(nèi)部。我給中小團(tuán)隊(duì)的建議是把項(xiàng)目分成兩種類型探索型項(xiàng)目目標(biāo)不是上線而是驗(yàn)證“這個方向是否可行”。周期可以放寬到幾周甚至幾個月考核標(biāo)準(zhǔn)是結(jié)論而不是代碼。交付型項(xiàng)目目標(biāo)是在約定時(shí)間提供一個可用的功能可靠性優(yōu)先范圍可以收縮但質(zhì)量不能妥協(xié)。更實(shí)際的做法是給探索型任務(wù)設(shè)置“時(shí)間盒”。比如一個Agent方向的預(yù)研任務(wù)規(guī)定兩周內(nèi)必須給出評估結(jié)論方案A可行、方案B需要更多數(shù)據(jù)、方案C直接放棄。時(shí)間一到不管結(jié)果是否完美先停下來復(fù)盤。很多AI項(xiàng)目出問題不是因?yàn)樘剿魈俣翘剿鳑]有截止時(shí)間最后變成一條無邊界的研究線把產(chǎn)品迭代拖死了。2. 先從模型選型和部署說起谷歌的平衡術(shù)在工程里如何落地2.1 先寫任務(wù)邊界再選模型哈薩比斯在谷歌面對的模型選擇問題和普通開發(fā)者在技術(shù)選型時(shí)本質(zhì)上是一樣的不是選“最強(qiáng)的模型”而是選“在成本、延遲、效果約束下最合適的模型”。很多團(tuán)隊(duì)一上來就把任務(wù)丟給旗艦大模型結(jié)果發(fā)現(xiàn)兩個問題賬單很高但有些簡單場景根本用不到那么強(qiáng)的推理能力輸出不穩(wěn)定連固定格式都經(jīng)常出錯。正確順序應(yīng)該是先寫任務(wù)邊界再選模型。任務(wù)邊界至少包括下面幾項(xiàng)輸入是什么純文本、結(jié)構(gòu)化數(shù)據(jù)、圖片、語音還是混合輸入輸出要求是什么自由文本、JSON、表格、代碼還是多選結(jié)果可接受的延遲范圍實(shí)時(shí)對話、異步處理、還是離線批量任務(wù)單條數(shù)據(jù)量級幾百字、幾千字還是超過模型上下文窗口的長文本允許的失敗率有些場景失敗重試就行有些場景一次錯誤會造成業(yè)務(wù)事故。運(yùn)行環(huán)境約束是否有私有化要求數(shù)據(jù)能不能傳輸?shù)酵獠拷涌趯懲赀吔缰笤倥袛嗄Ｐ湍芰Φ南孪?。這里有一個常見誤區(qū)總覺得能力越強(qiáng)越好。實(shí)際上在業(yè)務(wù)場景里模型能力過剩往往會引入更多不可控性。一個簡單的意圖分類任務(wù)用中等參數(shù)的模型跑穩(wěn)定性和成本都更容易控制非要用旗艦?zāi)Ｐ头炊赡芤驗(yàn)橥评硖`活把本不該判成同一類的樣本關(guān)聯(lián)起來。我自己一般會用一個三層篩選法先用中等參數(shù)模型在小樣本上跑一遍看輸出格式、關(guān)鍵字段和基本語義是否滿足要求。如果中等參數(shù)模型有明顯短板再升級到更大參數(shù)模型并記錄差異點(diǎn)。如果大參數(shù)模型仍然不穩(wěn)定優(yōu)先排查Prompt、輸入格式和上下文構(gòu)造而不是繼續(xù)換更強(qiáng)的模型。2.2 云端、本地、邊緣端怎么權(quán)衡模型部署形態(tài)是另一個“平衡點(diǎn)”。很多團(tuán)隊(duì)對“本地化部署”有執(zhí)念覺得數(shù)據(jù)必須留在自己的服務(wù)器上才安全。但這個決策如果做得太早成本會非常高需要自己維護(hù)GPU集群、鏡像、依賴環(huán)境、彈性伸縮和應(yīng)用監(jiān)控而這些在早期很可能都不是核心業(yè)務(wù)。更務(wù)實(shí)的路徑是分階段判斷部署形態(tài)適合場景主要成本注意點(diǎn)云端API托管業(yè)務(wù)驗(yàn)證期、低頻調(diào)用、原型Demo按調(diào)用量付費(fèi)單價(jià)可控要做好超時(shí)、限流和錯誤重試云端自建推理高頻調(diào)用、需要定制模型版本、成本敏感GPU機(jī)器、運(yùn)維、模型服務(wù)框架要監(jiān)控GPU利用率避免閑置資源本地化部署數(shù)據(jù)不能出內(nèi)網(wǎng)、合規(guī)要求嚴(yán)格硬件采購、運(yùn)維、版本升級模型體積和推理速度需要單獨(dú)驗(yàn)證邊緣端推理離線環(huán)境、低延遲、移動端App模型壓縮、端側(cè)框架、兼容性測試量化后要看效果損失是否在容忍范圍內(nèi)我見過一個很典型的項(xiàng)目團(tuán)隊(duì)一開始就購買了兩張昂貴的GPU卡做本地化部署給一個低頻內(nèi)部工具做助手。結(jié)果部署完成后平均每天調(diào)用量只有幾十次GPU利用率不到5%還要花大量時(shí)間處理驅(qū)動、依賴、日志和監(jiān)控問題。后來改用云端API每個月成本不到原來的十分之一。這不是說本地化不好而是說它的價(jià)值要在某個調(diào)用量和數(shù)據(jù)安全需求之上才會體現(xiàn)出來。如果還在業(yè)務(wù)驗(yàn)證期我的建議是先采用云端API把業(yè)務(wù)邏輯跑通用真實(shí)數(shù)據(jù)驗(yàn)證模型效果同時(shí)記錄調(diào)用量和失敗率。等業(yè)務(wù)量穩(wěn)定了再根據(jù)這些數(shù)據(jù)判斷是否需要自建推理服務(wù)或本地化部署。2.3 部署之后的評估與排查順序模型部署完成不代表結(jié)束接下來最關(guān)鍵的是評估。很多團(tuán)隊(duì)只看“能不能返回結(jié)果”但“能返回結(jié)果”和“返回正確結(jié)果”是兩回事。固定評測集至少要準(zhǔn)備50到100條代表性輸入。這些輸入要覆蓋正常請求、邊界請求、異常請求、長文本、空輸入、惡意輸入等類型。評測時(shí)記錄幾類指標(biāo)輸出完整性是否包含應(yīng)填寫的字段是否有截?cái)?。格式正確率需要JSON時(shí)是否返回合法JSON需要代碼時(shí)能否直接運(yùn)行。關(guān)鍵信息命中率業(yè)務(wù)核心字段是否與預(yù)期一致。平均耗時(shí)和P95耗時(shí)單條調(diào)用、并發(fā)場景下的延遲表現(xiàn)。失敗重試率多少請求第一次失敗需要重試之后才成功。排查時(shí)有一個固定的鏈路順序。先看現(xiàn)象再輸入再環(huán)境再參數(shù)最后才懷疑模型。很多報(bào)錯表面上是模型問題實(shí)際是路徑、權(quán)限、依賴版本或輸入格式的問題。舉個例子一個批量處理任務(wù)總是跑到一半就停下先不要盲目調(diào)temperature先去看輸出目錄是否有寫入權(quán)限、輸入文件里是否夾帶了格式異常的行、隊(duì)列服務(wù)有沒有把同一個任務(wù)重復(fù)投遞。日志里如果能看到具體的異常棧按順序處理會快得多。3. Agent開發(fā)的“能力放開程度”這是AI平衡術(shù)最容易被搞壞的地方3.1 工具調(diào)用范圍要分級AI Agent開發(fā)是現(xiàn)在很熱的方向也是最容易把“平衡”做壞的領(lǐng)域。Agent最大的賣點(diǎn)是可以自主調(diào)用工具但最大的風(fēng)險(xiǎn)也在這里。如果不對工具調(diào)用范圍分級一個看起來很有用的Agent可能在一次錯誤判斷里把不該執(zhí)行的寫入操作執(zhí)行了。我建議在工具注冊層做三級控制只讀工具查詢數(shù)據(jù)庫、搜索文檔、讀取文件內(nèi)容。這類工具可以放開給Agent自主調(diào)用。受限寫操作創(chuàng)建草稿、發(fā)送待確認(rèn)郵件、修改非核心字段。Agent可以發(fā)起但必須經(jīng)過用戶確認(rèn)或二次校驗(yàn)。禁止操作刪除數(shù)據(jù)、直接發(fā)起支付、修改生產(chǎn)環(huán)境配置。這類操作不能交給Agent必須由外部系統(tǒng)硬性攔截。一個更嚴(yán)格的做法是在工具層面加白名單和環(huán)境變量。即使Agent在內(nèi)部計(jì)劃中決定調(diào)用某個工具工具網(wǎng)關(guān)也要驗(yàn)證當(dāng)前會話的權(quán)限等級。不要相信模型生成的調(diào)用參數(shù)尤其是涉及路徑、金額、用戶ID這類關(guān)鍵字段時(shí)要做基礎(chǔ)校驗(yàn)。這里可以參考一個通用流程Agent收到請求 - 生成工具調(diào)用計(jì)劃 - 工具網(wǎng)關(guān)校驗(yàn)權(quán)限和數(shù)據(jù)格式 - 執(zhí)行調(diào)用 - 返回結(jié)果給Agent - Agent生成最終回復(fù)。每一環(huán)都寫日志方便回看Agent當(dāng)時(shí)的決策上下文。3.2 自由推理和固定流程怎么組合不是所有業(yè)務(wù)都需要讓Agent完全自由地推理。任務(wù)步驟是否會被業(yè)務(wù)方頻繁修改是判斷使用哪種編排方式的重要因素。如果業(yè)務(wù)邏輯相對固定比如客服工單分類、關(guān)鍵詞提取、摘要生成建議采用“固定流程 LLM填充字段”的方式。這樣可控性強(qiáng)、延遲低、故障定位容易。Agent的“智能”體現(xiàn)在處理格式變化和邊界情況而不是自由決定下一步做什么。如果任務(wù)確實(shí)需要多步推理和動態(tài)規(guī)劃比如跨系統(tǒng)任務(wù)調(diào)度、復(fù)雜文檔處理再引入ReAct或其他決策框架。但要注意自由度越高越需要設(shè)置最大迭代次數(shù)和步驟上限。我一般會把單次任務(wù)的最大工具調(diào)用次數(shù)控制在5到8次超過之后強(qiáng)制進(jìn)入人工處理。不要期待Agent永遠(yuǎn)能自己繞出來很多問題繞到最后只會浪費(fèi)token和用戶時(shí)間。用一個簡單的流程示意用戶輸入 - 意圖識別判斷走固定流程還是動態(tài)規(guī)劃 - 固定流程按預(yù)定義步驟調(diào)用工具LLM只負(fù)責(zé)填參數(shù) - 動態(tài)規(guī)劃Agent生成步驟逐步行事 - 每一步判斷是否達(dá)到目標(biāo)或達(dá)到最大迭代次數(shù) - 輸出結(jié)果或轉(zhuǎn)人工這個方案的好處是大多數(shù)常規(guī)請求走固定流程性能和穩(wěn)定性都有保證只有真正復(fù)雜的請求才走Agent動態(tài)決策把風(fēng)險(xiǎn)控制在小范圍內(nèi)。3.3 失敗重試、日志和止損Agent任務(wù)比普通接口更容易出現(xiàn)“看似成功、實(shí)際錯誤”的情況。比如LLM返回了一段封裝好的JSON但業(yè)務(wù)系統(tǒng)解析時(shí)發(fā)現(xiàn)字段缺失工具調(diào)用返回了結(jié)果但結(jié)果里沒有關(guān)鍵信息。這類情況不能簡單算作成功。我通常會給Agent增加三類保護(hù)機(jī)制結(jié)構(gòu)化輸出校驗(yàn)要求模型返回指定JSON格式然后在代碼里做schema校驗(yàn)不合法就重試一次并修正Prompt。超時(shí)和重試工具調(diào)用設(shè)置超時(shí)時(shí)間比如10秒。超時(shí)后重試一次仍然失敗就把失敗信息返回給Agent讓Agent切換方案。人工兜底連續(xù)失敗三次后不再讓Agent繼續(xù)嘗試直接進(jìn)入人工處理隊(duì)列。不要因?yàn)椤岸嘣噹状握f不定就行”而無限循環(huán)。日志是排查Agent問題的核心。建議把每次會話的歷史、模型輸入輸出、工具調(diào)用參數(shù)、返回結(jié)果、耗時(shí)、token消耗全部落盤。問題發(fā)生時(shí)先看Agent在哪個環(huán)節(jié)做出了錯誤決策是上下文被截?cái)唷⒐ぞ叻祷亟Y(jié)果有誤還是Prompt引導(dǎo)不夠清晰。很多Agent問題不是模型太笨而是歷史消息太長重要信息被淹沒或者工具返回格式不標(biāo)準(zhǔn)導(dǎo)致模型誤解。3.4 并發(fā)設(shè)置不要一上來就拉滿很多團(tuán)隊(duì)在Agent做完之后第一件事就是把并發(fā)數(shù)調(diào)到最大結(jié)果服務(wù)直接被打崩。原因是Agent任務(wù)和普通API調(diào)用不一樣一次Agent任務(wù)里可能包含多個模型請求和多個工具調(diào)用單個任務(wù)的執(zhí)行時(shí)間和資源消耗波動很大。正確做法是先跑小規(guī)模壓測。用10個、20個、50個請求分別測試記錄單任務(wù)耗時(shí)、總耗時(shí)、失敗率和資源占用。觀察P95延遲而不是只看平均值。平均值很容易被極端值拉偏P95更能反映真實(shí)體驗(yàn)。初始并發(fā)可以參考這個公式并發(fā)數(shù) 任務(wù)總數(shù) / 單任務(wù)預(yù)估耗時(shí)。比如100個任務(wù)每個任務(wù)平均2秒先開5個并發(fā)一輪大約需要40秒。跑通之后再逐步調(diào)大并發(fā)觀察失敗率是否上升、模型服務(wù)是否超時(shí)、工具調(diào)用是否觸發(fā)限流。不要為了追求吞吐量把錯誤率抬到不可接受的水平。4. 用評估機(jī)制平衡“快”和“好”從谷歌的產(chǎn)品壓力說起4.1 沒有評測集就沒有優(yōu)化依據(jù)谷歌把研究團(tuán)隊(duì)和產(chǎn)品團(tuán)隊(duì)放在一起時(shí)最需要解決的是“什么叫好”的定義。研究指標(biāo)比如準(zhǔn)確率、困惑度產(chǎn)品指標(biāo)比如用戶體驗(yàn)、任務(wù)完成率并不完全一致。如果不在團(tuán)隊(duì)內(nèi)部統(tǒng)一“好”的標(biāo)準(zhǔn)所有討論都會變成各說各話。放到具體項(xiàng)目里就是必須建評測集。沒有評測集的AI項(xiàng)目所有優(yōu)化都靠感覺有人說效果不好你問他哪里不好他說“看起來不對”。這是低效的。評測集的構(gòu)建有幾個要點(diǎn)數(shù)量不用太多50到100條足夠發(fā)現(xiàn)大部分問題。樣本要覆蓋正常場景、邊界場景、異常輸入。定期更新把線上真實(shí)出錯的案例補(bǔ)進(jìn)去防止模型越改越偏。每次換模型、改Prompt、改參數(shù)都要用同一批樣本回測。評測的時(shí)候可以分兩個維度一個是客觀維度比如格式正確率、字段完整率、重試率另一個是主觀維度比如輸出是否自然、是否符合業(yè)務(wù)習(xí)慣。主觀維度可以按1到5分打分每次改動后對比分?jǐn)?shù)變化。沒有評測機(jī)制AI項(xiàng)目很容易陷入“改A模型發(fā)現(xiàn)B場景壞了改回B模型又發(fā)現(xiàn)A場景不行”的循環(huán)。4.2 灰度發(fā)布怎么切模型流量模型更新不像普通代碼更新不能假設(shè)“新版本一定優(yōu)于舊版本”。同一個模型因?yàn)镻rompt小幅調(diào)整可能在某類場景下表現(xiàn)變好在另一類場景下表現(xiàn)變差。所以模型切換必須走灰度?；叶劝l(fā)布至少分三檔內(nèi)測階段只有開發(fā)者和測試人員可以訪問新模型版本重點(diǎn)看有沒有明顯報(bào)錯和結(jié)果異常。小流量階段切5%到10%的真實(shí)流量對比新舊版本的調(diào)用成功率、平均延遲、無效輸出率和用戶投訴率。全量階段小流量觀察一段時(shí)間后確認(rèn)核心指標(biāo)沒有退化再逐步切到100%?；叶冗^程中最怕出現(xiàn)“舊版本不可回滾”的問題。模型服務(wù)的回滾不只是切換版本號還要注意對話緩存、向量數(shù)據(jù)庫索引、工具版本是否兼容。如果新模型輸出的數(shù)據(jù)結(jié)構(gòu)變了舊模型可能無法理解緩存里的歷史內(nèi)容。所以每次改動盡量保持輸入輸出格式兼容避免上線后騎虎難下。4.3 該看的指標(biāo)到底看哪些很多監(jiān)控系統(tǒng)把CPU、內(nèi)存、GPU利用率全部展示出來看起來專業(yè)實(shí)際參考價(jià)值不大。AI項(xiàng)目真正要盯的指標(biāo)分成兩類。第一類是基礎(chǔ)設(shè)施指標(biāo)推理服務(wù)P95延遲。排隊(duì)請求數(shù)。GPU顯存利用率和模型服務(wù)吞吐。工具調(diào)用超時(shí)率和重試率。第二類是業(yè)務(wù)效果指標(biāo)調(diào)用成功率。輸出為空或無效的比例。用戶主動反饋負(fù)面體驗(yàn)的比例。單次任務(wù)平均token消耗和成本。不要追求“99.99%可用性”這種極端指標(biāo)。如果某個AI產(chǎn)品一個月里有幾十次小概率出錯但是都能被重試機(jī)制兜住用戶體驗(yàn)其實(shí)不會受太大影響。真正危險(xiǎn)的是“出錯時(shí)沒有日志、沒有提示、沒有兜底”用戶面對一個靜默失敗的黑盒這才是流失用戶的開始。5. 普通項(xiàng)目團(tuán)隊(duì)能借鑒的幾條平衡經(jīng)驗(yàn)5.1 早期不要過度建制谷歌這樣的公司需要復(fù)雜的組織結(jié)構(gòu)來管理不同團(tuán)隊(duì)但普通項(xiàng)目團(tuán)隊(duì)如果照搬大概率會死在復(fù)雜度上。很多AI應(yīng)用項(xiàng)目一開始就引入Kubernetes、微服務(wù)、多環(huán)境流水線、權(quán)限系統(tǒng)結(jié)果核心功能還沒跑通維護(hù)成本已經(jīng)失控。我更建議早期保持“單服務(wù) 任務(wù)隊(duì)列 日志”的輕量架構(gòu)。先把一個最小閉環(huán)跑通用戶輸入 - 模型處理 - 結(jié)果輸出 - 基礎(chǔ)日志。不要在一開始就追求“架構(gòu)先進(jìn)”。架構(gòu)的復(fù)雜度應(yīng)該跟著業(yè)務(wù)量增長而不是提前預(yù)支。研究型探索項(xiàng)目尤其要輕量因?yàn)楹芏嗵剿髯罱K會被推翻重架構(gòu)意味著高沉沒成本。5.2 把探索任務(wù)和生產(chǎn)任務(wù)分開管理無論是個人開發(fā)者還是團(tuán)隊(duì)都要在項(xiàng)目清單里明確標(biāo)注“這個項(xiàng)目是探索還是生產(chǎn)”。探索項(xiàng)目不需要承諾穩(wěn)定性上線不是目標(biāo)生產(chǎn)項(xiàng)目必須寫清楚SLA、監(jiān)控和兜底方案。這種分類方式可以避免很多內(nèi)耗探索項(xiàng)目求快、求結(jié)論生產(chǎn)項(xiàng)目求穩(wěn)、求可維護(hù)性。兩者混在一起最后只能互相拖累。在版本管理上探索項(xiàng)目可以放在獨(dú)立分支不必做過多的代碼審查和部署流程但要保證技術(shù)文檔和實(shí)驗(yàn)結(jié)果有記錄方便后續(xù)接手。生產(chǎn)項(xiàng)目的每一次改動都走評審、測試和灰度確保不把風(fēng)險(xiǎn)直接暴露給用戶。5.3 安全邊界要前置而不是事后補(bǔ)救現(xiàn)在市面上很多AI應(yīng)用都在最基礎(chǔ)的安全邊界上偷懶。比如聊天產(chǎn)品不做輸入內(nèi)容過濾Agent工具調(diào)用不做權(quán)限驗(yàn)證模型服務(wù)不記錄請求來源。從熱詞里可以看到很多人專門找“無違禁詞”的AI聊天工具這恰恰說明正規(guī)產(chǎn)品在安全能力上做得不夠反而讓這些灰色需求有了市場。對開發(fā)者來說內(nèi)容審核、權(quán)限控制、數(shù)據(jù)脫敏、操作審計(jì)這些能力應(yīng)該在項(xiàng)目第一天就規(guī)劃進(jìn)去。即使第一版只做最基礎(chǔ)的關(guān)鍵詞過濾和操作日志也要讓系統(tǒng)有“可追溯”的能力。等到用戶量上來再補(bǔ)安全能力成本會成倍增加而且一旦出事影響面很難控制。這其實(shí)是“平衡”的另一面AI能力放開得越快邊界和安全機(jī)制越要跟上。不是用安全限制AI的發(fā)展而是讓AI在可控范圍內(nèi)發(fā)展。5.4 每個取舍都記錄下來最后一條經(jīng)驗(yàn)是把每個技術(shù)決策的理由寫下來。為什么選這個模型而不是另一個為什么temperature設(shè)成0.3而不是0.8為什么允許Agent調(diào)用三個工具而不是五個這些決策當(dāng)時(shí)看起來可能很微小但兩個月后回頭看都是理解系統(tǒng)現(xiàn)狀的關(guān)鍵線索。可以簡單維護(hù)一份“AI項(xiàng)目決策記錄”不需要長篇大論一個表格就夠了日期、決策、背景、可選方案、選擇理由、需要重新評估的信號。模型效果波動、成本上升、用戶投訴增加時(shí)回頭翻這份記錄往往比重新分析代碼更有效率。谷歌這樣的巨頭需要平衡普通團(tuán)隊(duì)也需要只是我們要平衡的東西更小、更具體也更不能靠拍腦袋決定。AI行業(yè)每天都在冒出新工具和新模型真正拉開差距的往往不是誰先用上了新功能而是誰能持續(xù)做出正確的取舍。哈薩比斯在谷歌面對的是研發(fā)、產(chǎn)品、安全、商業(yè)的多重約束普通開發(fā)者在自己的項(xiàng)目里面對的是時(shí)間、成本、質(zhì)量和體驗(yàn)的取舍。兩者都需要在信息不完整的時(shí)候做決定然后通過數(shù)據(jù)和反饋持續(xù)修正。理解了這一點(diǎn)再看這個新聞就不會只當(dāng)成大廠八卦而會當(dāng)成一整套可以在自己工程里復(fù)用的決策思路。