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