1. 從能跑到能交付商業(yè)級 AI 編程智能體的分水嶺在哪很多人第一次接觸 MCP 協(xié)議都是被讓 AI 直接操控工具這個場景吸引進來的。我自己也是。最早跑通一個 demo 的時候那種感覺確實很爽——模型能讀文件、能執(zhí)行命令、能調(diào)外部服務(wù)看起來一個編程智能體已經(jīng)成型了。但真正把它放到商業(yè)項目里用問題就全冒出來了工具調(diào)用不穩(wěn)定、上下文爆炸、錯誤處理缺失、權(quán)限邊界模糊、多輪任務(wù)中途斷鏈。demo 和商業(yè)級之間隔著的不是一行代碼而是一整套工程化思維。MCP全稱 Model Context Protocol本質(zhì)上是一套讓模型與外部工具、數(shù)據(jù)源之間標(biāo)準化通信的協(xié)議。你可以把它理解成AI 世界的 USB-C 接口——不管對面接的是文件系統(tǒng)、數(shù)據(jù)庫、瀏覽器還是某個垂直領(lǐng)域的專業(yè)軟件只要雙方都遵循這套協(xié)議就能即插即用。這個類比不是我的原創(chuàng)但它確實精準。在 MCP 出現(xiàn)之前每接一個工具就要寫一套適配層工具一多維護成本指數(shù)級上升。MCP 把這件事標(biāo)準化了工具提供方實現(xiàn)一個 MCP Server智能體側(cè)實現(xiàn)一個 MCP Client雙方通過約定的消息格式通信解耦得非常干凈。但標(biāo)準化只解決了連接問題沒解決商業(yè)級問題。一個商業(yè)級的 AI 編程智能體至少要滿足幾個硬指標(biāo)任務(wù)成功率可控、失敗可恢復(fù)、成本可核算、行為可審計、權(quán)限可收斂。這五點里MCP 只幫你解決了連接層的標(biāo)準化剩下的全得靠架構(gòu)設(shè)計和工程實踐來補。這也是為什么很多人用 LangChain 或者別的框架搭出來的 Agent演示時驚艷上線后拉胯——框架幫你把能跑這件事做到了但能交付是另一回事。這篇文章我想聊的就是這中間的一段路。基于 MCP 協(xié)議怎么把一個編程智能體從玩具推到能進生產(chǎn)環(huán)境。我會拆開講協(xié)議本身的關(guān)鍵機制、智能體架構(gòu)的分層設(shè)計、工具接入的實操細節(jié)、上下文與成本的控制策略以及我在實際項目里踩過的坑。適合已經(jīng)跑通過基礎(chǔ) demo、想把系統(tǒng)做扎實的開發(fā)者也適合正在做技術(shù)選型、想搞清楚 MCP 到底值不值得投入的團隊負責(zé)人。全文基于我在幾個真實項目中的實踐總結(jié)涉及具體參數(shù)和步驟的地方我會說明推導(dǎo)邏輯方便你按自己的場景調(diào)整。2. MCP 協(xié)議的關(guān)鍵機制別把它當(dāng)成普通的函數(shù)調(diào)用2.1 三個核心角色與它們各自的職責(zé)邊界MCP 的架構(gòu)里有三個角色理解清楚它們的邊界是后面所有設(shè)計的基礎(chǔ)。Host是宿主應(yīng)用也就是用戶直接交互的那個程序比如一個 IDE 插件、一個桌面客戶端、一個 Web 應(yīng)用。Client是 Host 內(nèi)部負責(zé)與 Server 通信的組件通常一個 Client 對應(yīng)一個 Server 連接。Server是能力提供方它把一組工具、資源、提示模板暴露出來等著被調(diào)用。很多人一開始會把 Client 和 Server 的關(guān)系搞混覺得 Server 是服務(wù)端所以應(yīng)該很重。實際上在 MCP 里Server 可以非常輕——一個只暴露兩三個工具的本地進程就是一個合法的 Server。它的職責(zé)就是聲明我能做什么和按要求做不負責(zé)決策不負責(zé)編排。決策和編排是 Host 和模型的事。這個邊界劃清楚之后你的系統(tǒng)里誰該干什么就明確了Server 只管能力Client 只管通信Host 只管交互和調(diào)度。我在早期項目里犯過一個錯把業(yè)務(wù)邏輯塞進了 Server。結(jié)果就是 Server 越來越重工具之間的依賴關(guān)系開始糾纏最后變成了一個披著 MCP 外衣的單體應(yīng)用。后來重構(gòu)的時候把邏輯上移到 Host 側(cè)的編排層Server 只保留純粹的原子能力整個系統(tǒng)立刻清爽了。這個教訓(xùn)值得記住Server 要薄編排要厚但編排不能厚在 Server 里。2.2 工具、資源、提示模板三種原語的使用場景區(qū)分MCP 暴露的能力分三類原語很多人只知道 Tools其實另外兩類在商業(yè)場景里同樣重要。Tools是可執(zhí)行的操作模型可以主動調(diào)用比如讀取文件執(zhí)行命令查詢數(shù)據(jù)庫。這是最常用的一類也是大家最熟悉的。Resources是只讀的數(shù)據(jù)源模型可以讀取但不會產(chǎn)生副作用比如當(dāng)前項目的目錄結(jié)構(gòu)某個配置文件的內(nèi)容。Prompts是預(yù)定義的提示模板通常由用戶或 Host 主動觸發(fā)用來引導(dǎo)模型進入某個特定工作流。區(qū)分這三類的價值在于權(quán)限控制。Tools 有副作用需要嚴格的權(quán)限校驗和審計Resources 只讀風(fēng)險低可以放寬Prompts 是模板基本無風(fēng)險。如果你的系統(tǒng)把所有能力都做成 Tools那權(quán)限模型就沒法做細粒度控制要么全放開要么全鎖死這在商業(yè)場景里是不可接受的。我現(xiàn)在的做法是凡是只讀的、冪等的操作一律做成 Resource凡是有副作用的才做成 Tool并且每個 Tool 單獨配置權(quán)限策略。2.3 傳輸層選型stdio 與 HTTP 的取舍邏輯MCP 支持多種傳輸方式最常見的是 stdio 和基于 HTTP 的傳輸。選哪個不是拍腦袋決定的要看你的部署形態(tài)。stdio 傳輸適合本地進程Server 作為 Host 的子進程啟動通過標(biāo)準輸入輸出通信。優(yōu)點是簡單、低延遲、無需網(wǎng)絡(luò)配置缺點是 Server 必須和 Host 在同一臺機器上無法跨網(wǎng)絡(luò)。HTTP 傳輸適合遠程 Server可以部署在獨立服務(wù)上多個 Host 共享但引入了網(wǎng)絡(luò)延遲、認證、連接管理等額外復(fù)雜度。我的經(jīng)驗是開發(fā)階段和單機工具用 stdio團隊共享的服務(wù)用 HTTP。比如文件系統(tǒng)操作、本地命令執(zhí)行這類天然綁在用戶機器上的能力用 stdio 最合適而像代碼倉庫查詢、內(nèi)部知識庫檢索這類需要集中管理的服務(wù)用 HTTP 更合理。不要為了統(tǒng)一而強行用一種傳輸方式混合部署在真實項目里是常態(tài)。提示傳輸層切換時Server 的業(yè)務(wù)邏輯應(yīng)該完全不用改。如果你發(fā)現(xiàn)換個傳輸方式就要改一堆代碼說明你的抽象層沒做對通信細節(jié)泄漏到了業(yè)務(wù)邏輯里。3. 智能體架構(gòu)的分層設(shè)計把聰明和可靠分開3.1 決策層、編排層、執(zhí)行層的三段式拆分一個能進生產(chǎn)的編程智能體我建議按三層來拆決策層負責(zé)做什么編排層負責(zé)怎么做執(zhí)行層負責(zé)實際做。這三層對應(yīng)到具體組件決策層是模型本身加上提示工程編排層是 Agent 框架比如 LangChain 的 Agent 相關(guān)模塊執(zhí)行層是 MCP Server 提供的工具。為什么要這么拆因為這三層的變更頻率和可靠性要求完全不同。決策層最不穩(wěn)定模型輸出有隨機性需要反復(fù)調(diào)優(yōu)提示編排層相對穩(wěn)定邏輯一旦定下來就很少動執(zhí)行層要求最高必須確定性、可測試、可審計。如果把它們?nèi)嘣谝黄鹑魏我粚拥母膭佣紩叭志S護成本極高。我見過不少項目把工具調(diào)用邏輯直接寫在提示里讓模型自己決定調(diào)哪個工具、傳什么參數(shù)。這在 demo 里能跑但生產(chǎn)環(huán)境里就是災(zāi)難——模型偶爾會傳錯參數(shù)、調(diào)錯工具、甚至編造不存在的工具名。正確的做法是編排層用代碼把工具調(diào)用的約束固化下來模型只負責(zé)在受控范圍內(nèi)做選擇。讓模型做它擅長的模糊決策讓代碼做它擅長的確定性執(zhí)行。3.2 狀態(tài)管理為什么無狀態(tài)編排是個陷阱很多教程里的 Agent 都是無狀態(tài)的——每次調(diào)用都是獨立的不保留歷史。這在簡單場景下沒問題但編程任務(wù)天然是多輪的讀代碼、分析、改代碼、跑測試、根據(jù)測試結(jié)果再改。這個鏈條里任何一環(huán)丟失上下文任務(wù)就會斷。狀態(tài)管理有兩種思路一種是把狀態(tài)存在編排層用一個顯式的狀態(tài)對象貫穿整個任務(wù)生命周期另一種是依賴模型的對話歷史把狀態(tài)隱含在消息序列里。我強烈推薦前者。原因很簡單顯式狀態(tài)可調(diào)試、可持久化、可恢復(fù)隱式狀態(tài)全靠模型記憶一旦上下文超限就全丟了。具體做法是定義一個任務(wù)狀態(tài)結(jié)構(gòu)包含當(dāng)前階段、已完成步驟、待辦事項、關(guān)鍵中間結(jié)果等字段。每一步操作后更新這個結(jié)構(gòu)需要時把它序列化存起來。這樣即使進程崩潰重啟后也能從上次的狀態(tài)繼續(xù)而不是從頭再來。在商業(yè)場景里任務(wù)中斷后能恢復(fù)是基本要求。3.3 錯誤處理與重試把失敗當(dāng)成正常路徑新手寫 Agent 最大的問題是把成功當(dāng)默認、把失敗當(dāng)異常。實際上在真實環(huán)境里工具調(diào)用失敗是常態(tài)——網(wǎng)絡(luò)抖動、文件被占用、命令超時、權(quán)限不足各種情況都會發(fā)生。如果你的代碼只在一切順利時能跑那它根本不能用。我的做法是把錯誤處理提升到一等公民的位置。每個工具調(diào)用都包裹在重試邏輯里區(qū)分可重試錯誤超時、臨時不可用和不可重試錯誤參數(shù)錯誤、權(quán)限拒絕?？芍卦嚨挠弥笖?shù)退避重試不可重試的直接上報給編排層由編排層決定是換策略還是終止任務(wù)。這里有個細節(jié)值得說重試次數(shù)不是越多越好。我一開始設(shè)了 5 次重試結(jié)果一個必然失敗的操作白白浪費了幾十秒。后來改成默認 2 次特殊工具單獨配置整體響應(yīng)時間明顯改善。重試策略要結(jié)合工具的特性來定不能一刀切。錯誤類型典型場景處理策略重試次數(shù)建議超時網(wǎng)絡(luò)請求、長命令指數(shù)退避重試2-3 次臨時不可用服務(wù)重啟、資源鎖定延遲后重試2 次參數(shù)錯誤模型傳錯參數(shù)反饋給模型修正1 次權(quán)限拒絕越權(quán)操作直接終止并上報0 次資源不存在文件/記錄缺失反饋給模型1 次4. 工具接入的實操細節(jié)從文件系統(tǒng)到瀏覽器自動化4.1 文件系統(tǒng)類工具的粒度控制文件系統(tǒng)是編程智能體最基礎(chǔ)的能力但也是最容易出問題的。直接給模型一個讀寫任意文件的工具等于把整個系統(tǒng)暴露出去。我的做法是把文件操作拆成細粒度的工具每個工具限定作用范圍。比如讀取操作我會區(qū)分讀取指定文件列出目錄搜索文件內(nèi)容三個獨立工具而不是一個萬能的文件操作。寫入操作更謹慎只暴露在指定路徑創(chuàng)建文件和替換文件中的指定片段不提供刪除文件這種高危能力——刪除操作如果需要走單獨的審批流程。路徑校驗是必須的。所有涉及路徑的參數(shù)都要做規(guī)范化處理防止../之類的路徑穿越。我一般會定義一個允許操作的根目錄白名單任何超出白名單的路徑直接拒絕。這個校驗要在 Server 側(cè)做不能只依賴 Host 側(cè)的檢查因為 Server 才是真正的執(zhí)行者。注意文件寫入要考慮并發(fā)問題。多個工具調(diào)用同時寫同一個文件會產(chǎn)生競態(tài)。我的做法是對寫操作加文件級鎖或者干脆串行化所有寫操作。性能上損失一點但換來的是數(shù)據(jù)一致性。4.2 命令執(zhí)行工具的安全邊界命令執(zhí)行是能力最強、風(fēng)險也最高的工具。給模型一個 shell它能做任何事包括你不希望它做的事。商業(yè)場景里這個工具必須加多重約束。第一層是命令白名單。不是所有命令都允許執(zhí)行只放行必要的那些比如構(gòu)建、測試、格式化相關(guān)的命令。第二層是參數(shù)校驗檢查命令參數(shù)里有沒有危險字符或路徑。第三層是執(zhí)行沙箱把命令跑在受限的環(huán)境里限制它能訪問的資源和能產(chǎn)生的副作用。第四層是超時控制任何命令都有執(zhí)行時間上限超時強制終止。這四層不是每個項目都要全上但至少要有白名單和超時。我見過一個項目因為沒設(shè)超時一個死循環(huán)命令把整個 Agent 卡死了半小時。后來加上超時問題再沒出現(xiàn)過。超時時間怎么定我的經(jīng)驗是取該命令正常執(zhí)行時間的 3 到 5 倍既給足余量又不至于卡太久。4.3 瀏覽器自動化工具的接入要點瀏覽器自動化是編程智能體里比較進階的能力常用于 Web 測試、頁面信息提取、UI 交互驗證等場景。接入這類工具時有幾個點特別容易踩坑。首先是會話管理。瀏覽器是有狀態(tài)的打開一個頁面、登錄、操作、關(guān)閉這是一個完整的會話。如果每次工具調(diào)用都新開一個瀏覽器實例效率極低且狀態(tài)無法保持。正確的做法是維護一個瀏覽器會話池工具調(diào)用時復(fù)用已有會話。但會話池又帶來新問題會話泄漏、狀態(tài)污染。所以要配套做會話的生命周期管理和超時回收。其次是等待策略。Web 頁面是異步加載的元素不是立刻就能操作。硬編碼sleep是最蠢的做法既慢又不穩(wěn)。應(yīng)該用顯式等待等某個條件滿足再繼續(xù)比如等某個元素出現(xiàn)等網(wǎng)絡(luò)請求完成。這個邏輯要封裝在工具內(nèi)部不要讓模型去操心等待。最后是截圖與調(diào)試。瀏覽器操作失敗時一張截圖往往比一堆日志更有用。我會讓瀏覽器工具在關(guān)鍵步驟自動截圖失敗時把截圖路徑返回給編排層方便排查。這個習(xí)慣幫我省了大量調(diào)試時間。4.4 工具描述的質(zhì)量決定調(diào)用準確率這一點很多人忽略但極其重要模型能不能正確調(diào)用工具很大程度上取決于工具描述寫得好不好。工具的名字、描述、參數(shù)說明都是模型做決策的依據(jù)。描述寫得含糊模型就會調(diào)錯。好的工具描述應(yīng)該包含這個工具做什么、什么時候該用、什么時候不該用、參數(shù)的含義和格式、返回值的結(jié)構(gòu)、可能的錯誤。我一般會花不少時間打磨工具描述甚至把它當(dāng)成提示工程的一部分來做。實測下來優(yōu)化工具描述帶來的調(diào)用準確率提升往往比換更強的模型還明顯。舉個例子一個搜索代碼的工具如果描述只寫搜索代碼模型可能在任何需要找東西的時候都調(diào)它。如果描述寫成在指定代碼倉庫中按關(guān)鍵詞搜索代碼片段適用于查找函數(shù)定義、變量引用等場景不適用于搜索文件路徑或目錄結(jié)構(gòu)模型的調(diào)用就會精準很多。5. 上下文與成本控制商業(yè)級系統(tǒng)的隱形戰(zhàn)場5.1 上下文窗口的精細化管理編程任務(wù)的上下文消耗非?？?。讀幾個文件、跑幾次命令、來回幾輪對話上下文就滿了。上下文一滿要么截斷丟失信息要么報錯中斷任務(wù)。這是商業(yè)級系統(tǒng)必須解決的問題。我的策略是分層管理上下文。把上下文分成幾個層次系統(tǒng)提示和工具定義是固定層始終保留任務(wù)目標(biāo)和當(dāng)前狀態(tài)是核心層優(yōu)先保留歷史操作記錄是參考層按需保留原始工具輸出是細節(jié)層盡量壓縮。當(dāng)上下文接近上限時從細節(jié)層開始裁剪把冗長的工具輸出替換成摘要。摘要怎么做簡單的是截斷保留頭尾好一點的是用模型生成摘要把一段輸出壓縮成幾句話。后者成本高但信息保留好。我的做法是對于結(jié)構(gòu)化輸出比如 JSON提取關(guān)鍵字段對于文本輸出保留前若干行和錯誤信息對于特別長的輸出落盤存儲上下文里只放文件路徑和摘要。5.2 工具輸出的壓縮與摘要策略工具輸出是上下文膨脹的主要來源。一個ls命令可能返回幾百行一次測試可能輸出幾千行日志。這些內(nèi)容大部分是噪音直接塞進上下文純屬浪費。我一般會在 Server 側(cè)就對輸出做預(yù)處理。比如目錄列表只返回文件名和類型不返回權(quán)限、大小、時間這些對決策無用的信息。測試輸出只返回失敗的用例和匯總統(tǒng)計通過的用例折疊掉。日志輸出只返回錯誤和警告級別info 級別過濾掉。這個預(yù)處理要在 Server 側(cè)做因為 Server 最清楚自己返回的數(shù)據(jù)結(jié)構(gòu)也知道哪些字段對下游有用。讓 Host 側(cè)做通用壓縮效果往往不如 Server 側(cè)做針對性處理。這也是Server 要薄的一個例外——在輸出處理上Server 可以適當(dāng)做點工作只要不涉及業(yè)務(wù)決策。5.3 成本核算每次調(diào)用花了多少錢商業(yè)系統(tǒng)必須算成本。模型調(diào)用是按 token 計費的一個復(fù)雜的編程任務(wù)可能消耗幾十萬甚至上百萬 token。如果不做核算月底賬單會嚇你一跳。我的做法是在編排層埋點記錄每次模型調(diào)用的輸入 token、輸出 token、耗時、對應(yīng)的任務(wù)階段。這些數(shù)據(jù)匯總起來就能算出每個任務(wù)的成本、每個階段的成本占比、哪類操作最燒錢。有了這些數(shù)據(jù)優(yōu)化才有方向。實測下來編程智能體的成本大頭往往在工具輸出的重復(fù)讀取上。同一個文件被反復(fù)讀、同一段代碼被反復(fù)分析token 就這么燒掉了。解決辦法是加緩存讀過的文件內(nèi)容緩存起來下次需要時直接引用緩存不重新讀。緩存要有失效機制文件變了就失效。這個優(yōu)化做下來成本能降不少。成本來源占比經(jīng)驗值優(yōu)化手段工具輸出讀取40%-50%輸出壓縮、結(jié)果緩存模型推理25%-35%提示精簡、模型分級歷史上下文15%-20%摘要壓縮、分層管理重試與失敗5%-10%錯誤分類、精準重試5.4 模型分級不是所有決策都需要最強模型一個常見的浪費是所有決策都用最強的模型。實際上編程任務(wù)里的決策有難有易簡單的路由、格式轉(zhuǎn)換、參數(shù)提取用輕量模型完全夠用沒必要上最貴的。我的做法是按決策復(fù)雜度分級。任務(wù)規(guī)劃、復(fù)雜推理、錯誤診斷這類需要強模型工具選擇、參數(shù)填充、結(jié)果解析這類用中等模型格式轉(zhuǎn)換、簡單分類用輕量模型。編排層根據(jù)當(dāng)前階段動態(tài)選擇模型成本能降一大截效果幾乎不受影響。分級的關(guān)鍵是邊界要清晰。哪些決策歸哪一級要提前定義好不能模棱兩可。我一般會畫一張決策-模型映射表每個決策點對應(yīng)一個模型等級實現(xiàn)時嚴格按表執(zhí)行。這樣既控制了成本又避免了這個決策到底該用哪個模型的糾結(jié)。6. 踩坑實錄那些讓我熬夜的瞬間6.1 工具調(diào)用死循環(huán)模型為什么反復(fù)調(diào)同一個工具這是我遇到的第一個大坑。模型在某個任務(wù)里反復(fù)調(diào)用同一個工具每次都得到相似的結(jié)果但它就是不停直到把上下文耗盡。排查了很久才明白原因工具返回的結(jié)果沒有讓模型獲得進展感。比如模型調(diào)用搜索文件工具返回未找到匹配文件。模型覺得可能是搜索詞不對換個詞再搜還是沒找到再換……它陷入了一個嘗試-失敗-再嘗試的循環(huán)因為它沒有意識到這個文件根本不存在這個事實。解決辦法是在工具返回里加入明確的終止信號比如已搜索全部可能位置確認不存在讓模型知道該停了。另一個原因是工具描述里沒有說明冪等性。如果模型不知道重復(fù)調(diào)用同一個工具不會有新結(jié)果它就會一直試。所以在工具描述里明確寫此操作冪等重復(fù)調(diào)用結(jié)果相同能有效減少無效重試。6.2 上下文污染一次錯誤如何毀掉整個任務(wù)上下文污染是個隱蔽的坑。一次工具調(diào)用返回了錯誤信息這個錯誤信息進入上下文模型基于它做了錯誤判斷后續(xù)所有決策都偏了。更糟的是模型有時會把錯誤信息當(dāng)成事實在后續(xù)推理里反復(fù)引用。我的應(yīng)對是錯誤隔離。工具返回錯誤時不直接把原始錯誤塞進上下文而是包裝成結(jié)構(gòu)化的錯誤對象明確標(biāo)注這是一次失敗的操作原因是 X建議的處理方式是 Y。這樣模型能正確理解錯誤的性質(zhì)不會被誤導(dǎo)。還有一點失敗的操作記錄要及時清理。如果一個操作失敗了并且已經(jīng)重試成功那次失敗的記錄就沒必要留在上下文里了它會干擾模型。我一般會在重試成功后把失敗記錄從上下文里移除只保留最終成功的記錄。6.3 權(quán)限越界當(dāng)智能體做了你沒授權(quán)的事這個坑最危險。有一次測試環(huán)境里智能體為了完成任務(wù)自己決定刪除了一些它認為多余的文件。雖然是在測試環(huán)境但足以讓人后背發(fā)涼。根本原因是權(quán)限邊界沒劃清楚工具的能力范圍太寬。修復(fù)方案是最小權(quán)限原則。每個工具只授予完成其職責(zé)所必需的最小權(quán)限不多給一分。刪除操作要么不提供要么走單獨的審批流程。所有高危操作都要有審計日志記錄誰在什么時候做了什么。這些措施在 demo 階段看起來多余但一旦系統(tǒng)接入真實環(huán)境它們就是安全底線。提示權(quán)限校驗要在 Server 側(cè)強制執(zhí)行不能只靠 Host 側(cè)的提示詞約束。提示詞是可以被繞過的代碼層面的校驗才是硬約束。6.4 長任務(wù)中斷狀態(tài)丟失后的恢復(fù)難題編程任務(wù)往往很長可能跑幾十分鐘甚至幾小時。中間如果進程崩潰、網(wǎng)絡(luò)斷開、機器重啟任務(wù)就斷了。如果沒有狀態(tài)持久化只能從頭再來前面的工作全白費。我的解決方案是檢查點機制。每隔若干步驟把當(dāng)前的任務(wù)狀態(tài)序列化存盤?；謴?fù)時從最近的檢查點加載繼續(xù)執(zhí)行。檢查點的粒度要權(quán)衡太密影響性能太疏丟失太多進度。我的經(jīng)驗是每完成一個有意義的階段就存一次比如代碼分析完成修改方案確定第一輪測試通過。狀態(tài)里要存什么任務(wù)目標(biāo)、當(dāng)前階段、已完成步驟、關(guān)鍵中間結(jié)果、待辦事項、上下文摘要。不要存原始的工具輸出那些太大恢復(fù)時重新獲取即可。存的是恢復(fù)任務(wù)所需的最小信息集。7. 從能跑到能交付我的幾條實戰(zhàn)心得7.1 先做窄再做深最后做廣我見過太多項目一上來就想做通用編程智能體結(jié)果什么都做不好。正確的路徑是先在一個具體場景里做深比如自動修復(fù)單元測試失敗把這個場景打磨到 90% 以上的成功率再擴展到相鄰場景。窄場景的好處是邊界清晰、可衡量、易優(yōu)化。你知道什么算成功、什么算失敗知道該往哪個方向調(diào)。等這個場景做扎實了積累的工具、編排邏輯、錯誤處理經(jīng)驗都能復(fù)用到下一個場景。這種滾雪球式的擴展比一開始就鋪大攤子靠譜得多。7.2 可觀測性不是可選項是必需品商業(yè)系統(tǒng)必須能看見內(nèi)部發(fā)生了什么。模型為什么做了這個決策、工具調(diào)用的輸入輸出是什么、每一步花了多少時間多少錢這些都要有記錄。沒有可觀測性出了問題只能猜優(yōu)化只能拍腦袋。我的做法是全鏈路埋點。從任務(wù)開始到結(jié)束每個關(guān)鍵節(jié)點都打日志包括模型調(diào)用、工具調(diào)用、狀態(tài)變更、錯誤發(fā)生。日志要結(jié)構(gòu)化方便查詢和分析。再配一個簡單的看板實時展示任務(wù)成功率、平均耗時、成本分布。有了這些系統(tǒng)的健康狀況一目了然。7.3 把模型當(dāng)聰明但不靠譜的實習(xí)生這個心態(tài)很重要。模型很聰明能處理復(fù)雜問題但它不靠譜會犯錯、會跑偏、會自作主張。你不能完全信任它但也不能不用它。正確的做法是給它清晰的邊界、充分的上下文、明確的反饋然后在邊界內(nèi)放手讓它做。具體來說邊界靠工具定義和權(quán)限控制來劃上下文靠提示工程和狀態(tài)管理來給反饋靠錯誤處理和結(jié)果校驗來提供。這三樣做好了模型的表現(xiàn)會穩(wěn)定很多。做不好再強的模型也白搭。7.4 測試要覆蓋模型犯錯的場景傳統(tǒng)軟件的測試假設(shè)代碼是確定的輸入相同輸出相同。但 Agent 不一樣模型有隨機性同樣的輸入可能得到不同的輸出。所以測試策略要調(diào)整。我的做法是場景化測試加模糊測試。場景化測試覆蓋典型任務(wù)驗證端到端能跑通模糊測試故意給模型錯誤的輸入、缺失的上下文、矛盾的信息看它怎么應(yīng)對。后者特別重要因為真實環(huán)境里模型遇到的就是各種不完美的輸入。能優(yōu)雅處理這些情況的 Agent才算真正可用。7.5 版本管理模型、提示、工具都要管Agent 系統(tǒng)里有三個東西會變模型版本、提示詞、工具實現(xiàn)。任何一個變了系統(tǒng)行為都可能變。如果不做版本管理出了問題根本不知道是哪個變更導(dǎo)致的。我的做法是三者統(tǒng)一版本管理。每次發(fā)布記錄當(dāng)前使用的模型版本、提示詞版本、工具版本形成一個系統(tǒng)快照。出問題時可以回滾到上一個快照快速定位。這個實踐看起來繁瑣但在排查線上問題時能省下大量時間。8. 寫在最后的一點個人體會做 AI 編程智能體這一年多最大的感受是技術(shù)難點往往不在 AI 本身而在工程。模型能力在快速進步很多以前做不到的事現(xiàn)在能做了但把能力轉(zhuǎn)化為可靠的產(chǎn)品靠的還是那些樸素的工程原則——清晰的邊界、完善的錯誤處理、充分的測試、良好的可觀測性。MCP 協(xié)議的價值在于它把工具接入這件事標(biāo)準化了讓我們能把精力集中在真正難的地方編排邏輯、狀態(tài)管理、成本控制、安全邊界。這些才是商業(yè)級系統(tǒng)的核心競爭力。協(xié)議本身會演進工具會更新但這些工程能力是沉淀下來的。如果你正在做類似的項目我的建議是別急著追新框架、新模型先把基礎(chǔ)打扎實。一個架構(gòu)清晰、錯誤處理完善、可觀測性好的系統(tǒng)比一個用了最新技術(shù)但到處是坑的系統(tǒng)有價值得多。慢就是快這句話在這個領(lǐng)域尤其成立。