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