1. 先说清楚Agent 为什么会“睁眼说瞎话”做 Java 后端的人对“确定性”这件事是有执念的。数据库事务要么提交要么回滚接口要么返回 200 要么抛异常缓存过期时间精确到秒。但当你第一次把一个 Agent 接进生产环境你会发现之前那套确定性的世界观被狠狠挑战了——它会在你完全没有准备的时候一本正经地输出一个不存在的订单号、编造一段不存在的接口文档甚至把一个“是”的问题回答成“否”。我最早在项目里集成 Agent 时就在用户投诉工单里看到了这么一条用户问“我的退款到账了吗”Agent 回复“您的退款已于昨天 15:23 到账请注意查收”。实际上退款单还在审批流程里压根没打款。用户当然炸了而我作为后端连锅都甩不出去——因为这个回复是 Agent 生成的不是我们业务代码返回的。这就是 LLM 的幻觉问题。它的本质是概率生成不是数据库查询。你在 prompt 里让它“根据上下文回答”它就真的会“根据上下文编造”。对 Java 后端工程师来说幻觉问题比其他岗位更致命。前端拿到一段错误的 JSON 顶多页面显示异常但我这边 Agent 是要对接订单系统、库存系统、支付回调的一个幻觉结果发出去可能直接把脏数据写进业务表。所以我当时给自己定了一个原则Agent 不能直接碰业务它只能在我规定的流程里干我让它干的活。那怎么实现我用的是 n8n。2. 解决思路把“自由发挥”变成“按流程执行”2.1 核心原则确定性逻辑与生成能力分离我接触过很多团队一上来就把 Agent 当“超人”用所有的输入都丢给大模型让它自己理解、自己规划、自己调用工具、自己返回结果。这种全自主模式在 demo 里很酷但一上生产就翻车原因很简单——你把不可控的生成过程放在了链路最核心的位置。我后来换了一种思路六个字该定的全定死。业务流程的走向、每一步做什么、调用什么接口、数据怎么校验全部由代码和流程引擎决定。大模型只做它擅长的两件事理解用户的自然语言意图、生成自然语言回复。除此之外所有的“判断”和“执行”都交给确定性代码。这个思路用 n8n 落地是这样的我把一条业务链路画成一个可视化工作流里面大量使用 HTTP Request、IF、Switch、Code 这类确定性节点只在两个位置接大模型——入口处做意图识别出口处做回复润色。中间的参数提取、数据库查询、状态判断、调用下游接口全部是固定逻辑。这样做的最大好处是幻觉的影响范围被限制住了。大模型即使胡说了什么也只会胡说在一个很小的范围内不会影响业务状态。2.2 为什么是 n8n而不是自己写编排框架你可能想说我自己在 Java 里写个状态机、搞个责任链不也能实现同样的效果吗能但成本完全不同。我当时考虑过三条路第一在 Spring Boot 里自己写 Agent 编排框架用一个 Map 存流程状态再用策略模式扩展节点。第二接一个现成的 Agent 框架让 Agent 自己拆解任务。第三用 n8n 这类可视化工作流工具来做编排。选第三条是因为它有几个无可替代的优势。首先是可视化。Java 代码里的流程逻辑你再怎么画流程图业务方也看不懂。但 n8n 的流程是直接画出来的业务同学在 Canvas 上能直接看到“用户输入→识别意图→查订单→生成回复”每一步长什么样。其次是热更新。Java 代码改流程要发版、要灰度、要回滚n8n 里改一个节点保存就生效。第三是生态。n8n 自带几百个集成节点HTTP、数据库、消息队列、文件、邮件全是拖拽式的省掉大量重复的对接代码。还有一个很实际的原因n8n 的 AI Agent 节点是专门为“可控调用”设计的它可以限定模型只能调用你给定的工具列表而不是让它自由发挥。从工程角度看这相当于给 Agent 装了一个“笼子”。2.3 工作流拆解Agent 变成 Pipeline 的四个层次我习惯把一条 Agent 工作流拆成四层每一层都有明确的职责和确定的实现方式。接入层负责接收请求。n8n 用 Webhook 节点暴露一个 URLJava 后端把这个 URL 当成普通 HTTP 接口来调用请求体里带用户 ID、消息内容和业务上下文。路由层负责判断任务类型。用 IF 或 Switch 节点根据业务规则把请求分到不同分支。比如判断是否包含手机号是否命中缓存是否属于高风险操作。这一层全都是规则不需要大模型。执行层负责调用后端接口完成实际操作。用 HTTP Request 节点调 Java 写好的订单查询、库存扣减等 REST API返回值存到工作流的上下文变量里供后续使用。生成层才轮到 LLM 出场。把执行层拿到的真实数据拼成 prompt让大模型基于这些数据生成最终回复。关键是数据不是编出来的是接口返回的模型只是在“转述”真实结果。这四层拉通之后你再看整条链路大模型的参与比例可能只有 20%剩下的 80% 都是确定性节点在跑。Token 成本大幅下降幻觉基本消失而这些都是顺带的结果。根本原因是——你把能确定的部分全部确定化了。3. 实操一n8n 企业级部署与 Java 侧接入3.1 部署方案与配置要点n8n 的部署不算难但要按生产标准来有几个点必须注意。我用的部署方式是 Docker Compose单机模式跑在云服务器上核心配置如下services: n8n: image: n8nio/n8n:latest environment: - N8N_HOSTworkflow.example.com - N8N_PORT5678 - N8N_PROTOCOLhttps - DB_TYPEpostgresdb - DB_POSTGRESDB_HOSTpostgres - DB_POSTGRESDB_DATABASEn8n - DB_POSTGRESDB_USERn8n - DB_POSTGRESDB_PASSWORDchange-me - N8N_ENCRYPTION_KEYyour-32-char-secret - N8N_DIAGNOSTICS_ENABLEDfalse - N8N_METRICStrue - EXECUTIONS_DATA_PRUNEtrue - EXECUTIONS_DATA_MAX_AGE168 volumes: - n8n_data:/home/node/.n8n ports: - 5678:5678 restart: unless-stopped有几个配置是生产环境必须开的。数据库必须用 PostgreSQL默认的 SQLite 只适合本地体验生产环境用 SQLite 就是给自己埋雷。工作流版本、执行历史、并发锁这些特性都依赖数据库的健壮性。N8N_ENCRYPTION_KEY 必须显式配置不然 n8n 每次重启会重新生成密钥之前存的所有凭证数据库密码、API Key全部解密失败。这个坑我踩过重启完整个工作流全部报 unauthorized当时还以为是代码问题。EXECUTIONS_DATA_PRUNE 和 EXECUTIONS_DATA_MAX_AGE控制执行日志的保留时间。n8n 默认把所有执行详情都存下来跑一段时间磁盘就满了。我设置保留 7 天既够排查问题又不至于撑爆磁盘。部署完还要做三件事nginx 反向代理并开启 HTTPS、配置管理员账号、把工作流设置为 Active 状态。HTTPS 那一步尤其重要因为后面 Java 后端调用 Webhook 时如果 n8n 用 HTTP 明文传输Token 和业务数据等于裸奔。提示n8n 的工作流默认不会自动保存新版本对应的备份。改重要的生产工作流之前先在工作流右上角菜单里拖一份 Save As 副本或者在 Git 里接入版本管理。不然你改挂了想回滚只能手动重建。3.2 Webhook 接入Java 调用 n8n 工作流n8n 部署好之后创建第一个工作流时添加一个Webhook节点作为 Trigger。配置里有几个关键项HTTP MethodPOSTPath自定义路径比如/agent/queryResponse设置返回规则比如Response Body用 JSON 格式、指定返回工作流最后一个节点的输出n8n 会生成一个完整的 Webhook URL形如https://workflow.example.com/webhook/agent/query。Java 这边就简单了。我直接用 Spring Boot 的 RestTemplate新版项目也可以换成 WebClient封装一个调用类Service public class N8nWorkflowClient { private final RestTemplate restTemplate; public N8nWorkflowClient(RestTemplate restTemplate) { this.restTemplate restTemplate; } public AgentResponse callAgentQuery(AgentRequest request) { String webhookUrl https://workflow.example.com/webhook/agent/query; HttpHeaders headers new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); headers.set(X-Source-System, java-order-backend); headers.set(X-Request-Id, request.getRequestId()); HttpEntityAgentRequest entity new HttpEntity(request, headers); ResponseEntityAgentResponse response restTemplate.exchange( webhookUrl, HttpMethod.POST, entity, AgentResponse.class ); return response.getBody(); } }我额外在 header 里加了两个字段X-Source-System标识调用来源X-Request-Id做链路追踪。n8n 里可以在 Webhook 节点的“Incoming Webhook”配置中把这两个 header 作为字段提取出来后续节点直接用$(Webhook).item.json.headers[X-Request-Id]引用。这个 ID 会贯穿整个工作流出问题的时候排查日志特别方便。Java 端还要做超时控制。我给 RestTemplate 设置了连接超时 3 秒、读取超时 30 秒。因为后面要接 LLM 调用大模型推理本身就需要时间30 秒是一个比较保守但不过分的值。如果 n8n 那边因为模型超时或限流返回 5xxJava 端要能快速失败并走自己的降级逻辑。3.3 回调 Java 接口签名与重试机制n8n 工作流在执行过程中经常需要调 Java 后端的业务接口查数据、写状态。这个方向反过来n8n 通过 HTTP Request 节点调用 Spring Boot 的接口。这里有一个安全细节很多人忽略n8n 调用后端接口时不能只靠内网 IP 白名单接口需要做签名校验。理由是内网一旦有任何一个服务被 SSRF 利用攻击者就能通过 n8n 的 HTTP Request 节点打到你的后端任意接口。这相当于把 n8n 变成了一个跳板。我做了一套简单的 HMAC 签名方案流程是这样的n8n 的 HTTP Request 节点配置 HeaderX-Timestamp带当前时间戳X-Signature带签名值。签名值用 Java 和 n8n 共享的 Secret Key 计算对请求路径 时间戳 请求体 JSON做 HMAC-SHA256再 Base64 编码。Spring Boot 这边用一个拦截器HandlerInterceptor统一校验签名和时间戳的有效期5 分钟以内。n8n 里计算签名可以用 Code 节点const crypto require(crypto); const secretKey your-shared-secret-key; const timestamp Date.now().toString(); const path /api/order/query; const body JSON.stringify($json.body || {}); const signStr path timestamp body; const signature crypto .createHmac(sha256, secretKey) .update(signStr) .digest(base64); return { timestamp, signature };Java 拦截器里的校验逻辑大致如下Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String timestamp request.getHeader(X-Timestamp); String signature request.getHeader(X-Signature); if (timestamp null || signature null) { return reject(response, missing signature headers); } long ts Long.parseLong(timestamp); if (Math.abs(System.currentTimeMillis() - ts) 5 * 60 * 1000) { return reject(response, timestamp expired); } String body readBody(request); String signStr request.getRequestURI() timestamp body; String expected hmacSha256Base64(signStr, secretKey); if (!MessageDigest.isEqual(expected.getBytes(StandardCharsets.UTF_8), signature.getBytes(StandardCharsets.UTF_8))) { return reject(response, invalid signature); } return true; }这个拦截器写好后所有 n8n 调用的接口都走一遍校验安全性基本到位。要注意MessageDigest.isEqual是恒定时间比较不能直接用equals否则有计时攻击风险。n8n 侧还要配重试。HTTP Request 节点的设置里可以开Retry On Fail我一般设置重试 2 次、间隔 1 秒。因为 Java 接口偶尔会有 GC 停顿或连接池短暂打满重试能平滑过去。但要注意不是所有接口都适合自动重试。如果接口是幂等的查询、状态更新重试没问题。如果接口会触发非幂等操作比如创建订单、扣减库存就不要在 n8n 里开自动重试宁可让工作流失败走人工处理。4. 实操二打造确定性 Agent 工作流的核心环节4.1 路由分流什么任务进 LLM什么任务不进一个 Agent 工作流里如果所有请求都走 LLMToken 成本根本压不下来。我做的第一个优化就是分流能走规则的任务绝不走模型。n8n 的 Switch 节点可以在流程入口处分流我按这几个维度判断简单 FAQ命中知识库的固定问答直接返回预置答案。敏感操作涉及支付、删除、改密等操作不进 LLM直接调用业务接口完成并触发人工审核。需要推理的任务判断用户意图不明确、需要归纳总结的才进入 LLM 分支。实际操作里我会在 Webhook 节点后面接一个 Code 节点用正则和历史数据做个快速分类const message $json.message || ; // 判断是否包含订单号 const orderNoPattern /(ORD|SO)\d{10,}/i; // 判断是否包含手机号 const phonePattern /1[3-9]\d{9}/; // 判断是否涉及退款 const refundKeywords [退款, 退钱, 退货, refund]; const hitOrderNo orderNoPattern.test(message); const hitPhone phonePattern.test(message); const hitRefund refundKeywords.some(kw message.includes(kw)); // 路由简单查询走规则分支复杂咨询走LLM分支 let route llm; if (hitOrderNo !hitRefund) { route order_query; } else if (hitPhone !hitRefund) { route user_query; } else if (!hitOrderNo !hitPhone) { route llm; } return { route, message };这样一个很常见的“查订单”请求直接路由到 HTTP Request 节点查数据库然后拼一个固定模板返回全程零 Token。还有一类请求必须进人工而非 LLM情绪激烈的投诉。我加了关键词列表“投诉”“起诉”“媒体曝光”命中后直接转人工工单不让模型去安抚一个暴怒的用户。让 LLM 处理高压场景容易答错话出了事责任说不清。这种场景宁可慢一点也不能赌。4.2 结构化输出约束与校验闭环LLM 在 n8n 里返回的内容默认是个文本字符串。如果我们需要它返回 JSON它有时候会给你多包一层 markdown 代码块有时候注释里多一行中文直接导致 Java 侧 JSON 解析失败。我的经验是不要指望模型自觉要在流程上做硬约束。n8n 的 AI Agent 节点支持设置Output Schema即结构化输出本质是让模型厂商在生成时强制走 JSON Schema 校验。我一般这样定义{ type: object, properties: { answer: { type: string, description: 给用户的最终回复 }, needHumanConfirm: { type: boolean, description: 是否需要人工介入 }, confidence: { type: number, description: 置信度0到1之间 } }, required: [answer, needHumanConfirm, confidence] }有了这个 Schema模型返回的 JSON 就会严格符合结构不会出现字段缺失或类型错误。但 Schema 只能保证“类型对”不能保证“内容对”。所以我还在 n8n 里加了一个校验节点用 Code 节点做二次校验比如请确认结果是否包含订单号、字段是否为空、置信度是否低于阈值。低于阈值的直接走一个人工兜底分支丢到群机器人或者工单系统里不把低质结果返回给用户。这道校验闭环非常关键。它把“模型输出”从不可信变成了可验证边界一下就清晰了——模型说什么是它的自由但能不能出门我说了算。4.3 RAG 检索增强的落地细节Agent 幻觉的重灾区之一是对业务知识的捏造。比如用户问“你们的退货政策是什么”模型如果没有真实资料就会根据网上的通用知识编一套跟你的真实政策完全不同。解决这个问题的标准做法是 RAGRetrieval-Augmented Generation检索增强生成。n8n 对 RAG 有原生的支持可以通过向量数据库节点 LLM 节点组合实现。我在 n8n 里搭建的 RAG 流程是知识文档按段落切块通过 OpenAI Embedding 或其他厂商的向量化接口转成向量存到 Qdrant 或 pgvector。请求进来时先用同一套 Embedding 接口把用户问题转成向量在向量库里检索 Top-K 相关文档再把检索结果和用户问题一起拼进 prompt让模型“仅基于以下资料回答”。这里有个 Java 后端参与的点知识库的更新是 Java 侧发起的。业务文档如最新的运费规则、售后政策变更时Java 后端调一个 n8n 的“知识索引” Webhook触发重新向量化和入库。这样保证 Agent 用的知识永远是最新版本不会出现政策都改了两周Agent 还在按旧规则回答的尴尬。RAG 拼 prompt 时我踩过一个坑检索返回的 Top-K 不要贪多。一开始我配了 Top-8结果相关文档太长把模型上下文撑爆了回答质量反而下降。后来压到 Top-3并在每个片段前标注来源编号准确率明显提升。如果你发现 Agent 回答总是“借鉴”了无关片段先检查是不是召回太多了。4.4 人工确认节点Human-in-the-loop有些操作就算确定性流程已经走得通我还是不敢放 Agent 全自动。比如批量发送营销消息、修改用户账户等级这类影响面大的操作。我在 n8n 工作流里加了一个“人工确认”节点做法是工作流跑到一个特定分支时调用企业微信或钉钉机器人发送一条审批消息审批人点击“通过”Webhook 才会继续往下执行。用 n8n 实现这个逻辑不复杂核心是两个工作流配合主工作流执行到人工确认节点时先把业务数据存到一个临时表或 n8n 的 Waiting 节点然后调用企业微信机器人接口发送一条带 action 的卡片消息。回调工作流处理人员点击“通过”后企业微信回调 n8n 的一个独立 Webhook这个 Webhook 去临时表取出挂起的任务继续执行后续流程。这个设计在系统里撑起了一道人工防线。从后端视角看这样等于在自动化流程里加了一个“分布式事务的人肉 commit”环节——模型和代码都只能发起请求真正生效的是人工最后按下的确认键。5. Token 直降 80% 的工程实践5.1 Token 消耗画像钱都花在哪了降成本之前先得知道钱花在哪了。我给自己的系统做了一个 Token 消耗画像结论是三大块第一大块是无效输入。每次把全量上下文塞给模型时一大半都是不相关的内容。比如用户问了句“运费怎么算”我把整个订单详情、商品列表、用户历史全传进去了。模型没看这些但 Token 照收不误。第二大块是无效输出。模型不仅回答用户的问题还经常带着“好的经过分析”“我需要提醒您”这类冗余前缀。生成式模型的输出是逐字计费的这些废话全是成本。第三大块是无脑重试。Agent 一次调用失败整个链路重新跑一遍LLM 节点重新生成Token 双倍扣除。这种情况下钱不是花在“解决问题”上而是花在“重新犯错”上。所以降低 Token 的核心是一条条堵住这些漏点。5.2 六个我实测有效的降本手段手段一路由分流除了点肯定降前文已经详细讲了。我这边上线后的实际数据原来 100% 的请求都进 LLM分流之后只有约 25% 的请求真正调用了模型其余的全走规则分支。Token 用量直接先砍一半以上。手段二压缩 prompt 模板把长段背景描述、角色设定压成短句并把每次动态拼接的数据控制在小范围内。我给 n8n 的 AI Agent 节点设定的 prompt 模板从最初的 1200 字压到 400 字。同样的问题模型表现没有变差但每次调用省了 800 个输入 Token。背景n8n 里每个 AI Agent 节点都可以单独配置 System Prompt。我建议你们也做一次 prompt 瘦身把“你是…”这类身份描述控制在 50 字以内把“请用以下格式回答”的说明尽量挪到 Output Schema 里而不是写在自然语言中。手段三结果缓存用户问的问题高度重复时缓存能省掉重复调用。我在 n8n 加了一个“缓存查询”子流程路由层先计算请求的 hash对消息内容做归一化然后查 Redis。命中则直接返回缓存的答案未命中才进完整 LLM 流程并把结果写回 Redis 设置 3 分钟过期。我实测过下午高峰期重复问题占比能到 40%这个缓存机制差不多能再省 20% 的 Token。手段四用小模型做简单任务不是所有任务都需要最强模型的推理能力。我在 n8n 里把任务按复杂度分了两个模型通道简单问答、意图分类用小模型复杂推理、长文本生成用能力更强的模型。同类场景下小模型的 Token 单价只是大模型的零头成本差距直接体现在账单上。手段五限制最大 Token 输出给每个 AI 节点的 Max Output Token 设上限最长回复限制在 300 Token 以内大多数客服回复几百字完全够用了。更关键的是限制输出了能让模型克制住长篇大论的冲动实际效果反而更利落。这里注意如果经常需要长输出如生成周报就要单独创建大 Token 上限的节点别一刀切。手段六延迟批量处理对不要求实时响应的场景工作流里把响应模式设置为异步把任务放进队列攒一批后统一用离线任务处理。虽说单看每次调用没省但批量任务能合并上下文比如把 10 条同类请求合并成一次向量化请求总体 Token 花费能摊薄不少。5.3 降本后的效果对比与告警兜底这几个措施全做完之后我把一段稳定运行两周的数据拉出来对比Token 的整体用量相对原始“全自主 Agent”方案下降了约 82%稳定完成“直降 80%”的目标但实际降幅甚至比预期还高一点。量化下来大概是这样的按每日 5000 次请求量估算改造前每天 Token 消耗折合成本约 220 元改造后约 40 元。流量不变的情况下单日成本直接砍掉八成。但降成本不能牺牲稳定性。我加了两层兜底第一层是可观测性。n8n 开启 Prometheus 指标把工作流执行时间、失败率、Token 用量全部上报到 Grafana。我在 Java 侧还做了一个定时任务每 5 分钟拉一次 n8n API 的/metrics接口这个接口不用 Webhook走内网访问即可一旦检测到 Token 消耗突增比如超过日均值的两倍就触发告警。Token 突增往往意味着有人改了流程或者某类请求突然命中不了缓存提前发现能防止月底账单翻车。第二层是降级开关。Java 调用 n8n 的时候如果 n8n 返回 5xx 或超时自动走降级逻辑简单问题返回预置 FAQ复杂问题提示用户稍后再试并生成工单。降级逻辑本身不调用模型所以即使在 n8n 整个挂掉的情况下系统也能保持基础可用。提示千万别把降级逻辑做成“看模型心情随机应变”这样反而会成为新的不可控点。降级逻辑必须是完全确定性的是提前写死的一条固定路径。6. 常见问题排查实录6.1 Webhook 调不通这是接入 n8n 最常见的坑。Java 这边报 404 或 405但 n8n 里明明配置好了 Webhook 节点。我用过几次后总结先按这个顺序排查检查工作流是不是 Active 状态。n8n 的 Webhook 只有工作流处于 Active 时才会监听端口Inactive 状态下直接 404。检查 URL 路径和 Java 端配置的路径是否完全一致末尾有没有多余的斜杠。检查 n8n 的监听端口是不是被防火墙挡了。如果 Java 服务在另一台机器要确认 5678 端口对外可达或者在 nginx 层做代理。如果 Java 调用的 URL 和 n8n 面板里显示的 URL 不一样比如面板显示的是内网地址记得看下N8N_HOST配置是否正确。我曾经把N8N_HOST设成了内网 IP导致 n8n 生成的 Webhook URL 也是内网 IP外网调用永远不通。这里我建议一个省事儿的做法n8n 面板里直接把 Webhook URL 复制到浏览器或 curl 里调一遍确认通了再让 Java 接入问题能立刻隔离出来。6.2 Agent 输出 JSON 频繁解析失败如果你已经配置了 Output Schema但有时候还是解析失败多半是发生在模型返回空值或返回了额外字段的边界场景里。不要试图让模型彻底绝不出错而是在解析外面再包一层“救援逻辑”如果JSON.parse失败尝试清理掉 markdown 代码块标记再尝试一次再不行就返回一个固定错误提示给用户。我在 n8n 的 Code 节点里写了一个容错解析函数简单好用function safeParse(str) { try { return JSON.parse(str); } catch (e) { // 尝试去掉 markdown 代码块 const cleaned str.replace(/json|/g, ).trim(); try { return JSON.parse(cleaned); } catch (e2) { return null; } } } const parsed safeParse($json.output); if (!parsed) { return { error: failed_to_parse, raw: $json.output }; } return parsed;还有个容易忽略的点n8n 的某些节点会把你定义好的 JSON 字符串再转义一次导致 Java 侧接收时看到的是{\\answer\\:\\...这样带反斜杠的字符串。遇到这种问题通常是 n8n 节点里把输出当成字符串拼接了需要在 Code 节点里显式地 JSON.stringify 或提前 parse 一次保证最终落到 Webhook 响应体里的是真正的 JSON 对象而不是转义文本。6.3 并发场景下的数据一致性n8n 的工作流在默认配置下是会在队列里顺序执行的但如果你把并发数调高或者同一个 Webhook 被 Java 多条线程同时调用就会遇到 n8n 节点内部状态被并发覆盖的问题。典型症状是请求 A 和请求 B 同时进入工作流后续节点读取上下文时两个请求的变量互相串了。原因很容易理解工作流级别的变量是共享的并发执行时会互相覆盖。所以我的原则是同一时间只有一个工作流实例在写状态变量跨请求共享的数据一律走外部存储Redis、数据库不要依赖工作流的内存变量。如果确实需要高并发处理另起一个思路Java 侧先用消息队列把请求削峰n8n 开多个工作流实例每个实例处理一个队列任务不要在一个 Webhook 工作流里硬扛高并发。6.4 n8n 工作流执行变慢的排查工作流从 1 秒变成 5 秒绝大多数情况不是 n8n 本身的问题而是链路中某一个节点拖慢了整体。我用 profiling 的方式排查优先级从高到低第一查 LLM 调用耗时。模型推理本来就要几秒属于正常。如果各次耗时波动很大多半是模型服务端限流或者 n8n 与模型服务之间的网络链路易波动。把 LLM 节点加缓存和超时控制能明显改善。第二查外部接口。n8n 里的 HTTP Request 节点调下游 Java 接口如果 Java 接口本身慢n8n 也会跟着慢。这里可以直接看 n8n 的执行详情面板每个节点耗时会列出来一眼看出瓶颈。第三查数据库查询。如果你在 n8n 里用 PostgreSQL 节点直接查数记得看下有没有建索引。血泪教训我有一张表 5 万行没建索引n8n 里查一次全表扫描要 3 秒建完索引后毫秒级返回。n8n 的执行详情里会显示每个节点的具体耗时这个功能一定要用起来。最后要说的是如果你的 n8n 跑在单机 Docker 里CPU 和内存资源不够也会导致执行变慢。监控一下容器资源如果长期超过 70%就需要扩容或者调整并发数了。n8n 单机默认的并发不高很多慢其实是排队排出来的不是执行慢。7. 写在最后Java 后端与 Agent 的正确相处方式做完这个项目之后我最大的体会是Java 后端和 Agent 的关系不该是“把业务交给 Agent”而是“让 Agent 在业务规则划好的跑道里跑”。n8n 在这里扮演了一个很称职的执行导演——它不负责灵光一现它负责把每一个环节卡在正确的位置上。我也越来越觉得Java 工程师做 Agent 项目的核心优势恰恰是我们骨子里对“确定性”的偏执。大模型越自由我们越要用工程手段给它上枷锁。把流程拆碎、把数据校验闭环、把 Token 的成本明细算清楚这一套下来Agent 才能真正从“玩具”变成生产工具。至于 n8n它只是那根最顺手的缰绳而已。最后再分享一个实际处理中的小技巧不要在 n8n 的 AI Agent 节点里写太多花哨的提示词简单直接一点。那些看起来炫酷的角色扮演和复杂指令往往会让模型在边界场景里自作主张。把重心放在工作流的结构上而不是 prompt 的文学性上这才是工程化的正路。