1. 為什么我們畫的架構圖總讓人看不懂上周有個老朋友把一張他團隊畫的AI應用架構圖發(fā)給我讓我?guī)兔纯?。圖很大分了八九層從上到下分別是用戶、網(wǎng)關、服務、模型、向量庫、緩存、日志……箭頭密密麻麻一眼看過去像是某種電路板的微距照片。他說這圖畫了兩個星期改過十幾版結果給技術評審會上一放合伙人只問了一句“這個圖我看完之后不知道我們做的東西跟智譜、OpenAI的ChatGPT有什么區(qū)別”這個問題非常扎心但不是他畫得不好而是他用錯了畫圖的方法。傳統(tǒng)軟件的架構圖核心表達的是“模塊之間的依賴和調(diào)用關系”到了AI應用這里架構圖的使命完全變了它要表達的是“人的意圖如何被理解模型在什么地方接管又把什么結果交還給用戶”。你看這說的已經(jīng)不是圖的事是一個完整架構設計邏輯的偏移。如果你現(xiàn)在打開一個AI項目的白板大概率所有人都在討論模型選型、提示詞怎么寫、RAG的召回率有多高。但這里面最大的一個誤區(qū)是架構沒有立住所有局部優(yōu)化最后都會變成無效努力。模型、提示詞、檢索、Agent每個部件單獨拿出來都有非常成熟的方案但拼在一起之后沒有一張圖能夠幫助團隊回答“為什么這個模塊放在這里”“用戶的一次請求到底經(jīng)過了哪些環(huán)節(jié)”“哪個環(huán)節(jié)最脆弱、最貴”。這才是“圖解AI應用架構設計”真正要做的事情。這篇文章我想用我實際畫過的架構、踩過的坑來講清楚三件事AI應用架構圖和傳統(tǒng)架構圖本質(zhì)區(qū)別在哪里一張實戰(zhàn)級AI架構圖應該有哪些必備組件各自承擔什么職責以及你應該怎么一步步把圖畫出來讓不同背景的人都能一眼看懂。2. 傳統(tǒng)軟件架構的“分層思維”在這兒為什么卡殼了2.1 分層架構的前提是確定性而AI應用的命根子是不確定性先聊聊傳統(tǒng)軟件。我剛開始寫代碼那些年畫架構圖非常順手因為腦子里有一套固定的章法。前端、網(wǎng)關、業(yè)務層、數(shù)據(jù)庫七層也好五層也好邏輯是確定的請求進來走哪條路由調(diào)哪個接口返回什么結構全部寫死在代碼里。每一層是什么、干什么、誰調(diào)用誰清清楚楚。畫出來的圖哪怕復雜大家也能順著箭頭把一條請求從前到后理一遍。AI應用打破了這個前提。一個用戶說“幫我寫個郵件回復客戶的投訴”模型究竟會不會輸出你預期的那段文案它今天可能回復得特別好明天換個表述可能就離題萬里。這中間沒有確定的分支邏輯只有概率。那這種不確定性應該畫在哪一層你會發(fā)現(xiàn)常規(guī)分層的格子根本裝不下它因為不確定性是橫跨所有層的從輸入文本的解析開始一直到最后的輸出校驗每一環(huán)都有概率性的成分在里面。這就是為什么很多人畫AI架構圖總覺得哪里怪怪的你仍然在用確定性分層思維去表達一個確定性的流程而這個流程本身是概率性的。于是圖畫出來非常像樣但失真。2.2 “數(shù)據(jù)流圖”和“決策流圖”只能二選一這個開關很多人沒想明白還有個常見的困惑是架構圖上到底應該畫數(shù)據(jù)流還是決策流傳統(tǒng)系統(tǒng)里數(shù)據(jù)流和決策流通常是重疊的請求帶著參數(shù)進來代碼在該分支的地方做判斷然后往下走。但在AI應用里數(shù)據(jù)流和決策流經(jīng)常分叉。舉個我實際遇到的例子。我們做一個合同審查工具用戶上傳一份PDF合同。數(shù)據(jù)流很簡單文件上傳、解析、文本化、切片、向量化、存入向量庫。但決策流呢合同里有沒有異常條款這個判斷是由模型完成的可是“要不要讓模型來判”這是一個前置的決策。如果一份五頁的小合同也走RAG檢索再進大模型那延遲和成本都壓不住。我們最后單獨做了一個輕量級分類模型根據(jù)合同頁數(shù)和文本密度判斷是否需要檢索還是直接甩給模型就看完了。你看數(shù)據(jù)流走的是文件路徑?jīng)Q策流走的是“誰來分析”的判斷路徑。兩張流混在一張圖里畫出來就是一團麻。架構設計的真正任務其實是先分清“什么東西在流動”和“什么邏輯在做判斷”然后在圖上用不同形態(tài)的線把它們分開?？上Т蟛糠秩水媹D的時候沒有做這個區(qū)分結果拿到評審會上被質(zhì)疑的往往不是細節(jié)而是整體邏輯。3. 一張實戰(zhàn)級AI應用架構圖至少要有六根柱子3.1 模型出口與多模型路由你的圖里不該只有一個大模型很多朋友畫AI應用架構直接就是一個圖框?qū)憽按竽Ｐ汀比齻€字完事。這是我看過最普遍的問題。真實生產(chǎn)里大模型旁邊必須有“路由”這個組件否則性能和成本根本平衡不了。一個現(xiàn)成的例子同樣是改寫一段周報旗艦模型的輸出質(zhì)量上限確實高但用它處理“幫我改一下錯別字”這種簡單任務就是殺雞用牛刀。好的架構圖應該畫出兩條路一條走旗艦模型給復雜推理另一條走輕量級模型給機械任務。路由這個框會做意圖判定根據(jù)請求復雜度把流量分發(fā)到不同出口。畫圖的時候模型層不要只畫一個云服務商標要畫出口粒度。我當時做AI客服系統(tǒng)時開頭畫的架構圖里就一個大圈后來拆成了“生成主模型 意圖分類小模型 精簡任務小模型”三個出口路由畫在最上面。那張圖拿到后端團隊面前所有人第一反應是“哦原來我們要部署不止一個模型”。如果沒有把這一層拆開很多人會默認架構上只需要接一個API這是后面所有部署沖突的起點。3.2 上下文工程區(qū)這不是一個文件夾是整個系統(tǒng)的心臟地帶接下來是最重要的部分——上下文工程區(qū)。很多架構圖把提示詞、向量檢索、記憶當三條輔助線來處理隨便掛在模型邊上。實際上它們應該被畫成一個獨立區(qū)域我習慣叫它上下文工程區(qū)標準的叫法是Context Engineering。這里有一個我趟過的大坑。早期我們做行業(yè)問答AI架構圖畫的是“用戶輸入→拼接系統(tǒng)提示詞→調(diào)大模型”。圖很簡單上線也能跑但回答質(zhì)量非常飄。后來排查發(fā)現(xiàn)系統(tǒng)提示詞里有很長的企業(yè)背景介紹還有大量歷史對話摘要這些東西一股腦堆在上下文里模型注意力被嚴重稀釋。后面架構圖改成這樣上下文區(qū)域里分三格——靜態(tài)指令系統(tǒng)提示詞內(nèi)容固定、動態(tài)結果從向量庫里召回的知識片段按相關性排序、記憶槽歷史對話摘要按時間衰減。畫完這張圖的第二天團隊看問題的方式就變了之前是“提示詞寫得不好改提示詞”現(xiàn)在變成了“從召回結果里帶進來的噪聲太多得調(diào)檢索閾值”“記憶槽只有最后五輪用戶一周前說過什么根本記不住”。一個架構圖的調(diào)整直接改變了團隊排查問題的視角這個價值比什么圖好看重要得多。3.3 工具與插件邊界模型決定不了的事故工具區(qū)要攤開說再往下是工具層也就是Function Calling、外部API這一坨。架構圖上這一層最大的作用不是炫技術而是明確一個邊界模型對什么事情只有建議權什么事情有執(zhí)行權。我們項目里讓AI助手去操作公司內(nèi)部工單系統(tǒng)。架構圖我故意把工具層畫成單獨的框而且邊上注了一句話“工具執(zhí)行前必須經(jīng)過網(wǎng)關校驗參數(shù)?！碑嬐曛蟀踩珗F隊主動來找我確認校驗邏輯這個在以前是根本不會發(fā)生的對話。工具區(qū)還要畫出失敗語義。外部API超時了怎么辦返回什么給用戶這里一定要寫清楚。很多AI應用出事不是模型判斷錯了而是工具執(zhí)行得不對系統(tǒng)還繼續(xù)往下走把錯的結果包裝成正確的結果返回用戶。架構圖上如果沒有顯式標注工具不可用時的降級路徑那就等于把地雷埋在了線上。3.4 安全護欄與輸出校驗不能只指望模型“良心發(fā)現(xiàn)”AI應用的第四個關鍵區(qū)域是安全護欄。一個絕對不能省略的框。很多架構圖把“內(nèi)容安全”做成一個小角標甚至根本不畫。但真實運維里模型輸出是不可控的沒有精準的輸入輸出校驗層測試階段可能好好的上了一波奇怪的話術直接翻車。安全護欄不只指屏蔽敏感詞更核心的是“輸出格式校驗”和“行為邊界校驗”。什么叫行為邊界校驗系統(tǒng)提示詞里告訴模型“不許用搜索工具查天氣”但如果用戶繞彎子說“我明天去上海要帶傘嗎”模型可能直接調(diào)用搜索工具。沒有行為邊界校驗這種問題就靠運氣。架構圖上這個框需要畫在模型出口和用戶之間必要時雙保險一邊攔截異常輸入一邊校驗模型輸出。3.5 人機協(xié)同位置所有圖都繞不開“人在環(huán)上”四個字第五個區(qū)域“人在環(huán)上”。AI應用發(fā)展到現(xiàn)在沒有哪個嚴肅項目敢于聲稱全鏈路無人工介入。畫架構圖的時候人機協(xié)同的位置不標清楚后面上線一定會有倫理和運營上的雙重麻煩。比如我們做智能審核助手架構圖里凸顯一條規(guī)則所有對外發(fā)布的審核結果必須經(jīng)過人工抽檢置信度低于閾值的自動轉(zhuǎn)人工。這張圖畫完業(yè)務方、研發(fā)、測試終于在一個頻道上了誰對最終結果負責圖上一眼就能看出來。而初始版本沒畫清楚研發(fā)覺得自己寫了個完美系統(tǒng)業(yè)務方擔心砸了自己的招牌兩邊都對但就是交流不下去。3.6 成本與延遲標識這些數(shù)字不寫上去圖就是一張概念畫最后一根柱子是成本與延遲標識。很多人畫的架構圖像教室里的結構示意圖節(jié)點和箭頭一個個都很規(guī)范就是沒有任何數(shù)字。生產(chǎn)級架構圖不是這樣的它至少要在關鍵路徑上標注預期延遲、在模型節(jié)點標注單次調(diào)用成本。我之前幫一個創(chuàng)業(yè)團隊評審架構他們的圖很完整但我指著模型的框問一次普通請求大概多少錢他們愣了說沒算過。我當場打開他們選的模型的定價頁面大致算了一下假設每天一萬次請求其中八成都走旗艦模型一天的模型調(diào)用成本就好幾百。對創(chuàng)業(yè)團隊來說這個數(shù)字足夠改變技術選型。沒有這個數(shù)字架構圖只能算示意圖不能拿來做決策。4. 從空白畫布開始一步步把AI應用架構畫出來4.1 第一步鎖死場景和用戶角色這決定了圖的邊界和層次說了這么多組件具體落筆時怎么開始我建議先從確定邊界開始。拿一張白板畫出場景范圍和用戶角色。你可以把自己當導演開拍前先看劇本是發(fā)生在哪間屋子、有哪些人物。比如你做一個面向中小企業(yè)HR的簡歷篩選助手那場景就是“HR上傳簡歷→AI提取候選人亮點→HR篩選→發(fā)起面試邀請”。用戶角色只有HR一個。別把求職者也畫進來階段不同、權限不同場景全混進去圖就沒法看。邊界一定是刻意縮小的。當時我們做合同審查開始恨不得把“合同全生命周期管理”都畫進去后來切成一次審查、一個環(huán)節(jié)圖上每個節(jié)點都變得有實際指涉不再是為了占格子而存在。4.2 第二步畫三張草圖比反復修改一張詳圖有效得多正式動筆前先用三張草圖做快速探索。這三張各代表一種架構形態(tài)我常用的組合是直通型用戶輸入直接進大模型輸出返回。這是最簡單的也是MVP最喜歡用的。路由型輸入先進行意圖判斷再分流到不同模型或知識庫。協(xié)作型多個Agent分工協(xié)作各自有工具輸出匯聚后再進入下一個階段。這三張圖不要畫得太細粗線條、半小時搞定。它們的核心作用是讓參與架構討論的人在“到底選哪種形態(tài)”上達成初步共識而不是一上來就陷入“向量庫要不要加緩存”這種細節(jié)。直通型適合什么適用于需求明確、對性能壓力不大的內(nèi)部工具。路由型適合大多數(shù)對外產(chǎn)品意圖判斷先行簡單任務走小模型復雜任務走旗艦模型。協(xié)作型適合流程復雜、需要拆解的任務鏈但它對系統(tǒng)可靠性的要求會上一個等級。4.3 第三步從關鍵路徑開始填充把細枝末節(jié)全部扣掉選完形態(tài)現(xiàn)在才開始真正畫圖。這時候有人會打開Visio或者draw.io開始畫邊框、拉箭頭。我的建議是先從關鍵路徑畫起用戶發(fā)出請求這個請求經(jīng)歷的第一個組件是什么往下走會遇到什么最后怎么把結果送回來。關鍵路徑畫完再往旁邊加分支。比如知識檢索不是每次請求都需要走的只在部分場景觸發(fā)那它就應該畫成旁路而不是畫在最粗的主線上。這一條特別重要架構圖的可讀性取決于你是否有勇氣把很多有必要的組件擺到次要位置。當時我們給智能客服畫圖團隊最初版本把所有旁路功能全部畫成等寬的大框連“日志清理任務”都占了很大空間。我第一刀就是把這些功能砍一半留一半放到底部工具區(qū)。新同學看圖的反應完全不同他們一眼抓住了主鏈路想了解細節(jié)的時候再往下面翻層次感就出來了。4.4 第四步給關鍵的箭頭和數(shù)據(jù)流老老實實寫上載體和頻率畫完節(jié)點剩下的工作就是標數(shù)據(jù)流。但這里有個細節(jié)很多人把箭頭畫出來就認為自己表達清楚了。其實沒有箭頭至少需要附帶兩個信息數(shù)據(jù)通過什么形式流動、流動的頻率級別。這個怎么標舉個例子“用戶輸入→意圖路由”這條線旁邊可以標“JSON每請求一次”“向量庫→上下文拼裝”這條線可以標“Top-K召回每請求0到8段”。標完這些整個系統(tǒng)的負載畫像就浮出了。有一次我給別人做架構評審看到一個“定時任務→模型總結”的箭頭我問了一個很基礎的問題這個任務是每分鐘跑一次還是每天跑一次對方說每天我算了一下每天調(diào)模型1440次和1次成本差了三個數(shù)量級。不標頻率的架構圖等于沒標成本等于沒法決策。這個習慣值得養(yǎng)成每個數(shù)據(jù)流寫清楚載體和頻次會逼著所有人把模糊的架構討論變成可計算的工程決策。5. 為什么你的架構圖仍然在評審會上被打回三個致命短板5.1 圖里全是組件沒有“失敗語義”我發(fā)現(xiàn)一個高發(fā)問題絕大多數(shù)架構圖只畫了成功路徑?jīng)]畫失敗路徑。系統(tǒng)不會永遠成功的。模型可能超時、向量庫可能連不上、外部工具可能宕機。傳統(tǒng)架構圖我們習慣把失敗處理畫在各種“異常分支”而在AI應用架構圖里失敗語義應該直接寫在關鍵組件上。比如模型調(diào)用這個節(jié)點旁邊寫清楚“失敗后降級返回標準話術并發(fā)告警”和“失敗后重試最多兩次指數(shù)退避”。每個關鍵組件都能回答“你掛了怎么辦”這個問題架構圖才算是能扛事的圖。5.2 圖里沒有“觀察性”的概念誰在看這個系統(tǒng)還有一個經(jīng)常被忽略可觀測性。系統(tǒng)跑起來之后總得知道每個環(huán)節(jié)的調(diào)用量、延遲、成本、異常率。架構圖上要有觀測數(shù)據(jù)流它不是實時業(yè)務數(shù)據(jù)的一部分但它是從各個組件向外輸出的一段元數(shù)據(jù)。有個非常經(jīng)典的場景AI客服上線之后要追蹤“意圖路由分發(fā)到小模型”的比例是否合理。如果沒有可觀測設計這個數(shù)據(jù)根本采集不到你想調(diào)優(yōu)路由的權重都沒有依據(jù)。我在架構圖里一般會在最底部畫一條虛線把所有組件連到一個名“日志/指標/追蹤”的框。這條虛線看似多余但在上線后救了我很多次。比如模型在加班高峰期突然變慢如果不是圖上提前準備了指標來源團隊根本不知道是該擴容模型網(wǎng)關還是模型供應商那邊的問題還是上下文拼裝環(huán)節(jié)太慢。可觀測不是加不加的問題是加在哪個位置的問題。5.3 圖里沒有版本演進的空間畫成一潭死水最后很多架構圖畫完就當成“最終稿”存檔了這是一個非常嚴重的誤判。AI應用的架構是高度迭代的你可能過了兩周就要把路由規(guī)則調(diào)整一下、把記憶機制增強一下、把某個Agent拆成兩個。一張架構圖應該像你代碼倉庫里的文件一樣有版本號有改動日期有負責維護的人。我當時推進過一個原則架構圖必須跟著項目里程碑一起更新每次上線新功能架構圖同步更新并且在圖下方標注版本變更記錄。誰說“圖已經(jīng)畫完了”這種話團隊就會問一句那你功能迭代完不更新圖三個月之后新人來了看什么這個圖不叫最終稿它叫當前稿。如果你希望它有價值就得讓它一直活在項目演進的過程里。6. 兩種真實場景的架構圖拆解“客服助手”和“代碼評審Bot”6.1 客服助手的圖取舍目標是“省錢”和“不被客戶罵”客服助手是我做過很多次的場景它的架構圖體現(xiàn)的核心策略是“分層分流”。用戶的每條消息進來后先經(jīng)過意圖路由判斷一下這個問題是常見FAQ、流程咨詢還是投訴、需要人工介入。簡單任務直接走輕量模型配合與預設的FAQ向量庫做個快速檢索就行只有復雜任務才進大模型讓它提取情緒和意圖再生成回復方案。這個圖的關鍵點在于模型輸出之后必須經(jīng)過一個“置信度評估”環(huán)節(jié)。模型自己說“我很確定”不算數(shù)我們要設定規(guī)則多少分以下必須轉(zhuǎn)人工并且客服工作臺會自動彈窗提醒。架構圖上要把這條線畫得非常粗轉(zhuǎn)人工不是一個灰溜溜的操作而是系統(tǒng)設計里最高優(yōu)先級的安全通道。做客服架構時成本上千元一天的教訓讓我明白圖紙上沒有標注成本分層等量沖到一定量級老板看到賬單會非常痛苦。客服場景的架構圖如果你只標一個優(yōu)雅的模型調(diào)用鏈不標分流賬面根本扛不住。所以客服架構圖的靈魂就是“利用分層分流策略實現(xiàn)成本與體驗的平衡”。6.2 代碼評審Bot的圖取舍目標是“可信”和“不誤報”代碼評審Bot和圖又不一樣。這個場景最大的矛盾是AI提供代碼審查建議不難難的是開發(fā)和團隊憑什么信任它。如果AI每十條建議里有兩條是誤報整個系統(tǒng)信任感就崩塌了。所以代碼評審Bot的架構圖人機協(xié)同位置必須非常顯眼。我的設計是這樣代碼提交事件觸發(fā)→拉取代碼差異→調(diào)用模型做靜態(tài)缺陷識別和風格分析→輸出問題列表和嚴重程度分級→進人工復核隊列。架構圖最底部標注一條硬規(guī)則嚴重級別高的建議必須經(jīng)過至少一名資深工程師確認后才能推送給提交者模型輸出本身不自動生效。模型在這里不具備“下結論”的資格它只負責“發(fā)現(xiàn)問題”。架構圖畫清楚這條線之后產(chǎn)品、研發(fā)、測試三方的預期就對齊了。后續(xù)在運維中團隊提出不如“讓模型直接幫我們標記高危問題”但看架構圖我一句話就說服了對方那條“人工確認”鏈路就是我們最大的信任資產(chǎn)砍掉它省了人工失了信用。7. 架構圖推進的節(jié)奏把握從單體到多Agent的路該怎么走7.1 起步期寧可粗、不可亂單體結構是最好的談判起點不要第一版架構圖就上來畫四個Agent五個知識庫。起步階段單體結構的直通型架構往往是最合適的一個模型一個提示詞一個輸出。圖畫出來像一個水龍頭用戶進來流水出來。單體結構的好處是可控性極高。技術選型、成本計算、故障排查都簡單。而且單體階段的架構圖是最好的“談判起點”面對老板你不必解釋Agent是怎么協(xié)作的面對投資人你直接演示產(chǎn)品價值即可。很多團隊一上來就堆復雜架構直播翻車的多真正的核心功能連原型都沒跑通復雜度倒是先建立起來了。7.2 擴展期先加路由再加記憶最后再上多Agent當單體結構跑通你才有資格考慮擴展。我建議的擴展順序是先加路由再加記憶最后才考慮多Agent。這個順序來自一條很樸素的原則哪個組件帶來的確定性收益最大就先加哪個。路由解決了“什么請求該走什么模型”的問題收益立竿見影成本下降、性能上升。記憶解決了“用戶連續(xù)對話的語境保持”問題體驗會明顯變好。多Agent是最后一個選項因為它帶來的不確定性和運維復雜度最高只有在路由和記憶都無法滿足業(yè)務需求時再考慮。很多團隊反著來一上來就整多Agent協(xié)作成本燒得飛快穩(wěn)定性和效果卻遲遲跟不上最后把Agent這個詞都快做成了貶義詞。7.3 成熟期架構治理不是寫在文檔里的是畫在圖上的當系統(tǒng)進入成熟期架構圖開始承擔治理職能。它不只是一張供人瀏覽的圖還是一份所有人都必須遵守的“契約”。我自己比較推崇把架構圖的改動和權限綁定任何涉及到數(shù)據(jù)流、模型出口、安全護欄的改動都需要走架構評審圖必須同步更新。這個機制聽起來像行政管理但它真正保護的是研發(fā)效率。因為AI應用太容易“東改一個提示詞、西改一個閾值”了沒有架構治理三個月后系統(tǒng)變成一個誰也說不清的黑盒子。架構圖就是那個讓失控過程能隨時被定位的錨點。8. 畫一張能幫團隊做對決策的圖這三個習慣最重要最后分享三個我個人的實操習慣都是吃過虧換回來的。第一個習慣畫圖用的是“決策視角”不是“實現(xiàn)視角”。所謂決策視角就是每畫一個節(jié)點都要問自己“這筆有什么可決策的是成本、延遲、準確率還是安全”如果這個節(jié)點不存在任何需要權衡的決策它很可能就不配出現(xiàn)在主架構圖上。影響決策的組件放主屏純實現(xiàn)細節(jié)扔進附錄即可。第二個習慣注釋語言統(tǒng)一用“如果……那么……”的句式。比如“如果意圖路由置信度低于0.6那么轉(zhuǎn)人工”“如果工具調(diào)用超時那么降級為告知用戶稍后重試”。這種句式強迫你把架構圖里模糊的邏輯判斷顯式寫出來看起來可能很啰嗦但比畫一堆看不懂的圖例有用得多。第三個習慣每個季度把架構圖翻出來做一次“復盤壓力測試”。故意問自己如果這個月模型調(diào)用量翻十倍圖上哪個模塊會先崩如果主模型要換供應商哪些節(jié)點會受影響拿這些問題反復測圖測出來的代價就是團隊的下一次優(yōu)化方向。架構圖不能是靜態(tài)的它必須陪著系統(tǒng)一起呼吸。我個人實際帶團隊的經(jīng)驗是現(xiàn)在AI應用的競爭不是比誰的模型更強而是比誰的架構能更快、更穩(wěn)、更省地承載用戶需求。從來沒有一個架構可以靠一次畫圖一勞永逸但一張好的架構圖至少能確保每一次迭代都朝著正確的方向奔跑。