前面廿一篇把零件一个一个接上了模型接入、流式、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 占比多少是依赖关系。这条判据立不住后面所有的取舍都是情绪。笔者这一册用下来的判别表就一张五个维度判据AI-EnhancedAI-Native在自家仓库里怎么验把 AI 摘掉会怎样功能变少、输入变累主干照样跑流程不成立没有别的执行者决定下一步把ChatClient那个 bean 从配置里注掉数一下还剩几个接口能用流程主干由谁决定你的代码状态机、if-else、前端向导模型选哪个工具、还缺哪个槽、要不要再来一轮grep 谁在推进状态——是 Service 里的 state 字段还是这一轮返回的 tool calls错误由谁兜底校验失败前端报错模型错了只是建议不准错误必须在链路里被接住确认、调用上限、退回人工造一条工具永远返回再试一次的用例看它第几轮停、停在哪、谁拿到停止结果上线门槛单点人工抽测基本够用评测集门禁 成本归因 审计表三样缺一不可问一句上次 prompt 改动是谁批的、跑了什么答不上来就是没门槛回滚代价关掉开关回到没有 AI 的样子业务规则已经写进 prompt回滚等于把规则一起删掉真去做一次演练把一条规则从 prompt 收回 Java数要几天同一套业务能力两种堆法画出来是这样能力清单查单 / 解释政策 / 改签 / 退票—— 两种堆法用的是同一批 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 那一层。路径成本不对称走错一步的代价很小、但少问一步省很多时延的场景让模型自己决定跑几轮比写一个五段向导划算。需求变更频率 代码发布频率业务方每周都在改流程顺序而你的发布窗口两周一次。这时候硬编码编排的维护成本是双重征税。必须写死不给自主权的四种硬约束约束为什么不能交给模型落点资金与不可逆动作退票、退款、扣额度的错误没有再问一次这个补救动作写操作必经确认闸门第十八篇的ToolExecutionEligibilityChecker落点合规与留痕为什么允许这笔改签必须能一句话答出来模型的解释不是证据服务端二次校验 审计表的decision列幂等模型重试一次就是重复执行重复扣款不是 bug 是事故幂等键在 Service 层绝不在 prompt 里SLA 硬指标不可预估的轮次数直接打穿时延预算路径写死 模型只做旁路或显式设轮次上限编排方式选择表按谁决定路径排情形编排方式谁决定路径谁决定参数翻车长相步骤固定、能画流程图Chain / 硬编码 workflow模式一代码代码明明能写死却做成三轮模型调用慢且贵类别清晰但参数千变Routing模式三先分类再进专门的链模型只做分类分支仍写死模型填、代码校分类器飘一个类目吃掉全部流量子任务无法预先枚举Orchestrator-Workers模式四模型模型没有出口条件orchestrator 自己拆出二十个子任务质量可判且需要收敛Evaluator-Optimizer模式五模型循环代码管轮次上限模型判卷和答题用同一个模型同一个 prompt越修越偏涉钱 / 不可逆规则 人工确认代码代码确认之后又重新问了一遍模型第十八篇点过的那个错强时延预算首字节有指标写死路径 模型旁路代码代码一次提问三轮工具P95 直接翻倍比较有意思的是框架自己也在替路径交给模型这件事做准备——它在 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 里写的是规则你就得按规则的生命周期养它。这部分是我付得最冤的钱。五项成本每一条都有传统对应物但传统对应物不花钱成本具体表现为什么代码没这个毛病我怎么压不可 diff一段 system 文案改动在 Git 里是一个巨型字符串的变更review 的人看不出语义动了什么代码改动落在具名方法上能定位规则拆段、每段带 id一段一行禁止把三条规则塞进同一段不可单测同一输入不同输出assertThat(promptResult).isEqualTo(...)写不出来纯函数可以断言能枚举的断言下沉成mustContain类规则检查剩下的交给评测集跑趋势第二十篇改一处影响面未知我改过退款时限那一段两周后发现能改签几次的回答开始飘改一个方法编译器告诉你谁受影响触发式门禁diff 里出现 system 文案 / 工具description/ 分块参数 / TopK / Advisor 顺序就必须跑评估集漂移同一段 prompt 在不同模型版本上表现不一样提供商升级了你没改代码代码不会自己变锁modelVersion、temperature固定nightly 做一次去缓存全量跑审查缺失prompt 改动的提交人通常是业务或算法reviewer 默认不是安全和业务负责人核心链路的 Java 改动有 CODEOWNERSprompt 进仓库、带版本号、绑评测集改它必须同时改 baseline 文件漂移这一条我要说清楚它是我在这个版本里观察到的事实不是推测框架给的是Evaluator/EvaluationRequest/EvaluationResponseisPass()、score()和RelevancyEvaluator/FactCheckingEvaluator这两个内置实现spring-ai-test、spring-ai-spring-boot-testcontainers也都在 2.0.1 的 BOM 里——它们能告诉你这批用例这次过没过而这段 prompt 改完影响哪几条规则我在 2.0.1 的模块清单里没找到能回答它的部件。影响面分析这件事没有部件可买只能靠跑而跑就是要花钱花时间于是评测集的冷启动成本直接变成 prompt 的修改成本。业务规则三分类表这张表是我现在做架构评审时第一个问的东西规则类型例子落在哪变更管控方式出错长相确定性规则金额上限、状态机允许的迁移、幂等键、某角色能看哪些工具、证件号格式Java 单测Git PR 覆盖率 静态检查可预测的错同一输入永远同一结果能定位到行语义性规则“用户说的口语时间要归一化成具体日期”、“退款政策以内部条款为准不要凭常识”、“该拒答时要拒”Prompt 模板 检索内容Prompt 版本表 绑定评测集改动必须带 baseline diff概率性错靠评测集看趋势不能靠单次验证判断性规则这位旅客这单是否值得人工介入、多个可选航段里推荐哪个模型输出 人工确认抽样人审 审计 decision 列不可复现必须留证据事后能回答当时看到什么、为什么批落到具体做法我这边是一个 prompt 版本表和代码一起进仓库、一起 reviewprompt_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. 多模型路由与降级路由是四约束求解降级必须有确定性终点路由不是哪个便宜用哪个降级的终点如果还是模型那不叫降级。路由依据分四层自上而下筛选顺序不能反层判据决定什么参照L0 合规硬筛数据能不能出网 / 能不能出境 / 是否只能用私有化通道候选集合不是排序第十八篇 PII 出网那节位置比工具重要L1 任务难度分档要不要工具编排、上下文长度、是否要结构化输出选哪一档第十四篇模式三分类器要单独有指标L2 成本预算本功能 / 本用户当日剩余额度档内排序第十三篇的成本归因账本见本节末L3 时延 SLA首字节与总耗时预算超时阈值与并发策略第三篇的流式超时逐跳可控第十九篇先纠一个我自己的说法。多模型路由这件事的理由不是供应商多官方 reference 的 Chat Models 章节条目是 14 条所以20 模型提供商这种话我在文档口径上对不上宁可不写。真实理由是同一个通道内部也要分档——出域约束不同、上下文窗口不同、时延不同、按你自己账本算出来的相对成本不同。路由是应用层的事框架给的是抽象一个ChatModel接口加各家 starter这一圈我自己是在 Service 里写的。路由决策表情形首选降级第一跳最终兜底涉敏感字段的查询私有化 / 本地通道同通道小一档模型退回表单 人工不能退回公网模型长上下文总结高档长窗口截断 中档退回抽取要点用规则模板多轮槽位填充中档要结构化输出同档另一模型一次退回原表单把已收槽位回填进去一次性工具编排中档缩窄可见工具 重试一次退回人工工单把工具清单和已得参数一起带上高并发只读问答低档命中缓存 / FAQ 模板静态政策页链接示意代码路由 降级讲写法不讲编译// 路由与降级。重点是最后一行兜底是确定性路径不是再换个模型试一次publicRouteOutcomeroute(RouteRequestreq){ListChatModelcandidatesthis.pool.forTier(req.tier());// tier L0 合规硬筛 L1 难度分档for(ChatModelmodel:candidates){// 同档内按 L2 预算 / L3 时延排序longstartedAtSystem.nanoTime();try{ChatResponseresponsethis.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[]tokensthis.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业务不成立 护栏只读工具 上限 护栏确认闸门 幂等键 护栏评测门禁 审计回放 回滚演练每一步的进入条件、验收指标、止损信号阶段进入条件验收指标自己定线别抄别人止损信号退回动作Step1 只读叠加有明确的只读场景检索层已有 Recallk 基线第十、十三篇能挂的工具已分级建议采纳率、检索命中率、单条 token 与耗时采纳率长期低于你的心理线或单条 token 相对基线涨幅超两成入口收成搜索框 常见问题能力不删只是不再让它出现在主路径上Step2 单场景接管写操作有确认闸门且落库参数第十八篇幂等键已在 Service 层业务方愿意为确认改 UI确认转化率、误执行次数要求为 0、审计decision完整率确认链路落不了地前端不接受、客服嫌慢或确认后实际执行参数与用户看到的不一致砍写操作退回只读。这条不商量——没有确认链路的写操作就是没有闸门Step3 流程重构评测集已经进 CI 并且红过第二十篇成本能按功能归因第 4 节账本有数一条完整链路能回放主干切换后的 SLA 达成率、多轮任务成功率、一次真实回滚演练的耗时审计与回放能力跟不上新场景或出了一次说不清是谁决定的事故停止扩大范围先把已有场景的链路补成完整闭环再谈下一个场景三条我自己踩出来的规矩止损信号要在开工前写成可判定的句子。效果不好就退不是止损确认转化率连续两周低于三成或误执行 ≥ 1 次就关写操作才是。前者永远执行不了因为没人愿意承认效果不好。不允许跳步。我见过直接从 Step1 跳到 Step3 的做法新做一个纯对话产品跳过只读叠加代价是评测集和成本账本都是事后补的而事后补的评测集只会证明我们对的那部分。回滚演练要在 Step3 之前做一次真的把一条业务规则从 prompt 收回 Java看要几天、要不要重跑评测集、线上要不要灰度。这个耗时就是你 AI-Native 的实际回滚代价数字出来之前不要谈可维护。6. 我建议先别做的三件事收束篇如果没有这节就是又一篇展望水文。下面三件是我做完这一册之后明确从自己排期里划掉的。先别做为什么现在不做什么时候可以开始做触发条件一上来做多 Agent / 跨进程 Agent 编排三判据没算清之前多 Agent 只是把单点故障分布式化链路线性叠加延迟、错误跨跳放大、没有一份完整上下文可归因见 6.1 三条缺一不动把对话式 UX 当界面替代品铺满第十七篇的判据是槽位多、字段语义模糊才值得改把高频精确操作塞进对话是拿 token 和轮次去买一个更慢的表单见 6.2 三条全中让模型直连生产写接口攻击面从回答错话变成执行错动作而工具级权限这一层框架不管Tool上没有任何权限标记这条核对结论在第十八篇白名单只是这一轮挂了哪些 callback见 6.3 四条全通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 / STATELESSSSE 只作为兼容路径。但这只解决怎么运过去不解决谁在调。什么时候可以开始做我的触发条件三条同时满足单 Agent 的工具已经要用 tool-search 才装得下并且你能写出拆分的量化收益哪个 Agent 少挂几个工具、哪条权限必须换进程才能真正隔离第十九篇三判据至少落一条成具体数字。已经有一条跨进程链路能带着同一个 traceId 跑出完整审计——先有追踪再拆进程反过来做等于自断归因能力。存在真实的组织边界另一个团队或另一家公司要求你把能力以工具形式交付。不是以后可能用得上。6.2 不要把对话式 UX 铺满为什么现在不做表单把状态摊在屏幕上用户和系统看到的是同一份数据对话把状态变成要靠上下文推断的东西。这带来三笔同时上涨的成本——每轮都要付的 token、有限的记忆窗口第十七篇里那个窗口大小的取舍、以及用户看不清接下来会发生什么带来的不敢用。第十七篇那句判据我照抄过来只有槽位多、字段语义模糊的入口才值高频精确操作留在表单。触发条件我这边三条全中才开工目标入口字段数确实多我自己用的线是 5 个以上这是经验值不是标准且字段之间有依赖操作者是低频用户——他记不住字段也懒得找入口前端能配一个表单确认卡片回显将要发生什么对话输入 表单确认的混合模式而不是纯气泡流。6.3 不要让模型直连生产写接口为什么现在不做模型看得见哪个工具就调得动哪个工具第十八篇。存量接口在没做分级和描述整改之前直接开放给模型等于把你内部的隐式约定当成模型能猜对的东西。第廿一篇整篇在讲的接口盘点与分级就是这件事的前置作业。触发条件四条全通才允许写操作进模型链路接口已完成分级只读 / 可逆写 / 不可逆写 / 批量各自有策略写操作必经确认闸门确认后执行的是落库的那份参数不重新问模型幂等键已定重复点击和重复投递都不会产生第二笔动作审计表里decision有真实数据并且你用它跑通过一次复盘能回答这笔是谁批准的、当时看到的参数是什么。7. 一页收束决策总表、自检清单以及这套专题没解决什么如果这一册只留一页我希望是这一页。7.1 决策总表情形建议架构形态止步点必做工程项内部效率工具查文档、写周报、整理会议纪要AI-Enhanced 旁路停在只读不进业务流程prompt 进仓库、抽样人审存量核心链路上加助手Step1 只读叠加停在建议不执行检索质量基线、成本账本表单字段多且语义模糊Step2 对话填单 表单确认停在写操作要确认槽位状态机、幂等键、确认闸门非结构化输入转结构化票据、邮件、口语时间AI-Enhanced一次抽取调用停在人工复核校验留在代码里别交给模型自证能力要给别的团队/别的模型客户端复用MCP 工具化第廿一篇停在只读工具先上跨进程身份链路自己接全新产品主干就是自然语言Step3 流程重构停在审计覆盖不到的子流程评测门禁进 CI、成本归因、回滚演练涉资金、涉合规、不可逆模型只做旁路 人工确认不给自主权decision审计列、异常不回灌只有 Demo 能跑、门禁还没建不许对外停在内部试用先攒 30 条有名字有理由的评测用例7.2 自检清单#问题不过关的表征1能说清这个系统是 AI-Enhanced 还是 AI-Native 吗只有我们用了 AI这一句2把模型摘掉主干流程跑到哪一步停没人试过也没人知道3每条 prompt 规则有版本号和 owner 吗线上 prompt 在配置中心里被直接改4prompt / 工具 description 改动会触发评测集吗触发靠自觉5评测集里有多少条能说清防哪类退化用例来源是随手拍的题6每次模型调用的模型、token、耗时、命中工具落库了吗成本只会说变贵了7降级终点是确定性路径还是另一个模型只有换个模型重试8写操作的确认参数与实际执行参数是同一份吗确认后又问了一遍模型9做过一次真实回滚演练吗一条规则从 prompt 收回代码要几天从没退过所以不敢退10多 Agent / 跨进程拆分有量化收益吗拆分理由是看起来更先进11审计表能回答这笔操作当时基于哪版规则、哪个模型、谁批的吗只能回答发生了什么7.3 这套专题到第廿一篇为止没解决什么开篇那张还没解决什么的清单写完落地篇之后我逐条回看结论是这几条仍然开着没解决现状不是我不想做是条件不成立跨租户权限模型工具级权限这一层框架不管核对结论见第十八篇。这一册只示范了按请求挂 callback 工具内按 userId 复核归属多租户的租户上下文治理没做体系化Prompt 的静态分析工具链我在 2.0.1 的模块清单里没找到能回答改这段文案会影响哪几条用例的部件。框架有Evaluator/EvaluationRequest/EvaluationResponse但影响面分析这一段是空的只能靠全量跑评测集冷启动的真实成本从 0 到能用expectedDocIds和mustContain得人工标。第二十篇给了四周顺序但没替你标一条题多厂商的真实成本与稳定性数据BOM 169 个 artifact、reference Chat Models 章节 14 条之外各家通道的时延与失败率我没有横向账本只有自建 Demo 自己那一份样本不足以给别人当依据跨进程身份链路MCP 客户端_meta与服务端exchange之间接不上方案只能是自定义转换器 自己校验没有标准可引A2A 怎么落我只核到Spring AI 2.0.1 不提供支持、协议治理在 Linux Foundation、规范 1.0.x。如果要接接法是什么这一册没有答案最后总结判据只有一条把 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 Reference2.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 里怎么写