簡介面向全棧 AI 應用開發(fā)者的工程示例與平臺源碼包聚焦 Spring Boot 3 LangChain4j Vue 3 技術(shù)棧覆蓋智能代碼生成、AI 智能體、LangGraph4j 工作流與 Tool Calling 等核心能力并展示可視化編輯、一鍵部署、應用管理及智能路由的實現(xiàn)思路既有完整的前后端交互鏈路也適合作為 AI 應用平臺腳手架進一步擴展。壓縮包共 216 個文件、約 1.14MB其中 Java 后端邏輯約占 143 個文件Vue/TS 前端頁面與交互約 40 個文件另有 JSON、XML、YML、SQL 等配置腳本及 Markdown 說明目錄分層明顯便于按模塊閱讀與二次開發(fā)智能體編排、工具調(diào)用注冊、工作流節(jié)點配置等關(guān)鍵示例均包含在內(nèi)。資源還結(jié)合多級存儲與 Nginx 部署給出 Prometheus、Grafana、ARMS 監(jiān)控方案并預留 Cursor Vibe Coding 協(xié)作開發(fā)入口可幫助讀者快速復現(xiàn)一套可觀測、可擴展的 AI 應用平臺骨架。已有 250 人學習下載適合正在搭建智能體、工具調(diào)用或工作流平臺的同學對照源碼梳理完整實現(xiàn)鏈路。1. 從智能體到代碼生成這個 AI 應用平臺到底在解決什么問題一個 Java 技術(shù)棧為主的團隊想上 AI 應用往往卡在同一個地方Python 生態(tài)的 LangChain 很成熟但團隊沒人愿意跨界維護兩套技術(shù)棧。這個平臺標題給出的答案很直接——用 SpringBoot3 做后端底座用 LangChain4j 接大模型用 LangGraph4j 做工作流編排再配一個 Vue3 的可視化畫布把 AI 能力變成能拖拽、能部署、能管理的產(chǎn)品。它解決的不是怎么調(diào)一次大模型接口而是怎么把智能體、代碼生成、工具調(diào)用這些能力沉淀成企業(yè)內(nèi)部的標準化應用平臺。適合兩類人一是想從零構(gòu)建 AI 應用平臺的架構(gòu)師二是接了類似需求但不知道從哪落地的后端和前端工程師。2. SpringBoot3 LangChain4j 的工程底座選型理由與最小可運行配置2.1 為什么是 LangChain4j 而不是自研封裝或 Python LangChain先回答一個很多人糾結(jié)的問題我直接寫 OpenAI SDK 或者 Spring AI 不行嗎自己封裝 OpenAI SDK 當然能跑通對話但一旦涉及多輪對話的記憶管理、文檔的 Embedding 切分、工具的自動發(fā)現(xiàn)和調(diào)用代碼量會迅速膨脹。LangChain4j 在 Java 生態(tài)里的定位和 Python 版 LangChain 一樣把這些通用能力抽象成 ChatModel、EmbeddingModel、AiServices、Tool 這些接口你只需要替換模型廠商的依賴業(yè)務(wù)代碼基本不動。Spring AI 和 LangChain4j 之間我選了后者原因是它對 ToolCalling 和函數(shù)回調(diào)的支持更直接Tool 注解的體驗和 Java 開發(fā)者的直覺一致。LangGraph4j 的出現(xiàn)補齊了 LangChain4j 最缺的工作流編排能力——之前做復雜 Agent 只能自己手寫狀態(tài)機現(xiàn)在有官方的圖執(zhí)行引擎節(jié)點、條件邊、狀態(tài)傳遞都是聲明式的。這里要認清一個現(xiàn)實LangChain4j 的迭代速度很快API 在不同小版本之間有過調(diào)整所以工程落地時要先鎖版本不要一路上最新。2.2 SpringBoot3 工程骨架與模型接入的最小配置SpringBoot3 強制要求 JDK17 起步實際項目我建議直接用 JDK21LTS 版本虛擬線程對 AI 場景的流式輸出有幫助。創(chuàng)建一個標準的 Maven 工程關(guān)鍵依賴就三個langchain4j-spring-boot-starter、langchain4j-open-ai兼容 OpenAI 協(xié)議的服務(wù)都走這個、langgraph4j-core。下面這個 pom 片段是經(jīng)過驗證的最小集合properties java.version21/java.version spring-boot.version3.3.5/spring-boot.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-spring-boot-starter/artifactId /dependency dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-open-ai/artifactId /dependency !-- LangGraph4j 建議掛在 langchain4j 同一版本族下避免接口不匹配 -- dependency groupIdcom.langchain4j/groupId artifactIdlanggraph4j-core/artifactId /dependency /dependencies注意 langchain4j 和 langgraph4j 的 groupId 不一樣前者是 dev.langchain4j后者是 com.langchain4j。版本號我刻意沒寫死因為這兩個庫的版本更新頻繁直接查 Maven 倉庫選最新穩(wěn)定版即可但一定要檢查 langgraph4j 依賴的 langchain4j-core 版本和你項目里的保持一致否則運行時會出現(xiàn) NoSuchMethodError。模型接入配置走 SpringBoot 的配置文件這里以 OpenAI 兼容接口為例國內(nèi)云廠商的模型網(wǎng)關(guān)、Ollama、vLLM 部署的本地模型都能通過這個方式接入langchain4j: open-ai: chat-model: base-url: ${LLM_BASE_URL:http://localhost:8000/v1} api-key: ${LLM_API_KEY:sk-local} model-name: ${LLM_MODEL:qwen2.5-coder:32b} temperature: 0.2 max-tokens: 4096 log-requests: true log-responses: true embedding-model: base-url: ${LLM_BASE_URL:http://localhost:8000/v1} api-key: ${LLM_API_KEY:sk-local} model-name: ${EMBEDDING_MODEL:bge-m3}base-url 通過環(huán)境變量注入這樣同一個 jar 包在開發(fā)、測試、生產(chǎn)環(huán)境不用改配置。temperature 設(shè)成 0.2 是代碼生成場景的推薦值溫度太高模型會自由發(fā)揮生成的東西看著像代碼但編譯不過。log-requests 和 log-responses 在聯(lián)調(diào)階段一定要開LangChain4j 會把完整的請求體和響應體打出來排查 prompt 問題和 token 統(tǒng)計都靠它。2.3 模型接入層的抽象OpenAI 兼容接口與本地模型共存實際項目里不太可能只接一家模型。我一般會在業(yè)務(wù)代碼之上加一層 ModelRouter按場景路由到不同模型意圖識別用便宜的小模型代碼生成用能力強的 32B 以上模型Embedding 固定用一個。LangChain4j 的 ChatModel 接口天然支持這種抽象你只需要在配置類里聲明多個 BeanConfiguration public class ModelConfig { Bean Primary public ChatModel mainChatModel(Value(${llm.main.model}) String model) { return OpenAiChatModel.builder() .baseUrl(http://localhost:8000/v1) .apiKey(sk-local) .modelName(model) .temperature(0.2) .build(); } Bean public ChatModel fastChatModel(Value(${llm.fast.model}) String model) { return OpenAiChatModel.builder() .baseUrl(http://localhost:8000/v1) .apiKey(sk-local) .modelName(model) .temperature(0.1) .maxTokens(1024) .build(); } }Primary 注解保證默認注入的是能力最強的那個模型需要快模型的地方用 Qualifier(fastChatModel) 顯式指定。這個做法的好處是后續(xù)接 Anthropic 或 Gemini 時只要再實現(xiàn)一個 ChatModel Bean業(yè)務(wù)代碼零改動。到了這個階段你已經(jīng)有一個能對話、能 Embedding 的 SpringBoot3 后端了下一步就是把它升級成能自主完成任務(wù)的智能體。3. 用 LangGraph4j 編排代碼生成 Agent節(jié)點、條件邊與 ToolCalling3.1 LangGraph4j 的核心概念State、節(jié)點與條件邊LangGraph4j 解決的核心問題是一個智能體不只是一次模型調(diào)用而是感知-規(guī)劃-行動-觀察的循環(huán)。你需要在代碼里顯式表達這個循環(huán)包括循環(huán)什么時候結(jié)束、狀態(tài)怎么在節(jié)點之間傳遞。它有三個基礎(chǔ)概念State狀態(tài)、Node節(jié)點、Edge邊。State 是一個在節(jié)點間傳遞的數(shù)據(jù)載體Node 是處理狀態(tài)的一個函數(shù)Edge 定義節(jié)點的連接關(guān)系其中一種特殊的邊叫條件邊根據(jù)當前狀態(tài)決定下一步走哪個節(jié)點。這樣設(shè)計的好處是人和模型的分工變清楚了節(jié)點里的邏輯是你寫死的確定性代碼模型只負責在節(jié)點里產(chǎn)出內(nèi)容或決定走哪條條件邊。相比純提示詞驅(qū)動的 AgentLangGraph4j 讓整個流程可觀測、可 debug、可回放——這正是生產(chǎn)環(huán)境最需要的東西。下面定義一個代碼生成工作流的狀態(tài)類型public interface CodeGenState { GraphStateDTOString requirement GraphStateDTO.string(requirement); GraphStateDTOString plan GraphStateDTO.string(plan); GraphStateDTOString sourceCode GraphStateDTO.string(sourceCode); GraphStateDTOString execResult GraphStateDTO.string(execResult); GraphStateDTOInteger retryCount GraphStateDTO.int32(retryCount); GraphStateDTOBoolean passed GraphStateDTO.bool(passed); }每個節(jié)點只關(guān)心它需要的字段LangGraph4j 會在節(jié)點完成后自動合并新狀態(tài)。retryCount 在這里很關(guān)鍵它控制整個工作流的終止條件避免模型陷入生成-執(zhí)行失敗-再生成的死循環(huán)。3.2 定義代碼生成工具Tool 的參數(shù)描述決定調(diào)用準確率ToolCalling 是大模型連接外部系統(tǒng)的通道。LangChain4j 的做法是用 Tool 注解標記一個 Java 方法模型根據(jù)方法名、描述和參數(shù)描述來決定什么時候調(diào)用、傳什么參數(shù)。很多人第一次寫工具方法時只寫方法名結(jié)果模型死活不調(diào)用原因就是描述信息太少模型不知道這個方法能干什么、參數(shù)應該填什么。Component public class CodeExecutionTools { Tool(執(zhí)行傳入的 Java 源碼返回編譯和運行的標準輸出如果編譯失敗則返回錯誤信息) public String runJavaCode( ToolParam(完整的 Java 源碼字符串必須包含 public class Main 和 main 方法) String sourceCode) { // 將 sourceCode 寫入臨時文件調(diào)用 javac 編譯java 執(zhí)行 // 捕獲 stdout 和 stderr超時時間設(shè)為 10 秒防止模型生成死循環(huán)代碼。 return output; } Tool(讀取項目內(nèi)指定相對路徑的文本文件內(nèi)容) public String readFile( ToolParam(相對項目根目錄的文件路徑) String filePath) { return FileUtil.readUtf8String(filePath); } }ToolParam 里的描述會作為參數(shù)說明拼進模型請求的 tools 定義里描述越具體模型傳參的準確率越高。我踩過的坑是參數(shù)描述太模糊模型把文件路徑傳成 test.java而實際要傳 src/test/java/Test.java。這個環(huán)節(jié)沒捷徑每個工具都要站在模型的角度寫清楚這個參數(shù)應該是怎樣的格式。3.3 組裝可執(zhí)行的工作流plan → 生成 → 執(zhí)行 → 評審有了狀態(tài)和工具就可以組裝工作流了。這個代碼生成 Agent 的流程是先讓模型讀需求做計劃再生成源碼然后調(diào)用工具執(zhí)行最后讓模型評審執(zhí)行結(jié)果。評審不通過且重試次數(shù)沒超限就帶著錯誤信息回到生成節(jié)點重新生成。Service public class CodeGenWorkflow { private final ChatModel chatModel; private final ToolExecutor toolExecutor; public CodeGenWorkflow(ChatModel chatModel, ToolExecutor toolExecutor) { this.chatModel chatModel; this.toolExecutor toolExecutor; } public StateGraphCodeGenState buildGraph() { StateGraphCodeGenState graph new StateGraph(CodeGenState.SPEC); graph.addNode(planner, this::planNode); graph.addNode(codegen, this::codeGenNode); graph.addNode(executor, this::executeNode); graph.addNode(reviewer, this::reviewNode); graph.setEntryPoint(planner); graph.addEdge(planner, codegen); graph.addConditionalEdge(executor, this::needFix, Map.of(true, codegen, false, reviewer)); graph.addEdge(reviewer, StateGraph.END); return graph; } private MapString, Object planNode(MapString, Object state) { String requirement (String) state.get(requirement); String prompt 你是資深后端架構(gòu)師。根據(jù)需求輸出實現(xiàn)計劃要求 1. 列出需要創(chuàng)建的類及其職責 2. 標注每個類之間的依賴關(guān)系 3. 計劃不超過 200 字 需求%s .formatted(requirement); String plan chatModel.generate(prompt); return Map.of(plan, plan); } }condition 邊是 LangGraph4j 的核心needFix 方法返回 true 時回到 codegen 節(jié)點false 時進入 reviewer 節(jié)點。這樣模型生成錯了也不怕executor 節(jié)點拿到的編譯錯誤會被拼進新一輪生成的 Prompt形成錯誤反饋-重新生成的閉環(huán)。注意節(jié)點函數(shù)的入?yún)⒑头祷刂刀际?Map變量名要和狀態(tài)定義時的 key 保持一致。組裝工具調(diào)用要注意 langgraph4j 的機制和 LangChain4j 的 AiServices 不太一樣——工作流節(jié)點里需要你自己把 ChatModel 和工具的執(zhí)行結(jié)果串聯(lián)起來。常見的做法是復用 LangChain4j 的 AiServices把它綁定工具類后作為一個整體節(jié)點調(diào)用private MapString, Object codeGenNode(MapString, Object state) { CodeGenerator agent AiServices.builder(CodeGenerator.class) .chatModel(chatModel) .tools(new CodeExecutionTools()) .build(); String requirement (String) state.get(requirement); String plan (String) state.get(plan); String lastError state.get(execResult) null ? : (String) state.get(execResult); String code agent.generate(requirement, plan, lastError); return Map.of(sourceCode, code); }這里 AiServices 內(nèi)部已經(jīng)把 ToolCalling 的消息循環(huán)封裝好了模型請求調(diào)用工具框架自動執(zhí)行工具方法再把結(jié)果回傳給模型直到模型給出最終答案。你只需要在界面接口里定義 generate 方法并標注 SystemMessage 和 UserMessage 模板即可這就是 LangChain4j 把 Java 接口變成 Agent 的標準方式。3.4 流式輸出與進度推送SSE 把過程反饋給前端工作流跑起來后如果整個操作要等 30 秒才返回前端的體驗是災難。我一般用 SSEServer-Sent Events把每個節(jié)點的執(zhí)行狀態(tài)實時推給前端。后端在節(jié)點入口往 Spring 的 SseEmitter 里寫一條進度事件前端在畫布對應節(jié)點上亮燈。LangGraph4j 本身沒有內(nèi)置 SSE 支持但你可以用一個全局的 WorkflowProgressPublisher 組件節(jié)點里調(diào)用它發(fā)事件Controller 層暴露 SSE 接口訂閱。Go 的實現(xiàn)不復雜SseEmitter 存進 ConcurrentHashMap節(jié)點狀態(tài)變化時遍歷發(fā)送前端用 EventSource 接收。注意 SseEmitter 默認超時時間是 30 秒工作流超過這個時間要記得在初始化時顯式設(shè)置更長超時。4. Vue3 可視化編排從拖拽畫布到應用管理的一體化前端4.1 畫布的數(shù)據(jù)模型一個 JSON 就是一個工作流可視化編排的本質(zhì)是所見即所得地編輯一個 JSON后端拿著這個 JSON 再把它翻譯成 LangGraph4j 的 StateGraph。所以前端畫布的數(shù)據(jù)模型一定要工作流對齊而不是只顧畫得好看。我維護的數(shù)據(jù)結(jié)構(gòu)長這樣{ nodes: [ { id: n1, type: agent, label: 代碼生成, config: { model: qwen2.5-coder:32b, temperature: 0.2 } }, { id: n2, type: tool, label: 執(zhí)行器, config: { toolName: runJavaCode } }, { id: n3, type: condition, label: 評審通過, config: { condition: review.passed true } } ], edges: [ { source: n1, target: n2, label: normal }, { source: n2, target: n3, label: normal }, { source: n3, target: n1, label: false }, { source: n3, target: end, label: true } ], global: { maxRetry: 3, timeoutSeconds: 120 } }node 的 config 字段是給屬性面板用的每個節(jié)點的類型不同配置項也不同。agent 節(jié)點要選模型和調(diào)參tool 節(jié)點要選工具名和入?yún)?。后端解析這個 JSON 時按 type 分發(fā)到不同的節(jié)點工廠這樣就實現(xiàn)了一次編排、到處執(zhí)行。4.2 節(jié)點面板、連線和屬性表單的 Vue3 實現(xiàn)Vue3 實現(xiàn)拖拽畫布選 vue-flow 最省力它對 Vue3 Composition API 支持得很好節(jié)點拖拽、連線、縮放的交互開箱即用。核心組件結(jié)構(gòu)是左側(cè)一個節(jié)點物料面板中間是畫布右側(cè)是選中節(jié)點的屬性表單三個區(qū)域的數(shù)據(jù)流都匯到一個 reactive 對象上script setup import { ref, reactive, computed } from vue import { VueFlow, useVueFlow } from vue-flow/core import vue-flow/core/dist/style.css import AgentNode from ./nodes/AgentNode.vue import ToolNode from ./nodes/ToolNode.vue const nodes ref([]) const edges ref([]) const selectedNode ref(null) // 左側(cè)物料面板的拖拽把節(jié)點類型寫進 dataTransfer // 畫布 drop 事件里根據(jù)類型創(chuàng)建節(jié)點對象。 function onDragStart(event, type) { event.dataTransfer.setData(application/flow-type, type) event.dataTransfer.effectAllowed move } function onDrop(event) { const type event.dataTransfer.getData(application/flow-type) const position project({ x: event.clientX, y: event.clientY }) nodes.value.push({ id: node-${Date.now()}, type, position, config: defaultConfig(type) }) } // 選中節(jié)點后它的 config 直接綁定到右側(cè)表單組件 // 表單的每一項都是動態(tài)渲染的節(jié)點類型決定渲染哪些字段。 const selectedConfig computed(() selectedNode.value?.config || {}) /script核心思路就兩條節(jié)點類型決定默認配置和屬性表單的渲染字段選中節(jié)點和屬性表單之間用 selectedNode 單例綁定。屬性表單這里有一個 Vue3 動態(tài)增刪表單項的經(jīng)典需求——agent 節(jié)點的環(huán)境變量是不定長的我直接用 v-for 渲染一組 key-value 輸入框添加和刪除按鈕只操作數(shù)組的 push 和 splice配 deep 監(jiān)聽同步到畫布節(jié)點的 configdiv v-for(env, index) in selectedConfig.envs :keyindex classenv-row input v-modelenv.key placeholder環(huán)境變量名 / input v-modelenv.value placeholder值 / el-button typedanger clickselectedConfig.envs.splice(index, 1)刪除/el-button /div el-button clickselectedConfig.envs.push({ key: , value: })添加環(huán)境變量/el-button這個表單項的增刪改查全在 reactive 對象上完成Vue3 的代理機制保證畫布節(jié)點同步刷新。整體畫布在工作中就是一個后臺管理系統(tǒng)里的復雜表單只是這個表單的結(jié)構(gòu)不是人定的是用戶自己拖出來的。4.3 應用管理與一鍵部署的前后端銜接可視化編輯只是平臺的前半段后半段是應用管理和一鍵部署。后端需要提供應用維度的 CRUD 接口創(chuàng)建應用、保存畫布 JSON、發(fā)布版本、查看部署狀態(tài)。我習慣把保存和發(fā)布拆成兩個動作——保存只寫數(shù)據(jù)庫草稿發(fā)布才真正觸發(fā)構(gòu)建和部署。這樣用戶頻繁調(diào)整畫布不會產(chǎn)生一堆垃圾部署記錄發(fā)布記錄表里每一行都可回滾。一鍵部署的后端實現(xiàn)是異步任務(wù)加日志流推送。收到發(fā)布請求后后端把應用 ID、畫布 JSON、模型配置打包成一個部署任務(wù)丟給線程池執(zhí)行。部署過程分四步生成后端工程骨架、寫入工作流配置、Maven 打包、Docker 構(gòu)建并啟動。每一步的日志都通過 SSE 實時推給前端用戶在瀏覽器里能看到構(gòu)建進度條一行一行滾動這是一鍵部署體驗的關(guān)鍵。PostMapping(/api/apps/{appId}/deploy) public SseEmitter deploy(PathVariable Long appId, RequestBody DeployRequest request) { SseEmitter emitter new SseEmitter(300_000L); deployService.submit(appId, request, emitter); return emitter; }SseEmitter 的超時時間我顯式設(shè)成了 300 秒因為首次構(gòu)建要拉 Maven 依賴和 Docker 基礎(chǔ)鏡像慢的時候能跑到 3 分鐘以上。前端 EventSource 創(chuàng)建后要監(jiān)聽 readyState 變化部署完成后主動 close 連接避免無效連接占滿 Tomcat 線程。5. 從開發(fā)到上線的常見問題排查5 個高頻踩坑點5.1 SpringBoot 版本與 JDK 版本不匹配導致注解掃描失敗現(xiàn)象項目啟動后報 ClassNotFoundException: jakarta.servlet.http.HttpServlet或者 swagger 頁面打不開接口全 404。原因SpringBoot3 用的是 Jakarta EE 規(guī)范包名從 javax.* 改成了 jakarta.*。如果你的本機 JDK 是 8 或 11Maven 編譯時用了低版本 source/target生成的字節(jié)碼指向老的 javax 包運行時必然找不到類。還有一種情況是依賴里混入了 javax.servlet-api 的老傳遞依賴把包名污染了。解決JDK 鎖到 17 或 21在 pom 里顯式聲明 spring-boot-maven-plugin 的 jvmArguments 為 --add-opens java.base/java.langALL-UNNAMED防止反射告警。排除所有 javax.servlet 開頭的依賴改用 spring-boot-starter-web 統(tǒng)一管理。排查命令是 mvn dependency:tree看是否有老 servlet 傳遞進來。5.2 WebFlux 與 WebMVC 沖突SSE 流式輸出起不來的元兇現(xiàn)象后端加了 SSE 接口后項目啟動直接報 SpringApplicationApplicationContextException: Invalid web application: spring.main.web-application-typenone或者 SSE 接口永遠掛起不返回。原因LangChain4j 的流式響應在部分版本里默認依賴 WebFlux 的 Flux 類型引入 spring-boot-starter-webflux 后和原來的 spring-boot-starter-web 打架。Spring 容器檢測到兩個 WebApplicationFactory直接不知道用哪個只能報錯。解決確定自己用的是 Servlet 棧還是響應式棧。我用 Servlet 棧做 SSE就別引 webfluxLangChain4j 流式輸出用 StreamingChatModel 接口阻塞式訂閱 Flux 再轉(zhuǎn) SseEmitter。如果非得混用就把 web-application-type 顯式設(shè)為 servlet并保證 webflux 的依賴 scope 是 provided 或完全不引入。這個坑排查起來很費時間啟動日志里看到 invalid web application 直接去查依賴樹別去改配置瞎試。5.3 反代緩沖讓流式輸出變成等半天一次性吐出來現(xiàn)象本地 flow 輸出一個字一個字蹦部署到服務(wù)器之后前端 EventSource 要等幾十秒才收到第一批內(nèi)容。原因Nginx 默認開了 proxy_buffering會等后端響應全部寫完再一次性轉(zhuǎn)發(fā)給客戶端SSE 的 chunked 流式效果被徹底吞掉。這不是后端代碼的問題是網(wǎng)關(guān)層配置問題典型的上線才踩坑。解決在 Nginx 的 location 配置里加上 proxy_buffering off; 和 proxy_cache off;同時把 proxy_read_timeout 調(diào)到 300 秒以上。注意 SSE 用的是長連接心跳設(shè)置要同時照顧 Nginx 和瀏覽器兩側(cè)的超時。代碼里 SseEmitter 注釋里寫清楚必須配 Nginx 關(guān)緩沖防止部署的人不懂這個關(guān)聯(lián)關(guān)系。5.4 ToolCalling 工具參數(shù)缺失描述模型寧可拒絕也不調(diào)用現(xiàn)象日志里模型明確說需要調(diào)用工具但響應里的 tool_calls 是空的或者傳過來一個空的 JSON 參數(shù)業(yè)務(wù)側(cè)解析直接拋異常。原因大模型在不確定工具參數(shù)格式時會選擇不調(diào)用或傳入空值。而我早期寫的 ToolParam 只有參數(shù)名沒有描述模型不知道這個字符串應該填相對路徑還是絕對路徑。更隱蔽的是參數(shù)類型不匹配——工具方法聲明的是 Map模型傳過來的卻是 JSON 字符串。解決每個 ToolParam 都按格式 示例寫描述比如相對項目根目錄的文件路徑例如 src/main/java/Application.java。復雜參數(shù)不要用 Map定義成 POJO 配合 ToolParam 逐字段描述。另外要確認工具返回值轉(zhuǎn)成 String 后沒有截斷有些模型服務(wù)對 tool message 有長度限制超長返回會被丟棄表現(xiàn)為工具調(diào)用后模型沒有反應。5.5 Vue3 屬性繼承與表單校驗失效的連帶問題現(xiàn)象屬性面板里填的表單值保存后又變回原樣或者畫布的全屏按鈕在 Edge 瀏覽器里偶爾點不動鼠標點上去沒反應。原因這個現(xiàn)象和 Vue3 的組件屬性透傳機制有關(guān)。自定義組件如果根元素恰好是另一個組件外部傳入的 class、style、事件監(jiān)聽器會透傳到根組件上如果根組件內(nèi)部也用 v-bind$attrs容易產(chǎn)生事件覆蓋。比較典型的是 Element Plus 的 el-form-item 在動態(tài)渲染時label 屬性被透傳走了導致校驗觸發(fā)條件丟失表單值不更新另一種情況是畫布全屏按鈕的外層容器把 click 事件捕獲了。解決在 Vue3 組件里顯式聲明 inheritAttrs: false并手動在需要的位置綁定 $attrs避免事件和樣式透傳到意外的 DOM 節(jié)點上。動態(tài)表單項的 prop 屬性要用 index 拼接區(qū)分不要都用同一個固定字符串否則校驗狀態(tài)互相覆蓋。Edge 里點不動按鈕先懷疑是否被某個透明遮罩層擋住給按鈕加 z-index 并確保外層組件有明確的定位上下文別裸奔。注意以上五條是高頻但不是全部AI 應用平臺涉及的新依賴多、版本節(jié)奏快上線前把它當體檢列表過一遍能省出至少一個周末的排錯時間。6. 進階多模型路由、鏈路追蹤與壓測驗證平臺能跑通以后下一個問題就是成本和質(zhì)量。大模型 API 按 token 計費代碼生成場景一次調(diào)用動輒幾千 token全公司都用最強的 32B 模型扛不住。我一般會在網(wǎng)關(guān)層做模型路由分發(fā)而這正是多路召回思路的工程化落地——把用戶請求先做意圖分類簡單任務(wù)翻譯、格式化、解釋報錯直接落到一個輕量模型上復雜任務(wù)生成完整項目、多文件改造才轉(zhuǎn)發(fā)到強模型。public interface ModelRouter { String route(String intent, int estimatedInputTokens); } Component public class DefaultModelRouter implements ModelRouter { Override public String route(String intent, int estimatedInputTokens) { if (estimatedInputTokens 3000 || intent.startsWith(codegen:)) { return strong; } return fast; } }估 token 的辦法不精確但夠用中文字符按 1.5 倍估算代碼字符按 0.4 倍估算取整加余量。另外鏈路追蹤要趁早接工作流的每個節(jié)點執(zhí)行耗時、模型調(diào)用的 token 消耗、工具調(diào)用的成敗全都要落日志traceId 從請求進來就生成并貫穿 SSE 和異步任務(wù)。我用的是最樸素的方案——MDC put traceIdlogback 輸出到控制臺和文件排障時按 traceId grep 一次拿到全鏈路。微服務(wù)規(guī)模大了再上 SkyWalking 也不遲單機階段別過度設(shè)計。壓測驗證重點關(guān)注兩個指標工作流單次完成時間 P95 和部署任務(wù)的并發(fā)上限。前者決定用戶體驗后者決定平臺的穩(wěn)定性。用壓測工具模擬 50 個并發(fā)用戶同時觸發(fā)代碼生成工作流觀察數(shù)據(jù)庫連接池和線程池是否成為瓶頸。LangGraph4j 的節(jié)點執(zhí)行是阻塞式的但節(jié)點之間沒有共享狀態(tài)可以放心加 Async 把無依賴的節(jié)點并行化。我自己踩過的教訓是剛開始為圖省事把所有工具方法都加上 synchronized結(jié)果多路召回一上線就串行排隊P95 從 8 秒暴漲到 40 秒。后來改成工具內(nèi)部用無狀態(tài)設(shè)計只在寫文件時用臨時文件隔離壓測直接達標。這個平臺的完整落地路徑是SpringBoot3 接模型能力LangGraph4j 編排復雜工作流ToolCalling 打通系統(tǒng)邊界Vue3 把這一切變成可視化操作。到了后期你會意識到平臺最大的價值不是某一個 AI 能力而是把散落在各種腳本里的 AI 調(diào)用沉淀成了可編排、可觀測、可回滾的標準化應用。希望這些思路和踩坑記錄能幫到你少走一段我走過的彎路。本文還有配套的精品資源點擊獲取