企業(yè)級(jí)MCP部署這件事我本來(lái)以為最難的是協(xié)議理解和技術(shù)選型真正干完一個(gè)完整的項(xiàng)目才發(fā)現(xiàn)最磨人的是另外三件事身份怎么打通、預(yù)算怎么控住、錯(cuò)誤怎么兜底。這三個(gè)坑我全都踩了一遍而且是踩實(shí)了的那種。這篇文章把我自己的完整經(jīng)歷、踩坑過(guò)程、最終落地的方案和排查思路都寫出來(lái)給后面要上MCP的團(tuán)隊(duì)做個(gè)參考。先說(shuō)清楚我的背景方便你對(duì)號(hào)入座。我們團(tuán)隊(duì)做的是一個(gè)內(nèi)部知識(shí)平臺(tái)要給多個(gè)業(yè)務(wù)部門提供AI輔助能力底層通過(guò)MCP協(xié)議接入了一個(gè)模型服務(wù)同時(shí)自定義了十幾個(gè)MCP Server用來(lái)查知識(shí)庫(kù)、查訂單、查用戶權(quán)限、調(diào)審批接口等等。從開發(fā)聯(lián)調(diào)到上線運(yùn)行大概一個(gè)月中間經(jīng)歷了身份串號(hào)、預(yù)算超支、錯(cuò)誤滿天飛三個(gè)階段。下面按順序把三個(gè)大坑逐個(gè)拆開講。1. 企業(yè)級(jí)MCP部署為什么會(huì)踩坑以及這篇文章的閱讀對(duì)象1.1 從Demo到生產(chǎn)環(huán)境距離比想象中大得多很多團(tuán)隊(duì)接觸MCP都是從Demo開始的本地起一個(gè)MCP Server用官方的Client連一下調(diào)通一個(gè)工具感覺非常絲滑。我們最初也是這樣演示給業(yè)務(wù)方看的時(shí)候?qū)Ψ接X得挺好AI能調(diào)內(nèi)部系統(tǒng)了。但等到真正做企業(yè)級(jí)部署需要把MCP Server接入生產(chǎn)網(wǎng)絡(luò)、對(duì)接統(tǒng)一身份體系、接入現(xiàn)有監(jiān)控告警、統(tǒng)計(jì)調(diào)用成本的時(shí)候問題就一個(gè)接一個(gè)冒出來(lái)了。Demo環(huán)境里可以不管身份認(rèn)證Client和Server都是本地的跑通了就行。生產(chǎn)環(huán)境不行請(qǐng)求從用戶端過(guò)來(lái)要經(jīng)過(guò)API網(wǎng)關(guān)、要識(shí)別調(diào)用者是誰(shuí)、要判斷他的權(quán)限邊界還要給每個(gè)業(yè)務(wù)方單獨(dú)算賬。Demo環(huán)境里調(diào)錯(cuò)接口也無(wú)所謂重來(lái)一次就行。生產(chǎn)環(huán)境里一個(gè)錯(cuò)誤如果被AI自動(dòng)重試可能一次會(huì)話就重復(fù)扣了三次費(fèi)用。這些都是環(huán)境切換帶來(lái)的真實(shí)差異也是標(biāo)題里三個(gè)大坑的根源。1.2 這篇文章寫給誰(shuí)看如果你是架構(gòu)師或技術(shù)負(fù)責(zé)人正在評(píng)估或者推進(jìn)MCP企業(yè)級(jí)落地這篇文章可以直接幫你避掉80%的規(guī)劃盲區(qū)。如果你是后端工程師負(fù)責(zé)寫MCP Server或者對(duì)接模型服務(wù)里面關(guān)于錯(cuò)誤碼、超時(shí)、重試的設(shè)計(jì)可以直接拿過(guò)去用。如果你是運(yùn)維或SRE預(yù)算控制和監(jiān)控告警那部分可以重點(diǎn)看。我不會(huì)講太多MCP協(xié)議本身的概念重點(diǎn)是三個(gè)大坑的形成過(guò)程、排查思路和最終方案。每個(gè)坑我都會(huì)先說(shuō)現(xiàn)象再說(shuō)根因然后給可落地的解決辦法。文中涉及的配置和代碼片段都是簡(jiǎn)化后的示例但核心邏輯是我們生產(chǎn)環(huán)境實(shí)際驗(yàn)證過(guò)的。2. 第一個(gè)大坑身份認(rèn)證與權(quán)限傳遞2.1 踩坑現(xiàn)場(chǎng)一所有請(qǐng)求都變成匿名用戶第一次踩坑是在聯(lián)調(diào)階段。我們的MCP Server需要調(diào)用內(nèi)部系統(tǒng)的接口拿數(shù)據(jù)而內(nèi)部接口要求帶上當(dāng)前登錄用戶的身份信息。最開始我們圖省事在MCP Server里寫了一個(gè)固定的Service Account所有請(qǐng)求都用這個(gè)賬號(hào)去調(diào)后端。結(jié)果AI查詢業(yè)務(wù)數(shù)據(jù)時(shí)后端審計(jì)日志里顯示所有操作都來(lái)自同一個(gè)服務(wù)賬號(hào)用戶維度完全沒法區(qū)分。這個(gè)問題的直接后果就是權(quán)限管控形同虛設(shè)。原本該按用戶隔離的數(shù)據(jù)比如員工只能看自己的薪資信息、項(xiàng)目經(jīng)理只能看自己項(xiàng)目的數(shù)據(jù)全部變成了服務(wù)賬號(hào)權(quán)限下的統(tǒng)一返回。更麻煩的是出問題后沒法追溯因?yàn)閷徲?jì)日志里看不到具體是誰(shuí)發(fā)起的請(qǐng)求。2.2 為什么MCP的身份傳遞這么麻煩MCP協(xié)議本身是客戶端-服務(wù)器架構(gòu)Client發(fā)起請(qǐng)求Server執(zhí)行工具調(diào)用。問題在于MCP Server在執(zhí)行工具時(shí)并不知道當(dāng)前對(duì)話的用戶是誰(shuí)。如果只是做一個(gè)本地調(diào)試工具這個(gè)問題不明顯但企業(yè)級(jí)場(chǎng)景下MCP Server經(jīng)常要跨系統(tǒng)調(diào)用用戶身份必須從Client一層一層傳下去。標(biāo)準(zhǔn)的MCP協(xié)議在請(qǐng)求頭里可以帶元數(shù)據(jù)但不同客戶端實(shí)現(xiàn)對(duì)這個(gè)字段的支持程度不一樣有的直接忽略有的只透?jìng)鞑恍ｒ?yàn)。更麻煩的是如果你的MCP Server里嵌套調(diào)用了多個(gè)子工具中間任何一層把身份信息弄丟了最終落到業(yè)務(wù)系統(tǒng)的請(qǐng)求就沒法溯源。2.3 解決思路統(tǒng)一網(wǎng)關(guān) JWT傳遞 Scope隔離我的最終方案是三層結(jié)構(gòu)。第一層是統(tǒng)一API網(wǎng)關(guān)。所有MCP Client的請(qǐng)求先經(jīng)過(guò)網(wǎng)關(guān)網(wǎng)關(guān)負(fù)責(zé)完成用戶身份認(rèn)證也就是登錄態(tài)校驗(yàn)?zāi)玫接脩粜畔⒑蠛灠l(fā)一個(gè)短時(shí)效的JWT Token再把這個(gè)Token附加到MCP請(qǐng)求的元數(shù)據(jù)里轉(zhuǎn)發(fā)給MCP Server。第二層是MCP Server內(nèi)部的中間件。Server收到請(qǐng)求后先從元數(shù)據(jù)里解析JWT校驗(yàn)簽名和有效期然后把解析出來(lái)的用戶ID、角色、部門信息放到請(qǐng)求上下文里。后續(xù)每個(gè)工具調(diào)用都從這個(gè)上下文里取身份信息。第三層是業(yè)務(wù)系統(tǒng)調(diào)用時(shí)的身份傳遞。MCP Server調(diào)用后端接口時(shí)不再使用固定Service Account而是把上一步解析到的用戶身份通過(guò)Header字段透?jìng)鬟^(guò)去。后端系統(tǒng)統(tǒng)一從這里取當(dāng)前操作人寫入審計(jì)日志。代碼層面可以參考這個(gè)簡(jiǎn)化示例import jwt from fastapi import Request, HTTPException async def resolve_identity(request: Request): # 從MCP請(qǐng)求元數(shù)據(jù)中取token token request.headers.get(X-MCP-Identity-Token) if not token: raise HTTPException(status_code401, detail缺少身份令牌) try: # 校驗(yàn)簽名和有效期注意這里要用統(tǒng)一的公鑰 payload jwt.decode(token, public_key, algorithms[RS256]) return { user_id: payload[sub], roles: payload.get(roles, []), department: payload.get(dept, ), scope: payload.get(scope, []) } except jwt.ExpiredSignatureError: raise HTTPException(status_code401, detail身份令牌已過(guò)期) except jwt.InvalidTokenError: raise HTTPException(status_code401, detail無(wú)效的身份令牌)身份拿到了還不夠還要做Scope隔離。每個(gè)工具調(diào)用前做一道權(quán)限檢查核心邏輯是當(dāng)前用戶是否擁有調(diào)用這個(gè)工具的權(quán)限如果權(quán)限不足直接返回業(yè)務(wù)層面的錯(cuò)誤碼而不是讓工具去后端接口碰一次壁再報(bào)錯(cuò)。這里有一個(gè)配套的關(guān)鍵動(dòng)作MCP Server注冊(cè)的工具列表要按調(diào)用者的角色做動(dòng)態(tài)過(guò)濾。比如普通員工進(jìn)來(lái)Server只能看到查知識(shí)庫(kù)查個(gè)人考勤等幾個(gè)工具管理者進(jìn)來(lái)才會(huì)看到查團(tuán)隊(duì)績(jī)效查審批流等高級(jí)工具。這樣即使模型誤調(diào)用也會(huì)因?yàn)楣ぞ吒静辉诹斜砝锒鵁o(wú)法執(zhí)行從源頭減少越權(quán)風(fēng)險(xiǎn)。2.4 身份認(rèn)證配置清單我把這個(gè)坑整理成了一份自查清單照著檢查基本不會(huì)漏確認(rèn)MCP Client是否會(huì)透?jìng)髯远x元數(shù)據(jù)不同客戶端行為差異很大有的會(huì)自動(dòng)剝離未知字段確認(rèn)JWT簽名算法和密鑰分發(fā)方式建議使用RS256非對(duì)稱簽名私鑰只在網(wǎng)關(guān)保留確認(rèn)Token有效期設(shè)置企業(yè)內(nèi)部場(chǎng)景建議5到10分鐘太短會(huì)導(dǎo)致AI連續(xù)工具調(diào)用時(shí)頻繁刷新身份確認(rèn)Scope拆分的粒度工具維度的Scope比接口維度的Scope更容易維護(hù)和排查確認(rèn)審計(jì)日志中是否記錄了端到端的用戶身份鏈路身份這塊解決之后緊接著撞上的是預(yù)算問題。身份問題影響的是安全和合規(guī)預(yù)算問題影響的是項(xiàng)目能不能持續(xù)跑下去。3. 第二個(gè)大坑預(yù)算控制與成本歸一3.1 踩坑現(xiàn)場(chǎng)二測(cè)試環(huán)境一個(gè)月燒掉全年預(yù)算預(yù)算這個(gè)坑對(duì)我們來(lái)說(shuō)更疼。MCP的調(diào)用鏈路是用戶提問 - 模型理解意圖 - 調(diào)用MCP Server工具 - 拿到結(jié)果 - 模型生成回復(fù)。每一次完整對(duì)話過(guò)程至少產(chǎn)生兩輪模型調(diào)用如果模型多次調(diào)用工具token消耗會(huì)指數(shù)級(jí)上升。我們上線第一周開發(fā)環(huán)境跑得一切正常。結(jié)果到了月底一看賬單MCP這個(gè)入口的token消費(fèi)占到了全項(xiàng)目消耗的70%。查下來(lái)發(fā)現(xiàn)是測(cè)試腳本里有一個(gè)定時(shí)任務(wù)每小時(shí)自動(dòng)發(fā)起一批對(duì)話請(qǐng)求而且因?yàn)楫?dāng)時(shí)沒做預(yù)算控制這些請(qǐng)求全部用的高配模型參數(shù)單次成本直接頂格。3.2 成本失控的三個(gè)關(guān)鍵環(huán)節(jié)我把MCP的消耗拆成三個(gè)環(huán)節(jié)每個(gè)環(huán)節(jié)都可能失控。第一個(gè)環(huán)節(jié)是模型調(diào)用本身。MCP Server里的工具返回結(jié)果后模型要把這些結(jié)果重新組織成自然語(yǔ)言答案這一段消耗的token往往比對(duì)話本身要多。如果工具返回的數(shù)據(jù)量大比如一個(gè)查詢返回了200條訂單記錄模型全部讀進(jìn)去再總結(jié)一次消耗可能頂普通對(duì)話十次。第二個(gè)環(huán)節(jié)是工具的無(wú)效調(diào)用。AI模型在自主決策時(shí)有時(shí)候會(huì)反復(fù)調(diào)用同一個(gè)工具來(lái)確認(rèn)結(jié)果。比如第一次調(diào)用查訂單狀態(tài)返回處理中模型覺得不確定又調(diào)了一次還是處理中再調(diào)一次。每一次調(diào)用都附帶完整的上下文傳輸累積起來(lái)就是真金白銀。第三個(gè)環(huán)節(jié)是多輪會(huì)話的上下文堆積。MCP Server每次返回的工具結(jié)果都會(huì)拼接到對(duì)話上下文里繼續(xù)傳給模型。如果單輪會(huì)話很長(zhǎng)上下文里的歷史消息加上工具返回結(jié)果會(huì)讓每次請(qǐng)求的輸入token持續(xù)膨脹到后面可能輸入比輸出貴得多。3.3 預(yù)算控制方案從配額到熔斷我們最終落地的方案分四層。第一層是配額管理。每個(gè)業(yè)務(wù)方接入MCP時(shí)先在配置中心申請(qǐng)一個(gè)每日配額和月度配額粒度可以細(xì)分到模型調(diào)用次數(shù)、輸入token數(shù)、輸出token數(shù)三個(gè)維度。配額用完之后系統(tǒng)自動(dòng)降級(jí)到低配模式比如切換到更小參數(shù)的模型、禁止調(diào)用高成本工具而不是直接拒絕服務(wù)。第二層是模型參數(shù)分級(jí)。同一個(gè)MCP Server對(duì)應(yīng)不同業(yè)務(wù)場(chǎng)景使用不同的模型參數(shù)組合。高價(jià)值場(chǎng)景用完整的多步推理配置一般場(chǎng)景用普通配置開發(fā)測(cè)試環(huán)境統(tǒng)一使用調(diào)試模式比如限制最大輸出長(zhǎng)度、關(guān)閉部分思考鏈路。這一層如果做得細(xì)成本差距可以達(dá)到數(shù)倍。第三層是請(qǐng)求級(jí)熔斷。實(shí)時(shí)監(jiān)控每次工具調(diào)用的token消耗如果單次請(qǐng)求的消耗超過(guò)設(shè)定閾值直接截?cái)嗌舷挛膹?qiáng)制結(jié)束當(dāng)前工具調(diào)用返回一個(gè)查詢結(jié)果過(guò)大請(qǐng)縮小范圍的錯(cuò)誤提示讓模型重新組織問題而不是硬著頭皮處理海量結(jié)果。第四層是成本審計(jì)。每次MCP調(diào)用無(wú)論成功還是失敗都把調(diào)用者的身份、工具名、模型消耗、token數(shù)量記錄到獨(dú)立的成本審計(jì)表里。每天凌晨出一個(gè)匯總報(bào)表按業(yè)務(wù)方、按工具、按模型三個(gè)維度統(tǒng)計(jì)。這樣業(yè)務(wù)方來(lái)問為什么我們部門賬單又漲了你能直接拉出明細(xì)而不是拍腦袋解釋。成本審計(jì)表的結(jié)構(gòu)可以參考這個(gè)簡(jiǎn)化設(shè)計(jì)CREATE TABLE mcp_cost_audit ( id BIGINT PRIMARY KEY AUTO_INCREMENT, request_id VARCHAR(64) NOT NULL, user_id VARCHAR(64) NOT NULL, department VARCHAR(128), tool_name VARCHAR(128), model_name VARCHAR(64), prompt_tokens INT DEFAULT 0, completion_tokens INT DEFAULT 0, total_tokens INT DEFAULT 0, estimated_cost DECIMAL(10, 6), call_success BOOLEAN, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_department_time (department, created_at), INDEX idx_tool_time (tool_name, created_at) );有了這張表預(yù)算問題就不再是感覺花了很多錢而是每個(gè)業(yè)務(wù)方花了多少錢、花在哪了、是不是合理都能直接回答。3.4 預(yù)算閉環(huán)告警通知預(yù)算控制還有一個(gè)容易被忽略的部分告警。配額用到了80%發(fā)一條預(yù)警100%觸發(fā)降級(jí)超過(guò)120%直接熔斷。這條告警鏈路要同時(shí)通知到MCP平臺(tái)負(fù)責(zé)人和業(yè)務(wù)方負(fù)責(zé)人不需要等月底看賬單問題發(fā)生時(shí)就能介入。這里我特別想說(shuō)一個(gè)心得預(yù)算控制一定要做成實(shí)時(shí)的事后復(fù)盤救不了預(yù)算。我們最開始是T1出報(bào)表結(jié)果某天半夜一個(gè)異常腳本跑了一整夜到第二天看到報(bào)表的時(shí)候費(fèi)已經(jīng)把周配額全吃完了。后來(lái)才把成本統(tǒng)計(jì)改成實(shí)時(shí)打點(diǎn)每10秒聚一次配合閾值觸發(fā)熔斷才把這層風(fēng)險(xiǎn)控制住。4. 第三個(gè)大坑錯(cuò)誤處理與重試策略4.1 踩坑現(xiàn)場(chǎng)三一次靜默失敗引發(fā)的連鎖事故第三個(gè)坑是錯(cuò)誤處理這個(gè)坑在開發(fā)階段完全看不出來(lái)一到生產(chǎn)環(huán)境就暴露了。現(xiàn)象是用戶問AI一個(gè)問題AI判斷需要調(diào)用知識(shí)庫(kù)工具工具返回了一個(gè)異常但MCP Server沒有把異常細(xì)節(jié)透?jìng)鞒鰜?lái)模型拿到的是一個(gè)模糊錯(cuò)誤開始自行發(fā)揮編了一個(gè)答案回復(fù)用戶。更糟的是另一次情況后端接口超時(shí)MCP Server沒設(shè)置超時(shí)時(shí)間直接掛起等待。模型這邊也在等結(jié)果用戶等得不耐煩刷新頁(yè)面重新發(fā)起了同樣的問題。結(jié)果第一個(gè)請(qǐng)求5分鐘后恢復(fù)返回結(jié)果第二個(gè)請(qǐng)求也正常返回兩個(gè)請(qǐng)求同時(shí)扣了兩次費(fèi)。這就是典型的錯(cuò)誤處理缺失引發(fā)重復(fù)計(jì)費(fèi)。4.2 錯(cuò)誤處理的三個(gè)層面MCP鏈路里的錯(cuò)誤處理我認(rèn)為要分成三個(gè)層面來(lái)看。第一個(gè)層面是協(xié)議層的錯(cuò)誤。比如MCP Server響應(yīng)超時(shí)、返回值格式不符合Schema、JSON解析失敗。這類錯(cuò)誤要由MCP框架本身處理設(shè)置好超時(shí)時(shí)間對(duì)返回內(nèi)容做嚴(yán)格校驗(yàn)失敗就立刻報(bào)錯(cuò)不留給模型猜測(cè)空間。第二個(gè)層面是工具函數(shù)層的錯(cuò)誤。比如工具內(nèi)部調(diào)用業(yè)務(wù)接口時(shí)對(duì)方返回了HTTP 500或401此時(shí)MCP Server不能把這堆原始異常直接丟給模型而是要轉(zhuǎn)換成結(jié)構(gòu)化的錯(cuò)誤碼和可讀信息讓模型知道這個(gè)動(dòng)作失敗了原因是什么還可以嘗試什么替代方案。第三個(gè)層面是業(yè)務(wù)規(guī)則層的錯(cuò)誤。比如調(diào)用審批工具時(shí)當(dāng)前用戶沒有審批權(quán)限或者單據(jù)已經(jīng)被別人處理。這類錯(cuò)誤的特點(diǎn)是模型無(wú)論如何重試都不會(huì)成功必須明確告知模型這是終態(tài)錯(cuò)誤不要重試直接告知用戶。只有把這三層錯(cuò)誤全部設(shè)計(jì)進(jìn)去模型才能做出正確反應(yīng)。否則它面對(duì)一個(gè)不明不白的異常只會(huì)按照訓(xùn)練時(shí)的習(xí)慣猜測(cè)一個(gè)最可能的答案回答用戶這就等于在生產(chǎn)和合規(guī)環(huán)境里埋了一顆雷。4.3 超時(shí)設(shè)置、重試機(jī)制與冪等控制我在錯(cuò)誤處理上重點(diǎn)做了三件事。第一件事是給所有MCP工具調(diào)用設(shè)置了超時(shí)時(shí)間默認(rèn)10秒重試一次重試超時(shí)減半到5秒。兩次都失敗就立刻返回錯(cuò)誤不無(wú)限等待。這個(gè)經(jīng)驗(yàn)值來(lái)自我們的實(shí)際場(chǎng)景正常情況下工具調(diào)用耗時(shí)在1秒以內(nèi)超過(guò)3秒基本就是接口有問題了5秒是內(nèi)部接口的硬性底線不需要給更長(zhǎng)的時(shí)間。第二件事是設(shè)計(jì)了一個(gè)標(biāo)準(zhǔn)錯(cuò)誤響應(yīng)結(jié)構(gòu)所有工具返回統(tǒng)一格式{ code: TOOL_EXECUTION_ERROR, message: 查詢訂單接口暫時(shí)不可用, retryable: false, suggestion: 請(qǐng)稍后再試或聯(lián)系管理員 }retryable字段是關(guān)鍵。模型看到retryable: true可以進(jìn)行一次重試看到false就必須停止動(dòng)作把錯(cuò)誤轉(zhuǎn)述給用戶。這個(gè)字段來(lái)自我們對(duì)所有異常的分類網(wǎng)絡(luò)抖動(dòng)和超時(shí)是可重試的權(quán)限不足和業(yè)務(wù)沖突是不可重試的。這樣就從機(jī)制上約束了模型的行為不再讓它自己猜。第三件事是冪等控制。所有涉及寫操作的MCP接口比如發(fā)起審批、創(chuàng)建訂單、修改數(shù)據(jù)都要求業(yè)務(wù)方提供冪等鍵也就是一個(gè)唯一的請(qǐng)求標(biāo)識(shí)。MCP Server把冪等鍵透?jìng)鹘o后端后端在收到重復(fù)請(qǐng)求時(shí)直接返回第一次的結(jié)果不作二次處理。這樣即使AI因?yàn)槌瑫r(shí)重發(fā)請(qǐng)求也不會(huì)造成業(yè)務(wù)側(cè)重復(fù)操作。冪等鍵的生成規(guī)則我建議這樣由MCP Server在第一次調(diào)用時(shí)生成格式是用戶ID 時(shí)間戳 隨機(jī)數(shù)存儲(chǔ)在當(dāng)前請(qǐng)求上下文中。如果同一輪對(duì)話里模型對(duì)同一個(gè)工具發(fā)起多次調(diào)用冪等鍵保持不變后端只處理第一次后續(xù)請(qǐng)求全部復(fù)用第一次的響應(yīng)。4.4 錯(cuò)誤碼規(guī)范與監(jiān)控告警最后是錯(cuò)誤碼的規(guī)范。我把MCP Server的錯(cuò)誤碼分成了幾個(gè)區(qū)間方便排查問題錯(cuò)誤碼范圍含義典型場(chǎng)景1000-1999身份認(rèn)證類錯(cuò)誤Token過(guò)期、簽名無(wú)效、Scope不足2000-2999工具執(zhí)行類錯(cuò)誤后端接口超時(shí)、數(shù)據(jù)格式異常3000-3999業(yè)務(wù)規(guī)則類錯(cuò)誤無(wú)權(quán)限、單據(jù)狀態(tài)沖突、參數(shù)不滿足要求4000-4999協(xié)議框架類錯(cuò)誤響應(yīng)超時(shí)、JSON解析失敗、Schema不匹配每個(gè)錯(cuò)誤碼都配一個(gè)固定的中文錯(cuò)誤描述禁止在代碼里直接拋英文異常。模型讀中文描述的理解準(zhǔn)確率比讀英文堆棧高得多這是實(shí)踐下來(lái)的經(jīng)驗(yàn)。監(jiān)控告警方面我給MCP平臺(tái)接上了和普通業(yè)務(wù)一樣的告警體系。錯(cuò)誤率超過(guò)閾值、平均響應(yīng)時(shí)間升高、慢請(qǐng)求占比變多都會(huì)觸發(fā)告警。另外專門加了一個(gè)模型補(bǔ)樓告警如果模型在工具返回錯(cuò)誤后仍然給用戶輸出了一段看似合理的答案系統(tǒng)會(huì)在后臺(tái)記錄一條警告日志。這個(gè)不太好自動(dòng)化判斷目前是抽樣人工排查但效果很好已經(jīng)發(fā)現(xiàn)了好幾例模型強(qiáng)行解釋錯(cuò)誤的case。5. 三個(gè)大坑常見問題排查速查表我把部署和運(yùn)維過(guò)程中遇到過(guò)的典型問題整理成了一個(gè)速查表。這個(gè)表是我在項(xiàng)目結(jié)束之后花了一個(gè)下午總結(jié)出來(lái)的對(duì)照排查效率很高。癥狀可能原因排查方法解決方案工具返回?cái)?shù)據(jù)沒有用戶維度身份信息未透?jìng)骰蛲競(jìng)麈溌窋嗔巡榭磳徲?jì)日志中的操作人字段統(tǒng)一JWT傳遞Server端解析后寫入上下文同一個(gè)操作重復(fù)扣費(fèi)超時(shí)重試未做冪等控制查看成本審計(jì)表中相同request_id的多條記錄增加冪等鍵后端按冪等鍵去重模型回答了錯(cuò)誤信息工具異常未結(jié)構(gòu)化透?jìng)鞑榭碝CP Server端錯(cuò)誤日志中模型的返回值錯(cuò)誤響應(yīng)統(tǒng)一code/message/retryable字段預(yù)算短時(shí)間內(nèi)消耗殆盡缺少實(shí)時(shí)配額熔斷機(jī)制查看成本審計(jì)表按時(shí)間聚合增加實(shí)時(shí)統(tǒng)計(jì)和閾值熔斷測(cè)試環(huán)境費(fèi)用比生產(chǎn)高測(cè)試腳本未限流或使用高配模型參數(shù)檢查測(cè)試配置中的模型參數(shù)環(huán)境維度配置獨(dú)立配額上限工具調(diào)用永遠(yuǎn)處于pendingMCP Server未設(shè)置超時(shí)時(shí)間檢查Server端的HTTP客戶端配置設(shè)置默認(rèn)10秒超時(shí)禁止無(wú)限等待權(quán)限校驗(yàn)時(shí)靈時(shí)不靈Scope定義粒度不一致檢查工具注冊(cè)時(shí)是否帶Scope標(biāo)簽工具維度Scope統(tǒng)一管理動(dòng)態(tài)過(guò)濾注冊(cè)列表審計(jì)日志查不到責(zé)任人后端只記錄了Service Account檢查后端接口的調(diào)用鏈Header透?jìng)饔脩鬒D到后端系統(tǒng)這張表的用法是先看癥狀對(duì)應(yīng)哪一行再按排查方法去檢查大概率能一步定位。比起對(duì)著日志瞎猜效率能高出一個(gè)量級(jí)。6. 最后說(shuō)幾個(gè)部署前必做的安排寫到這里三個(gè)大坑都講完了。最后我想從一個(gè)實(shí)際操盤者的角度分享幾個(gè)復(fù)盤后才想明白的建議。如果你現(xiàn)在正準(zhǔn)備把MCP從Demo推向生產(chǎn)可以先按這幾條自查一遍。第一個(gè)建議不要把Demo環(huán)境的代碼直接搬到生產(chǎn)。Demo環(huán)境默認(rèn)單機(jī)、信任、無(wú)超時(shí)生產(chǎn)環(huán)境是多用戶、跨網(wǎng)絡(luò)、布滿限制的。至少要把身份認(rèn)證鏈路和超時(shí)配置這兩項(xiàng)在Demo階段就按照生產(chǎn)標(biāo)準(zhǔn)來(lái)設(shè)計(jì)后面改動(dòng)成本會(huì)小很多。第二個(gè)建議預(yù)算控制一定要在設(shè)計(jì)階段就想好而不是等到賬單回來(lái)了再加。我們當(dāng)時(shí)就是先上線再補(bǔ)救結(jié)果第一個(gè)月的消耗完全是失控的狀態(tài)。流程上建議這樣接入MCP之前先定方案、這是我自己在項(xiàng)目收尾階段踩出來(lái)的教訓(xùn)預(yù)算審計(jì)表和冪等控制是兩個(gè)最值得優(yōu)先投入的點(diǎn)花費(fèi)的工時(shí)不長(zhǎng)但是效果立竿見影。第三個(gè)建議不要指望模型聰明地處理好所有異常。設(shè)計(jì)錯(cuò)誤響應(yīng)時(shí)一定要把retryable這類結(jié)構(gòu)化信息給到模型明確告訴它能做什么、不能做什么。我見過(guò)很多團(tuán)隊(duì)只扔一個(gè)大堆棧給模型指望它自己識(shí)別錯(cuò)誤結(jié)果就是模型給出了一個(gè)看似合理、實(shí)際完全錯(cuò)誤的答案。企業(yè)級(jí)場(chǎng)景下行為約束比模型能力可靠得多。第四個(gè)建議分配給MCP的監(jiān)控告警資源不要省。MCP鏈路比普通API多了一層模型參與故障定位難度本來(lái)就高。如果你連成本審計(jì)表都沒有出了問題只能靠猜。把這些基礎(chǔ)建設(shè)做好后面的運(yùn)維壓力會(huì)小非常多。我們團(tuán)隊(duì)目前已經(jīng)把這三個(gè)大坑對(duì)應(yīng)的方案固化成了標(biāo)準(zhǔn)部署流程新業(yè)務(wù)方接入MCP時(shí)會(huì)按照身份、預(yù)算、錯(cuò)誤處理三個(gè)維度走一套檢查清單確認(rèn)通過(guò)后才能拿到生產(chǎn)的接入權(quán)限。這套東西也同樣值得你們做一遍畢竟踩坑的最大價(jià)值就是讓后來(lái)的人不用再踩第二遍。