最近在做AI應用架構設計評審時我發(fā)現(xiàn)一個特別普遍的現(xiàn)象很多團隊把大模型應用想得過于簡單覺得只要封裝一個API、把Prompt拼好、把返回結果丟給前端就算做完了?？梢坏┯脩袅可蟻砘蛘邩I(yè)務需要接入多個模型、引入Agent編排、處理長對話記憶原本一個接口一把梭的代碼就會變成一團亂麻。真正成熟的AI應用從來不是調用大模型這一個動作而是從入口到數(shù)據再到模型之間的一系列架構決策。這篇文章我想用畫圖的思路帶你把AI應用架構設計拆開揉碎。會先講清楚AI應用到底在架構什么再逐個分析模型網關、向量庫、Agent編排這些核心組件接著聊并發(fā)流量怎么扛上下文工程怎么做最后從單Agent走向多Agent協(xié)作時架構會發(fā)生什么變化。無論你是剛開始做AI應用開發(fā)還是正在負責技術選型這篇都能給到你一份可以直接落地的參考框架。1. 從調API到建架構AI應用到底在架構什么1.1 一次最簡單的調用背后藏著哪些模塊我們先看一個最樸素的大模型聊天機器人。用戶在網頁里敲了一句幫我總結這份合同前端把這句話發(fā)給后端后端往大模型API里一丟模型返回總結頁面渲染出來。就這么一個流程看起來五步搞定但真正到了生產環(huán)境你至少還需要考慮這五件事之外的十幾個隱藏模塊。我在剛入行時踩過一個坑第一個AI應用上線后服務端突然收到一堆重復請求因為前端做了重試后端又沒有做冪等結果同一條用戶消息被模型處理了兩遍用戶收到了兩條重復回復。這就是典型的架構缺失——沒有請求去重沒有超時控制。一個完整的AI應用調用鏈路在業(yè)務邏輯之前應該先有API網關、身份認證、限流、審計日志、內容安全審核、Prompt模板管理在業(yè)務邏輯之后還要有結果緩存、成本統(tǒng)計、可觀測性埋點。如果你把這條鏈路畫成一張時序圖會發(fā)現(xiàn)用戶和模型之間隔著一大堆中間層。這些中間層不是可有可無的裝飾而是讓AI應用具備生產可用性的骨架。早期很多團隊直接讓前端調模型API省事是省事但密鑰會暴露成本失控模型一限流整個系統(tǒng)全掛。所以架構的第一步就是把這些看不見的模塊顯式化。1.2 用一張圖拆開AI應用的四層結構我平時習慣把AI應用架構畫成四層自上而下分別是接入層、編排層、模型層、數(shù)據層。下面用表格列出每層的職責和典型組件層級核心職責典型組件/技術接入層對外暴露接口處理認證、限流、安全、協(xié)議轉換API Gateway、Nginx、Auth Service編排層組裝Prompt、決定調用順序、管理Agent循環(huán)、處理工具調用LangGraph、CrewAI、自研Orchestrator模型層對接一個或多個大模型控制路由、降級、緩存OpenAI兼容網關、vLLM、TensorRT-LLM數(shù)據層提供外部記憶、檢索增強、業(yè)務數(shù)據庫訪問向量庫、Redis、PostgreSQL、對象存儲為什么要分成四層核心目的是隔離變化。模型層是最容易變的地方你可能今天用A模型明天因為成本換成B模型如果業(yè)務代碼里到處是from openai import OpenAI換模型就成了一場災難。有了模型網關上層只面對一個統(tǒng)一接口模型怎么換是下面的事。數(shù)據層也一樣今天用向量庫做RAG明天想換成圖數(shù)據庫增強關系推理只要編排層通過數(shù)據服務接口訪問底層替換就不會炸到業(yè)務邏輯。畫完這張圖你還能直觀看出每一層之間的接口定義。比如編排層和模型層之間到底傳遞的是純文本還是結構化的消息數(shù)組數(shù)據層返回的檢索片段是直接塞進Prompt還是先經過一個重排模塊這些問題都屬于架構設計的核心決策圖一畫出來哪里模糊哪里缺接口一目了然。2. 核心組件選型模型網關、向量庫和Agent編排2.1 為什么不能繞過模型網關很多中小項目一開始只接一家模型廠商覺得模型網關是過度設計。我的看法恰恰相反模型網關不是可有可無的中間層而是AI應用架構里的斷路器。它至少承擔四件關鍵事統(tǒng)一接口、密鑰托管、負載均衡和質量開關。統(tǒng)一接口很好理解無論你接的是字節(jié)的模型還是阿里的網關都把它包裝成一個標準的Completion接口業(yè)務側不感知廠商差異。密鑰托管則解決安全問題直接在前端調用模型接口最大的風險是密鑰泄漏網關把密鑰鎖在后端前端只跟網關打交道。負載均衡更實在同一個模型請求可以按權重打到不同廠商的同級別模型上或者按用戶維度做路由。我印象最深的一個案例是某家做客服助手的團隊把模型網關配成了主備模式主用旗艦模型當旗艦模型因限流返回429時網關自動把請求降級到備用的成本更低的模型。結果某天晚高峰主模型排隊嚴重他們的系統(tǒng)靠著網關自動降級硬是撐住了兩個小時的流量高峰業(yè)務成功率只下降了不到3%。沒有網關這種容災幾乎不可能一個接口全局實現(xiàn)。2.2 向量數(shù)據庫不是可選項取決于場景AI應用一定要上RAGRAG一定要上向量庫這是我在社區(qū)里聽到最多的錯誤直覺。實際上向量庫是否必要取決于你的應用是否需要語義相似度檢索這種能力。如果你的AI應用只是做純生成、總結、翻譯不依賴私有知識庫那引入一個獨立的向量數(shù)據庫大概率是給自己找運維負擔。但一旦你遇到這些場景——讓AI基于企業(yè)內部文檔回答、讓AI從幾千條聊天記錄里找到相似問題、給用戶做語義搜索——向量庫就是不可繞過的組件。選型時我習慣先把需求摁到兩種類型里嵌入式向量索引比如FAISS適合單機數(shù)據量小、離線索引可接受、不需要復雜過濾的場景。優(yōu)點是部署簡單丟進應用進程里就能跑缺點是數(shù)據量上來后內存壓力大多副本同步也麻煩。獨立向量數(shù)據庫比如Milvus、Qdrant、pgvector適合數(shù)據量大、需要實時寫入、需要按業(yè)務字段過濾、需要高并發(fā)查詢的場景。好處是彈性擴展、帶持久化和權限控制缺點是代價是一個額外的分布式系統(tǒng)需要監(jiān)控運維。我曾經在一個項目里先用了FAISS后來業(yè)務要按用戶ID過濾結果還要支持每天百萬級記錄更新FAISS單機內存完全扛不住才不得不遷到獨立向量庫。如果前期就畫清楚數(shù)據流的圖這個返工完全可以避免。數(shù)據量、過濾條件、更新頻率三大要素決定了向量庫選型的走向。2.3 Agent編排決定應用具備多少自主性Agent是當前AI應用架構里熱度最高的詞但很多團隊把Agent等同于多輪對話。真正的Agent編排核心是讓模型在一個循環(huán)里自主決定下一步動作當前輸入要不要調用工具調用哪個工具需要什么樣的參數(shù)如果工具返回異常是不是該換一條路徑重試把這個循環(huán)畫出來就是經典的ReAct模式模型觀察用戶請求結合當前狀態(tài)推理決定采取動作執(zhí)行工具工具返回結果模型再觀察直到得出最終答案。這個循環(huán)必須由編排層控制而不是讓模型自己無止境地跑下去。所以編排層至少要維護兩個東西一個是狀態(tài)記錄當前Agent走到了哪一步、已經收集了哪些信息另一個是路由表定義什么條件下該用哪個工具、什么條件下該結束循環(huán)。市面上LenangGraph、CrewAI這些框架本質上都是幫你管理節(jié)點、狀態(tài)和路由的。但我的經驗是框架可以解決80%的通用編排問題剩下的20%比如工具返回異常后的重試策略、Agent步驟的持久化、超時后的降級應答往往還是要自研。架構設計時不能只畫一個Agent框就完事要把這個框內部的狀態(tài)機畫出來才能準確評估復雜度和風險。3. 架構中的流量與并發(fā)Agent怎么扛住真實壓力3.1 請求鏈路中的每個環(huán)節(jié)都可能成為瓶頸在大模型應用里一個用戶請求往往不只是調用一次模型。尤其Agent場景可能先做一次意圖識別然后檢索向量庫再調用一次外部工具最后再讓模型匯總答案。整條鏈路下來可能觸發(fā)三到五次模型調用。這意味著你看到的在線用戶數(shù)和背后模型API的實際調用量中間可能隔著好幾倍的系數(shù)。我自己畫鏈路圖時會給每個節(jié)點標注它可能出現(xiàn)的瓶頸。用戶一多最先扛不住的往往不是模型API而是前面這些看似輕量的環(huán)節(jié)環(huán)節(jié)可能瓶頸常用應對手段API網關連接數(shù)上限、限流誤傷水平擴容、按用戶/按IP分級限流會話存儲Redis連接/內存瓶頸集群化、冷熱分層Prompt組裝模板渲染耗時緩存編譯后的模板模型調用API限流、排隊延遲并發(fā)池、隊列削峰、多路降級熱點數(shù)據緩存緩存失效擊穿本地緩存分布式鎖外部工具第三方API限流熔斷、退避重試這些瓶頸不是等線上報警了才去加而是在畫架構圖時就要標出來。我習慣在每條鏈路旁邊寫一行假設模型響應3秒Agent最多調用5次則用戶最長體驗是15秒如果這個數(shù)字超過產品預期就要考慮并行調用工具、提前預取檢索結果甚至改異步交互模式。3.2 狀態(tài)管理無狀態(tài)化與外部化會話Agent應用最容易被忽視的架構問題就是狀態(tài)放哪。如果你把對話歷史、Agent的中間思考、工具調用結果都放在服務進程的內存里那么一旦服務實例重啟、擴容或縮容用戶會話就全丟了。更要命的是負載均衡很難做——同一用戶的請求必須一直打回同一個實例。解決辦法是讓服務無狀態(tài)把狀態(tài)全部外部化。最常見的手段是用Redis存會話狀態(tài)鍵通常是session:{userId}值是一個對象包含消息列表、Agent當前階段、已調用工具的結果、剩余步數(shù)等。每次請求進來編排層從Redis讀取狀態(tài)執(zhí)行完一步再把新的狀態(tài)寫回去。這里的細節(jié)是狀態(tài)粒度。粒度太粗整個對話歷史塞成一個對象更新頻繁時Redis網絡開銷很大粒度太細每次要串行讀好幾份Key反而變慢。我的經驗是把高頻變化的部分比如當前step、pending tool call和低頻變化的部分比如消息列表分開存或者用Hash結構一個Key下多個Field按需更新。架構圖上要明確標出狀態(tài)讀寫路徑和狀態(tài)失效策略不然代碼寫著寫著就會變成內存緩存和Redis之間互相打架。3.3 隊列與批處理從同步到異步的取舍并非所有AI應用請求都必須實時同步返回。如果你讓用戶在一個界面里等待Agent跑完五輪工具調用體驗大概率是崩潰的。架構上一個經典解法是引入任務隊列把重計算和輕響應分離開。可以這樣想象同步鏈路只負責接收用戶請求、創(chuàng)建任務、立刻返回一個任務ID然后由后臺Worker異步處理Agent循環(huán)處理完成后通過WebSocket或輪詢通知前端。這種模式特別適合分析報告生成、批量文檔審核、自動化工作流這類耗時任務。但在做異步化之前要分清場景。用戶和機器人聊天這種強交互場景異步會破壞對話連續(xù)性但如果任務本身就要跑幾十秒異步幾乎是唯一選擇。我的取舍原則是預期耗時大于5秒就考慮異步化大于30秒必須異步化需要用戶等待且可能排隊就上隊列加優(yōu)先級。畫架構圖時我會在接入層和編排層之間加一個任務分發(fā)器再在編排層旁邊畫一個結果存儲這就是異步化的標準畫法。3.4 彈性伸縮模型推理的并發(fā)控制即便你做好了網關和隊列模型本身的并發(fā)能力仍然是致命的約束。大模型推理不像普通HTTP接口它有時間很長的占用過程GPU顯存和算力有限并發(fā)一旦超過閾值排隊時間指數(shù)上升最終表現(xiàn)為整體服務的P99延遲變得不可接受。這里有三個詞大家容易混淆并發(fā)請求數(shù)、吞吐量和響應時間。模型服務能承載的并發(fā)是有限的假設它每秒鐘能完整推理4個請求平均耗時2秒并不意味著同時并發(fā)8個請求也沒問題——因為模型推理是分批的超出的請求會在隊列里等待可能從2秒飆到4秒。所以在接入層和模型網關之間一定要有一層并發(fā)控制用信號量限制同時發(fā)給模型服務的請求數(shù)寧可讓請求在隊列里等也不要把后端打爆。如果你自建模型服務還可以用連續(xù)批處理continuous batching和動態(tài)批大小來提高吞吐。如果是調用外部API沒有這個控制權就只能在網關層做請求合并、多級緩存和主動退避。架構圖上要給并發(fā)控制器一個獨立的位置并寫明最大并發(fā)數(shù)和隊列長度這些參數(shù)必須經過壓測不能拍腦袋。4. 數(shù)據流與上下文工程喂給模型的內容決定天花板4.1 上下文窗口是硬約束架構要為它服務大模型的能力邊界和上下文窗口強相關。哪怕最新的模型支持超長上下文你也不可能把整個業(yè)務數(shù)據庫都塞進一次請求里。上下文就是AI應用架構中的數(shù)據總線什么數(shù)據能進入Prompt以什么順序進入如何控制token預算直接決定了模型輸出的質量。在架構設計時我需要一個專門的上下文組裝器模塊。它負責三件事從外部存儲取回會話歷史通過RAG檢索取回相關知識片段把當前用戶意圖和候選工具定義拼裝成最終發(fā)送給模型的Prompt。這個模塊要能動態(tài)裁剪比如歷史太長時自動保留最近的幾輪再加一個壓縮后的摘要知識片段太多時按相關性排序后只取Top K。很多人忽略的一點是上下文組裝器是純邏輯模塊但它必須緩存。模型調用結果、檢索結果、Prompt模板的編譯結果都可以緩存避免同一份數(shù)據反復去做向量檢索也避免重復調用模型。畫架構圖時我會把上下文組裝器畫在編排層和模型層之間并在它內部標注輸入過濾器和輸出解析器兩個子模塊一個防止臟數(shù)據進Prompt一個防止非JSON結果崩掉業(yè)務解析。4.2 RAG檢索增強從參數(shù)記憶到外部記憶大模型本身就像一個壓縮過的記憶體參數(shù)里存了海量知識但它是靜態(tài)的不知道你最新的產品文檔、客戶溝通記錄和內部政策。RAG檢索增強生成就是用外部數(shù)據源給模型補充臨時記憶讓它在回答時能基于最新資料。RAG架構畫出來并不復雜離線環(huán)節(jié)把文檔切塊、向量化、寫入向量庫在線環(huán)節(jié)把用戶問題轉成向量去向量庫召回相關片段再拼進Prompt。但真正考架構經驗的是細節(jié)。文檔切分chunk尤其折磨人切太碎語義不完整切太大召回噪音高。切好后還要做清洗、去重、權限過濾否則模型可能把不該透露的內部信息回答給用戶。我建議在數(shù)據層里增加一個文檔處理管道它不是一個簡單的腳本而是一個可重放、可追蹤的任務隊列。原始文檔進來經過去重、切分、向量化、寫庫每一步都要記錄狀態(tài)這樣文檔重復上傳也能增量更新。檢索端也不要只用一個向量相似度可以加上關鍵詞權重、業(yè)務過濾條件、時間排序甚至再接一個重排模型做二次精排。這些都叫架構不只是調一個向量庫的API。4.3 上下文管理策略截斷、壓縮與摘要記憶長對話是AI應用最常見的場景但聊著聊著歷史越長成本越高響應也越慢模型還可能被遙遠的早期信息干擾。架構上最常見的三種策略是截斷、壓縮和摘要記憶。截斷最簡單保留最近N輪對話超過的部分直接丟棄。代價是模型可能忘掉開頭用戶說過的關鍵需求。壓縮是讓模型把舊對話改寫成更精簡的表達保留關鍵信息的同時降低token占用。摘要記憶更進一步維護一個長期摘要每次對話結束就把新信息合并進摘要下次請求時把摘要放在對話最前面后面跟隨最近幾輪原始消息。我實際做過的方案是滾動窗口加摘要混合模式系統(tǒng)維護一個全局摘要始終放進Prompt再維護最近十輪原始消息按時間正序排列如果近十輪的信息量和摘要沖突以原始消息為準。這個模式在多數(shù)客服、助手類應用里表現(xiàn)相當穩(wěn)定。而且摘要本身是異步更新的不需要每輪對話都重新生成可以等用戶停頓幾秒后再觸發(fā)一次后臺摘要更新避免用戶等待時間翻倍。4.4 工具調用后的數(shù)據回寫閉環(huán)當AI應用開始調用外部工具數(shù)據流就從一個簡單的人→模型→人變成了人→模型→工具→模型→人的閉環(huán)。工具返回的數(shù)據往往不能原樣塞進上下文。一個查詢金融數(shù)據庫的工具可能返回幾千條記錄直接塞進Prompttoken瞬間爆炸且模型會被無關字段干擾。架構上應在工具調用服務和上下文組裝器之間加一層結果處理器它的任務是按業(yè)務規(guī)則裁剪字段只保留模型需要的結果把結構化數(shù)據轉成自然語言摘要如果結果太多再做一級聚合統(tǒng)計。比如查銷售訂單不返回300行明細而是返回總訂單數(shù)、總金額、TOP3客戶、同比變化這樣的精簡摘要。工具調用的另一個坑是冪等與重試。很多外部工具不支持天然冪等你重試一次可能就下了兩個訂單。AI Agent在工具超時時很容易下意識重試架構上必須給每次工具調用生成一個唯一的traceId并且在調外部接口時把traceId透傳過去配合外部系統(tǒng)的冪等鍵。這個細節(jié)不畫在架構圖上等到線上出了重復扣款再回頭補就晚了。5. 從單Agent到多Agent協(xié)作架構復雜度的躍遷5.1 單Agent架構的簡化模型我們先看看單個Agent的架構是什么樣子。畫成狀態(tài)圖它就是一個循環(huán)初始狀態(tài)接收用戶輸入 → 推理階段決定下一步動作 → 如果動作是調用工具執(zhí)行工具并返回結果 → 更新上下文 → 重新推理 → 如果動作是生成最終回答結束循環(huán)。這個模型能覆蓋很多業(yè)務比如客服助手、文檔問答、代碼生成助手。單Agent的關鍵優(yōu)勢是鏈路短問題定位簡單資源消耗可控。我在項目里有一個原則能用單Agent解決的絕不輕易上多Agent。因為多Agent不是免費的性能升級而是實打實的架構復雜度。但單Agent有一個天然上限一個模型循環(huán)里的工具選擇、判斷條件、狀態(tài)控制都堆在一起業(yè)務規(guī)則稍微復雜一點Prompt就變得臃腫模型經常在多個工具之間猶豫甚至把不該調的工具調了。當你發(fā)現(xiàn)單個Agent的角色太多任務類型差異太大一個循環(huán)已經難以穩(wěn)定控制時就該考慮拆分。5.2 多Agent協(xié)作模式與通信協(xié)議多Agent協(xié)作本質上是在AI應用里引入了多角色和消息傳遞。我見過最樸素的做法是讓幾個Agent函數(shù)互相調用最后把結果拼到一個主Prompt里。這種假多Agent做得多了會發(fā)現(xiàn)一個嚴重問題沒有統(tǒng)一的Agent間通信協(xié)議任務狀態(tài)、錯誤處理、超時全部靠參數(shù)硬傳代碼根本不可維護。真正要做多Agent第一步是定義Agent之間的消息結構。我的建議是每條消息至少包含任務ID、源Agent、目標Agent、任務類型、Payload、狀態(tài)、錯誤信息、時間戳。目標Agent是可以路由過去的如果采用訂閱或事件驅動還要有事件主題。協(xié)議定清楚之后Agent之間就不再是函數(shù)調用而更像服務之間發(fā)送消息這也讓日志追蹤變得可行。另一個問題是任務分配和結果回收。主管Agent分下去的任務執(zhí)行Agent完成后結果要按任務ID回收到正確的位置一旦某個子任務失敗主管要決定是重試還是換一種路徑。這背后是有狀態(tài)的狀態(tài)機管理建議放在編排層統(tǒng)一維護不要讓每個Agent各自維護我是誰、我該找誰。5.3 編排者-工作者、管道、圖譜三種拓撲多Agent協(xié)作不是只有一個模式畫圖時我常用三種拓撲編排者-工作者Orchestrator-Workers一個主導Agent負責分析整體目標、拆分任務、派發(fā)給多個工作Agent再收集結果并匯總成最終輸出。適合需要拆解多個獨立子任務的場景比如寫一份行業(yè)分析報告可以拆成數(shù)據收集、政策解讀、競品分析、圖表生成等多個子任務。優(yōu)點是控制集中劣勢是主導Agent可能成為瓶頸如果任務拆得太多編排者自己就亂了。管道PipelineAgent按固定順序執(zhí)行前一個的輸出是后一個的輸入。比如先做意圖識別再做實體抽取再生成回復。這種拓撲適合流水線式的固定流程延遲可控但靈活性差無法應對分叉和回溯。圖譜Graph把各個Agent節(jié)點按條件路由連接起來允許分支、循環(huán)、并行而且支持條件判斷。LangGraph就是這種思路。它最靈活也最復雜需要單獨的運行時和狀態(tài)管理。拓撲優(yōu)點缺點適用場景編排者-工作者控制集中、易于審計編排者易成瓶頸、任務拆分難度大子任務相互獨立的復雜任務管道簡單、延遲低固定流程、難擴展處理步驟固定且順序確定圖譜高度靈活、支持分支循環(huán)狀態(tài)管理復雜、調試門檻高決策路徑多且條件多變的業(yè)務我用得比較多的組合是管道 圖譜主流程用明確的鏈路但鏈路在某個關鍵節(jié)點上分叉用圖譜的條件路由選出不同分支。純圖譜模式對于大部分中小團隊來說維護成本太高容易畫得好看落地上卻變成一團亂麻。5.4 多Agent場景下的可觀測性與容錯多Agent系統(tǒng)最怕的是什么不是某個Agent答得不好而是整條鏈路黑盒。用戶說我要退款主管Agent分給客服Agent客服Agent調了訂單系統(tǒng)結果訂單系統(tǒng)超時客服Agent又嘗試了一次最后主管Agent匯總了一個錯誤的結論說退款已發(fā)起。如果沒有鏈路追蹤你根本不知道是哪一步出了問題?？捎^測性在多Agent架構里不是可選項而是基礎設施。我給每個Agent調用鏈都設計一個統(tǒng)一的traceId貫穿用戶請求進入、編排器決策、工作Agent執(zhí)行、工具調用、模型返回的每一個環(huán)節(jié)。每個環(huán)節(jié)記錄輸入輸出摘要、token消耗、延遲、狀態(tài)碼。這套東西可以用OpenTelemetry標準做但真正重要的是日志里要有語義化的字段能支持你回答這個Agent當時為什么調用那個工具。容錯機制同樣要前置。在架構圖上我會給每個Agent節(jié)點周圍畫上重試、超時、熔斷、降級四道保險。比如子Agent連續(xù)失敗兩次就不要再盲目重試而是讓主管Agent換一種表達或換一個工具路徑整體鏈路超時就返回一個預設的兜底回答而不是讓用戶無限等待。沒有這些保險多Agent系統(tǒng)上線后大概率每天都要靠人工背鍋。6. 架構落地時的隱藏成本與決策清單6.1 延遲、成本、準確率的三難權衡AI應用架構到最后很多決策都不是能不能做而是值不值得做。在架構評審時我最常拋出的三難問題是延遲低、成本低、準確率高你要哪個答案往往是全都要但現(xiàn)實必須取舍。一個典型場景是RAG檢索。多加兩路檢索、再過一個重排模型準確率大概率上升但延遲會增加200到500毫秒成本也會增加。另一個典型場景是模型選型旗艦模型效果最好但貴輕量模型便宜但復雜推理容易翻車。架構設計可以引入模型路由來緩解簡單意圖走輕量模型復雜推理走旗艦模型。但模型路由本身也要計算成本你需要一個統(tǒng)計平臺來估算不同策略的總體成本。我做得最多的一件事就是對線上請求做標簽化分析。把所有請求按業(yè)務類型、模型消耗、token數(shù)量、響應延遲打上標簽定期復盤哪些請求其實不需要那么大模型、哪些檢索可以加緩存。架構不是靜態(tài)圖它應該是一個會根據數(shù)據持續(xù)演化的動態(tài)系統(tǒng)。6.2 評測體系沒有指標架構就無從迭代很多團隊在AI應用架構上折騰了半天最后連效果變好了還是變壞了都說不清。沒有評測體系的架構設計就像沒有測試的代碼重構隨時可能倒退。所以我建議在架構設計一開始就搭一套離線評測集。把典型用戶問題、期望回答、各類邊界場景整理成幾十到幾百條測試用例每次架構調整后跑一遍評測對比通過率和輸出質量。更進一步還要有在線監(jiān)控統(tǒng)計用戶點贊、點踩、對話放棄率、回答被修改率。沒有這些指標你真不知道該把成本投入在更復雜的Agent編排還是更優(yōu)秀的Prompt。在評測集里我特別強調對抗樣本。比如用戶故意問和知識庫無關的問題、給出模棱兩可的指令、或者要求模型執(zhí)行超出權限的動作。這類樣本在架構評審時能暴露很多設計缺陷。一個Agent架構如果連對抗樣本都過不了上線之后必然被真實用戶折磨。6.3 一張架構決策檢查清單最后分享一張我常用的架構決策檢查清單每做一個AI應用我都會對著過一遍決策點檢查問題關鍵考量接入方式用戶請求如何進系統(tǒng)是否有統(tǒng)一API網關認證、限流、審計、冪等模型接入是否通過模型網關統(tǒng)一接多個模型密鑰管理、模型路由、降級會話狀態(tài)狀態(tài)放在服務內存還是外部存儲擴展性、容災、跨實例一致性上下文管理是否有獨立的上下文組裝器token預算、歷史截斷、摘要策略外部記憶是否需要RAG用向量庫還是普通數(shù)據庫數(shù)據規(guī)模、過濾需求、更新頻率Agent編排單Agent夠用還是需要多Agent用哪種拓撲任務復雜度、調試成本、可觀測性并發(fā)控制是否限制了模型層并發(fā)有沒有隊列削峰延遲SLA、API限流、成本容錯機制超時、重試、熔斷、降級是否都到位錯誤恢復、用戶體驗評測監(jiān)控是否有離線評測集和在線監(jiān)控效果可度量、回歸可發(fā)現(xiàn)這張清單不一定覆蓋所有業(yè)務但至少能幫你把架構圖里的空白補齊。每你對著它畫一遍通常就能發(fā)現(xiàn)一兩個之前沒考慮到的風險點。我個人的體會是AI應用架構設計最大的難點不是技術選型多酷而是能不能在復雜度和業(yè)務價值之間找到平衡。一張架構畫得好不好不在于線條多漂亮而在于它能不能讓你一眼看出系統(tǒng)的薄弱環(huán)節(jié)在哪。從模型網關到上下文管理從單Agent到多Agent每一步都是取舍。先把圖畫清楚再動手寫代碼這個習慣幫我省過太多了線上救火的時間。