企业官网建设流程全解析

💡前面廿一篇把零件一个一个接上了：模型接入、流式、Advisor、记忆、Tools、MCP、RAG、评测、可观测、编排模式，然后是落地篇的第十七到第廿一篇。写到第廿一篇那天，我在自己那套自建 Demo（某航司客服场景，数据全部脱敏）前面坐了很久，问题不再是"这个能力怎么接"，而是一个更难回答的问题——我到底在做 AI-Enhanced 的系统，还是 AI-Native 的系统？

这两件事的差别不在"用了多少 AI"。我把 Demo 第一版的助手关掉，客服照样能查单、改签、退票，只是打字打得累；而第二版把模型关掉之后，连"下一步该问用户什么"都没人决定了——因为那段逻辑我当时觉得写不出来，就写进 prompt 里了。

所以这一篇不讲新部件，只讲取舍：一条能用的判据、Agent 替代硬编码编排的边界、把 Prompt 当业务规则要付的真实成本、多模型路由与降级的落法、三步迁移每一步的止损，最后明确列出我建议先别做的三件事，以及这套专题到第廿一篇为止仍然没解决的问题。这里不写趋势预测，只写我在 Spring AI 2.0.1 这个版本里实际看到的事实和我自己的判断。从 AI-Enhanced 到 AI-Native 的架构取舍，哪些该拆、哪些不该做、Prompt 当业务规则要付什么

1. 判据先行：把 AI 摘掉，这套流程还能不能跑

分界线不是"AI 占比多少"，是"依赖关系"。这条判据立不住，后面所有的取舍都是情绪。

笔者这一册用下来的判别表就一张，五个维度：

同一套业务能力，两种堆法画出来是这样：

能力清单（查单 / 解释政策 / 改签 / 退票）—— 两种堆法用的是同一批 Service AI-Enhanced 主干是代码，AI 挂在边上 表单/接口 ──> [ Java 状态机 + Service + @Valid ] ──> DB │ └─ 旁路：摘要 / 填充 / 政策解释 ──> 模型 摘掉旁路 → 主干照跑，用户自己打字 AI-Native 主干是模型的当场决策，AI 摘不掉 自然语言 ──> [ 意图与槽位 ] ──> [ 编排：模型决定下一步 ] ──> 工具 ──> DB │ │ └── 追问策略 ──────────┴── 确认 / 上限 / 审计 / 回滚（全是你自己的代码）

比较容易被忽略的是右边那张图的下半部分：主干交给模型之后，属于工程的那一层不减反增。第十四篇那五种模式解决的是"多轮模型调用怎么组织"，它没解决"错了算谁的"。

我的结论是一句话：AI-Native 不是目标，是结果。它是被成本账本和用户体验一起推出来的稳态，不是架构图上画出来的。没有哪个团队开会决定"我们要转成 AI-Native"之后就真的转成了；实际发生的是——旁路里的建议开始承担判断，判断开始承担写操作，写操作开始承担审计义务，某天回头看，AI 已经摘不掉了。

Q1：那 AI-Enhanced 是低级形态吗？

不是，而且我认为对绝大多数存量系统来说，AI-Enhanced 是正确稳态，不是过渡态。理由很实在：AI-Enhanced 的错误代价有上界（最坏就是建议不准），AI-Native 的错误代价取决于你的闸门做到哪一层。一个每天两百单的改签流程，做成表单加一个填充旁路，用户省 40 秒；做成对话式主干，你要额外买一套评测集、一份成本账本、一条确认链路和一个回滚预案。这笔账在多数场景里算不平。

真正值得往右走的信号只有两个：分支多到规则穷举不了（要维护的 if 开始按周增加），或者输入是自然语言且结构不稳定（用户给的信息本身就是一段话）。这两个都不沾，停在左边不丢人。

2. Agent 替代硬编码编排的边界：哪些路径该交给模型

第十四篇给了五种模式的代码，这一节只回答一个问题：什么时候该把"路径决定权"交出去，交了之后拿不拿得回来。

先把该让位的三种情形和必须写死的四种约束钉住。

该让位：

• 分支多而规则不可穷举：用户说"我想改到国庆后头那天，别太早，最好靠窗"，你要枚举的组合数远超能维护的量。这类交给模型（模式四 Orchestrator-Workers 那一层）。
• 路径成本不对称：走错一步的代价很小、但少问一步省很多时延的场景，让模型自己决定跑几轮比写一个五段向导划算。
• 需求变更频率 > 代码发布频率：业务方每周都在改流程顺序，而你的发布窗口两周一次。这时候硬编码编排的维护成本是双重征税。

必须写死（不给自主权的四种硬约束）：

编排方式选择表，按"谁决定路径"排：

比较有意思的是，框架自己也在替"路径交给模型"这件事做准备——它在 2.0.1 里给了一组专门管失控的开关：spring.ai.tools.limits.max-calls-per-tool（默认 40）、max-total-tool-calls（默认 150）、on-limit-exceeded（默认 THROW）。这组默认值本身就说明，"一次提问触发上百轮工具调用"在框架眼里是常态而不是异常。换句话说：把路径交给模型这件事，框架的态度是"你可以干，但我先把保险丝装上了"。我的判断是这些默认值不是生产值，要按场景显式改小（第十八篇 6.1 展开过）。

还有一条更直接的证据：2.0.1 里有 tool-search 这一整族模块（ToolSearchToolCallingAdvisor、ToolIndex、ToolSearchRequest，带会话级 TTL / LRU 淘汰），用途是"工具太多时先检索再挂给模型"。工具规模本身已经变成一个成本项，需要框架级部件来治。第十九篇把它的正确用法定成"撑到拆进程之前"，我同意，但要在架构评审里多记一句：当你需要靠检索给模型挑工具时，很可能不是工具多了，是这个 Agent 的职责边界画粗了——先问能不能拆职责，再问能不能加检索。

一句话结论：路径可以交给模型，出口必须留在代码里。出口有四个：轮次上限、时延预算、成本预算、确认闸门。四个都没有就不要交。

3. 把 Prompt 当业务规则：五项真实成本与三分类管控

一旦 prompt 里写的是规则，你就得按规则的生命周期养它。这部分是我付得最冤的钱。

五项成本，每一条都有传统对应物，但传统对应物不花钱：

漂移这一条我要说清楚它是我在这个版本里观察到的事实，不是推测：框架给的是Evaluator/EvaluationRequest/EvaluationResponse（isPass()、score()）和RelevancyEvaluator/FactCheckingEvaluator这两个内置实现，spring-ai-test、spring-ai-spring-boot-testcontainers也都在 2.0.1 的 BOM 里——它们能告诉你"这批用例这次过没过"；而"这段 prompt 改完影响哪几条规则"，我在 2.0.1 的模块清单里没找到能回答它的部件。影响面分析这件事没有部件可买，只能靠跑，而跑就是要花钱花时间，于是评测集的冷启动成本直接变成 prompt 的修改成本。

业务规则三分类表，这张表是我现在做架构评审时第一个问的东西：

落到具体做法，我这边是一个 prompt 版本表，和代码一起进仓库、一起 review：

prompt_key version template_ref owner eval_suite status refund-policy-answer v12 prompts/refund/v12.txt 客服域 eval/refund-block-30.jsonl PROD change-flight-slots v7 prompts/change/v7.txt 客服域 eval/slot-fill-18.jsonl PROD cancel-confirm-prompt v3 prompts/cancel/v3.txt 风控 eval/inject-12.jsonl PROD

三行硬要求：进仓库（不允许在配置中心里直接改线上 prompt）、带版本号（版本号和它跑过的评测通过率一起进审计记录）、绑评测集（没有对应评测集分区的 prompt 不许上线，这条由 CI 判，不靠人自觉）。审计那条链路里，prompt_version和model_version两个字段一起落表，才有资格回答"这笔操作当时是基于哪一版规则、哪一个模型做的决定"。

Q1：把 prompt 里的规则搬回代码，不就是退回硬编码？

一半搬回去，而且要心甘情愿地搬。能在评审会上写成"如果 X 则 Y"的规则，一律搬进 Java；搬不动的（依赖自然语言理解的那部分）才留在 prompt 里，然后给它套上版本表和评测集。这条分界线就是我判断"这个系统该不该做成 AI-Native"的实际操作版本：如果你的 prompt 里有八成规则其实能写死，那你做的是 AI-Enhanced，却付了 AI-Native 的工程成本——这是最差的位置。

4. 多模型路由与降级：路由是四约束求解，降级必须有确定性终点

路由不是"哪个便宜用哪个"；降级的终点如果还是模型，那不叫降级。

路由依据分四层，自上而下筛选，顺序不能反：

先纠一个我自己的说法。多模型路由这件事的理由不是"供应商多"：官方 reference 的 Chat Models 章节条目是 14 条，所以"20+ 模型提供商"这种话我在文档口径上对不上，宁可不写。真实理由是同一个通道内部也要分档——出域约束不同、上下文窗口不同、时延不同、按你自己账本算出来的相对成本不同。路由是应用层的事：框架给的是抽象（一个ChatModel接口加各家 starter），这一圈我自己是在 Service 里写的。

路由决策表：

示意代码（路由 + 降级，讲写法不讲编译）：

// 路由与降级。重点是最后一行：兜底是"确定性路径"，不是"再换个模型试一次"publicRouteOutcomeroute(RouteRequestreq){List<ChatModel>candidates=this.pool.forTier(req.tier());// tier = L0 合规硬筛 + L1 难度分档for(ChatModelmodel:candidates){// 同档内按 L2 预算 / L3 时延排序longstartedAt=System.nanoTime();try{ChatResponseresponse=this.invoker.call(model,req.prompt(),req.deadline());this.costLedger.record(req,model,response,startedAt);// 模型/token/耗时/命中工具，四个字段一次写全returnRouteOutcome.ok(response);}catch(RuntimeExceptione){this.costLedger.recordFailure(req,model,e,startedAt);// 换模型不算恢复，落库才是证据}}returnthis.deterministicFallback.apply(req);// 退回规则模板 / 退回表单 / 生成人工工单}

// 成本落库：没有这张表，上面四个阈值全是拍脑袋publicvoidrecord(RouteRequestreq,ChatModelmodel,ChatResponseresp,longstartedAt){long[]tokens=this.usageReader.of(resp);// 从响应里取 prompt / completion 两个计数this.repository.insert(newAiCallRecord(req.conversationId(),req.turnId(),req.userId(),req.feature(),req.requestedTier(),this.modelKey(model),req.promptVersion(),tokens[0],tokens[1],elapsedMillis(startedAt),req.visibleToolNames(),// 这一轮挂了哪些工具也要记false,null,MDC.get("traceId")));}

账本字段我建议照抄，因为它同时是路由的输入、成本的输出、事故复盘的证据：

ai_call_ledger(call_id, conversation_id, turn_id, user_id, feature, requested_tier, model_id, prompt_tokens, completion_tokens, latency_ms, hit_tools, fell_back, fallback_reason, prompt_version, trace_id, created_at)

fell_back和fallback_reason这两列最值钱。上线两周后你真正要回答的问题不是"花了多少"，而是"降级发生了多少次、因为什么发生"——如果大多数降级原因是超时，那要改的是时延预算和候选顺序；如果是预算耗尽，那要改的是难度分档；如果原因列全是空，那是你的兜底路径根本没接进去。prompt_version和model_version要一起进这张表，否则第 3 节说的漂移你连查都查不出来。

Q1：既然有降级链路，为什么不干脆配两个模型互相当备胎？

因为"换个模型再试"经常不是降级，只是把同一次失败延迟了。两个模型可能同时被同一个上游抖动打中；也可能备胎的上下文窗口更小，主模型失败的原因（上下文太长）在备胎上同样会复现。降级要降的是"这件事的做法"，不是"做这件事的模型"：退回规则模板、退回人工、退回表单，这三条路共同点是成功率与模型无关。我在 Demo 里给每条兜底路径都算了一个独立的成功率指标，因为它才真正决定用户会不会第二次打开这个入口。

5. 三步迁移与每步止损

第十六篇回答"从哪一层开始叠"，这一节回答"每步走到哪就该停，以及怎么退回来"。

Step1 只读叠加 Step2 单场景接管 Step3 流程重构 AI 给建议，人执行 --> AI 提方案，人确认后执行 --> AI 决定路径，人管闸门 摘掉 AI：主干照跑 摘掉 AI：退回原表单 摘掉 AI：业务不成立 护栏：只读工具 + 上限 护栏：确认闸门 + 幂等键 护栏：评测门禁 + 审计回放 + 回滚演练

每一步的进入条件、验收指标、止损信号：

三条我自己踩出来的规矩：

1. 止损信号要在开工前写成可判定的句子。"效果不好就退"不是止损，"确认转化率连续两周低于三成，或误执行 ≥ 1 次，就关写操作"才是。前者永远执行不了，因为没人愿意承认效果不好。
2. 不允许跳步。我见过直接从 Step1 跳到 Step3 的做法（新做一个纯对话产品，跳过只读叠加），代价是评测集和成本账本都是事后补的，而事后补的评测集只会证明"我们对的那部分"。
3. 回滚演练要在 Step3 之前做一次真的：把一条业务规则从 prompt 收回 Java，看要几天、要不要重跑评测集、线上要不要灰度。这个耗时就是你 AI-Native 的实际回滚代价，数字出来之前不要谈"可维护"。

6. 我建议先别做的三件事

收束篇如果没有这节，就是又一篇展望水文。下面三件是我做完这一册之后，明确从自己排期里划掉的。

6.1 不要一上来做多 Agent / 跨进程 Agent 编排

为什么现在不做，除了三判据（上下文预算、权限隔离、独立伸缩）没量化之外，还有一个我在 2.0.1 里实际看到的原因：跨进程那一层的部件基本是缺的，你得自己接，而且接的是身份。

• BOM 169 个 artifact 里，没有任何 A2A 协议的 artifact，也没有 OpenAPI 转工具定义的 artifact。A2A 这件事本身已经由 Linux Foundation 托管、规范在 1.0.x，但它不在 Spring AI 里——这一句我只写到"没有"，不写"该怎么用"。
• MCP 侧的身份链路默认是断的：客户端会把ToolContext转成CallToolRequest的_meta发出去（默认转换器全量拷贝），而服务端自动转换器只会给被包工具塞一个exchange键。也就是说**"我在这一侧塞了 userId"到不了那一侧的工具方法里**，跨进程要自己写转换器并补校验。
• 传输这一层反而已经定了：spring.ai.mcp.server.protocol默认就是streamable（取值 SSE / STREAMABLE / STATELESS），SSE 只作为兼容路径。但这只解决"怎么运过去"，不解决"谁在调"。

什么时候可以开始做，我的触发条件三条同时满足：

1. 单 Agent 的工具已经要用 tool-search 才装得下，并且你能写出拆分的量化收益：哪个 Agent 少挂几个工具、哪条权限必须换进程才能真正隔离（第十九篇三判据至少落一条成具体数字）。
2. 已经有一条跨进程链路能带着同一个 traceId 跑出完整审计——先有追踪再拆进程，反过来做等于自断归因能力。
3. 存在真实的组织边界：另一个团队或另一家公司要求你把能力以工具形式交付。不是"以后可能用得上"。

6.2 不要把对话式 UX 铺满

为什么现在不做：表单把状态摊在屏幕上，用户和系统看到的是同一份数据；对话把状态变成"要靠上下文推断的东西"。这带来三笔同时上涨的成本——每轮都要付的 token、有限的记忆窗口（第十七篇里那个窗口大小的取舍）、以及用户"看不清接下来会发生什么"带来的不敢用。第十七篇那句判据我照抄过来：只有槽位多、字段语义模糊的入口才值；高频精确操作留在表单。

触发条件（我这边三条全中才开工）：

• 目标入口字段数确实多（我自己用的线是 5 个以上，这是经验值不是标准），且字段之间有依赖；
• 操作者是低频用户——他记不住字段，也懒得找入口；
• 前端能配一个"表单确认卡片"回显将要发生什么（对话输入 + 表单确认的混合模式），而不是纯气泡流。

6.3 不要让模型直连生产写接口

为什么现在不做：模型看得见哪个工具，就调得动哪个工具（第十八篇）。存量接口在没做分级和描述整改之前直接开放给模型，等于把你内部的隐式约定当成"模型能猜对的东西"。第廿一篇整篇在讲的接口盘点与分级，就是这件事的前置作业。

触发条件（四条全通才允许写操作进模型链路）：

1. 接口已完成分级：只读 / 可逆写 / 不可逆写 / 批量，各自有策略；
2. 写操作必经确认闸门，确认后执行的是落库的那份参数，不重新问模型；
3. 幂等键已定，重复点击和重复投递都不会产生第二笔动作；
4. 审计表里decision有真实数据，并且你用它跑通过一次复盘（能回答"这笔是谁批准的、当时看到的参数是什么"）。

7. 一页收束：决策总表、自检清单，以及这套专题没解决什么

如果这一册只留一页，我希望是这一页。

7.1 决策总表

7.2 自检清单

7.3 这套专题到第廿一篇为止没解决什么

开篇那张"还没解决什么"的清单，写完落地篇之后我逐条回看，结论是这几条仍然开着：

最后总结

• 判据只有一条：把 AI 摘掉，这套流程还能不能跑。跑得动是 AI-Enhanced，跑不动是 AI-Native。这条判据比任何定义都好用，因为它直接连到回滚代价。
• AI-Native 不是目标，是结果。它是被成本账本和用户体验推出来的稳态，不是架构图画出来的；多数存量系统的正确稳态是停在 AI-Enhanced，不是过渡。
• 路径可以交给模型，出口必须留在代码里：轮次上限、时延预算、成本预算、确认闸门。框架在 2.0.1 已经把保险丝装好了（spring.ai.tools.limits.*默认 40 / 150 / THROW），也在承认"工具规模本身是成本"（tool-search 那一族）——但保险丝不是护栏，护栏是你自己那四层出口。
• 把 Prompt 当业务规则要付五项成本：不可 diff、不可单测、影响面未知、漂移、审查缺失。管控办法是把规则三分类——确定性进代码走 PR、语义性进 prompt 走版本表加评测集、判断性进模型走抽样人审加审计。能写死的规则留在 prompt 里，是净亏。
• 路由是四约束求解（合规 → 难度 → 预算 → 时延），降级终点必须是确定性路径：退回规则、退回人工、退回表单。"换个模型再试"不是降级。而这一切的前提是每次调用的模型、token、耗时、命中工具、prompt 版本都落了库。
• 三步迁移每步都要在开工前写下可判定的止损句：命中率不达标就退回单点，确认链路落不了地就砍写，审计回放跟不上就停止扩大范围。回滚演练要在切换前做一次真的。
• 我建议先别做的三件事——多 Agent 跨进程编排、对话式 UX 铺满、模型直连生产写接口——不是因为方向错，是因为你现在缺的都是工程条件，不是模型能力。每条我给了可判定的触发条件，够上再做。
• 对于后端 / 架构同学，这一册真正想说的是：AI-Native 的门槛不在模型能力，在工程能力（评测、审计、成本核算、回滚）。要补的两块，第一块是把调用记录当业务表来设计——路由、降级、止损的每一个阈值都要从这张表算出来，没有它你所有判断都是修辞；第二块是把确认与回滚当一等公民——闸门、落库参数、decision审计列、一次真实演练。这两块跟模型能力无关，全是后端的基本功，也恰好是最容易被"AI 项目"排期挤掉的部分。

一句话结论：能摘掉 AI 的系统，说明你还没付对应的账；摘不掉 AI 的系统，说明你要么已经在赚这笔钱，要么已经在被这笔钱追着跑。

参考资料 & 致谢

[1] Spring AI Reference（2.0.1 官方文档）

[2] spring-projects/spring-ai - GitHub

[3] spring-ai-bom 2.0.1 目录 - Maven Central

[4] Spring AI 第三篇：多模型、流式输出与工具调用

[5] Spring AI 第五篇：Advisor 对话拦截的使用和自定义

[6] Spring AI 第八篇：Tools / function-call 使用 + 原理 + 7 大痛点

[7] Spring AI 第九篇：MCP 实现、原理、源码读与鉴权

[8] Spring AI 第十一篇：基于航空智能客服的 RAG 实战

[9] Spring AI 第十二篇：RAG 评测与幻觉防线

[10] Spring AI 第十三篇：给 AI 应用装上仪表盘

[11] Spring AI 第十四篇：Agent 五种模式在 2.0 里怎么写