把能跑的 Agent Demo 變成能長(zhǎng)期承受生產(chǎn)壓力的 Agent真正的難點(diǎn)不是模型推理而是邊界控制、失敗兜底、可觀測(cè)性和權(quán)限設(shè)計(jì)。很多 Agent 項(xiàng)目在本地示例里表現(xiàn)很好一接到真實(shí)業(yè)務(wù)就出現(xiàn)“執(zhí)行器不響應(yīng)”“工具調(diào)用結(jié)果沒有被模型采用”“批量任務(wù)跑完后輸出對(duì)不上”等問(wèn)題。這類問(wèn)題大多不是大模型能力不行而是工程結(jié)構(gòu)一開始就沒有按生產(chǎn)要求去設(shè)計(jì)。下面不打算復(fù)述理論而是圍繞生產(chǎn)環(huán)境里最容易踩坑的五個(gè)環(huán)節(jié)整理成五條規(guī)則并補(bǔ)充實(shí)際排查順序。無(wú)論你是直接用代碼編排還是引入 Agent 開發(fā)框架甚至只是給現(xiàn)有業(yè)務(wù)加上一個(gè)智能助手這套判斷方式基本都能用上。1. 規(guī)則一一個(gè) Agent 只負(fù)責(zé)一條清晰業(yè)務(wù)鏈路很多人把 Agent 等同于“能聊天、能搜索、能調(diào)用工具、能操作很多系統(tǒng)”的通用助手。這種想法在做 Demo 的時(shí)候沒問(wèn)題放到生產(chǎn)環(huán)境就會(huì)立刻失控。生產(chǎn)級(jí) Agent 的第一個(gè)要求不是能力多而是邊界清楚。1.1 不要一開始就構(gòu)建“全能助手”單實(shí)例 Agent 承擔(dān)的職責(zé)越多出問(wèn)題的概率就越大。每一個(gè)新增技能都會(huì)往系統(tǒng)提示詞里加描述往工具列表里加接口往上下文里加示例。當(dāng)這些內(nèi)容互相干擾時(shí)模型容易在“該調(diào)用哪個(gè)工具”“該輸出什么格式”“該不該繼續(xù)追問(wèn)”之間搖擺。更穩(wěn)妥的做法是把業(yè)務(wù)拆成單一職責(zé)的 Agent。比如訂單售后助手只處理退換貨、物流查詢和異常登記。工單分類助手只負(fù)責(zé)把用戶描述映射到預(yù)定義工單類型。代碼檢查助手只讀取代碼倉(cāng)庫(kù)并返回檢查建議不做其他操作。判斷邊界是否合理有一個(gè)很實(shí)用的標(biāo)準(zhǔn)如果新增一個(gè)工具時(shí)你需要反復(fù)修改系統(tǒng)提示詞說(shuō)明職責(zé)已經(jīng)過(guò)寬。正常情況應(yīng)該是加一個(gè)工具即可提示詞不需要大改。如果不同業(yè)務(wù)之間工具高度重疊就先用一個(gè)上層路由 Agent 做分發(fā)再交給各自的執(zhí)行 Agent而不是把全部工具塞進(jìn)同一個(gè) Agent。1.2 輸入、輸出、失敗標(biāo)準(zhǔn)必須在第一行規(guī)則里寫死開始寫代碼之前先定義清楚三類問(wèn)題。第一輸入范圍。用戶請(qǐng)求經(jīng)過(guò)前置處理之后哪些字段允許進(jìn)入 Agent哪些字段必填哪些字段要過(guò)濾如果不做輸入限制用戶發(fā)一段超長(zhǎng)文本、一個(gè)惡意指令或者一串不完整 JSONAgent 會(huì)在第一步就開始混亂。第二輸出格式。不要允許 Agent 輸出任意自然語(yǔ)言作為最終結(jié)果。生產(chǎn)環(huán)境里最終結(jié)果應(yīng)當(dāng)是結(jié)構(gòu)化數(shù)據(jù)例如 JSON、狀態(tài)碼、消息類型加業(yè)務(wù)字段。模型輸出自然語(yǔ)言可以但下游系統(tǒng)接收前必須完成解析和校驗(yàn)。第三失敗標(biāo)準(zhǔn)。到底什么算成功不是模型回復(fù)“好的”就算成功而是業(yè)務(wù)系統(tǒng)里的狀態(tài)發(fā)生了變化。比如售后工單確實(shí)被創(chuàng)建或者訂單狀態(tài)確實(shí)被更新。什么算失敗超時(shí)未響應(yīng)、重試后仍然失敗、輸出結(jié)構(gòu)校驗(yàn)不通過(guò)、需要人工介入都要在規(guī)則里寫清楚。這樣后續(xù)所有日志、告警和排查才有依據(jù)。注意很多項(xiàng)目出了問(wèn)題說(shuō)不清是模型原因還是鏈路原因就是因?yàn)橐婚_始沒有把“成功”定義清楚。先寫死輸入、輸出和失敗標(biāo)準(zhǔn)再談 Agent 能力優(yōu)化。2. 規(guī)則二先跑通最小閉環(huán)再疊加記憶、知識(shí)庫(kù)和工具編排Agent 項(xiàng)目的技術(shù)棧選擇很容易讓人上頭。MCP、Agent Skill、向量知識(shí)庫(kù)、長(zhǎng)期記憶、多 Agent 編排每個(gè)名詞聽起來(lái)都值得研究。但生產(chǎn)落地不是搭積木功能疊加得越快定位問(wèn)題就越難。2.1 最小閉環(huán)至少要包含“接收輸入、調(diào)用一次工具、返回結(jié)果”很多項(xiàng)目上來(lái)就做“多輪對(duì)話 長(zhǎng)期記憶 多個(gè)工具編排”結(jié)果第一輪對(duì)話就卡在工具調(diào)用上。問(wèn)題不是模型看不懂工具描述而是整個(gè)鏈路里沒有單獨(dú)驗(yàn)證過(guò)某一環(huán)。我更建議把第一次測(cè)試拆成三層接收一條用戶輸入交給模型。模型輸出一次工具調(diào)用參數(shù)代碼解析并真實(shí)調(diào)用接口。工具返回結(jié)果模型生成最終回復(fù)代碼校驗(yàn)后輸出。這三步跑通說(shuō)明基礎(chǔ)鏈路是通的。如果這期間出現(xiàn)超時(shí)、參數(shù)解析失敗、結(jié)果截?cái)?、響?yīng)格式不對(duì)問(wèn)題都出在最底層而不是記憶或編排層。先解決底層再往上分層加。2.2 記憶和知識(shí)庫(kù)不是越早上越好Agent 一旦引入記憶模塊就要回答幾個(gè)問(wèn)題記憶存多久一個(gè)會(huì)話內(nèi)還是一周、一個(gè)月、永久誰(shuí)可以讀只有當(dāng)前用戶還是所有用戶都共享能不能刪除用戶要求刪除歷史數(shù)據(jù)時(shí)系統(tǒng)能不能真正清掉記憶會(huì)不會(huì)占滿上下文每次攜帶所有歷史會(huì)讓模型響應(yīng)變慢、成本升高而且未必提升效果。判斷是否需要長(zhǎng)期記憶標(biāo)準(zhǔn)很直接同一個(gè)用戶下一輪提問(wèn)是否必須依賴上一輪結(jié)論。比如售后助手查詢工單用戶問(wèn)完“工單狀態(tài)”又問(wèn)“如何處理”確實(shí)需要上下文銜接這時(shí)做會(huì)話級(jí)記憶就夠。如果一個(gè)任務(wù)每次請(qǐng)求信息完整不依賴歷史就沒必要引入長(zhǎng)期記憶。知識(shí)庫(kù)也是同樣邏輯。先確認(rèn)業(yè)務(wù)是否需要專業(yè)資料檢索。如果只是普通規(guī)則寫進(jìn)提示詞或工具參數(shù)里就夠了。真正需要知識(shí)庫(kù)的場(chǎng)景通常是資料量大、內(nèi)容更新頻繁、用戶提問(wèn)是開放式的這時(shí)才值得引入向量檢索。2.3 Agent Skill 和 MCP 先區(qū)分定位再選型MCP 全稱是 Model Context Protocol屬于工具接入層面的協(xié)議它解決的是“模型如何更規(guī)范地調(diào)用外部工具”。Agent Skill 則更像一組可復(fù)用的提示詞、工具調(diào)用步驟和業(yè)務(wù)操作封裝解決的是“某個(gè)復(fù)雜任務(wù)怎么做”。兩者不是誰(shuí)替代誰(shuí)的關(guān)系。如果只是接幾個(gè)內(nèi)部 API用 MCP 風(fēng)格的工具描述就能搞定讓模型按約定參數(shù)調(diào)用接口。如果要沉淀一套多步驟能力比如“審計(jì)日志分析”“多標(biāo)簽工單流轉(zhuǎn)”再把它封裝成 Skill后續(xù)其他 Agent 可以直接復(fù)用。選型時(shí)不要先問(wèn)“哪個(gè)更主流”而是先列出業(yè)務(wù)動(dòng)作需要調(diào)用哪些接口、有哪些判斷步驟、哪些環(huán)節(jié)允許模型自由發(fā)揮、哪些環(huán)節(jié)必須走固定流程。流程固定度越高越適合編排流程開放度越高越需要模型能力。3. 規(guī)則三工具調(diào)用必須可觀測(cè)、可重試、可回滾工具調(diào)用是 Agent 生產(chǎn)運(yùn)行中最容易出問(wèn)題的部分。模型擅長(zhǎng)生成文本但調(diào)用外部系統(tǒng)時(shí)網(wǎng)絡(luò)超時(shí)、參數(shù)非法、權(quán)限不足、接口返回異常這些情況幾乎每天都會(huì)遇到。不能把這些都扔給用戶也不能讓模型自行處理一切。3.1 每次工具調(diào)用都要留結(jié)構(gòu)化日志日志不要只記錄“成功”或“失敗”要記錄完整的調(diào)用上下文。我建議至少包含這些字段request_id一次用戶請(qǐng)求的唯一標(biāo)識(shí)。agent_step當(dāng)前屬于哪個(gè)執(zhí)行步驟。tool_name調(diào)用的工具名稱。arguments傳給工具的參數(shù)摘要。status成功、失敗、超時(shí)、重試中。error_type錯(cuò)誤分類。latency_ms調(diào)用耗時(shí)。retry_count重試次數(shù)。示例{ request_id: req_20250321_001, agent_step: tool_call, tool_name: query_order, arguments: { order_id: A1001 }, status: failed, error_type: timeout, latency_ms: 30500, retry_count: 2 }有了這樣的日志定位問(wèn)題時(shí)會(huì)快很多。沒有日志的情況下排查 Agent基本等于靠猜。3.2 重試順序區(qū)分瞬時(shí)錯(cuò)誤和業(yè)務(wù)錯(cuò)誤工具調(diào)用失敗時(shí)不要一律重試。先判斷錯(cuò)誤類型。瞬時(shí)錯(cuò)誤包括網(wǎng)絡(luò)超時(shí)、連接被重置、服務(wù)暫時(shí)不可用。這類錯(cuò)誤可以重試但一般建議限制次數(shù)比如最多重試 3 次重試之間加遞增間隔。不要無(wú)限重試否則上游服務(wù)恢復(fù)時(shí)會(huì)突然積壓大量請(qǐng)求造成二次雪崩。業(yè)務(wù)錯(cuò)誤包括參數(shù)非法、權(quán)限不足、業(yè)務(wù)規(guī)則不允許操作。這類錯(cuò)誤重試沒有意義正確做法是返回失敗信息讓 Agent 基于失敗結(jié)果換一種方式或者直接升級(jí)到人工處理。判斷標(biāo)準(zhǔn)很簡(jiǎn)單如果同樣的參數(shù)調(diào)用 100 次都會(huì)失敗那就是業(yè)務(wù)錯(cuò)誤如果第一次失敗、第二次可能成功那就是瞬時(shí)錯(cuò)誤。把兩種錯(cuò)誤分開處理整個(gè)鏈路會(huì)穩(wěn)定很多。3.3 工具返回內(nèi)容過(guò)大時(shí)先截?cái)嗷蛘俳唤o模型大模型上下文窗口有限工具返回結(jié)果不是越多越好。比如查詢一個(gè)訂單詳情可能返回幾百行關(guān)聯(lián)記錄查日志可能返回幾十 KB 文本。如果全部塞給模型容易出現(xiàn)兩個(gè)問(wèn)題一是超出上下文長(zhǎng)度導(dǎo)致截?cái)喽菬o(wú)關(guān)內(nèi)容干擾模型判斷。正確的做法是在工具層做處理。比如查詢列表只返回前 20 條和總條數(shù)。日志內(nèi)容先做關(guān)鍵詞提取或摘要。數(shù)據(jù)庫(kù)查詢只返回需要的字段不 SELECT *。這步處理不能交給模型自己決定因?yàn)槟Ｐ蜔o(wú)法預(yù)知完整數(shù)據(jù)量。生產(chǎn)環(huán)境里返回內(nèi)容的裁剪、摘要、分頁(yè)都應(yīng)該在工具接口內(nèi)部完成。4. 規(guī)則四并發(fā)、隊(duì)列和長(zhǎng)任務(wù)資源要提前設(shè)計(jì)Agent 任務(wù)通常不是一次 HTTP 請(qǐng)求就結(jié)束而是多步推理加多次工具調(diào)用耗時(shí)和資源消耗都高于普通接口。如果按照傳統(tǒng) Web 服務(wù)的思維去設(shè)計(jì)上線后很容易在并發(fā)上出問(wèn)題。4.1 并發(fā)數(shù)不是越高越好假設(shè)一次完整 Agent 調(diào)用需要 3 次模型推理和 4 次工具調(diào)用。這個(gè)過(guò)程中CPU、內(nèi)存、模型服務(wù)、外部 API 都在持續(xù)工作。如果同時(shí)開 50 個(gè)并發(fā)模型服務(wù)的排隊(duì)時(shí)間會(huì)明顯增加外部接口也可能被限流。建議從很小的并發(fā)開始測(cè)試。比如同時(shí) 2 到 5 個(gè)任務(wù)觀察成功率、平均延遲、P95 延遲和資源占用。確認(rèn)穩(wěn)定之后再逐步上調(diào)。如果失敗率上升不要急著加服務(wù)器先看是不是并發(fā)數(shù)把上游 API 打滿了或者模型服務(wù)排隊(duì)嚴(yán)重。判斷并發(fā)是否合理不要只看“跑沒跑完”要看平均單任務(wù)耗時(shí)。任務(wù)在隊(duì)列中的等待時(shí)間。模型服務(wù)的排隊(duì)長(zhǎng)度。外部 API 的錯(cuò)誤率。數(shù)據(jù)庫(kù)連接和磁盤讀寫。這些指標(biāo)適合在生產(chǎn)前做一輪壓測(cè)不需要太精細(xì)但至少能確認(rèn)系統(tǒng)在峰值流量下不會(huì)崩。4.2 長(zhǎng)任務(wù)用隊(duì)列不用同步阻塞接口Agent 任務(wù)可能耗時(shí)幾秒到幾分鐘。如果客戶端一直同步等待體驗(yàn)會(huì)很差也容易觸發(fā)網(wǎng)關(guān)超時(shí)。生產(chǎn)環(huán)境里建議把任務(wù)改成異步模式客戶端提交請(qǐng)求服務(wù)立即返回 task_id。Agent 任務(wù)進(jìn)入隊(duì)列后臺(tái)消費(fèi)者執(zhí)行?？蛻舳送ㄟ^(guò)輪詢或 Webhook 獲取結(jié)果。這個(gè)設(shè)計(jì)不需要一開始就引入重型消息中間件。如果團(tuán)隊(duì)已經(jīng)有 RabbitMQ、Redis、Kafka 可以復(fù)用沒有的話用數(shù)據(jù)庫(kù)表存任務(wù)狀態(tài)也可以。核心是“任務(wù)狀態(tài)可查詢”。4.3 任務(wù)狀態(tài)至少要區(qū)分“排隊(duì)、執(zhí)行中、成功、失敗、需人工”每個(gè)任務(wù)狀態(tài)都要有最后更新時(shí)間。當(dāng)任務(wù)卡住時(shí)運(yùn)維人員能夠立刻看到問(wèn)題。排隊(duì)任務(wù)已進(jìn)入隊(duì)列等待消費(fèi)。執(zhí)行中消費(fèi)者正在處理。成功處理完成結(jié)果可查詢。失敗重試后仍然失敗。需人工業(yè)務(wù)無(wú)法自動(dòng)處理需要人工介入。執(zhí)行中狀態(tài)超過(guò)一定時(shí)間沒有變化可以視為異常。超時(shí)閾值由業(yè)務(wù)自己定比如普通售后任務(wù) 10 分鐘復(fù)雜分析任務(wù) 30 分鐘。一旦超過(guò)閾值就觸發(fā)告警并允許運(yùn)維手動(dòng)重試或終止。注意任務(wù)狀態(tài)要支持冪等更新。同一任務(wù)被重復(fù)消費(fèi)時(shí)不能重復(fù)創(chuàng)建工單、重復(fù)扣款或重復(fù)寫入數(shù)據(jù)。每次調(diào)度都帶上 task_id 做去重判斷。5. 規(guī)則五安全、權(quán)限和輸出校驗(yàn)不能放到上線后補(bǔ)Agent 的能力越強(qiáng)安全隱患越明顯。它能調(diào)用工具意味著它能發(fā)起真實(shí)操作。如果權(quán)限沒有控制好一條惡意指令就可能造成越權(quán)操作。這個(gè)不能等上線后再補(bǔ)救。5.1 Agent 的權(quán)限要按最小范圍授予不要讓 Agent 使用管理員賬號(hào)調(diào)用所有接口。生產(chǎn)環(huán)境里應(yīng)該單獨(dú)創(chuàng)建服務(wù)賬號(hào)只給它開通完成業(yè)務(wù)所必需的權(quán)限。比如查詢訂單狀態(tài)的工具只需要只讀權(quán)限。創(chuàng)建工單的工具只允許寫入工單系統(tǒng)不允許修改其他業(yè)務(wù)數(shù)據(jù)。文件讀取工具只允許讀取指定目錄不允許遍歷磁盤。判斷權(quán)限是否合理的標(biāo)準(zhǔn)如果刪掉 Agent 的賬號(hào)核心業(yè)務(wù)還能正常運(yùn)行說(shuō)明權(quán)限設(shè)計(jì)是合適的。反過(guò)來(lái)如果 Agent 賬號(hào)擁有太多權(quán)限一旦提示詞被注入或者模型被誘導(dǎo)風(fēng)險(xiǎn)面會(huì)非常大。5.2 模型輸出必須過(guò)一道校驗(yàn)層模型輸出的自然語(yǔ)言不能直接當(dāng)做業(yè)務(wù)結(jié)果使用。尤其當(dāng)結(jié)果要寫入數(shù)據(jù)庫(kù)、調(diào)用下游 API 或展示給用戶時(shí)必須經(jīng)過(guò)校驗(yàn)。校驗(yàn)至少包括結(jié)構(gòu)校驗(yàn)輸出是否包含必需的字段JSON 是否能解析。類型校驗(yàn)字段值是否在預(yù)期范圍內(nèi)。長(zhǎng)度校驗(yàn)輸出是否過(guò)長(zhǎng)是否需要截?cái)?。?nèi)容校驗(yàn)是否包含不合規(guī)內(nèi)容是否包含敏感信息。業(yè)務(wù)校驗(yàn)比如金額字段是否大于零訂單號(hào)是否存在。如果模型輸出沒有通過(guò)校驗(yàn)需要提前決定是重試、降級(jí)還是轉(zhuǎn)人工。不能一直卡在同一處循環(huán)重試。5.3 日志、審計(jì)和隱私脫敏一起設(shè)計(jì)Agent 在處理任務(wù)時(shí)接觸的數(shù)據(jù)可能包含用戶隱私。日志里不要記錄完整手機(jī)號(hào)、身份證號(hào)、密碼、Token 等敏感信息應(yīng)當(dāng)脫敏后再落盤。審計(jì)方面要能回答這些問(wèn)題什么時(shí)間發(fā)起了什么請(qǐng)求請(qǐng)求來(lái)自哪個(gè)用戶或哪個(gè)系統(tǒng)Agent 調(diào)用了哪些工具最終執(zhí)行了什么操作結(jié)果是什么這些日志不是為了事后追責(zé)而是生產(chǎn)事故回溯和問(wèn)題定位的基礎(chǔ)。沒有審計(jì)鏈路Agent 一旦出錯(cuò)你很難知道它在哪個(gè)環(huán)節(jié)偏離了預(yù)期。6. 生產(chǎn)環(huán)境最常見的失敗模式與排查順序前面五條規(guī)則能覆蓋大部分生產(chǎn) Agent 的工程結(jié)構(gòu)。但實(shí)際運(yùn)行中總會(huì)出現(xiàn)一些看起來(lái)很怪的問(wèn)題。下面列出三種最常見的失敗模式并給出排查重點(diǎn)。6.1 現(xiàn)象一Agent 長(zhǎng)時(shí)間不響應(yīng)常見原因有三個(gè)長(zhǎng)任務(wù)使用同步接口客戶端等待超時(shí)。外部 API 沒有設(shè)置客戶端超時(shí)時(shí)間導(dǎo)致請(qǐng)求掛死。模型服務(wù)排隊(duì)請(qǐng)求進(jìn)入隊(duì)列后長(zhǎng)時(shí)間沒有結(jié)果。排查時(shí)先看任務(wù)狀態(tài)和最后更新時(shí)間。如果狀態(tài)一直在“執(zhí)行中”說(shuō)明任務(wù)卡在某個(gè)環(huán)節(jié)。再看日志里最后一次工具調(diào)用的耗時(shí)和環(huán)境信息。如果工具調(diào)用遲遲沒有返回優(yōu)先檢查外部 API 的超時(shí)設(shè)置和限流狀態(tài)。不要一上來(lái)就重啟服務(wù)。重啟只是掩蓋問(wèn)題下次還會(huì)出現(xiàn)。6.2 現(xiàn)象二工具返回正常但模型沒有執(zhí)行后續(xù)動(dòng)作工具調(diào)用成功日志顯示工具結(jié)果正常但模型沒有繼續(xù)生成后續(xù)步驟而是直接輸出了一段文本或者停在那里。排查順序先看模型的原始輸出確認(rèn)它到底有沒有生成工具調(diào)用參數(shù)。如果模型輸出了普通文本說(shuō)明它對(duì)當(dāng)前狀態(tài)的理解出現(xiàn)了偏離可能是提示詞沒有交代清楚“拿到結(jié)果后必須繼續(xù)”。如果工具返回結(jié)果太長(zhǎng)可能被截?cái)嗄Ｐ蜎]有拿到核心信息需要在工具層做摘要。如果上下文太長(zhǎng)模型可能忽略了早期指令需要壓縮歷史消息或重新組織提示詞。這類問(wèn)題不是簡(jiǎn)單的“模型變笨了”而是上下文結(jié)構(gòu)和工具返回內(nèi)容的組織方式需要調(diào)整。6.3 現(xiàn)象三批量任務(wù)跑完后結(jié)果對(duì)不上批量任務(wù)最常見的坑是并發(fā)場(chǎng)景下的共享狀態(tài)沖突。比如兩個(gè)任務(wù)同時(shí)寫同一個(gè)文件后寫的覆蓋先寫的或者兩個(gè)任務(wù)共用同一個(gè)內(nèi)存變量互相污染又或者任務(wù)重復(fù)執(zhí)行數(shù)據(jù)庫(kù)里生成了多條重復(fù)記錄。解決思路每個(gè)任務(wù)使用唯一 task_id。中間結(jié)果和輸出文件按 task_id 命名。寫入數(shù)據(jù)庫(kù)時(shí)使用事務(wù)或唯一約束。任務(wù)調(diào)度時(shí)先查重判斷任務(wù)是否已經(jīng)處理過(guò)。批量任務(wù)的成功率不能只看“最終有沒有輸出”要檢查輸出是否完整、是否一一對(duì)應(yīng)、有沒有重復(fù)和遺漏。6.4 排查順序與檢查清單排查層次優(yōu)先檢查項(xiàng)常見誤區(qū)現(xiàn)象報(bào)錯(cuò)信息、超時(shí)時(shí)間、任務(wù)狀態(tài)直接重啟服務(wù)掩蓋真實(shí)問(wèn)題輸入?yún)?shù)格式、文件編碼、路徑、輸入字段是否完整只改參數(shù)不檢查輸入樣本環(huán)境依賴版本、權(quán)限、資源占用、端口沖突把環(huán)境問(wèn)題當(dāng)成模型問(wèn)題參數(shù)并發(fā)數(shù)、重試次數(shù)、模型溫度、上下文長(zhǎng)度把參數(shù)拉滿反而更不穩(wěn)定工具本身工具版本、接口變更、已知限制忽略版本變更日志和兼容性排查時(shí)按這個(gè)順序走能避免很多無(wú)效操作。先看現(xiàn)象再確認(rèn)輸入再檢查環(huán)境然后調(diào)參數(shù)最后才去質(zhì)疑工具本身。很多看起來(lái)像 Agent 能力問(wèn)題的情況最后定位出來(lái)都是環(huán)境變量配錯(cuò)、路徑不對(duì)或者依賴版本不一致。生產(chǎn)級(jí) Agent 和 Demo 最大的區(qū)別不在于模型有多強(qiáng)而在于每一層設(shè)計(jì)是否留了后路。邊界、日志、重試、隊(duì)列、權(quán)限、校驗(yàn)這些都是聽起來(lái)枯燥但真正決定能不能長(zhǎng)期運(yùn)行的環(huán)節(jié)。我個(gè)人建議按順序來(lái)做先定業(yè)務(wù)邊界和成功標(biāo)準(zhǔn)再跑最小閉環(huán)然后補(bǔ)日志和重試接著設(shè)計(jì)隊(duì)列和并發(fā)最后把權(quán)限和校驗(yàn)加上。如果一上來(lái)就追求全自動(dòng)、多工具、強(qiáng)記憶最后往往會(huì)在最普通的地方卡住。