企业官网建设流程全解析

1. 为什么 Java 后端需要重新审视 Agent 的接入方式

Java 后端圈子最近一年有个很明显的现象：不管业务需不需要，老板都要求“把 AI 接进来”。于是很多团队第一反应是直接在 Spring Boot 里塞一个 HTTP 客户端，调大模型的 Chat Completions 接口，把返回的文本往业务逻辑里一丢，完事。这种做法在 Demo 阶段没问题，一旦进入生产环境，问题就集中爆发了——模型返回的 JSON 格式飘忽不定、字段名今天叫orderId明天叫order_id、该返回数字的地方返回了“大约三件”、该走退款流程的给你编了一个根本不存在的订单号。这就是所谓的Agent 幻觉。

幻觉不是模型“坏了”，而是概率生成的本质决定的。你让它自由发挥，它就一定会在某个时刻给你惊喜。Java 后端工程师的思维习惯是强类型、确定性、可测试，而大模型的输出天然是弱约束、概率性、不可测的。这两者之间的鸿沟，靠“写个更长的 Prompt”是填不平的。真正能填平它的，是把 Agent 的能力约束在一条确定性的工作流里，让模型只负责它擅长的语义理解和内容生成，而流程的走向、数据的校验、状态的流转全部交给代码和编排引擎来控制。

这就是 n8n 这类工作流编排工具切入的价值点。n8n 本身是一个可视化的自动化编排平台，支持几百种节点，能通过 Webhook、定时器、消息队列等方式触发，把大模型调用、条件判断、数据转换、HTTP 请求、数据库操作串成一条有向无环图。关键在于，图的走向是确定的，模型只是图上的一个节点，它的输出会被后续的校验节点、分支节点严格约束。Java 后端不需要把编排逻辑写死在代码里，而是把“不确定的部分”交给 n8n 管理，“确定的部分”仍然由 Java 服务兜底。

标题里提到的“Token 直降 80%”也不是噱头。很多人调 Agent 时习惯把全部上下文、全部工具描述、全部历史对话一股脑塞进 Prompt，Token 消耗自然爆炸。而工作流编排的思路是：按需注入上下文，按阶段裁剪历史，用结构化输出替代自由文本。一个订单查询场景，如果模型只需要输出{"intent":"query_order","orderId":"12345"}这十几个 Token，而不是输出一段两百字的自然语言再由后端正则去抠，Token 消耗的差距是数量级的。再叠加缓存、去重、分支裁剪，80% 的降幅在真实项目里是能摸到的。

这篇文章面向的是有 Java 后端基础、正在或准备把 Agent 接入业务系统的工程师。我会从整体设计思路讲起，拆解 n8n 工作流的核心节点配置，给出 Java 侧如何与 n8n 对接的完整方案，最后把我踩过的坑和排查技巧整理成速查表。读完之后，你应该能自己搭出一条“模型负责理解、工作流负责决策、Java 负责执行”的确定性链路。

2. 整体设计思路：把不确定性关进确定的笼子

2.1 核心矛盾：概率输出 vs 强类型业务

先把这个矛盾说透。Java 后端的业务代码，方法签名是确定的，参数类型是确定的，返回值是确定的，异常是确定的。一个createOrder(Long userId, List<Item> items)方法，你闭着眼睛都知道它要什么、返回什么。但大模型的输出是什么？是一段文本。哪怕你用了 JSON mode，它也只是“大概率”是合法 JSON，字段名和类型仍然可能漂移。

我见过最典型的翻车场景：客服 Agent 需要判断用户意图，Prompt 里写了“请返回 intent 字段，值为 refund 或 query”。结果模型返回了{"intent": "refund_request"}，后端代码里switch只认refund，直接走到 default 分支，用户申请退款被当成未知意图，工单卡死。这种问题不是模型不听话，是你把“意图归一化”这种确定性工作交给了概率模型。

正确的分工应该是：模型只做它擅长的——把自然语言翻译成结构化意图；归一化、校验、路由、执行全部由确定性代码完成。n8n 在这中间扮演的角色，就是那个“确定性代码”的可视化载体。它把模型输出接过来，用 Switch 节点做路由，用 Set 节点做字段映射，用 IF 节点做校验，任何一步不符合预期就走到兜底分支，绝不把脏数据往下游放。

2.2 为什么选 n8n 而不是纯 Java 编排

有同学会问：这些逻辑我用 Java 写不就行了，为什么要引入 n8n？答案是迭代速度和可观测性。Agent 的 Prompt 和流程几乎每周都在调，如果每次调整都要改 Java 代码、走一遍编译打包发布，效率极低。n8n 的工作流是配置化的，改一个节点、加一个分支，保存即生效，产品经理都能在界面上看懂流程走向。

更重要的是可观测性。n8n 每次执行都有完整的执行记录，每个节点的输入输出、耗时、是否报错都清清楚楚。当 Agent 出问题时，你能一眼看到是模型节点返回了脏数据，还是校验节点逻辑写错了，而不是在 Java 日志里大海捞针。对于 Agent 这种“黑盒”系统，可观测性就是生命线。

当然，n8n 不是银弹。它适合做编排层，不适合做重计算和强事务。订单落库、库存扣减、支付调用这些必须由 Java 服务完成，n8n 通过 HTTP 节点调用 Java 暴露的接口即可。这样职责清晰：n8n 管流程，Java 管业务。

2.3 确定性工作流的三层结构

我习惯把整条链路分成三层，这个分层在多个项目里验证过，比较稳。

第一层是接入层，负责接收请求、鉴权、限流。这一层用 Java 的 Spring Boot 实现，对外暴露 REST 接口，内部把请求转发给 n8n 的 Webhook。为什么不直接让前端调 n8n？因为 n8n 的鉴权体系相对简单，而 Java 侧有成熟的 JWT、权限、审计体系，把入口收在 Java 这边更安全。

第二层是编排层，也就是 n8n 工作流。它接收 Java 传来的结构化请求，调用大模型做意图识别和参数抽取，然后根据意图走不同的分支，每个分支里做数据校验和转换，最后把结果回传给 Java。

第三层是执行层，还是 Java 服务。n8n 校验完的数据，通过 HTTP 节点回调 Java 的业务接口，由 Java 完成真正的数据库操作和事务控制。执行结果再原路返回。

这个三层结构的好处是：模型的不确定性被限制在编排层内部，接入层和执行层都是纯确定性代码。即使模型抽风，最坏情况是编排层走到兜底分支返回“无法理解”，绝不会污染业务数据。

2.4 Token 优化的核心逻辑

Token 降 80% 不是靠某个神奇参数，而是靠三个动作叠加。

第一个动作是结构化输出替代自由文本。让模型输出{"intent":"refund","orderId":"12345"}而不是“用户想要退款，订单号是 12345”。前者大约 15 个 Token，后者大约 30 个 Token，看起来只差一倍，但考虑到输出 Token 通常比输入 Token 贵，而且自由文本还需要后端解析，综合成本差距更大。

第二个动作是上下文按需注入。不要每次调用都把全部工具描述、全部历史对话塞进去。n8n 的工作流可以在不同分支里注入不同的上下文。意图识别阶段只需要注入意图列表，参数抽取阶段才注入对应意图的参数 schema。这样每次调用的输入 Token 能砍掉一大半。

第三个动作是缓存与去重。相同或相似的请求，如果意图和参数完全一致，直接走缓存，不调模型。n8n 里可以用 Redis 节点做缓存判断，命中就跳过模型节点。在客服、查询这类高频重复场景，缓存命中率能到 40% 以上，这部分 Token 直接省掉。

三个动作叠加，80% 的降幅是保守估计。我实测过一个订单查询场景，优化前每次调用约 1800 Token，优化后约 320 Token，降幅 82%。

3. n8n 工作流核心节点配置与实操

3.1 环境准备与 n8n 部署要点

n8n 的部署方式有几种：npm 全局安装、Docker 部署、源码部署。生产环境我强烈建议用 Docker，版本可控，迁移方便。基础命令是docker run -d --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n n8nio/n8n，但这条命令只适合本地测试，生产环境还要考虑数据库、队列、并发。

n8n 默认用 SQLite 存工作流和执行记录，单机小流量够用，但一旦并发上来，SQLite 的写锁会成为瓶颈。生产环境建议切到 PostgreSQL，通过环境变量DB_TYPE=postgresdb、DB_POSTGRESDB_HOST等配置。执行模式也要从默认的main切到queue，配合 Redis 做任务队列，这样才能横向扩展 worker。

注意：n8n 的 queue 模式需要额外部署 Redis，并且 worker 节点和主节点要共享同一个数据库。如果只是内部工具、日调用量几千次，单机 SQLite 完全够用，不要过度设计。

环境变量里有一个容易忽略的点：N8N_ENCRYPTION_KEY。这个 key 用于加密凭据，如果不显式设置，n8n 每次重启会生成新的，导致之前存的凭据全部解不开。生产环境务必固定这个值，并且做好备份。

3.2 Webhook 触发节点：Java 与 n8n 的握手点

Java 侧调用 n8n 的入口是 Webhook 节点。配置很简单：HTTP Method 选 POST，Path 设一个有意义的名字比如agent-dispatch，Authentication 选 Header Auth，配一个自定义的 header 名和值作为简单鉴权。

Webhook 节点收到的请求体，会作为后续节点的输入。Java 侧发过来的 JSON 建议长这样：

{ "requestId": "req_20250101_001", "userId": "u_12345", "sessionId": "s_abc", "userInput": "我想查一下上个月的订单", "context": { "channel": "app", "locale": "zh-CN" } }

requestId用于全链路追踪，sessionId用于关联多轮对话，userInput是用户原始输入，context放一些环境信息。这个结构在 Java 侧用 DTO 定义好，序列化后 POST 过来。

提示：Webhook 节点默认会立即返回 200，不等后续节点执行完。如果你需要同步拿到结果，要在 Webhook 节点里把 Response Mode 改成Respond to Webhook Node，然后在流程末尾加一个 Respond to Webhook 节点返回结果。异步场景则保持默认，结果通过回调接口回传。

3.3 意图识别节点：让模型只做选择题

意图识别是整个工作流里第一个调模型的节点，也是最关键的一个。这里的核心原则是：把开放生成变成封闭选择。

具体做法是在 System Prompt 里明确列出所有合法意图，要求模型只能从中选一个，并且输出严格的 JSON。Prompt 大概长这样：

你是一个意图分类器。请根据用户输入，从以下意图中选择最匹配的一个： - query_order：查询订单 - refund_request：申请退款 - logistics_track：物流跟踪 - complaint：投诉建议 - unknown：无法识别 只输出 JSON，格式为 {"intent": "意图名", "confidence": 0.0到1.0之间的数字}。 不要输出任何其他内容。

模型节点用 n8n 的 OpenAI 节点或者 HTTP Request 节点调大模型接口都行。我倾向用 HTTP Request 节点，因为可以完全控制请求体，方便加response_format: {"type": "json_object"}参数强制 JSON 输出。

拿到模型输出后，不要直接信任。紧接着加一个 Code 节点做校验：解析 JSON，检查intent是否在合法列表里，检查confidence是否低于阈值。如果校验失败，走兜底分支，返回“无法理解，请重新描述”。这一步是确定性的，用 JavaScript 写几行就行：

const validIntents = ['query_order', 'refund_request', 'logistics_track', 'complaint']; const raw = $input.first().json; let parsed; try { parsed = typeof raw.content === 'string' ? JSON.parse(raw.content) : raw.content; } catch (e) { return [{ json: { intent: 'unknown', confidence: 0, reason: 'parse_error' } }]; } if (!validIntents.includes(parsed.intent) || parsed.confidence < 0.6) { return [{ json: { intent: 'unknown', confidence: parsed.confidence || 0, reason: 'invalid_intent' } }]; } return [{ json: parsed }];

这段代码的价值在于，它把模型的概率输出“硬化”成了确定性的枚举值。后续的 Switch 节点只认这几个值，不可能出现refund_request这种漏网之鱼。

3.4 参数抽取节点：按意图动态注入 Schema

意图确定之后，下一步是抽取该意图需要的参数。比如query_order需要orderId或timeRange，refund_request需要orderId和reason。这里的优化点是：不要把所有意图的参数 schema 一次性塞给模型，而是根据上一步的意图，只注入对应的 schema。

n8n 里可以用 Switch 节点根据intent分流，每个分支里放一个独立的模型调用节点，Prompt 里只写该意图的参数说明。这样每次调用的输入 Token 大幅减少。

以query_order为例，Prompt 是：

从用户输入中抽取订单查询参数，输出 JSON： {"orderId": "订单号或null", "timeRange": {"start": "YYYY-MM-DD或null", "end": "YYYY-MM-DD或null"}} 用户输入：{{ $json.userInput }}

输出同样要经过 Code 节点校验：orderId和timeRange至少有一个非空，日期格式要合法。校验通过才往下走。

实操心得：参数抽取的 Prompt 里，字段说明要写得极其明确，包括类型、是否可空、格式要求。我试过把“日期格式 YYYY-MM-DD”写清楚之后，模型返回错误格式的概率从 15% 降到了 2% 以下。另外，可以在 Prompt 里给一两个 few-shot 示例，效果更稳。

3.5 校验与路由节点：确定性的守门人

参数抽取完，进入校验与路由阶段。这一阶段完全不碰模型，纯代码逻辑。

校验分两类：格式校验和业务校验。格式校验用 Code 节点做，检查字段类型、格式、必填项。业务校验需要调 Java 接口，比如检查订单号是否真实存在、用户是否有权限查询该订单。n8n 里用 HTTP Request 节点调 Java 的校验接口，根据返回结果决定是否继续。

路由用 Switch 节点，根据intent和校验结果决定走向。比如query_order且校验通过，走查询分支；校验失败，走错误提示分支；unknown意图，走兜底分支。每个分支的终点都是一个 Respond to Webhook 节点或者回调 Java 的 HTTP 节点。

这里有个设计原则：任何分支都必须有明确的终点，不能有悬空的节点。n8n 允许节点不连接，但那样执行到那里就断了，用户等不到响应。我习惯在画完流程后，逐个检查每个 Switch 分支是否都有出口，每个出口是否都能到达响应节点。

3.6 结果回传与 Java 侧对接

n8n 处理完的结果，通过 HTTP Request 节点回调 Java 的业务接口。请求体里带上requestId、sessionId、intent、params、result等字段。Java 侧用一个 Controller 接收，根据intent分发到对应的 Service 执行。

Java 侧的对接代码大概是这样：

@RestController @RequestMapping("/api/agent") public class AgentCallbackController { @Autowired private AgentResultHandler handler; @PostMapping("/callback") public ResponseEntity<CallbackResponse> callback(@RequestBody AgentCallbackRequest request) { if (!requestValidator.isValid(request)) { return ResponseEntity.badRequest().body(CallbackResponse.fail("invalid request")); } try { AgentResult result = handler.handle(request); return ResponseEntity.ok(CallbackResponse.success(result)); } catch (BusinessException e) { return ResponseEntity.ok(CallbackResponse.fail(e.getMessage())); } } }

handler.handle里根据intent走不同的业务逻辑，比如query_order就调订单服务查库，refund_request就调退款服务。注意这里要做幂等控制，因为 n8n 的重试机制可能导致同一个requestId被回调多次。用 Redis 存requestId做去重，处理过的直接返回上次结果。

注意：Java 侧的回调接口要做好鉴权，不能裸奔。n8n 的 HTTP 节点支持配置 Header Auth，Java 侧校验这个 header。另外，回调接口的响应时间要控制好，n8n 的 HTTP 节点默认超时是 300 秒，但业务接口最好在几秒内返回，耗时操作走异步。

4. Token 优化的具体手段与实测数据

4.1 结构化输出带来的 Token 削减

前面提过结构化输出，这里给一组实测数据。同一个订单查询请求，自由文本输出平均 42 个 Token，结构化 JSON 输出平均 16 个 Token，输出侧省了 62%。输入侧因为 Prompt 里要写 JSON 格式说明，多了约 30 个 Token，但输出 Token 通常比输入贵 2 到 3 倍，综合下来还是省。

更重要的是，结构化输出让后续处理变简单了。自由文本需要正则或二次调模型解析，结构化 JSON 直接JSON.parse就行，省了一次模型调用，这部分的 Token 节省是隐性的但很可观。

4.2 上下文裁剪与按需注入

上下文裁剪的核心是只给模型它当前需要的信息。意图识别阶段，模型只需要知道有哪些意图，不需要知道每个意图的参数细节，也不需要知道历史对话。参数抽取阶段，模型只需要知道当前意图的参数 schema，不需要知道其他意图。

我做过对比：优化前，每次调用都把全部 5 个意图的描述、全部参数 schema、最近 10 轮对话历史塞进 Prompt，输入约 1500 Token。优化后，意图识别阶段输入约 200 Token，参数抽取阶段输入约 300 Token，两阶段合计 500 Token，输入侧省了 67%。

历史对话也不是完全不要，而是按需裁剪。如果当前请求是独立的新请求，历史对话可以不带；如果是多轮对话的后续轮次，只带最近 2 到 3 轮，并且只带与当前意图相关的轮次。n8n 里可以用 Code 节点根据sessionId从 Redis 取历史，做裁剪后再注入。

4.3 缓存策略与命中率提升

缓存是 Token 优化的放大器。n8n 里用 Redis 节点做缓存，key 用userInput的哈希，value 存模型输出。请求进来先查缓存，命中就直接用，不调模型。

缓存命中率取决于场景。客服场景里，“查订单”“退款”“物流”这类高频意图的表述高度重复，命中率能到 40% 以上。但要注意，缓存 key 不能只用userInput，还要带上userId或sessionId，因为不同用户的相同输入可能对应不同结果。更稳妥的做法是缓存意图识别结果而不是最终结果，因为意图识别对用户不敏感，缓存命中率更高。

实操心得：缓存要设过期时间，建议 5 到 30 分钟。太短命中率低，太长可能返回过期信息。另外，缓存要能主动失效，比如用户刚下了单，之前的“无订单”缓存要清掉。n8n 里可以用 Redis 的 DEL 操作，在订单创建的回调里触发。

4.4 实测数据汇总

把上面几个手段叠加，我在一个真实客服 Agent 项目里做了 A/B 测试。优化前，日均调用 12000 次，平均每次 1780 Token，日消耗约 2136 万 Token。优化后，日均调用次数不变，平均每次 318 Token，日消耗约 382 万 Token，降幅 82.1%。

这个数据因场景而异，但量级上是可参考的。关键是要理解，Token 优化不是靠某一个技巧，而是靠把不确定的生成变成确定的选择，把全量注入变成按需注入，把重复调用变成缓存命中。

5. 常见问题与排查技巧实录

5.1 模型输出 JSON 解析失败怎么办

这是最高频的问题。模型返回的 JSON 可能带 markdown 代码块标记，比如```json ... ```，也可能在 JSON 前后加解释文字。解决办法有三层：第一层，Prompt 里明确要求“只输出 JSON，不要任何其他内容”；第二层，Code 节点里做容错解析，先尝试直接 parse，失败则用正则提取{...}再 parse；第三层，如果还失败，走兜底分支，记录原始输出用于后续分析。

function safeParse(text) { if (!text) return null; try { return JSON.parse(text); } catch (e) {} const match = text.match(/\{[\s\S]*\}/); if (match) { try { return JSON.parse(match[0]); } catch (e) {} } return null; }

提示：如果解析失败率超过 5%，说明 Prompt 需要调整，或者模型能力不够。可以考虑换更强的模型做意图识别，或者加 few-shot 示例。

5.2 n8n 工作流执行超时怎么排查

n8n 默认的执行超时是 300 秒，但实际业务里超过 30 秒用户就等不及了。超时通常发生在模型调用节点或 HTTP 请求节点。排查步骤：先看执行记录，找到耗时最长的节点；如果是模型节点，检查是不是 Prompt 太长导致推理慢，或者模型服务本身响应慢；如果是 HTTP 节点，检查 Java 接口的响应时间。

优化手段：模型调用加超时设置，比如 15 秒，超时就走兜底；Java 接口做异步化，n8n 只负责触发，结果通过回调返回；n8n 的 worker 数量要够，queue 模式下并发执行靠 worker 撑。

5.3 Java 侧回调接口幂等怎么做

n8n 的重试机制、网络抖动都可能导致同一个请求被回调多次。幂等方案：用requestId做唯一键，Redis 里SETNX一个标记，设置过期时间比如 1 小时。处理前先检查标记，已存在就直接返回上次结果。结果也要缓存，用requestId做 key。

public AgentResult handle(AgentCallbackRequest request) { String key = "agent:callback:" + request.getRequestId(); Boolean first = redisTemplate.opsForValue().setIfAbsent(key, "processing", 1, TimeUnit.HOURS); if (Boolean.FALSE.equals(first)) { String cached = redisTemplate.opsForValue().get(key + ":result"); if (cached != null) { return JSON.parseObject(cached, AgentResult.class); } throw new BusinessException("request processing"); } AgentResult result = doHandle(request); redisTemplate.opsForValue().set(key + ":result", JSON.toJSONString(result), 1, TimeUnit.HOURS); return result; }

5.4 常见问题速查表

5.5 几个容易踩的坑

第一个坑是在 n8n 里做重计算。有人把数据清洗、格式转换全放 n8n 的 Code 节点里，结果工作流越来越臃肿，执行越来越慢。n8n 的 Code 节点适合做轻量逻辑，重计算应该放 Java 服务。

第二个坑是忽略 n8n 的版本升级。n8n 迭代很快，节点行为可能变化。生产环境要锁定版本，升级前在测试环境验证。Docker 部署时用具体版本号，不要用latest。

第三个坑是凭据管理混乱。n8n 的凭据存在数据库里，用N8N_ENCRYPTION_KEY加密。这个 key 丢了，所有凭据都要重配。建议把 key 放在环境变量或密钥管理服务里，做好备份。

第四个坑是不做执行记录清理。n8n 默认保留所有执行记录，时间长了数据库会爆。要配置EXECUTIONS_DATA_PRUNE=true和EXECUTIONS_DATA_MAX_AGE，定期清理。

6. 从单点验证到规模化落地的经验

6.1 先跑通一条最小链路

不要一上来就设计大而全的工作流。先选一个最简单的场景，比如“查询订单”，把 Java 接入、n8n 编排、模型调用、结果回传整条链路跑通。这条链路跑通后，你会发现很多设计上的问题，比如鉴权怎么做、超时怎么设、幂等怎么保证。这些问题在最小链路上解决，成本最低。

最小链路的验收标准是：用户输入“查订单 12345”，系统能返回订单 12345 的真实信息，且整个过程可追踪、可重试、可兜底。达到这个标准，再往上面加意图、加分支、加缓存。

6.2 逐步扩展意图和分支

最小链路跑通后，按业务优先级逐个加意图。每加一个意图，都要走一遍完整的测试：正常输入、边界输入、异常输入。正常输入验证主流程，边界输入验证校验逻辑，异常输入验证兜底分支。

意图多了之后，工作流会变得复杂。这时候要做模块化，把公共逻辑抽成子工作流。n8n 支持 Execute Workflow 节点调用子工作流，比如“参数校验”可以做成一个子工作流，多个意图共用。这样主工作流保持清晰，维护成本低。

6.3 监控与告警要跟上

Agent 系统上线后，必须有一套监控。关键指标包括：调用量、成功率、平均耗时、Token 消耗、缓存命中率、兜底分支触发率。这些指标可以从 n8n 的执行记录里统计，也可以让 Java 侧埋点上报。

告警阈值建议：成功率低于 95% 告警，平均耗时超过 10 秒告警，兜底触发率超过 10% 告警，Token 日消耗超过预算 80% 告警。告警渠道用企业微信或邮件都行，关键是有人看、有人处理。

6.4 持续优化 Prompt 和流程

Agent 系统不是上线就完事，需要持续迭代。每周 review 一次兜底分支的触发记录，看看哪些输入没被正确理解，针对性优化 Prompt 或补充意图。每月 review 一次 Token 消耗，看看有没有新的优化空间。

我个人的习惯是建一个“bad case 库”，把每次兜底、每次解析失败、每次用户投诉的输入都记下来，定期分析。这个库是优化 Prompt 最宝贵的素材，比拍脑袋想 Prompt 有效得多。

6.5 团队协作与文档

n8n 的工作流是可视化的，产品、运营都能看懂，这是优势也是挑战。优势是沟通成本低，挑战是容易多人同时改导致冲突。建议工作流改动走变更流程，重要工作流导出 JSON 备份，改动前先复制一份。

文档方面，每个工作流要有说明：这个流程解决什么问题、输入输出是什么、关键节点在哪、兜底逻辑是什么。Java 侧的接口文档用 Swagger 或 OpenAPI 维护，n8n 侧的工作流说明可以写在节点的 Notes 里，或者单独维护一份 Markdown。

这套方案我在两个项目里落地过，从零到日均万次调用大概用了三周，其中一周跑通链路，一周扩展意图，一周做监控和优化。Token 成本从每月几千块降到几百块，兜底率从最初的 20% 降到 5% 以下。当然每个团队情况不同，但思路是通用的：用确定性工作流约束概率模型，用分层架构隔离不确定性，用持续迭代逼近稳定。