1. 為什么我勸你把“3天落地”當成一個認真的工程目標過去一年里我見過不少團隊做Agent項目死法驚人地一致。有個做供應鏈服務的項目組花了整整兩周搭了一個“綜合性智能助手”——能聊天、能寫周報、能解釋術語業(yè)務方看演示的時候都說“哇”。等真讓它對接WMS系統(tǒng)去查庫存、改單子就開始裝傻要么答非所問要么參數缺胳膊少腿要么直接編一個不存在的庫存數量。最后項目被砍復盤結論寫著“大模型能力不足”其實根本是需求模糊加上流程根本沒跑通。所以我特別想聊“3天落地”這個事。它不是讓你把半年的項目壓縮成3天去趕工而是逼著你只做一條最窄、最高價值、能跑通業(yè)務的鏈路——從需求拆解到上線全流程的所有環(huán)節(jié)全部在72小時內走完。這個時間盒是很好的工程紀律它強制你放棄“做一個全能的Agent”這種不切實際的目標老老實實把“一個場景里的一類任務”徹底做好。這篇內容是給誰看的主要是兩類人第一類手里已經有業(yè)務系統(tǒng)有API、有數據庫、有業(yè)務規(guī)則但團隊還沒想清楚Agent該從哪里入手第二類正在做Agent POC但擔心做出來又是“能說不能干”的演示品。讀完之后你會得到一張可直接用的三天推進清單以及我在多個企業(yè)級項目里踩過、填過的坑。先說一句結論放在前面Agent項目的真正難點從來不是模型不夠聰明而是工程化不夠結實。3天的目標就是把這句話變成現實。1.1 一個失敗的樣本兩周Demo為什么被砍剛才提到的那個供應鏈項目我再拆細一點。他們的需求是“做一個能處理訂單異常的智能助手”聽起來很明確但實際開發(fā)中所有人都在做加法。一開始只打算查訂單狀態(tài)后來業(yè)務方說“能不能順便把退換貨規(guī)則也答了”再后來產品經理說“如果用戶問‘為什么我的貨還沒到’咱們能不能主動查物流延遲原因”。需求面越鋪越寬到第10天時Agent需要理解30多種意圖調用8套內部系統(tǒng)其中一半系統(tǒng)連穩(wěn)定的測試環(huán)境都沒有。最后的演示很熱鬧但懂行的人一看就知道沒有一個環(huán)節(jié)經得起生產環(huán)境考驗。沒有超時處理大模型卡住的時候用戶只能干等沒有工具調用的校驗邏輯模型抽參數抽漏了系統(tǒng)照樣把空值發(fā)給下游沒有人工兜底答錯就是答錯連個“轉人工”的通道都沒設計。這個案例給我最大的教訓是不是任務越復雜越有價值而是任務越閉環(huán)越有價值。1.2 “3天”背后的工程邏輯用Deadline逼出優(yōu)先級坦白說給項目設置3天時間本身就是一種需求篩選手段。我常用一個辦法叫“三問淘汰法”需求出現的時候連問三個問題這個需求每周出現多少次如果每周出現不足50次直接不進首期范圍。這個需求是否依賴單一業(yè)務系統(tǒng)如果調用鏈超過兩個系統(tǒng)后移到二期。這個需求的結果是否可以明確驗收如果“答得好不好”都沒有標準說明業(yè)務方自己也沒想清楚。用這三問過濾完之后你會發(fā)現真正值得做的Agent場景所剩無幾但留下來的每一個都是高確定性、高頻率、可驗收的。我最近做一個零售行業(yè)的售后客訴Agent就是拿這套方法砍掉了8個候選場景中的7個只留下“查單催發(fā)貨”這一個場景第1天晚上就把端到端流程跑通了。剩下的2天全在打磨邊界條件、加工程保護最后業(yè)務方反而覺得這個Agent比那些大而全的Demo靠譜得多。2. 需求拆解的第一課先定義“不做清單”很多技術團隊習慣拿到需求就畫架構圖我建議反過來先寫“不做清單”。這事一旦做晚了代價會指數級上升。2.1 用“高頻、閉環(huán)、可驗收”三把尺子篩需求關于這個問題我可以展開說說高頻不是“偶爾能幫上忙”而是“每天都會發(fā)生”。有真實業(yè)務數據的團隊直接翻過去一個季度的客服工單、系統(tǒng)操作日志、業(yè)務報表把Top10高頻操作拉出來。沒有數據的就找業(yè)務方一起做“一周排演”把一周內可能出現的用戶問題全部過一遍能寫滿一整墻便利貼的才是真需求。閉環(huán)這個任務從開始到結束Agent能不能獨立走完比如“查快遞到哪了”用戶問、Agent查、系統(tǒng)回三步閉環(huán)好做。而“幫我想想這周團購選什么套餐”沒有明確的工具、數據和成功標準這就不是閉環(huán)任務是開放聊天先放一邊?？沈炇諛I(yè)務層面得有判斷依據。我一般會要求業(yè)務方回答一個問題“如果這個Agent明天上線你覺得好用還是不好用用什么例子來判斷”能舉出具體例子的場景才做。比如“客戶問發(fā)貨時間Agent必須在5秒內給出準確時間給錯了算事故”——這種定義方式開發(fā)才知道往哪個方向努力。2.2 把業(yè)務語言翻譯成一張“決策表”需求拆解有一個非常實用的產出物我一般叫它“意圖決策表”。拿零售售后場景舉例拆完之后大概是這個樣子的用戶輸入特征意圖類型需要的參數調用的工具業(yè)務動作包含“訂單號物流/到哪/發(fā)貨”物流查詢訂單號物流系統(tǒng)接口返回物流軌跡包含“訂單號退/換”售后請求訂單號原因售后工單系統(tǒng)生成工單轉人工審核包含“投訴/客服電話”人工客服無轉接模塊緊急轉人工輸入不匹配任何規(guī)則兜底意圖無無回復“我還沒學會已轉人工”這張表的作用不是拿給模型訓練而是讓開發(fā)知道Agent的“大腦中軸線”是什么。模型不在這一步自由發(fā)揮它做的事情只是在有限意圖里做一次分類和參數抽取正確率會高很多。2.3 邊界條件清單寧可拒絕不能瞎猜企業(yè)級Agent和普通聊天機器人的分水嶺就在邊界條件的處理上。個人用戶的聊天機器人答錯了用戶頂多罵一句然后自己重試。企業(yè)場景里Agent答錯了可能直接引發(fā)客訴、造成庫存誤扣甚至觸發(fā)合規(guī)問題。所以從需求拆解的第一天起你就必須在每個意圖旁邊標注“不確定時怎么辦”。我自己的硬性規(guī)則是模型置信度低于閾值通常設在0.6左右具體根據場景調整時允許的響應方式只有兩種——要么直接轉人工要么明確告訴用戶“我沒有理解你的需求請重新描述”絕不強行給答案。這條規(guī)則寫進需求文檔比寫進代碼更重要因為業(yè)務方只有在需求階段同意了這條兜底策略后續(xù)驗收才不會有分歧。3. 架構落地選型不是越重越好編排層才是靈魂第1天下午開始進入技術選型階段。很多團隊一上來就在糾結“用哪個大模型”我說先別急畫清楚架構邊界比選模型重要十倍。3.1 先畫一條清晰的分層線Agent系統(tǒng)只有5層我在企業(yè)項目里最常用的分層方式是這樣的接入層負責接收各種入口的統(tǒng)一請求——網頁對話、企業(yè)微信、客服系統(tǒng)接口對接入口可以有很多個但接入層后必須收斂成一種內部統(tǒng)一協(xié)議。我通常用“消息對象”作為標準結構里面至少包含用戶ID、會話ID、文本內容、附帶參數比如訂單號、時間戳。這一步不做的話后面每個渠道都要單獨適配你會瘋掉。編排層是Agent的心臟也是整個架構里最值得投入的地方。它的職責是意圖識別、參數抽取、工具選擇、結果校驗、流程控制。這套邏輯一定寫在應用代碼里由編程語言控制而不是讓模型自己去“想”。重復一遍這句話——不管多厲害的模型都別讓它獨立決定“該調用哪個API、參數填什么”至少初期不要。工具層把已有的內部系統(tǒng)包裝成模型可調用的“函數”。需要重點設計的是每個工具的參數Schema下面第4章會細講。另外工具層的返回值無論內部是什么數據結構都要在外面加一層“展示摘要”——讓模型只看到精簡后的業(yè)務結果別把各種內部狀態(tài)碼和原始日志喂進去。記憶層負責上下文保持包含兩部分短期記憶當前任務會話中的關鍵信息和長期記憶用戶偏好、歷史工單摘要。企業(yè)場景不推薦簡單堆對話歷史因為Token成本和噪音都會被放大。更好的做法是設置“工作臺”結構只維護當前任務需要的參數和結果詳見第4.3節(jié)。審計層負責記錄一切輸入、輸出、工具入參、出參、模型返回的原始內容、耗時、成本。這層在Demo階段沒什么用一上線立刻變成剛需。業(yè)務有爭議的時候沒有審計日志你連自己答過什么都沒法證明。3.2 模型選型的幾個務實標準大模型選型我用的判斷維度是這樣的維度核心問題我的建議工具調用能力給定函數定義能否準確抽出參數找3組臟數據實測錯誤一次都換響應延遲端到端時間里占比最大的就是模型推理同一場景下要求P95在2秒內上下文長度夠裝下決策表工具定義工作臺信息4K到8K足夠貪大于心智負擔服務穩(wěn)定性高峰期會不會限流有無重試機制選型前先問SLA別在線上賭運氣成本單次調用的綜合成本按日活和平均輪次估算月成本這里說一個很多團隊容易踩的坑光看公開評測榜單選模型。你在公有能力排行榜看到的結果和你業(yè)務場景的實際情況完全是兩碼事。正確的做法是選型當天就構造一批你們業(yè)務特有的“臟輸入”——比如訂單號缺一位、用戶把收貨地址說了一半、用戶用語音轉文字所以有錯別字——直接拿到各候選模型上跑一遍看誰最抗造。記住你是去干活的不是去評榜的。3.3 編排框架的三個選項我推薦哪一個當前可選的路大致有三條。選項A使用較成熟的開源編排框架。這類框架幫你解決了很多通用問題比如多輪對話、工具調用循環(huán)、記憶持久化上手快。我大概評估過它們的定位適合團隊對Agent還比較陌生、需要在短時間內先跑通一版、同時不打算在基礎設施上花太多人力的情況。代價是框架本身有學習成本和一定的抽象膨脹很多邏輯被包在黑盒里出了問題排查起來稍微費點工夫。選項B自研一個輕量編排器。這其實比很多人想象的要簡單。一個意圖識別函數、一個參數抽取函數、一個工具調用分發(fā)函數、一個校驗與兜底函數——四個核心類撐死了兩三千行代碼卻能換來極高的可控性。我們用這種方案落地過不少項目好處是每一個環(huán)節(jié)都能打日志每一條錯誤都能準確定位。代價是基礎能力要自己搭比如多輪會話管理、調用重試、狀態(tài)機這類通用功能都得自己寫。選項C純提示詞派。讓模型直接看一大段提示詞要求它按流程調用工具。優(yōu)點是原型快缺點是生產環(huán)境極難控制稍微復雜一點的工具組合就可能亂套。我的建議很直接如果你以后要持續(xù)維護這個Agent別選C如果你團隊里沒人深入了解過開源的編排框架也別A因為出了線上事故你不知道該改框架源碼還是改自己的代碼。首選B用一個周末就能寫完的輕量編排器換來的是100%的可控性。3.4 可控性是第一原則給模型一條“窄路”走有一點我想特別強調企業(yè)級Agent和學術Demo之間最大的觀念差異是對“自由發(fā)揮”的態(tài)度。Demo喜歡讓模型自由發(fā)揮顯得“智能”企業(yè)生產要的是穩(wěn)定輸出智能是排在穩(wěn)定之后的。所以給模型的路越窄越好意圖列表固定、工具選擇固定、參數抽取有明確約束模型只在一個極小的決策空間里做選擇題和填空題。我們內部有個說法叫“Model in a Box”意思是模型被裝進一個邊界明確的框里框之外是業(yè)務代碼的絕對控制區(qū)。做到這一點你對系統(tǒng)的可預測性、可測試性、可審計性就都有了保障。而企業(yè)界的人其實不太喜歡把關鍵業(yè)務動作全交給模型直接決策的——各個團隊都有自己踩過“自由發(fā)揮”的坑最后得出的結論幾乎出奇一致。4. 第二天把“能聊天”的Agent改成“會辦事”的任務系統(tǒng)第一天結束的時候你應該已經完成了需求拆解表、技術選型、系統(tǒng)分層的設計并且搭好了工程骨架。第二天全天目標只有一個讓Agent在一條真實業(yè)務鏈路上端到端跑通。4.1 最小閉環(huán)六個環(huán)節(jié)一個都不能少一個能“辦事”而不是“聊天”的Agent它的每次任務處理一定是結構化的意圖識別把用戶輸入分類到預定義的意圖列表中。參數抽取從文本中提取調用工具所需的字段包括從對話歷史里補全缺失字段。工具選擇根據意圖和已抽到的參數由代碼邏輯決定調用哪個工具。工具調用執(zhí)行內部API請求處理超時和重試。結果校驗把工具返回的結果和用戶問題做一致性檢查判斷是否滿足回答條件?；貜蜕苫诠ぞ叻祷亟Y構用模型生成面向用戶的自然語言回復。第2步和第5步是很多人最容易忽略的但它們恰恰是“會辦事”和“假裝會辦事”的關鍵區(qū)別。參數抽取得全工具調用才不會失敗結果校驗做得好模型才不會把系統(tǒng)返回的“查無此單”硬生生編成“您的貨物正在運輸途中”。4.2 工具調用的Schema才是Agent的“骨相”如果架構有骨頭那工具調用的Schema就是骨相。參數定義得漂不漂亮直接決定模型抽參數能不能抽得準。拿查詢訂單狀態(tài)舉例一個工具的函數定義大概長這樣{ name: query_order_status, description: 根據訂單號查詢訂單的最新狀態(tài)和物流信息。訂單號必須完整。, parameters: { type: object, properties: { order_no: { type: string, description: 用戶提供的訂單號一般為12位數字例如202501011234。如果用戶只提供部分訂單號不要嘗試拼接直接標記為缺失。 }, user_id: { type: string, description: 當前登錄用戶的ID從會話上下文中獲取不需要用戶重新提供 } }, required: [order_no, user_id] } }三個經驗之談。第一description不要寫教科書式的解釋要寫“給模型看的提示詞”。把業(yè)務判斷規(guī)則寫進去比如“訂單號必須完整”“不要嘗試拼接”比你在prompt里反復強調有用得多。第二必填參數盡量少。能不依賴用戶輸入的字段就通過會話上下文注入比如登錄用戶的ID要用戶輸入的也要想清楚哪些是“可后續(xù)追問補全”的。第三返回值要做成“扁平摘要”。不要讓模型去讀一堆子表、嵌套字段、狀態(tài)碼直接匯總成一句類似“包裹已發(fā)出當前位于某地轉運中心預計明天送達”的文本或者一行結構化的關鍵字段。模型拿到的信息越清爽最終回復質量就越高。4.3 記憶和上下文給Agent一個“工作臺”而不是“聊天記錄”第二天的另一個重要工程是“工作臺”設計。一個對話半小時的用戶中間可能穿插各種問題如果指望模型從幾百句聊天記錄里自己找“剛才那個訂單號是多少”它一定會出錯。所以我推薦每個會話維護一個結構化的任務工作臺類似這樣字段內容說明current_intent查詢物流當前正在處理的意圖collected_paramsorder_no202501011234已確認可用的參數pending_params無仍欠缺的參數tool_result已返回包裹到達某轉運中心上一次工具調用的結果摘要statusWAITING_USER_INPUT任務狀態(tài)等待追問或等回復每一輪對話結束你的編排層按“先更新工作臺、再做決策”的順序處理。這種方式有兩個好處一是模型每次只需要看到工作臺里的關鍵信息不會迷失在歷史里二是所有參數的確認鏈路清晰可控哪些是用戶說的、哪些是系統(tǒng)給的、哪些是模型猜的一目了然。4.4 讓流程可見人可以在中途接管企業(yè)級Agent還有一個標配能力是好多Demo做不到的人在中途接管。所謂“接管”不是說一句“轉人工”就完事而是當前任務得能完整交接。比如Agent正在推進一個退貨流程抽到了訂單號但用戶糾結要不要留退貨原因這時候用戶說“算了不退了”Agent要能立刻終止當前意圖重置工作臺而不是執(zhí)著地繼續(xù)追問退貨原因。更嚴謹的系統(tǒng)里任務狀態(tài)里還有“掛起待審核”這一類。有些操作在試運行期或高風控場景下必須有人工審批Assistant只負責把資料收集齊然后生成一個結構化摘要推給業(yè)務人員審核。執(zhí)行權在人工手里Agent永遠只是“建議者”而不是“行動者”。5. 上線前的工程加固超時、重試、狀態(tài)機與安全邊界第3天上午開始進入我稱之為“工程加固”的階段。這一天的任務不是加功能而是把最有可能會在線上炸掉的地方先補上。5.1 大模型接口的“三超”問題超時、超流量、超預算所有接過大模型API的人遲早都會在線上遇到下面的情況。模型服務商偶爾抽風不是網絡問題就是服務端限流響應時間波動劇烈超時的時候看起來就像系統(tǒng)死了。應對方案里最基礎但最有效的是三層控制書接上回我先說超時。我給系統(tǒng)定了三個時間閾值單次模型調用超時設為5秒整個Agent任務端到端時長不超過15秒超過閾值立即終止當前流程并給出兜底回復“系統(tǒng)有點忙請稍后再試或轉人工”。別設得太長一個用戶如果盯著屏幕等30秒體驗已經崩了還不如快速失敗讓用戶重試。再說流量和預算。每次調用在編排層都要有“熔斷開關”——連續(xù)5次調用失敗自動熔斷10分鐘期間所有請求直接走兜底文案。成本控制方面給模型單獨設置每日額度比如一天最多消耗預算X元超過之后自動降級為只用簡單規(guī)則回復或轉人工。這套邏輯在第二行代碼就要加進去。def call_llm_with_retry(prompt, max_retries2): for attempt in range(max_retries 1): try: # 單次超時設置為5秒不包含排隊等待時間 response llm_client.chat( messagesprompt, timeout5 ) return response except TimeoutError: if attempt max_retries: return generate_fallback_reply() time.sleep(0.5 * (attempt 1)) # 退避等待 except RateLimitError: if attempt max_retries: return generate_fallback_reply() time.sleep(2) # 限流常見多等一會兒 return generate_fallback_reply()這里要特別提醒一個細節(jié)重試只對“暫時性錯誤”有意義對超過預算、鑒權失敗這類“永久性錯誤”重試完全沒有價值白白浪費時間和資源。所以重試邏輯里一定要區(qū)分錯誤類型。5.2 從“一輪對話”到“任務狀態(tài)機”到了上線前這一步我會強制要求把Agent的任務從“無狀態(tài)對話”升級為“狀態(tài)機”。不要覺得這個重其實就是把會話生命周期里的幾個狀態(tài)顯式化。常規(guī)任務狀態(tài)至少應該是這些狀態(tài)含義進入方式PENDING等待用戶輸入或新任務開始新會話創(chuàng)建TOOL_CALLING正在調用內部工具意圖識別完成參數已齊WAITING_USER_INPUT缺少參數正在追問用戶參數校驗發(fā)現缺失項SUCCESS本任務已完成可發(fā)起新意圖工具返回成功且校驗通過FAILED任務執(zhí)行失敗走兜底回復重試仍失敗或超時NEED_REVIEW需要人工審核或接管命中高風控動作或低置信度狀態(tài)機的意義在于它讓Agent的行為變得可預期。比如用戶在Agent查物流的路上突然問了一個新問題狀態(tài)機要能正確處理“意圖切換”當前任務掛起新意圖入棧舊任務的參數保留在工作臺里等用戶回頭再說。沒有狀態(tài)機這種場景會讓Agent立刻精神分裂把兩個任務的信息混在一起回答。5.3 安全與審計Agent做出的是“建議”還是“動作”最后一天還要認真設計一個邊界問題哪些操作Agent可以直接執(zhí)行哪些必須走審批。我個人的原則是只讀操作可以自動執(zhí)行比如查庫存、查訂單、看物流寫操作必須二次確認比如改地址、改數量、提交工單涉及資金、刪除、權限變更這類高危動作必須走人工審批鏈路。這個原則說給業(yè)務方聽對方基本都會同意因為沒有人愿意讓一個還不能完全信任的Agent直接動錢。審計日志的字段建議至少包含會話ID、用戶ID、時間戳、意圖名稱、模型輸入摘要、模型輸出全文、工具名稱、工具入參、工具出參摘要、耗時、消費Token數、命中策略。落庫之后別只存著不看建議每天跑一個成本匯總和錯誤輪次回看。6. 驗收標準與灰度發(fā)布怎樣才算真正可以砍掉人工到第3天下午系統(tǒng)跑通、加固完成看起來一切正常了。但能不能真正上線還需要一套驗收方法論。6.1 四個指標一個都不能少我在所有Agent項目里都在用這四把尺子來衡量“能不能放量”指標計算方式參考初值任務完成率成功完成任務數 / 總請求數不低于85%工具調用準確率工具返回結果正確/調用成功 / 工具總調用次數不低于90%端到端P95時延從發(fā)消息到收到回復的第95百分位耗時不超過8秒人工介入率需要人工接管/轉人工的請求 / 總請求數不超過20%任務完成率可以過濾那些“答了但沒辦成事”的對話工具調用準確率單獨看是因為即使任務沒完成工具調用也不能有太多錯P95時延決定用戶體驗人工介入率是兜底策略執(zhí)行情況的度量太高說明Agent能力不足太低比如為0反而要警惕是不是業(yè)務規(guī)則的邊界設得太保守。驗收的具體方式是準備80條帶標注的測試樣本覆蓋每個意圖的正例、反例、邊界情況比如訂單號缺失、重復追問、情緒化輸入跑完后按指標逐條算。做這一步的時候有個心態(tài)要擺正測試樣本過了不代表上線穩(wěn)了但樣本都過不了上線一定會出事。6.2 灰度策略影子模式 → 小流量 → 人工復核 → 全量雖然只有3天時間但上線環(huán)節(jié)我也不會一把梭。標準的灰度鏈路是四段。影子模式把線上真實流量復制一份給AgentAgent的答復不觸達用戶只和人工客服的真實答復做對比目的是看它在真實數據上的表現。小流量比如放1%的真實用戶進來Agent直接回復同時安排客服在旁邊待命。觀察剛才那四個指標尤其關注任務完成率。人工復核把Agent已經完成的任務按一定比例抽出來人工復查。我第一次做合作伙伴的Agent項目時這一步抓出了大量“看似成功實則答非所問”的樣本提前發(fā)現了上下文混亂的問題。全量放量指標達標后全量同時前兩周每天盯指標。6.3 上線不是結束錯題集回灌和模型無關項目上線以后真正開始產生價值的是“錯題集”復盤機制。我比較建議每周做一次樣本評審把當周的失敗案例撈出來分類記錄是意圖分類錯了、參數抽錯了、工具調用邏輯出問題了還是模型回復的時候跑偏了。評估過很多案例后我發(fā)現一件有意思的事六成以上的問題不在模型本身而在工具Schema描述不清、工作臺信息維護不完整、決策表的邊界定義太粗。換句話說你花再多錢換更聰明的模型效果都不一定比花半天時間把Schema里的描述寫得更清楚來得好。所以錯題集回灌更新的優(yōu)先級排第一的是工具描述其次是決策表規(guī)則最后才是考慮換模型。這個順序不要搞反。對了最后提一個我自己每次都會做的小步驟第二天晚上找一個沒參與開發(fā)的人來當“紅隊”讓他對著Agent自由提問專挑邊界情況。往往他問出來的問題比你自己準備的所有測試用例都要刁鉆。這個環(huán)節(jié)最多花兩個小時但總能趕在上線前揪出一兩個漏網的“靈異問題”比上線后被用戶發(fā)現要體面得多。