1. 為什么 Java 后端一碰 Agent 就容易“翻車”1.1 從一次線上事故說起Agent 的“幻覺”是怎么變成生產(chǎn)事故的去年年底我接手了一個客服工單自動分類的項(xiàng)目。業(yè)務(wù)方的訴求很樸素用戶提交工單后系統(tǒng)自動判斷它屬于“退款”“物流”“賬號”還是“其他”然后路由到對應(yīng)的處理隊(duì)列。聽起來是個典型的文本分類任務(wù)用 Java 寫個 Spring Boot 服務(wù)調(diào)一下大模型接口就完事了。第一版我確實(shí)是這么干的。Java 后端接收工單拼一段 Prompt調(diào)用大模型拿到返回的 JSON解析后寫庫。上線第一天準(zhǔn)確率看著還行大概 85% 左右。但到了第三天問題來了有一批工單被分到了“退款”隊(duì)列可內(nèi)容明明是“我的賬號登不上去”。客服同事炸了說系統(tǒng)在亂分。我去翻日志發(fā)現(xiàn)模型返回的 JSON 里category字段寫的是“退款”但reason字段寫的是“用戶無法登錄賬號疑似賬號問題”。也就是說模型自己都自相矛盾了。這就是典型的Agent 幻覺它不是在“判斷”而是在“編造一個看起來合理的答案”。更麻煩的是這種幻覺不是每次都出現(xiàn)。同樣的工單早上分對了下午分錯了。你沒法用傳統(tǒng)的單元測試去覆蓋它因?yàn)榇竽Ｐ偷妮敵霰举|(zhì)上是概率性的。Java 后端習(xí)慣了“輸入確定輸出確定”的世界突然面對一個“輸入確定輸出隨機(jī)”的組件整個工程體系都開始搖晃。1.2 確定性工作流的核心思路把“自由發(fā)揮”關(guān)進(jìn)籠子問題的根源在于我們把太多決策權(quán)交給了模型。模型既要理解文本又要判斷分類還要生成理由最后還要輸出格式正確的 JSON。任何一個環(huán)節(jié)“自由發(fā)揮”結(jié)果就不可控。我的解決思路是把 Agent 的能力拆解成多個確定性步驟每一步只讓模型做一件小事并且用工作流引擎把步驟串起來中間加上校驗(yàn)和兜底。這就是“確定性工作流”的核心。具體來說我用了 n8n 作為工作流編排引擎。n8n 是一個開源的工作流自動化工具支持可視化編排、條件分支、循環(huán)、錯誤處理而且可以通過 HTTP 節(jié)點(diǎn)和 Java 后端無縫對接。Java 后端負(fù)責(zé)業(yè)務(wù)邏輯和數(shù)據(jù)持久化n8n 負(fù)責(zé)調(diào)度模型調(diào)用和流程控制。這樣做的直接好處是Token 消耗從原來的每次請求 3000 降到了 600 左右降幅超過 80%。為什么因?yàn)樵瓉硎且淮涡园汛蠖紊舷挛娜o模型讓它“自由發(fā)揮”現(xiàn)在是分步驟、按需調(diào)用每一步的 Prompt 都很短而且很多步驟根本不需要調(diào)模型用規(guī)則就能搞定。1.3 這套方案適合誰Java 后端 n8n Agent 的三角組合如果你是一個 Java 后端開發(fā)正在被 Agent 的幻覺問題折磨或者你正在做 AI Agent 相關(guān)的項(xiàng)目發(fā)現(xiàn) Token 成本居高不下那這套方案就是為你準(zhǔn)備的。它不需要你放棄 Java 技術(shù)棧也不需要你從頭學(xué) Python 的 LangChain你只需要理解 n8n 的基本用法剩下的還是你熟悉的 Spring Boot、MyBatis、Redis。另外如果你正在準(zhǔn)備 Java 面試面試官問到“AI Agent 怎么保證輸出穩(wěn)定性”“Token 怎么優(yōu)化”這類問題這套方案里的思路和參數(shù)計(jì)算過程可以直接拿去當(dāng)案例講。我后來面過幾個候選人能講清楚“為什么要把 Agent 拆成工作流”的人屈指可數(shù)。2. 整體架構(gòu)設(shè)計(jì)Java 做骨架n8n 做神經(jīng)Agent 做肌肉2.1 為什么不讓 Java 直接調(diào)模型非要引入 n8n很多人第一反應(yīng)是我 Java 里寫個HttpClient調(diào)模型接口不就行了為什么要多引入一個 n8n這不是增加復(fù)雜度嗎我一開始也是這么想的。但實(shí)際做下來發(fā)現(xiàn) Java 直接調(diào)模型有幾個繞不過去的坑第一流程控制太啰嗦。比如“先判斷工單類型如果是退款類再調(diào)一次模型提取退款金額如果不是直接走規(guī)則路由”。這種分支邏輯在 Java 里就是一堆if-else嵌套改起來痛苦測起來更痛苦。而在 n8n 里就是一個可視化節(jié)點(diǎn)拖拽連線邏輯一目了然。第二重試和降級不好做。模型接口偶爾超時、返回格式錯誤Java 里要寫一堆try-catch和重試邏輯。n8n 自帶錯誤處理節(jié)點(diǎn)可以配置“失敗后重試 3 次每次間隔 2 秒如果還失敗就走降級分支”。第三調(diào)試和觀測困難。Java 里調(diào)模型日志打出來是一大坨 JSON想看某一步的輸入輸出得翻半天。n8n 每個節(jié)點(diǎn)都有獨(dú)立的執(zhí)行記錄點(diǎn)進(jìn)去就能看到這一步的輸入是什么、輸出是什么、耗時多少排查問題效率高一個數(shù)量級。所以我的架構(gòu)是Java 后端負(fù)責(zé)“重”的部分——數(shù)據(jù)庫操作、事務(wù)管理、權(quán)限校驗(yàn)、對外 APIn8n 負(fù)責(zé)“輕”的部分——流程編排、模型調(diào)用、條件判斷、重試降級。兩者通過 HTTP 接口通信Java 把任務(wù)丟給 n8nn8n 處理完把結(jié)果回調(diào)給 Java。2.2 工作流拆解把一次 Agent 調(diào)用拆成五個確定性步驟以工單分類為例我把原來的一次模型調(diào)用拆成了五個步驟預(yù)處理Java 后端對工單文本做清洗去掉 HTML 標(biāo)簽、多余空格、敏感信息脫敏然后提取關(guān)鍵字段標(biāo)題、描述、用戶等級。規(guī)則預(yù)判n8n 里先用規(guī)則節(jié)點(diǎn)判斷如果工單標(biāo)題包含“退款”“退貨”等關(guān)鍵詞直接標(biāo)記為退款類不走模型。這一步能覆蓋大約 40% 的工單Token 消耗為零。模型分類剩下的工單調(diào)用模型做分類但 Prompt 只包含“請判斷以下工單屬于哪個類別只返回類別名稱不要解釋”。輸出被限制在一個枚舉值里。結(jié)果校驗(yàn)n8n 里加一個校驗(yàn)節(jié)點(diǎn)檢查模型返回的類別是否在預(yù)設(shè)的枚舉列表中。如果不在走降級分支標(biāo)記為“待人工處理”?；卣{(diào)寫庫校驗(yàn)通過后n8n 把結(jié)果回調(diào)給 Java 后端Java 寫入數(shù)據(jù)庫并觸發(fā)后續(xù)路由。這樣拆下來每次模型調(diào)用的 Token 消耗從原來的 3000 降到了 600 左右。而且因?yàn)槊恳徊降妮敵龆际谴_定的要么是枚舉值要么是布爾值幻覺的影響被限制在了最小范圍內(nèi)。2.3 數(shù)據(jù)流轉(zhuǎn)與接口約定Java 和 n8n 怎么“對話”Java 和 n8n 之間的通信我用的是最簡單的 HTTP JSON。Java 后端暴露一個/api/agent/dispatch接口接收工單 ID然后異步調(diào)用 n8n 的 Webhook 地址把工單數(shù)據(jù)傳過去。n8n 處理完后調(diào)用 Java 的/api/agent/callback接口把結(jié)果寫回。這里有幾個細(xì)節(jié)要注意異步處理Java 調(diào) n8n 的 Webhook 時不要同步等待結(jié)果否則工單量一上來線程池直接被打滿。我的做法是 Java 把任務(wù)丟到消息隊(duì)列RabbitMQ然后由一個消費(fèi)者去調(diào) n8nn8n 處理完回調(diào) Java 的接口Java 再更新工單狀態(tài)。冪等性n8n 的回調(diào)可能因?yàn)榫W(wǎng)絡(luò)問題重復(fù)發(fā)送Java 的 callback 接口必須做冪等處理。我的做法是用工單 ID 處理批次號作為唯一鍵重復(fù)回調(diào)直接忽略。超時設(shè)置n8n 調(diào)模型接口的超時時間設(shè)置為 15 秒Java 調(diào) n8n 的超時時間設(shè)置為 30 秒。為什么是 30 秒因?yàn)?n8n 內(nèi)部可能有多步模型調(diào)用每步 15 秒留一點(diǎn)緩沖。3. 核心細(xì)節(jié)解析Prompt 設(shè)計(jì)、Token 計(jì)算與 MCP 協(xié)議3.1 Prompt 瘦身從 3000 Token 到 600 Token 的具體操作原來我的 Prompt 是這樣的你是一個客服工單分類助手。請仔細(xì)閱讀以下工單內(nèi)容判斷它屬于以下哪個類別退款、物流、賬號、其他。 請給出你的判斷理由并按照 JSON 格式返回包含 category 和 reason 兩個字段。 工單標(biāo)題{title} 工單描述{description} 用戶等級{userLevel} 歷史工單{history}這個 Prompt 的問題在于它讓模型做了太多事。模型既要理解文本又要判斷類別還要生成理由最后還要保證 JSON 格式正確。任何一個環(huán)節(jié)出錯整個結(jié)果就廢了。優(yōu)化后的 Prompt 是這樣的判斷以下工單類別只返回類別名稱不要解釋。 類別退款、物流、賬號、其他。 工單{title} {description}就這么短。為什么敢這么短因?yàn)槲野选吧衫碛伞边@一步去掉了。理由對業(yè)務(wù)沒有直接價值客服同事只看類別。而且“只返回類別名稱”這個約束讓模型的輸出空間被壓縮到了四個詞幻覺的概率大幅降低。Token 計(jì)算也很直觀原來的 Prompt 大約 800 個中文字符加上歷史工單和用戶等級總共 3000 Token。優(yōu)化后工單標(biāo)題和描述加起來平均 200 字加上指令總共 600 Token 左右。按 GPT-4 的定價每次調(diào)用成本從 0.09 元降到了 0.018 元降幅正好 80%。3.2 輸出校驗(yàn)用 Java 枚舉把模型的“自由發(fā)揮”堵死模型返回的類別名稱必須嚴(yán)格匹配 Java 后端的枚舉值。我在 Java 里定義了一個TicketCategory枚舉public enum TicketCategory { REFUND(退款), LOGISTICS(物流), ACCOUNT(賬號), OTHER(其他); private final String label; TicketCategory(String label) { this.label label; } public static TicketCategory fromLabel(String label) { for (TicketCategory category : values()) { if (category.label.equals(label)) { return category; } } return null; } }n8n 回調(diào) Java 時Java 用fromLabel方法校驗(yàn)。如果返回 null說明模型輸出了枚舉之外的值直接標(biāo)記為“待人工處理”不寫庫。這樣即使模型幻覺了也不會污染業(yè)務(wù)數(shù)據(jù)。這里有個經(jīng)驗(yàn)枚舉值不要用英文直接用中文。因?yàn)槟Ｐ蛯χ形念悇e的理解更直接你讓它返回“REFUND”它有時候會返回“refund”或者“Refund”大小寫不一致校驗(yàn)就失敗了。用中文“退款”模型基本不會寫錯。3.3 MCP 協(xié)議在其中的角色讓工具調(diào)用也變成確定性步驟MCPModel Context Protocol是最近比較火的一個協(xié)議簡單說就是讓模型能夠調(diào)用外部工具。比如模型可以調(diào)用“查詢訂單狀態(tài)”的工具然后根據(jù)返回結(jié)果判斷工單類別。但在我的方案里MCP 不是必須的。為什么因?yàn)?MCP 的本質(zhì)是讓模型“自主決定調(diào)用哪個工具”這又引入了不確定性。模型可能該調(diào) A 工具卻調(diào)了 B 工具或者該調(diào)工具卻直接編了個答案。我的做法是把工具調(diào)用也變成工作流里的確定性節(jié)點(diǎn)。比如“查詢訂單狀態(tài)”這個操作我在 n8n 里直接寫一個 HTTP 節(jié)點(diǎn)去調(diào)訂單服務(wù)然后把結(jié)果作為上下文傳給模型。模型不需要知道工具的存在它只需要基于我給的上下文做判斷。這樣做的代價是靈活性降低但換來了確定性。對于工單分類這種場景確定性比靈活性重要得多。如果你做的是開放式對話 Agent那 MCP 確實(shí)有用但如果是業(yè)務(wù)流程自動化我建議還是用工作流把工具調(diào)用固定下來。4. 實(shí)操過程從零搭建一套確定性工作流4.1 環(huán)境準(zhǔn)備n8n 的部署與 Java 項(xiàng)目的對接配置n8n 的部署很簡單官方提供了 Docker 鏡像。我用的是 Docker Compose配置文件如下version: 3 services: n8n: image: n8nio/n8n:latest ports: - 5678:5678 environment: - N8N_BASIC_AUTH_ACTIVEtrue - N8N_BASIC_AUTH_USERadmin - N8N_BASIC_AUTH_PASSWORDyour_password - WEBHOOK_URLhttp://your-server-ip:5678 volumes: - ./n8n_data:/home/node/.n8n啟動后訪問http://your-server-ip:5678用配置的用戶名密碼登錄。然后創(chuàng)建一個新的 Workflow添加一個 Webhook 節(jié)點(diǎn)作為入口。Java 這邊我用 Spring Boot 寫了一個AgentDispatchService核心代碼如下Service public class AgentDispatchService { Autowired private RestTemplate restTemplate; private static final String N8N_WEBHOOK_URL http://your-server-ip:5678/webhook/ticket-classify; public void dispatch(Ticket ticket) { MapString, Object payload new HashMap(); payload.put(ticketId, ticket.getId()); payload.put(title, ticket.getTitle()); payload.put(description, ticket.getDescription()); payload.put(callbackUrl, http://your-java-server/api/agent/callback); restTemplate.postForEntity(N8N_WEBHOOK_URL, payload, String.class); } }注意callbackUrl這個字段它是告訴 n8n 處理完后往哪里回調(diào)。這樣 n8n 就不需要硬編碼 Java 的地址靈活性更好。4.2 n8n 工作流搭建Webhook、規(guī)則節(jié)點(diǎn)、模型節(jié)點(diǎn)、校驗(yàn)節(jié)點(diǎn)、回調(diào)節(jié)點(diǎn)在 n8n 里我搭建了這樣一個工作流第一步Webhook 節(jié)點(diǎn)。接收 Java 傳來的 JSON 數(shù)據(jù)包含ticketId、title、description、callbackUrl。第二步規(guī)則判斷節(jié)點(diǎn)。用 n8n 的 IF 節(jié)點(diǎn)判斷title是否包含“退款”“退貨”“退錢”等關(guān)鍵詞。如果包含直接設(shè)置category為“退款”跳到第五步。如果不包含進(jìn)入第三步。第三步模型調(diào)用節(jié)點(diǎn)。用 n8n 的 HTTP Request 節(jié)點(diǎn)調(diào)用大模型接口。請求體里拼接 Prompt{ model: gpt-4, messages: [ { role: user, content: 判斷以下工單類別只返回類別名稱不要解釋。類別退款、物流、賬號、其他。工單{{$json.title}} {{$json.description}} } ], temperature: 0 }注意temperature設(shè)置為 0這是讓模型輸出盡可能確定的關(guān)鍵參數(shù)。溫度越高模型越“有創(chuàng)意”幻覺越多。對于分類任務(wù)溫度必須為 0。第四步校驗(yàn)節(jié)點(diǎn)。用 n8n 的 Switch 節(jié)點(diǎn)檢查模型返回的category是否在[退款, 物流, 賬號, 其他]列表中。如果在進(jìn)入第五步如果不在設(shè)置category為“待人工處理”。第五步回調(diào)節(jié)點(diǎn)。用 HTTP Request 節(jié)點(diǎn)把ticketId和categoryPOST 到 Java 的callbackUrl。整個工作流跑下來平均耗時 2-3 秒其中模型調(diào)用占 1.5 秒左右規(guī)則判斷和校驗(yàn)幾乎不耗時。4.3 Java 回調(diào)接口的實(shí)現(xiàn)與冪等處理Java 的回調(diào)接口長這樣RestController RequestMapping(/api/agent) public class AgentCallbackController { Autowired private TicketService ticketService; PostMapping(/callback) public ResponseEntityString callback(RequestBody CallbackRequest request) { boolean updated ticketService.updateCategory( request.getTicketId(), request.getCategory(), request.getBatchNo() ); if (updated) { return ResponseEntity.ok(success); } else { return ResponseEntity.ok(duplicate); } } }updateCategory方法里做了冪等處理public boolean updateCategory(Long ticketId, String category, String batchNo) { String key ticket:callback: ticketId : batchNo; Boolean success redisTemplate.opsForValue().setIfAbsent(key, 1, 1, TimeUnit.HOURS); if (Boolean.FALSE.equals(success)) { return false; } // 更新數(shù)據(jù)庫 ticketMapper.updateCategory(ticketId, category); return true; }用 Redis 的setIfAbsent做分布式鎖同一個工單同一個批次的回調(diào)只處理一次。為什么用批次號而不是只用工單 ID因?yàn)橥粋€工單可能因?yàn)槿斯ぶ匦掠|發(fā)而再次進(jìn)入工作流這時候批次號不同應(yīng)該允許更新。4.4 參數(shù)計(jì)算Token 消耗、并發(fā)量與成本估算假設(shè)每天有 10000 個工單其中 40% 被規(guī)則節(jié)點(diǎn)攔截不需要調(diào)模型。剩下 6000 個工單需要調(diào)模型。優(yōu)化前每個工單 3000 Token6000 個工單就是 1800 萬 Token。按 GPT-4 輸入價格 0.03 元/千 Token 計(jì)算每天成本 540 元。優(yōu)化后每個工單 600 Token6000 個工單就是 360 萬 Token。每天成本 108 元。每天節(jié)省 432 元一個月節(jié)省約 13000 元。這還沒算上因?yàn)榛糜X導(dǎo)致的錯誤分類帶來的客服返工成本。并發(fā)量方面n8n 單實(shí)例大概能扛住每秒 50 個請求。如果工單量更大可以部署多個 n8n 實(shí)例用 Nginx 做負(fù)載均衡。Java 這邊用消息隊(duì)列削峰把并發(fā)壓力轉(zhuǎn)移到隊(duì)列里n8n 按自己的節(jié)奏消費(fèi)。5. 常見問題與排查技巧實(shí)錄5.1 模型返回格式不對怎么辦三種兜底策略即使 Prompt 里寫了“只返回類別名稱”模型有時候還是會返回“這個工單屬于退款類別”這種帶解釋的句子。我的兜底策略有三種策略一字符串匹配。在 n8n 的校驗(yàn)節(jié)點(diǎn)里不要求完全相等而是用“包含”判斷。比如返回“這個工單屬于退款類別”只要包含“退款”就認(rèn)為是退款類。這個策略能覆蓋 90% 的格式異常。策略二正則提取。如果字符串匹配也失敗用正則表達(dá)式從返回文本里提取類別關(guān)鍵詞。比如/(退款|物流|賬號|其他)/匹配到哪個就是哪個。策略三降級人工。如果前兩種都失敗直接標(biāo)記為“待人工處理”不寫庫。這個策略雖然增加了人工成本但保證了數(shù)據(jù)質(zhì)量。這三種策略在 n8n 里用 Switch 節(jié)點(diǎn)串聯(lián)優(yōu)先級從高到低。5.2 n8n 工作流執(zhí)行超時原因分析與解決路徑n8n 工作流超時最常見的原因是模型接口響應(yīng)慢。我遇到過幾次模型接口平均響應(yīng)時間從 1.5 秒突然漲到 10 秒導(dǎo)致 n8n 工作流超時。排查思路先看 n8n 的執(zhí)行記錄找到耗時最長的節(jié)點(diǎn)。如果是模型節(jié)點(diǎn)說明是模型接口的問題。檢查模型接口的監(jiān)控?cái)?shù)據(jù)看是不是整體延遲升高還是個別請求慢。如果是整體延遲考慮切換模型或者增加超時時間。如果是個別請求慢考慮加緩存。我的解決路徑是在 n8n 的模型節(jié)點(diǎn)上配置重試失敗后重試 2 次每次間隔 1 秒。如果重試后還失敗走降級分支標(biāo)記為“待人工處理”。同時Java 后端加了一個監(jiān)控告警當(dāng)“待人工處理”的比例超過 10% 時發(fā)通知給運(yùn)維。5.3 高頻踩坑速查表問題現(xiàn)象可能原因排查方法解決方案模型返回類別不在枚舉中溫度參數(shù)過高檢查 n8n 模型節(jié)點(diǎn)的 temperature 設(shè)置設(shè)置為 0n8n 回調(diào) Java 失敗callbackUrl 配置錯誤檢查 n8n 執(zhí)行記錄中的 HTTP 請求節(jié)點(diǎn)確認(rèn) Java 服務(wù)地址和端口同一工單被重復(fù)處理冪等鍵設(shè)計(jì)不當(dāng)檢查 Redis 中的 key 是否存在用 ticketId batchNo 作為冪等鍵Token 消耗突然升高Prompt 中混入了歷史數(shù)據(jù)檢查 n8n 模型節(jié)點(diǎn)的請求體移除不必要的上下文規(guī)則節(jié)點(diǎn)攔截率下降關(guān)鍵詞列表過期統(tǒng)計(jì)最近一周的工單標(biāo)題定期更新關(guān)鍵詞列表5.4 獨(dú)家避坑技巧我踩過的三個坑坑一不要用模型的“理由”字段做業(yè)務(wù)判斷。我一開始讓模型返回reason字段然后 Java 里根據(jù)reason的內(nèi)容做二次判斷。結(jié)果發(fā)現(xiàn)模型有時候category寫“退款”reason寫“用戶無法登錄”兩者矛盾。后來我把reason去掉了只保留category問題消失?？佣8n 的 Webhook 節(jié)點(diǎn)要設(shè)置認(rèn)證。默認(rèn)情況下n8n 的 Webhook 是公開的任何人都能調(diào)。我在測試環(huán)境沒注意結(jié)果被掃描到了有人往我的 Webhook 發(fā)了一堆垃圾數(shù)據(jù)。后來加了 Basic Auth并且只允許 Java 后端的 IP 訪問?？尤Ｐ徒涌诘牟l(fā)限制要提前確認(rèn)。我用的是某個國內(nèi)模型接口默認(rèn)并發(fā)是 10。工單量一上來n8n 并發(fā)調(diào)模型直接觸發(fā)限流大量請求失敗。后來我在 n8n 里加了隊(duì)列節(jié)點(diǎn)把并發(fā)控制在 8 以下問題解決。6. 擴(kuò)展思考這套方案還能怎么用6.1 從工單分類擴(kuò)展到其他場景合同審核、代碼審查、數(shù)據(jù)清洗這套“Java n8n Agent”的確定性工作流不只能做工單分類。我后來把它用在了合同審核上Java 后端上傳合同 PDFn8n 調(diào)用 OCR 提取文本然后用規(guī)則節(jié)點(diǎn)判斷合同類型再調(diào)模型提取關(guān)鍵條款金額、期限、違約責(zé)任最后校驗(yàn)并寫庫。Token 消耗比原來一次性讓模型讀全文降低了 70%。代碼審查也是類似Java 后端接收 Git 提交n8n 調(diào)模型分析代碼變更規(guī)則節(jié)點(diǎn)先過濾掉純格式變更模型只分析邏輯變更最后輸出審查意見。數(shù)據(jù)清洗場景下n8n 的規(guī)則節(jié)點(diǎn)可以處理 80% 的格式問題模型只處理剩下的 20% 復(fù)雜情況。6.2 面試怎么講把“Token 直降 80%”變成你的項(xiàng)目亮點(diǎn)如果你在準(zhǔn)備 Java 面試面試官問到 AI 相關(guān)項(xiàng)目你可以這樣講“我做過一個客服工單自動分類的項(xiàng)目用 Java 做后端n8n 做工作流編排大模型做分類。一開始模型幻覺很嚴(yán)重Token 消耗也高。后來我把一次模型調(diào)用拆成了五個確定性步驟用規(guī)則節(jié)點(diǎn)攔截了 40% 的請求Prompt 從 3000 Token 壓縮到 600 Token成本降低了 80%。同時用 Java 枚舉做輸出校驗(yàn)用 Redis 做冪等保證了數(shù)據(jù)一致性?！边@段話里包含了架構(gòu)設(shè)計(jì)、成本優(yōu)化、數(shù)據(jù)一致性三個技術(shù)點(diǎn)面試官很容易順著往下問。而且“Token 直降 80%”這個數(shù)字很具體比說“優(yōu)化了性能”有說服力得多。6.3 后續(xù)優(yōu)化方向緩存、批處理與模型微調(diào)這套方案還有幾個優(yōu)化方向。緩存對于重復(fù)的工單描述可以在 n8n 里加一個 Redis 緩存節(jié)點(diǎn)先查緩存命中直接返回不用調(diào)模型。批處理如果工單量很大可以把多個工單合并成一個請求發(fā)給模型讓模型一次性返回多個分類結(jié)果進(jìn)一步降低 Token 消耗。模型微調(diào)如果業(yè)務(wù)場景固定可以收集一批標(biāo)注數(shù)據(jù)微調(diào)一個小模型替代通用大模型成本和延遲都能大幅降低。不過這些優(yōu)化都有前提緩存要考慮失效策略批處理要考慮單條失敗的影響微調(diào)要考慮數(shù)據(jù)標(biāo)注的成本。我的建議是先把確定性工作流跑通再根據(jù)實(shí)際瓶頸逐步優(yōu)化不要一上來就追求完美。我個人在實(shí)際操作中的體會是Agent 的幻覺問題本質(zhì)上不是模型的問題而是工程的問題。你把模型當(dāng)成一個“不確定的組件”然后用工程手段去約束它、校驗(yàn)它、兜底它問題就解決了一大半。剩下的那一小半交給人工兜底別想著 100% 自動化。