1. 從“為誰服務(wù)”的困惑談起最近和幾個做AI應(yīng)用的朋友聊天發(fā)現(xiàn)一個挺有意思的現(xiàn)象。大家熱火朝天地討論著各種Agent框架從LangChain、AutoGPT到LlamaIndex再到國內(nèi)外的各種新秀技術(shù)選型能聊一下午。但當(dāng)我問到一個更根本的問題“你們折騰的這套Infra基礎(chǔ)設(shè)施最終是為誰服務(wù)的是給老板看的PPT是技術(shù)團隊的玩具還是真正能讓終端用戶感知到價值的智能體” 現(xiàn)場往往會沉默幾秒。這不是一個技術(shù)問題而是一個產(chǎn)品與工程思維的原點問題。在Agent概念席卷而來的時代我們很容易陷入一種“技術(shù)軍備競賽”的幻覺忙著堆砌最炫的框架、接入最強的模型、設(shè)計最復(fù)雜的工作流卻忘了回頭看看這一切的基石——Infra究竟因何而建。你可能會說Infra不就是為Agent本身服務(wù)的嗎確保它穩(wěn)定、高效、可擴展地運行。這話沒錯但只說對了一半。這就像說汽車工廠是為生產(chǎn)線服務(wù)的而不是為最終買車的用戶服務(wù)的。一個只為“運行”而存在的Infra很容易變成一個昂貴、復(fù)雜且脆弱的技術(shù)堆棧它可能擁有漂亮的監(jiān)控面板和優(yōu)雅的微服務(wù)架構(gòu)但其上的Agent卻笨拙、低效無法解決真實場景下的問題。真正的挑戰(zhàn)在于我們需要構(gòu)建的是一種“用戶價值導(dǎo)向”的基礎(chǔ)設(shè)施。這意味著從設(shè)計的第一天起每一個技術(shù)決策——從模型選型、記憶設(shè)計到工具調(diào)用、狀態(tài)管理——都要不斷地追問這個設(shè)計是讓最終使用Agent的人可能是客服、分析師、普通消費者任務(wù)完成得更順暢還是僅僅讓我們開發(fā)者自己感覺更“高科技”舉個例子很多團隊在搭建Agent時會優(yōu)先追求“全能”給Agent裝備上搜索引擎、代碼解釋器、文檔分析等一大堆工具Skills認(rèn)為能力越多越強。這對應(yīng)的Infra就需要處理復(fù)雜的工具路由、權(quán)限校驗和沖突解決。但如果你的Agent核心場景只是幫用戶從內(nèi)部知識庫中精準(zhǔn)提取合同條款那么一個花哨的、支持上百種工具的Infra其大部分復(fù)雜性都成了負(fù)擔(dān)反而拖累了核心檢索鏈路的穩(wěn)定性和速度。你的Infra本質(zhì)上是在為你Agent的“核心價值主張”而建。偏離了這一點再精美的架構(gòu)也是空中樓閣。2. 拆解Agent Infra的四個核心服務(wù)對象要回答“為誰而建”我們必須先厘清Agent生態(tài)中的不同角色。一個典型的Agent系統(tǒng)至少涉及四方利益相關(guān)者你的Infra需要同時、但以不同優(yōu)先級滿足他們的需求。2.1 終極用戶體驗與效率的沉默裁判這是最容易被Infra團隊忽視卻又是最終的“買單者”。終端用戶不關(guān)心你用的是ReAct還是Plan-and-Execute范式也不關(guān)心你的向量數(shù)據(jù)庫是Pinecone還是Milvus。他們只關(guān)心三件事任務(wù)能不能完成完成得準(zhǔn)不準(zhǔn)過程快不快為“任務(wù)完成”而建Infra必須保證Agent的可用性與可靠性。這意味著需要健壯的錯誤處理機制。例如當(dāng)調(diào)用外部API失敗時Infra不能直接讓Agent崩潰或返回一個晦澀的技術(shù)錯誤而應(yīng)該設(shè)計降級策略。比如一個訂票Agent在調(diào)用航班接口失敗時Infra可以支撐Agent轉(zhuǎn)向回復(fù)“目前實時航班查詢暫時不可用但我可以根據(jù)歷史數(shù)據(jù)為您推薦幾個常見時段的選擇或者您可以直接告訴我您的偏好我為您生成一個備選方案” 這背后需要Infra提供可配置的失敗重試、備用工具鏈、優(yōu)雅的上下文回復(fù)模板等一系列支持。為“結(jié)果準(zhǔn)確”而建這直接指向Infra的“認(rèn)知”能力支撐。用戶無法忍受一個胡說八道的Agent。Infra需要通過精心設(shè)計的數(shù)據(jù)管道和驗證層來保障。例如檢索增強生成RAG的質(zhì)量你的向量檢索Infra是否支持多路召回、重排序是否考慮了查詢改寫、上下文窗口的智能截斷當(dāng)用戶問“上季度華東區(qū)銷售表現(xiàn)”Infra能否自動將查詢拆解為“財務(wù)數(shù)據(jù)”、“華東區(qū)”、“Q1 2024”等維度并從正確的數(shù)據(jù)源中檢索工具調(diào)用的精確性當(dāng)Agent需要執(zhí)行“發(fā)送郵件給項目組核心成員”時Infra提供的工具調(diào)用層是否能準(zhǔn)確解析出“項目組”對應(yīng)的郵件列表并處理好收件人權(quán)限這需要Infra集成身份系統(tǒng)、提供清晰的功能描述Tool Description給LLM并設(shè)計嚴(yán)格的參數(shù)驗證與執(zhí)行確認(rèn)流程。為“過程快速”而建延遲是體驗殺手。一個需要思考10秒才能回復(fù)下一句的對話Agent幾乎不可用。Infra必須在性能上做深度優(yōu)化流式響應(yīng)這是基礎(chǔ)要求。Infra需要支持將LLM生成的內(nèi)容以流Stream的形式實時推送給前端讓用戶看到Agent“思考”的過程心理等待時間會大大縮短。異步與并行如果Agent需要同時查詢天氣、日歷和交通信息Infra是否支持并行調(diào)用這些工具還是傻傻地串行執(zhí)行一個支持有向無環(huán)圖DAG的任務(wù)編排引擎能顯著降低端到端延遲。緩存策略對于頻繁且結(jié)果不變的查詢?nèi)纭肮镜哪昙僬呤鞘裁础盜nfra應(yīng)在LLM調(diào)用層和工具調(diào)用層設(shè)計多層緩存避免重復(fù)計算和網(wǎng)絡(luò)請求。為終端用戶服務(wù)的Infra其成功標(biāo)準(zhǔn)是“無感”。當(dāng)用戶覺得事情自然、順暢地辦成了你的Infra就做到了最好。2.2 Agent開發(fā)者生產(chǎn)力與靈活性的天平開發(fā)者是Infra的直接使用者。他們的核心訴求是用盡可能少的代碼、盡可能快的方式構(gòu)建出強大且可靠的Agent。Infra對他們而言應(yīng)該是一個“能力增強平臺”而非“約束框架”。為“降低認(rèn)知負(fù)擔(dān)”而建優(yōu)秀的Infra應(yīng)該封裝復(fù)雜性。例如提供一個統(tǒng)一的AgentSession類內(nèi)部自動處理對話歷史的管理、token的計數(shù)與截斷、上下文窗口的滑動。開發(fā)者只需session.add_message(“user”, “你好”)而不需要自己維護一個列表并時刻擔(dān)心超出模型限制。為“快速集成與調(diào)試”而建工具Skill的熱插拔Infra應(yīng)提供標(biāo)準(zhǔn)的工具定義、注冊和發(fā)現(xiàn)機制。開發(fā)者想新增一個“生成圖表”的技能應(yīng)該只需要寫一個符合接口的函數(shù)并用裝飾器注冊即可無需修改核心調(diào)度邏輯。可視化的調(diào)試與追蹤這是目前很多開源框架的短板。一個強大的Infra應(yīng)該提供像“LangSmith”那樣的可觀測性平臺讓開發(fā)者能清晰地看到一次Agent調(diào)用中LLM收到了什么提示詞每一步的思考Chain-of-Thought是什么調(diào)用了哪個工具輸入輸出為何耗時多少這能極大降低調(diào)試成本。你的Infra至少應(yīng)該能輸出結(jié)構(gòu)化的日志并易于接入APM系統(tǒng)。提示詞Prompt管理將硬編碼在代碼中的提示詞抽離出來通過Infra提供版本化、環(huán)境化的管理。開發(fā)者可以方便地A/B測試不同版本的提示詞對Agent效果的影響。為“靈活的策略配置”而建不同的Agent需要不同的“性格”和策略。Infra應(yīng)該提供配置化的策略選擇。例如推理策略是讓LLM一步步思考ReAct還是先規(guī)劃再執(zhí)行Plan-and-Execute記憶策略是只用短期對話記憶還是結(jié)合向量數(shù)據(jù)庫的長期記憶記憶的摘要和提取方式如何回退策略當(dāng)主要模型如GPT-4調(diào)用失敗或超時是否自動降級到備用模型如Claude或本地模型為開發(fā)者服務(wù)的Infra其成功標(biāo)準(zhǔn)是“愉悅”。開發(fā)者覺得順手、高效、可控他們才愿意在此基礎(chǔ)上進行深度創(chuàng)新。2.3 運營與業(yè)務(wù)方可度量、可運營、可迭代Agent上線不是終點而是起點。業(yè)務(wù)方需要知道Agent的效果和成本運營團隊需要持續(xù)優(yōu)化它。Infra必須為“運營”而生。為“可度量”而建Infra需要內(nèi)置一套核心指標(biāo)Metrics采集體系。這不僅僅是技術(shù)指標(biāo)如QPS、延遲、錯誤率更重要的是業(yè)務(wù)指標(biāo)任務(wù)完成率用戶意圖被成功解決的比例。這可能需要設(shè)計一些端到端的評估流程或依賴用戶反饋如點贊/點踩。對話輪次平均完成一個任務(wù)需要多少輪對話輪次減少通常意味著Agent效率提升。工具調(diào)用準(zhǔn)確率Agent發(fā)起的工具調(diào)用中參數(shù)正確、執(zhí)行成功的比例。成本每次對話消耗的Token數(shù)、調(diào)用的外部API費用。Infra需要能按會話、按用戶、按時間段進行成本歸因。為“可干預(yù)”而建再聰明的Agent也會出錯或遇到新情況。Infra需要提供“人工介入”的通道。例如人工接管Human-in-the-loop當(dāng)Agent置信度低于某個閾值或觸發(fā)了某些關(guān)鍵操作如確認(rèn)支付時Infra應(yīng)能無縫將對話轉(zhuǎn)接給人工客服并將之前的上下文完整傳遞。知識庫快速更新當(dāng)業(yè)務(wù)規(guī)則變化時運營人員能否通過一個管理后臺直接上傳新的文檔或QA對而無需等待開發(fā)發(fā)版這要求Infra的RAG模塊支持實時或近實時的索引更新。為“可迭代”而建Infra應(yīng)支持A/B測試和灰度發(fā)布。你可以讓10%的用戶使用新版本的提示詞或新集成的工具對比其與老版本在核心指標(biāo)上的差異。數(shù)據(jù)驅(qū)動迭代是Agent進化的唯一路徑。為運營服務(wù)的Infra其成功標(biāo)準(zhǔn)是“透明”。所有過程和結(jié)果都應(yīng)是可觀測、可分析、可操作的。2.4 系統(tǒng)自身穩(wěn)定、安全與成本最后Infra必須為自己而建——確保自身的可持續(xù)性。這是一個經(jīng)典的“非功能性需求”領(lǐng)域卻決定了Agent系統(tǒng)能走多遠(yuǎn)。為“穩(wěn)定”而建高可用架構(gòu)、容錯設(shè)計、限流熔斷、災(zāi)難恢復(fù)預(yù)案。特別是對于重度依賴外部LLM API和各類第三方工具的場景必須假設(shè)它們是不可靠的。Infra需要有服務(wù)降級、請求重試、故障隔離的能力。為“安全”而建這是紅線尤其在企業(yè)級場景。數(shù)據(jù)泄露確保用戶對話數(shù)據(jù)、通過Agent查詢的內(nèi)部文檔不會被泄露給LLM服務(wù)商或第三方工具。這可能意味著需要對出境數(shù)據(jù)進行清洗或使用本地化模型。提示詞注入Prompt InjectionInfra需要在Agent調(diào)用LLM前對用戶輸入進行必要的清洗和檢測防止用戶輸入惡意指令劫持Agent行為。工具濫用嚴(yán)格控制Agent的工具調(diào)用權(quán)限。一個內(nèi)部數(shù)據(jù)分析Agent絕不能擁有刪除數(shù)據(jù)庫或發(fā)送全員郵件的權(quán)限。Infra需要實現(xiàn)細(xì)粒度的工具權(quán)限管控。為“成本”而建LLM API調(diào)用是核心成本。Infra需要實施精細(xì)化的成本控制緩存對常見、結(jié)果確定的查詢進行緩存。模型路由根據(jù)查詢的復(fù)雜度智能路由到不同成本的模型。簡單問答用便宜的gpt-3.5-turbo復(fù)雜推理再用gpt-4。Token優(yōu)化自動精簡上下文、對歷史對話進行智能摘要以減少不必要的Token消耗。為系統(tǒng)自身服務(wù)的Infra其成功標(biāo)準(zhǔn)是“堅如磐石”。它默默無聞但一旦出現(xiàn)問題便是全局性的災(zāi)難。3. 構(gòu)建價值導(dǎo)向型Agent Infra的實踐路徑理解了為誰而建接下來就是如何建。這不是一蹴而就的而是一個從核心到外圍、持續(xù)演進的旅程。3.1 第一步定義最小價值單元MVU從“單點極致”開始不要一開始就夢想構(gòu)建一個支持所有Agent類型的通用平臺。你的第一個目標(biāo)應(yīng)該是圍繞一個最核心、最明確的用戶場景打造一個體驗極致的單一Agent并為其構(gòu)建剛剛好夠用的Infra。如何找到MVU問幾個問題當(dāng)前業(yè)務(wù)中哪個重復(fù)、規(guī)則清晰、但耗時的手工任務(wù)最多哪個崗位的員工最需要“智能助理”例如可能是“幫銷售快速從CRM和產(chǎn)品手冊中提取信息生成客戶方案草稿”或者是“幫客服自動總結(jié)通話記錄并填寫工單”。Infra的對應(yīng)形態(tài)這個階段的Infra可以極其簡單。它可能就是一個腳本集成了LangChain等框架連接了1-2個必要的工具如內(nèi)部知識庫檢索、文檔生成并部署在一個簡單的云函數(shù)上。它的核心使命是驗證Agent在這個場景下的價值假設(shè)用戶是否愿意用效率是否真提升。此時Infra不需要考慮多租戶、高并發(fā)、復(fù)雜的可觀測性它的架構(gòu)應(yīng)該是輕量、快速迭代的。3.2 第二步抽象公共能力形成“Infra內(nèi)核”當(dāng)你的第一個Agent被驗證成功并開始計劃第二個、第三個時重復(fù)造輪子就變得低效。這時你需要從已有的實踐中抽象出所有Agent都需要的公共能力形成“Infra內(nèi)核”。典型的內(nèi)核能力包括對話管理統(tǒng)一的會話Session抽象處理歷史消息、Token計數(shù)與截斷。工具框架統(tǒng)一的工具定義、注冊、發(fā)現(xiàn)和調(diào)用接口。確保新工具可以像插件一樣輕松接入。模型抽象層統(tǒng)一調(diào)用不同LLMOpenAI、Anthropic、本地模型的接口方便切換和降級。基礎(chǔ)記憶提供短期會話記憶和基于向量數(shù)據(jù)庫的長期記憶基礎(chǔ)接口。核心編排引擎一個輕量級的、決定Agent下一步該“思考”還是“行動”的調(diào)度器。關(guān)鍵設(shè)計原則內(nèi)核要保持精簡和穩(wěn)定。它只提供最基礎(chǔ)的、原子化的能力不包含具體的業(yè)務(wù)邏輯。它應(yīng)該是Agent框架的“操作系統(tǒng)”。3.3 第三步圍繞場景擴展發(fā)展“垂直解決方案”有了穩(wěn)定的內(nèi)核你就可以像搭積木一樣為不同的垂直場景快速構(gòu)建Agent。這時Infra的角色從“提供基礎(chǔ)能力”轉(zhuǎn)變?yōu)椤疤峁﹫鼍盎鉀Q方案”。例如對于“客服助手”場景你需要擴展的Infra能力可能包括情感分析模塊在對話過程中實時分析用戶情緒觸發(fā)安撫話術(shù)或升級流程。工單自動創(chuàng)建與填充與工單系統(tǒng)如Jira、Zendesk深度集成的工具套件。多輪對話狀態(tài)跟蹤專門用于處理復(fù)雜投訴或咨詢流程的狀態(tài)機。合規(guī)性檢查確保Agent的回復(fù)符合行業(yè)監(jiān)管要求如金融、醫(yī)療。對于“數(shù)據(jù)分析助手”場景則需要SQL生成與安全執(zhí)行將自然語言轉(zhuǎn)換為安全、高效的數(shù)據(jù)庫查詢并在沙箱中執(zhí)行。圖表生成引擎根據(jù)數(shù)據(jù)結(jié)果自動選擇合適的圖表類型并生成。數(shù)據(jù)血緣與權(quán)限集成公司的數(shù)據(jù)權(quán)限系統(tǒng)確保Agent只能訪問用戶被授權(quán)查看的數(shù)據(jù)。這些垂直解決方案可以構(gòu)建在內(nèi)核之上作為可選的“增強模塊”或“模板”存在。它們極大地降低了特定領(lǐng)域Agent的開發(fā)門檻。3.4 第四步打造運營與治理平臺實現(xiàn)“規(guī)模化管理”當(dāng)你有成百上千個Agent在生產(chǎn)環(huán)境運行時一個強大的運營平臺就不可或缺了。這是Infra演化的高級階段專注于規(guī)模化和可持續(xù)性。核心平臺能力Agent生命周期管理從創(chuàng)建、配置、測試、部署、版本管理到下線提供全流程可視化支持。集中監(jiān)控與告警聚合所有Agent的技術(shù)與業(yè)務(wù)指標(biāo)設(shè)置智能告警規(guī)則。成本分析與優(yōu)化中心全局視角分析LLM和工具調(diào)用成本找出“成本大戶”并提供優(yōu)化建議。知識庫統(tǒng)一管理對所有RAG使用的知識文檔進行集中存儲、版本更新和效果評估。安全與合規(guī)中心集中管理提示詞安全策略、數(shù)據(jù)過濾規(guī)則、工具訪問權(quán)限審計等。這個平臺使得Infra從一個技術(shù)組件轉(zhuǎn)變?yōu)橐粋€真正的產(chǎn)品服務(wù)于整個組織的AI能力建設(shè)。4. 關(guān)鍵決策點技術(shù)選型中的價值權(quán)衡在構(gòu)建Infra的每一步你都會面臨技術(shù)選型。記住沒有最好的技術(shù)只有最適合你當(dāng)前“服務(wù)對象”和階段的技術(shù)。4.1 模型層云端大模型 vs. 本地私有模型這是最重要的決策之一直接關(guān)乎成本、性能、安全和能力。選擇云端大模型如GPT-4、Claude為誰服務(wù)主要服務(wù)于追求極致Agent能力和開發(fā)速度的團隊。它們的推理能力強能處理復(fù)雜任務(wù)且無需維護模型基礎(chǔ)設(shè)施。Infra考量你的Infra需要重點建設(shè)API調(diào)用管理限流、重試、降級、成本監(jiān)控、數(shù)據(jù)安全過濾防止敏感信息出境和提示詞工程體系。何時選MVP驗證階段、對效果要求極高的C端產(chǎn)品、處理非敏感數(shù)據(jù)且預(yù)算充足的場景。選擇本地私有模型如Llama、Qwen、DeepSeek為誰服務(wù)主要服務(wù)于對數(shù)據(jù)安全和長期成本控制有嚴(yán)苛要求的企業(yè)級場景以及需要高度定制化模型行為的場景。Infra考量你的Infra復(fù)雜度陡增。需要構(gòu)建完整的模型部署、服務(wù)化、監(jiān)控、版本更新流水線。需要深入硬件資源管理GPU調(diào)度。需要在提示詞工程和RAG上投入更多以彌補模型本身能力的不足。何時選金融、政務(wù)、醫(yī)療等強監(jiān)管行業(yè)對話數(shù)據(jù)高度敏感長期調(diào)用量巨大TCO總擁有成本模型算下來更劃算。混合架構(gòu)這往往是成熟企業(yè)的最終選擇。Infra需要實現(xiàn)智能的模型路由簡單任務(wù)走本地小模型復(fù)雜任務(wù)走云端大模型實時性要求高的走云端涉密查詢走本地。這要求Infra有一個強大的模型網(wǎng)關(guān)和統(tǒng)一的API抽象。4.2 記憶與狀態(tài)短期會話 vs. 長期個性化Agent的記憶能力決定了它的連續(xù)性和個性化水平。短期會話記憶上下文窗口為誰服務(wù)所有Agent的基礎(chǔ)。服務(wù)于單次對話的連貫性。Infra實現(xiàn)相對簡單管理好Token計數(shù)和滑動窗口即可。但需要警惕成本過長的上下文意味著高昂的API費用。長期記憶向量數(shù)據(jù)庫摘要為誰服務(wù)需要記住用戶偏好、歷史交互的個性化Agent如個人學(xué)習(xí)伴侶、智能健身教練。Infra實現(xiàn)復(fù)雜。需要設(shè)計記憶的存儲、索引、檢索和更新機制。關(guān)鍵決策點包括存儲什么是存儲原始對話還是存儲LLM生成的摘要摘要會丟失細(xì)節(jié)但節(jié)省空間和檢索成本。如何檢索當(dāng)用戶說“繼續(xù)我們上次聊的讀書計劃”如何從長期記憶中精準(zhǔn)找到相關(guān)片段這需要好的元數(shù)據(jù) tagging 和檢索策略。如何更新與遺忘記憶不是只增不減的。陳舊的、錯誤的信息需要被清理或覆蓋。Infra需要設(shè)計記憶的“衰減”或“刷新”機制。我的經(jīng)驗不要一開始就過度設(shè)計長期記憶。先從基于會話的短期記憶開始當(dāng)明確驗證了“記住用戶”能帶來顯著體驗提升后再逐步引入長期記憶模塊。初期可以用簡單的鍵值對存儲用戶的基本偏好這比上馬一個完整的向量記憶系統(tǒng)要務(wù)實得多。4.3 工具Skills框架統(tǒng)一網(wǎng)關(guān) vs. 去中心化調(diào)用Agent需要通過工具與外部世界交互。如何管理這些工具統(tǒng)一工具網(wǎng)關(guān)集中式模式所有工具調(diào)用都先經(jīng)過一個中心化的網(wǎng)關(guān)服務(wù)。網(wǎng)關(guān)負(fù)責(zé)鑒權(quán)、路由、參數(shù)校驗、格式轉(zhuǎn)換、監(jiān)控和熔斷。為誰服務(wù)服務(wù)于對安全、管控、可觀測性要求極高的企業(yè)環(huán)境。網(wǎng)關(guān)成為安全的咽喉要道。優(yōu)點管控力強易于實施統(tǒng)一的安全策略和審計日志。缺點容易成為性能瓶頸和單點故障增加了調(diào)用鏈路的復(fù)雜性。去中心化直接調(diào)用模式Agent或其所運行的環(huán)境直接持有調(diào)用工具的憑據(jù)通過SDK或API直接調(diào)用。為誰服務(wù)服務(wù)于追求高性能、低延遲、高靈活性的團隊或者工具本身非常輕量、安全的場景。優(yōu)點鏈路短性能好架構(gòu)簡單。缺點安全憑據(jù)分散難以統(tǒng)一管控工具本身的故障可能直接影響Agent。折中實踐我傾向于一種“注冊制”的輕量級網(wǎng)關(guān)。Infra提供一個工具注冊中心Agent從這里發(fā)現(xiàn)可用的工具及其訪問端點、Schema和權(quán)限要求。實際的調(diào)用可以是直接的但調(diào)用前后需要向Infra發(fā)送審計事件。這樣既保證了靈活性和性能又滿足了基本的可觀測性和安全審計需求。5. 避坑指南那些我趟過的“河”最后分享幾個在構(gòu)建Agent Infra過程中容易踩坑的地方這些坑往往源于忘記了“為誰而建”。坑一過度追求架構(gòu)“美感”忽視迭代速度。早期花三個月設(shè)計一個完美無缺、支持一切擴展的插件化架構(gòu)不如用三周時間先讓第一個Agent跑起來并拿到用戶反饋。Infra應(yīng)該與業(yè)務(wù)Agent共同演進而不是提前過度設(shè)計。坑二將LLM的“不穩(wěn)定”視為異常而非常態(tài)。LLM的生成具有隨機性API可能超時或限流。你的Infra必須假設(shè)LLM是不可靠的組件。重試、降級如切換到備用模型、返回更保守的答案、設(shè)置合理的超時和斷路器這些不是可選項而是必選項。在一次關(guān)鍵演示中因為依賴的LLM API突發(fā)抖動又沒做降級處理導(dǎo)致整個Agent服務(wù)癱瘓這個教訓(xùn)讓我銘記于心。坑三忽略了“人機回環(huán)”的入口設(shè)計。再智能的Agent也有無法處理的情況。Infra必須在一開始就設(shè)計好人工接管的接口。這個接口不僅僅是技術(shù)上的更是流程和產(chǎn)品上的。例如在對話界面提供一個醒目的“轉(zhuǎn)人工”按鈕并確保上下文能完整移交。否則當(dāng)Agent犯錯時用戶會陷入無助體驗徹底崩壞。坑四成本失控。沒有設(shè)置預(yù)算告警和用量監(jiān)控直到收到天價賬單才追悔莫及。Infra需要從第一天就集成成本監(jiān)控并設(shè)置不同層級的告警如每日預(yù)算的50%、80%、100%。同時通過緩存、模型路由、優(yōu)化提示詞等手段主動控制成本。坑五把Infra當(dāng)成一個純后端工程問題。實際上Agent Infra與用戶體驗前端緊密耦合。流式響應(yīng)、客戶端狀態(tài)管理、中斷處理等都需要前后端協(xié)同設(shè)計。Infra團隊必須與前端/產(chǎn)品團隊緊密合作定義好通信協(xié)議如SSE、WebSocket和數(shù)據(jù)格式才能打造流暢的端到端體驗。構(gòu)建Agent Infra是一場馬拉松而不是百米沖刺。它的目標(biāo)不是技術(shù)的堆砌而是價值的傳遞。在每一個技術(shù)決策面前多問一句“這個改動最終是讓我的終端用戶、開發(fā)者、運營同事還是系統(tǒng)自身受益受益有多大” 以終為始你的Infra才能真正成為Agent時代堅實而智慧的基石。