簡介美團大模型Agent實踐手冊是一份面向技術(shù)開發(fā)者、業(yè)務(wù)應(yīng)用者與決策者的系統(tǒng)性技術(shù)指南聚焦大模型Agent從理論認(rèn)知到工程落地的完整鏈路。手冊共八章從基礎(chǔ)認(rèn)知切入梳理大模型Agent的定義、核心能力與美團內(nèi)部定位并回顧其發(fā)展歷程隨后深入技術(shù)架構(gòu)介紹龍貓大模型LongCat-Flash-Chat核心架構(gòu)、模型訓(xùn)練流程與策略及能力評估矩陣。業(yè)務(wù)實踐部分覆蓋外賣、到店、酒旅、共享單車四條業(yè)務(wù)線通過實際案例展示Agent如何應(yīng)對差異化需求開發(fā)流程章節(jié)則拆解需求分析、數(shù)據(jù)預(yù)處理、模型選型與微調(diào)、架構(gòu)設(shè)計、測試優(yōu)化等關(guān)鍵步驟并延伸至工具鏈、監(jiān)控運維與安全合規(guī)等工程化議題最后給出評估迭代方法與避坑指南。資源為1個PDF文件壓縮包約753KB目錄結(jié)構(gòu)清晰、章節(jié)完整便于按模塊檢索學(xué)習(xí)。目前已有178人學(xué)習(xí)適合希望系統(tǒng)掌握大模型Agent架構(gòu)設(shè)計與業(yè)務(wù)落地方法的中高級讀者參考。1. 美團大模型 Agent 實踐手冊從單點問答到可編排智能體的落地路徑美團業(yè)務(wù)線里跑著大量長鏈路任務(wù)比如商家入駐審核、騎手申訴判責(zé)、客服工單分流這些場景單靠一次大模型問答根本兜不住。所謂美團大模型 Agent 實踐本質(zhì)是把大模型從「會聊天」推到「會干活」給它工具、給它記憶、給它編排邏輯讓它在多輪交互里自己決定下一步調(diào)什么接口、查什么數(shù)據(jù)、什么時候停下來交給人。這份手冊面向的是已經(jīng)能把大模型 API 跑通、但卡在「怎么讓它穩(wěn)定完成一個真實業(yè)務(wù)閉環(huán)」的工程師。你會看到 Agent 的架構(gòu)分層、工具注冊、記憶管理、編排與評測以及那些上線后才會暴露的坑。它不解決模型能力上限問題解決的是工程可控性問題——讓一個概率模型在確定性業(yè)務(wù)里少翻車、可回滾、能觀測。適合后端、算法工程和業(yè)務(wù)研發(fā)一起看因為 Agent 落地從來不是單點技術(shù)活。2. 美團大模型 Agent 的架構(gòu)分層與選型理由2.1 為什么不能把業(yè)務(wù)邏輯全塞進提示詞很多團隊第一版 Agent 就是一段超長 system prompt把工具說明、業(yè)務(wù)規(guī)則、輸出格式全寫進去。跑 demo 沒問題一上量就崩提示詞超過幾千 token 后模型對中間段指令的遵循度明顯下降改一條規(guī)則要動整段文本回歸測試無從下手。美團這類業(yè)務(wù)的特點是規(guī)則多、變更頻繁、責(zé)任邊界清晰所以必須把「模型負(fù)責(zé)決策」和「代碼負(fù)責(zé)執(zhí)行」拆開。常見做法是三層決策層大模型、能力層工具/函數(shù)、編排層狀態(tài)機或圖。決策層只輸出結(jié)構(gòu)化意圖能力層用確定性代碼實現(xiàn)編排層控制流程走向和終止條件。這樣模型再飄也飄不出代碼畫的圈。選型上如果任務(wù)步驟固定用狀態(tài)機編排就夠如果步驟依賴中間結(jié)果動態(tài)變化才上更靈活的圖編排。別一上來就追求全自主 Agent業(yè)務(wù)方要的是穩(wěn)定交付不是炫技。2.2 工具注冊把內(nèi)部接口變成模型能調(diào)的 functionAgent 能不能干活取決于工具描述寫得好不好。模型看不到你的代碼只能靠 name、description、parameters 三樣?xùn)|西判斷該不該調(diào)、怎么調(diào)。description 要寫「什么時候用」不是「這是什么」。下面是一個商家信息查詢工具的注冊示例用 Python 字典描述適配主流 function calling 協(xié)議。# 工具注冊每個工具必須包含名稱、用途描述、參數(shù) schema tools [ { type: function, function: { name: query_merchant_info, description: 根據(jù)商家ID查詢?nèi)腭v狀態(tài)、經(jīng)營品類和違規(guī)記錄。當(dāng)用戶詢問某商家資質(zhì)或歷史處罰時調(diào)用。, parameters: { type: object, properties: { merchant_id: { type: string, description: 商家唯一標(biāo)識格式為 M 開頭加 8 位數(shù)字 }, fields: { type: array, items: {type: string}, description: 需要返回的字段可選 status/category/violations不傳返回全部 } }, required: [merchant_id] } } } ]邏輯說明description 里明確「當(dāng)用戶詢問資質(zhì)或處罰時調(diào)用」這是給模型的觸發(fā)條件比單純寫「查詢商家信息」命中率高得多。參數(shù) schema 里把 merchant_id 的格式寫死能擋掉一部分模型瞎編 ID 的情況。fields 設(shè)計成可選數(shù)組是為了控制返回體積——Agent 上下文很貴別一次把整條商家記錄塞回去。參數(shù)說明required 只放真正必需的字段可選字段給默認(rèn)行為。如果某個工具調(diào)用頻率極高考慮在 description 里加一句「優(yōu)先調(diào)用本工具」但別濫用否則模型會過度依賴單一工具。工具數(shù)量超過 20 個后建議按業(yè)務(wù)域分組每輪只掛載相關(guān)組減少模型選擇困難。2.3 記憶管理短期上下文與長期事實要分開存Agent 記憶分兩類短期是當(dāng)前會話的對話歷史長期是跨會話的用戶偏好、商家檔案這類事實。新手常把兩者混在一個 list 里無限追加結(jié)果上下文爆炸、成本飆升、模型注意力被稀釋。正確做法是短期用滑動窗口加摘要長期用外部存儲按需檢索。短期記憶我一般保留最近 6 到 8 輪原始對話更早的用一次輕量模型調(diào)用壓縮成摘要摘要里只留決策相關(guān)的事實比如「用戶已確認(rèn)商家 ID 為 M12345678」。長期記憶走向量庫或 KV 存儲每輪開始時根據(jù)當(dāng)前 query 檢索 top-k 相關(guān)事實注入 system prompt。注意注入的事實要帶時間戳和來源否則模型會把過期信息當(dāng)現(xiàn)狀用這在商家狀態(tài)查詢里是致命的。3. 用編排把多步任務(wù)串起來狀態(tài)機與圖兩種寫法3.1 狀態(tài)機編排步驟固定的業(yè)務(wù)首選商家入駐審核這類流程步驟是確定的收資料 → 校驗資質(zhì) → 查違規(guī) → 出結(jié)論。這種用狀態(tài)機最穩(wěn)每個狀態(tài)對應(yīng)一個函數(shù)模型只在需要判斷的分支上介入。下面是一個簡化狀態(tài)機骨架。# 狀態(tài)機編排固定步驟用代碼控制模型只做分支判斷 class MerchantAuditAgent: def __init__(self, llm, tools): self.llm llm self.tools tools self.state RECEIVE def run(self, context): while self.state ! DONE: if self.state RECEIVE: context[merchant_id] self._extract_id(context[input]) self.state VALIDATE elif self.state VALIDATE: info self.tools[query_merchant_info](context[merchant_id]) context[info] info # 模型只判斷資質(zhì)是否齊全不決定流程走向 decision self.llm.judge_qualification(info) self.state CHECK_VIOLATION if decision[qualified] else REJECT elif self.state CHECK_VIOLATION: if context[info].get(violations): self.state REJECT else: self.state APPROVE elif self.state in (APPROVE, REJECT): context[result] self.state self.state DONE return context邏輯說明流程走向由 state 變量控制模型只在 VALIDATE 階段輸出一個布爾判斷。這樣即使模型判斷錯了影響范圍也被限制在單個分支不會導(dǎo)致整個流程亂跳。每個狀態(tài)轉(zhuǎn)換都可以打點出問題能精確定位是哪一步。參數(shù)說明_extract_id 建議用正則而非模型抽取確定性更高。judge_qualification 的提示詞要求模型輸出 JSON包含 qualified 和 reason 兩個字段reason 用于人工復(fù)核。狀態(tài)機適合步驟少于 10 步、分支明確的場景步驟再多維護成本會超過收益。3.2 圖編排步驟動態(tài)變化時的選擇當(dāng)任務(wù)步驟依賴中間結(jié)果動態(tài)生成比如客服工單可能要先查訂單、再查物流、再判斷是否賠付順序不固定這時用圖編排更合適。核心是把每個能力封裝成節(jié)點邊由模型或規(guī)則決定。常見做法是用現(xiàn)成的圖編排框架節(jié)點間通過共享狀態(tài)傳遞數(shù)據(jù)。關(guān)鍵參數(shù)是最大步數(shù)限制我一般設(shè) 15 步超過就強制終止并轉(zhuǎn)人工。沒有這個上限模型可能陷入循環(huán)調(diào)用。另外每個節(jié)點要有超時和重試外部接口抖動不能讓整個 Agent 掛死。圖編排的調(diào)試比狀態(tài)機難建議每個節(jié)點都記錄輸入輸出快照方便回放。4. 避坑與排查上線后才會暴露的五個問題4.1 工具調(diào)用參數(shù)類型對不上現(xiàn)象模型傳的 merchant_id 是數(shù)字工具期望字符串直接拋類型錯誤。原因JSON schema 里寫了 string但模型從上下文里看到的是純數(shù)字自作主張轉(zhuǎn)了類型。解決工具入口做一次強制類型轉(zhuǎn)換和格式校驗別信任模型輸出。校驗失敗時把錯誤信息回傳給模型讓它重試通常一次就能糾正。4.2 上下文里工具返回結(jié)果過大現(xiàn)象某次查詢返回了完整商家檔案幾千 token后續(xù)幾輪模型開始答非所問。原因大段無關(guān)信息擠占了注意力模型抓不住重點。解決工具返回前做字段裁剪只回當(dāng)前任務(wù)需要的字段如果必須回大對象先摘要再注入。我一般限制單個工具返回不超過 500 token。4.3 模型在分支判斷上反復(fù)橫跳現(xiàn)象同一份資料模型第一次判斷合格重試一次又判斷不合格。原因提示詞里判斷標(biāo)準(zhǔn)模糊模型每次采樣結(jié)果不同。解決把判斷標(biāo)準(zhǔn)寫成明確的規(guī)則列表要求模型逐條核對并輸出核對結(jié)果而不是給一個整體印象分。必要時把 temperature 調(diào)到 0。4.4 長期記憶注入了過期事實現(xiàn)象商家狀態(tài)已變更Agent 還在用上周的記憶回答。原因長期記憶沒有失效機制。解決每條記憶帶 TTL 或版本號檢索時過濾過期項對狀態(tài)類事實強制實時查詢而非走記憶。記憶只存「用戶偏好」這類慢變信息快變狀態(tài)一律實時查。4.5 流式輸出中斷導(dǎo)致狀態(tài)不一致現(xiàn)象前端用 SSE 流式渲染用戶中途關(guān)閉頁面后端 Agent 已經(jīng)執(zhí)行了寫操作但沒返回結(jié)果。原因流式輸出和業(yè)務(wù)執(zhí)行沒解耦。解決把「決策」和「執(zhí)行」分開流式只推決策過程寫操作等決策確認(rèn)后單獨提交并做冪等。中斷時記錄斷點恢復(fù)時從斷點繼續(xù)而不是重跑。5. 評測與灰度怎么判斷一個 Agent 能不能上生產(chǎn)Agent 評測不能只看最終答案對不對要看過程。我一般建三層評測單步工具調(diào)用準(zhǔn)確率、多步任務(wù)完成率、人工接管率。單步評測用構(gòu)造好的 query-工具對跑幾百條看命中率多步任務(wù)用歷史工單回放看端到端完成比例人工接管率是線上指標(biāo)超過閾值就回滾?；叶壬舷扔白幽Ｊ脚芤恢蹵gent 只出建議不執(zhí)行對比人工決策看一致率。一致率穩(wěn)定在 90% 以上再開小流量執(zhí)行執(zhí)行階段保留人工確認(rèn)按鈕。這里沒有后悔藥寧可慢一點也別一次性全量。我自己的習(xí)慣是每個新 Agent 上線前必須跑完 500 條回放用例且人工接管率低于 5% 才放行。這套流程跑下來翻車概率會低很多。希望幫到你。本文還有配套的精品資源點擊獲取 美團大模型Agent實踐手冊：從單點問答到可編排智能體的落地路徑
簡介美團大模型Agent實踐手冊是一份面向技術(shù)開發(fā)者、業(yè)務(wù)應(yīng)用者與決策者的系統(tǒng)性技術(shù)指南聚焦大模型Agent從理論認(rèn)知到工程落地的完整鏈路。手冊共八章從基礎(chǔ)認(rèn)知切入梳理大模型Agent的定義、核心能力與美團內(nèi)部定位并回顧其發(fā)展歷程隨后深入技術(shù)架構(gòu)介紹龍貓大模型LongCat-Flash-Chat核心架構(gòu)、模型訓(xùn)練流程與策略及能力評估矩陣。業(yè)務(wù)實踐部分覆蓋外賣、到店、酒旅、共享單車四條業(yè)務(wù)線通過實際案例展示Agent如何應(yīng)對差異化需求開發(fā)流程章節(jié)則拆解需求分析、數(shù)據(jù)預(yù)處理、模型選型與微調(diào)、架構(gòu)設(shè)計、測試優(yōu)化等關(guān)鍵步驟并延伸至工具鏈、監(jiān)控運維與安全合規(guī)等工程化議題最后給出評估迭代方法與避坑指南。資源為1個PDF文件壓縮包約753KB目錄結(jié)構(gòu)清晰、章節(jié)完整便于按模塊檢索學(xué)習(xí)。目前已有178人學(xué)習(xí)適合希望系統(tǒng)掌握大模型Agent架構(gòu)設(shè)計與業(yè)務(wù)落地方法的中高級讀者參考。1. 美團大模型 Agent 實踐手冊從單點問答到可編排智能體的落地路徑美團業(yè)務(wù)線里跑著大量長鏈路任務(wù)比如商家入駐審核、騎手申訴判責(zé)、客服工單分流這些場景單靠一次大模型問答根本兜不住。所謂美團大模型 Agent 實踐本質(zhì)是把大模型從「會聊天」推到「會干活」給它工具、給它記憶、給它編排邏輯讓它在多輪交互里自己決定下一步調(diào)什么接口、查什么數(shù)據(jù)、什么時候停下來交給人。這份手冊面向的是已經(jīng)能把大模型 API 跑通、但卡在「怎么讓它穩(wěn)定完成一個真實業(yè)務(wù)閉環(huán)」的工程師。你會看到 Agent 的架構(gòu)分層、工具注冊、記憶管理、編排與評測以及那些上線后才會暴露的坑。它不解決模型能力上限問題解決的是工程可控性問題——讓一個概率模型在確定性業(yè)務(wù)里少翻車、可回滾、能觀測。適合后端、算法工程和業(yè)務(wù)研發(fā)一起看因為 Agent 落地從來不是單點技術(shù)活。2. 美團大模型 Agent 的架構(gòu)分層與選型理由2.1 為什么不能把業(yè)務(wù)邏輯全塞進提示詞很多團隊第一版 Agent 就是一段超長 system prompt把工具說明、業(yè)務(wù)規(guī)則、輸出格式全寫進去。跑 demo 沒問題一上量就崩提示詞超過幾千 token 后模型對中間段指令的遵循度明顯下降改一條規(guī)則要動整段文本回歸測試無從下手。美團這類業(yè)務(wù)的特點是規(guī)則多、變更頻繁、責(zé)任邊界清晰所以必須把「模型負(fù)責(zé)決策」和「代碼負(fù)責(zé)執(zhí)行」拆開。常見做法是三層決策層大模型、能力層工具/函數(shù)、編排層狀態(tài)機或圖。決策層只輸出結(jié)構(gòu)化意圖能力層用確定性代碼實現(xiàn)編排層控制流程走向和終止條件。這樣模型再飄也飄不出代碼畫的圈。選型上如果任務(wù)步驟固定用狀態(tài)機編排就夠如果步驟依賴中間結(jié)果動態(tài)變化才上更靈活的圖編排。別一上來就追求全自主 Agent業(yè)務(wù)方要的是穩(wěn)定交付不是炫技。2.2 工具注冊把內(nèi)部接口變成模型能調(diào)的 functionAgent 能不能干活取決于工具描述寫得好不好。模型看不到你的代碼只能靠 name、description、parameters 三樣?xùn)|西判斷該不該調(diào)、怎么調(diào)。description 要寫「什么時候用」不是「這是什么」。下面是一個商家信息查詢工具的注冊示例用 Python 字典描述適配主流 function calling 協(xié)議。# 工具注冊每個工具必須包含名稱、用途描述、參數(shù) schema tools [ { type: function, function: { name: query_merchant_info, description: 根據(jù)商家ID查詢?nèi)腭v狀態(tài)、經(jīng)營品類和違規(guī)記錄。當(dāng)用戶詢問某商家資質(zhì)或歷史處罰時調(diào)用。, parameters: { type: object, properties: { merchant_id: { type: string, description: 商家唯一標(biāo)識格式為 M 開頭加 8 位數(shù)字 }, fields: { type: array, items: {type: string}, description: 需要返回的字段可選 status/category/violations不傳返回全部 } }, required: [merchant_id] } } } ]邏輯說明description 里明確「當(dāng)用戶詢問資質(zhì)或處罰時調(diào)用」這是給模型的觸發(fā)條件比單純寫「查詢商家信息」命中率高得多。參數(shù) schema 里把 merchant_id 的格式寫死能擋掉一部分模型瞎編 ID 的情況。fields 設(shè)計成可選數(shù)組是為了控制返回體積——Agent 上下文很貴別一次把整條商家記錄塞回去。參數(shù)說明required 只放真正必需的字段可選字段給默認(rèn)行為。如果某個工具調(diào)用頻率極高考慮在 description 里加一句「優(yōu)先調(diào)用本工具」但別濫用否則模型會過度依賴單一工具。工具數(shù)量超過 20 個后建議按業(yè)務(wù)域分組每輪只掛載相關(guān)組減少模型選擇困難。2.3 記憶管理短期上下文與長期事實要分開存Agent 記憶分兩類短期是當(dāng)前會話的對話歷史長期是跨會話的用戶偏好、商家檔案這類事實。新手常把兩者混在一個 list 里無限追加結(jié)果上下文爆炸、成本飆升、模型注意力被稀釋。正確做法是短期用滑動窗口加摘要長期用外部存儲按需檢索。短期記憶我一般保留最近 6 到 8 輪原始對話更早的用一次輕量模型調(diào)用壓縮成摘要摘要里只留決策相關(guān)的事實比如「用戶已確認(rèn)商家 ID 為 M12345678」。長期記憶走向量庫或 KV 存儲每輪開始時根據(jù)當(dāng)前 query 檢索 top-k 相關(guān)事實注入 system prompt。注意注入的事實要帶時間戳和來源否則模型會把過期信息當(dāng)現(xiàn)狀用這在商家狀態(tài)查詢里是致命的。3. 用編排把多步任務(wù)串起來狀態(tài)機與圖兩種寫法3.1 狀態(tài)機編排步驟固定的業(yè)務(wù)首選商家入駐審核這類流程步驟是確定的收資料 → 校驗資質(zhì) → 查違規(guī) → 出結(jié)論。這種用狀態(tài)機最穩(wěn)每個狀態(tài)對應(yīng)一個函數(shù)模型只在需要判斷的分支上介入。下面是一個簡化狀態(tài)機骨架。# 狀態(tài)機編排固定步驟用代碼控制模型只做分支判斷 class MerchantAuditAgent: def __init__(self, llm, tools): self.llm llm self.tools tools self.state RECEIVE def run(self, context): while self.state ! DONE: if self.state RECEIVE: context[merchant_id] self._extract_id(context[input]) self.state VALIDATE elif self.state VALIDATE: info self.tools[query_merchant_info](context[merchant_id]) context[info] info # 模型只判斷資質(zhì)是否齊全不決定流程走向 decision self.llm.judge_qualification(info) self.state CHECK_VIOLATION if decision[qualified] else REJECT elif self.state CHECK_VIOLATION: if context[info].get(violations): self.state REJECT else: self.state APPROVE elif self.state in (APPROVE, REJECT): context[result] self.state self.state DONE return context邏輯說明流程走向由 state 變量控制模型只在 VALIDATE 階段輸出一個布爾判斷。這樣即使模型判斷錯了影響范圍也被限制在單個分支不會導(dǎo)致整個流程亂跳。每個狀態(tài)轉(zhuǎn)換都可以打點出問題能精確定位是哪一步。參數(shù)說明_extract_id 建議用正則而非模型抽取確定性更高。judge_qualification 的提示詞要求模型輸出 JSON包含 qualified 和 reason 兩個字段reason 用于人工復(fù)核。狀態(tài)機適合步驟少于 10 步、分支明確的場景步驟再多維護成本會超過收益。3.2 圖編排步驟動態(tài)變化時的選擇當(dāng)任務(wù)步驟依賴中間結(jié)果動態(tài)生成比如客服工單可能要先查訂單、再查物流、再判斷是否賠付順序不固定這時用圖編排更合適。核心是把每個能力封裝成節(jié)點邊由模型或規(guī)則決定。常見做法是用現(xiàn)成的圖編排框架節(jié)點間通過共享狀態(tài)傳遞數(shù)據(jù)。關(guān)鍵參數(shù)是最大步數(shù)限制我一般設(shè) 15 步超過就強制終止并轉(zhuǎn)人工。沒有這個上限模型可能陷入循環(huán)調(diào)用。另外每個節(jié)點要有超時和重試外部接口抖動不能讓整個 Agent 掛死。圖編排的調(diào)試比狀態(tài)機難建議每個節(jié)點都記錄輸入輸出快照方便回放。4. 避坑與排查上線后才會暴露的五個問題4.1 工具調(diào)用參數(shù)類型對不上現(xiàn)象模型傳的 merchant_id 是數(shù)字工具期望字符串直接拋類型錯誤。原因JSON schema 里寫了 string但模型從上下文里看到的是純數(shù)字自作主張轉(zhuǎn)了類型。解決工具入口做一次強制類型轉(zhuǎn)換和格式校驗別信任模型輸出。校驗失敗時把錯誤信息回傳給模型讓它重試通常一次就能糾正。4.2 上下文里工具返回結(jié)果過大現(xiàn)象某次查詢返回了完整商家檔案幾千 token后續(xù)幾輪模型開始答非所問。原因大段無關(guān)信息擠占了注意力模型抓不住重點。解決工具返回前做字段裁剪只回當(dāng)前任務(wù)需要的字段如果必須回大對象先摘要再注入。我一般限制單個工具返回不超過 500 token。4.3 模型在分支判斷上反復(fù)橫跳現(xiàn)象同一份資料模型第一次判斷合格重試一次又判斷不合格。原因提示詞里判斷標(biāo)準(zhǔn)模糊模型每次采樣結(jié)果不同。解決把判斷標(biāo)準(zhǔn)寫成明確的規(guī)則列表要求模型逐條核對并輸出核對結(jié)果而不是給一個整體印象分。必要時把 temperature 調(diào)到 0。4.4 長期記憶注入了過期事實現(xiàn)象商家狀態(tài)已變更Agent 還在用上周的記憶回答。原因長期記憶沒有失效機制。解決每條記憶帶 TTL 或版本號檢索時過濾過期項對狀態(tài)類事實強制實時查詢而非走記憶。記憶只存「用戶偏好」這類慢變信息快變狀態(tài)一律實時查。4.5 流式輸出中斷導(dǎo)致狀態(tài)不一致現(xiàn)象前端用 SSE 流式渲染用戶中途關(guān)閉頁面后端 Agent 已經(jīng)執(zhí)行了寫操作但沒返回結(jié)果。原因流式輸出和業(yè)務(wù)執(zhí)行沒解耦。解決把「決策」和「執(zhí)行」分開流式只推決策過程寫操作等決策確認(rèn)后單獨提交并做冪等。中斷時記錄斷點恢復(fù)時從斷點繼續(xù)而不是重跑。5. 評測與灰度怎么判斷一個 Agent 能不能上生產(chǎn)Agent 評測不能只看最終答案對不對要看過程。我一般建三層評測單步工具調(diào)用準(zhǔn)確率、多步任務(wù)完成率、人工接管率。單步評測用構(gòu)造好的 query-工具對跑幾百條看命中率多步任務(wù)用歷史工單回放看端到端完成比例人工接管率是線上指標(biāo)超過閾值就回滾?；叶壬舷扔白幽Ｊ脚芤恢蹵gent 只出建議不執(zhí)行對比人工決策看一致率。一致率穩(wěn)定在 90% 以上再開小流量執(zhí)行執(zhí)行階段保留人工確認(rèn)按鈕。這里沒有后悔藥寧可慢一點也別一次性全量。我自己的習(xí)慣是每個新 Agent 上線前必須跑完 500 條回放用例且人工接管率低于 5% 才放行。這套流程跑下來翻車概率會低很多。希望幫到你。本文還有配套的精品資源點擊獲取