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