智能體面試準備五十四智能體線上實驗與效果歸因體系——上線決策科學引言為什么離線評測高分不等于線上能發B31 講過 Agent 評測體系軌跡指標、LLM-as-Judge、benchmarkB20 講過可觀測性。但評測高分只是門票——真正決定一個智能體能不能上線的是線上實驗能不能證明它比舊版好且好在哪里、壞在哪里可解釋。本篇是工程實戰深化的收官講講清智能體上線前的實驗設計A/B、影子、漸進和上線后的效果歸因因果分解、bad case 漏斗、上線門禁。這是大廠面試里有沒有真把 Agent 跑過生產的分水嶺。讀完本篇你應當能說清Agent 的線上實驗和普通推薦系統 A/B 有何不同、指標該怎么設計才不會騙自己、出問題時怎么歸因到具體環節。普通模型上線: 輸入X - 模型 - 輸出Y, 可隨機分流做 A/B Agent 上線: 輸入X - 多步規劃/工具調用/環境交互 - 輸出Y 差異: 路徑非確定(同輸入不同軌跡)、狀態有副作用(調了API/改了數據)、成本隨步數變 所以: 實驗設計要管軌跡和副作用, 不只管最終 Y第一節 離線到在線的鴻溝Agent 特有的三類落差1.1 分布落差離線 benchmark 是靜態題集線上請求是真實、長尾、帶噪的。離線答得好的 Agent線上遇到沒見過的工具報錯、用戶亂輸入可能直接崩。所以離線只能證偽差的一律不過不能證真高分不代表線上穩。1.2 路徑落差Agent 同一個輸入可能走出不同軌跡離線評測只采樣了幾條線上千奇百怪。要看成功率而非某次對不對更要看最壞軌跡會不會造成破壞。1.3 副作用落差普通模型輸出文本無副作用Agent 會調接口、寫庫、發消息。線上實驗必須隔離副作用影子模式/沙箱否則 A/B 實驗本身就在制造事故。離線評測 - 線上實驗 的鴻溝 分布: 靜態題集 vs 真實長尾 路徑: 采樣軌跡 vs 全軌跡分布 副作用: 無 vs 有(必須隔離) 結論: 離線過線只是允許進實驗, 不是允許全量第二節 三種線上實驗形態及其在 Agent 上的特殊性2.1 A/B 實驗在線分流把流量按比例分給實驗組新 Agent和對照組舊版對比指標。Agent 的特殊性在于不能只看最終答案準確率還要看過程成本平均步數、工具調用次數、token 消耗和安全指標錯誤動作率、需人工接管的次數。一個答案略好但成本是舊版 3 倍、且多調了兩次危險接口的版本不能算贏。2.2 影子模式Shadow新 Agent 在線上跑但不執行——它和實際請求一起推理、生成動作但動作不真正落地只記錄它會怎么做并與真實結果對比。這是上線前最安全的驗證零副作用卻能拿到真實分布下的軌跡和指標。2.3 漸進發布Canary / 漸進先放 1% 流量看住指標逐檔放量到 5%、20%、100%。Agent 上線尤其需要漸進因為長尾問題往往在量起來后才暴露。配合自動熔斷指標越界立即回滾把事故半徑控制在最小。形態副作用能看什么適用階段A/B有需隔離/分流真實效果成本安全已較有信心要定勝負影子無真實分布下的軌跡上線前最后一道關漸進小限流內放量后的長尾表現正式上線過程第三節 指標設計別被準確率騙了3.1 四組指標缺一不可效果指標任務成功率、最終答案準確率、用戶滿意度過程指標平均規劃步數、工具調用次數、重試次數成本指標平均 token 消耗、平均延遲TTFT/TPOT、單位請求成本安全指標錯誤動作率、需人工接管率、危險操作次數、越權嘗試。面試常考只盯成功率有什么問題 答可能掩蓋成本爆炸或安全隱患。一個成功率 95% 但每次都調危險接口、成本是舊版 5 倍的版本全量上線就是事故。3.2 指標要分層、要可歸因每個指標應當能下鉆到是哪類子任務拖的。例如成功率按單跳/多跳有無工具報錯長尾 query分桶才能知道新版到底在哪變好、在哪變差。# 指標分桶記錄示意defrecord(run):bucketf{run.hop_type}/{run.has_tool_error}/{run.is_longtail}metrics[bucket].successrun.okmetrics[bucket].costrun.token_costmetrics[bucket].safe(0ifrun.danger_actionelse1)第四節 因果歸因出問題時知道壞在哪4.1 bad case 漏斗把失敗按發生在哪一步建漏斗規劃錯檢索錯工具調用錯結果組裝錯這樣一次失敗能定位到具體環節而不是籠統的Agent 不行。失敗歸因漏斗 任務失敗 100 ├─ 規劃階段錯 40 (子問題拆分/路由錯) ├─ 檢索階段錯 25 (召回不準/模態選錯) ├─ 工具調用錯 20 (參數錯/超時/報錯未處理) └─ 生成組裝錯 15 (幻覺/格式錯)4.2 因素分解與對照用 A/B 的對照數據做因素分解實驗組成功率比對照組低 5 個點是所有桶都低模型整體退化還是只在多跳長尾桶低特定能力缺口前者要回退后者可以針對性補數據或加檢索。歸因結論要能指導下一步動作而不是只給一個數字。4.3 可觀測性支撐歸因B20 講的可觀測性在這里是關鍵基建每一次 Agent 運行都要有完整 trace每步輸入/輸出/工具調用/耗時/錯誤信息歸因才能從猜變成查日志。沒有 trace 的 Agent線上出問題就是黑盒。第五節 上線門禁與回滾把發不發變成規則5.1 門禁清單上線不是拍腦袋而是一組硬性門禁效果不顯著劣于對照、成本增幅在預算內、安全指標零越線、長尾桶無異常退化。任一門禁不達標即攔截。5.2 自動熔斷與回滾實驗跑起來后實時監控門禁指標一旦越界立即把流量切回舊版自動回滾并告警。Agent 上線尤其要快回滾因為副作用可能隨時間累積如錯誤數據越寫越多。上線決策流 離線過線 - 影子驗證(零副作用看軌跡) - 漸進1% - 門禁監控 ├─ 全部門禁達標 - 逐檔放量 - 100% 全量 └─ 任一越界 - 自動熔斷回滾 - 歸因 - 修復 - 重進實驗第六節 工程骨架一個最小實驗與歸因框架classAgentExperiment:def__init__(self,control,treatment,gate):self.control,self.treatment,self.gatecontrol,treatment,gatedefroute(self,req):returnself.treatmentifhash(req.id)%100self.rolloutelseself.controldefevaluate(self,runs):repsummarize(runs)# 四組指標分桶ifnotself.gate.pass_(rep):# 任一門禁不達標self.rollback();self.alert(rep)# 自動回滾告警return(BLOCKED,attr_breakdown(runs))# 返回歸因return(PASS,rep)這段代碼把分流—評估—門禁—回滾—歸因串成閉環面試里能寫出來就說明你真做過上線而不只是調 prompt。第七節 五個上線實驗踩坑坑一用平均成功率掩蓋長尾崩壞。整體成功率只掉 1%但多跳長尾桶掉了 20%全量后投訴爆了。必須分桶看長尾桶單獨設門禁。坑二影子模式忘了隔離寫操作。以為不執行就安全但 Agent 還是調了帶副作用的接口發消息/寫庫。影子必須走只讀副本或沙箱寫操作一律 mock。坑三A/B 兩組環境不一致。實驗組用了新的檢索器、對照組是舊的指標差異分不清是誰的功勞。上線實驗要保證除被比較的變量外其他全一致。坑四回滾不及時副作用累積。指標越界后沒自動熔斷Agent 繼續往生產庫寫錯數據半小時。回滾觸發條件要前置、要快寧可誤攔不可漏攔。坑五歸因只給數字不給動作。復盤說成功率降了 5%但沒人知道降在哪、怎么改。歸因的終點必須是下一步具體動作回退/補數據/加檢索/改規劃否則等于沒歸因。面試速答本篇可直接背的 3 句Agent 上線實驗和普通 A/B 的根本差異Agent 路徑非確定、有副作用、成本隨步數變所以實驗必須管軌跡副作用成本安全不能只看最終答案。離線評測只能證偽不能證真上線前要過影子模式零副作用看真實分布軌跡再漸進放量配合自動熔斷回滾。效果歸因靠 bad case 漏斗規劃/檢索/工具/生成分步定位 指標分桶對照結論要能指導回退還是針對性補靠完整 trace 支撐。高頻追問清單Agent 的 A/B 實驗怎么保證同輸入分到同組以便對照提示按請求 id 哈希分流影子模式下 Agent 不執行動作那它調用的工具要不要真打提示打只讀/沙箱禁寫成功率提升 2% 但成本漲 3 倍發不發你的門禁怎么設bad case 漏斗里規劃錯占比最高下一步具體怎么改漸進發布從 1% 到 100%每檔要看多久、看哪些指標才放量沒有可觀測性 trace歸因只能靠什么為什么這是硬傷