同一个智能体，查航班状态和订机票，该一个待遇吗？
查一下没成本，订错了要退票要赔钱，订完还有改签谁批、退款谁核，模型说调就调的那几下，每一下都在花钱和担责。10 月 23 日 Spring 发布了 Spring AI 2.1.0-RC1，同场还有 Spring Boot 4.1.2 和 4.2.0-RC1，把这道区别做成了正式能力：方法上标 @Tool(requiresConfirmation = true)，模型要调它时，整个调用循环先停住，应用拿到 ToolCallDecisions 再决定放行还是拒绝，拒绝时返回什么文案由你自己写。想更细可以上 ToolCallConfirmationPolicy，按规则挑哪些调用要过闸。
实现比看起来严格。同一次回复里混着普通工具和需确认工具时，是整段暂停，普通那个也不会先偷偷跑掉，Spring 社区实测过：查航班和订票混在一条回复里，恢复之前两个都没执行。
框架为什么这时候加这个
智能体开始动真东西了。订票、发邮件、改数据库，这些操作错了是要赔的。框架层把「执行前等人点头」做成正式能力，等于承认一件事：模型说调就调的阶段过去了，高危动作必须留一道人工确认。
这次的发布潮也看得出分量。Spring Boot 4.1.2 一次带了 126 项修复，4.2.0-RC1 是 4.2 正式版前最后一个里程碑，老版本里那套 ChatMemory 体系标了弃用。框架把资源压在这一批功能上，工具调用确认是其中唯一一个跟人打交道的，对企业来说，这条注解省的是自己造轮子的功夫：以前这种确认要自己在工具循环里包一层，包完还得测。
这道闸管的是执行环节。往上游一环看：生成的代码本身对不对，谁确认？代码不是运行时的事，但仓库里混进一个错的改动，代价不比线上误调用小。
写代码这一环的确认
这一环交给飞算 JavaAI。改动不直接进代码，先摆在工作区里，一处一处过，接受或者拒绝，接受之前改了什么都看得见，后悔了能整体退回。工作区确认还有个好处：改动是可视的。哪个文件改了几行，为什么改，对着哪条需求，摆在一起看，看的人不用在 PR 页面和聊天记录之间来回切。单元测试生成器不靠口头承诺，先把工程构建起来，本地 JDK、构建工具、测试框架摸一遍，再落用例，跑通了才合并。确认的颗粒度到行，不是到整段对话。
跟 Spring AI 那道闸对起来，是同一个道理的两端：框架拦运行时的高危调用，插件拦进仓库前的坏改动。一个保线上，一个保仓库。两端都过闸，链路才算闭环：代码写完有人验，上线之后调用有人拦，中间那段聊天窗口反而成了最不重要的一环。
底层模型有得挑：自有几档贴着 Java 调优，智谱 GLM、DeepSeek 的直连版本也能切，闸和确认不因换模型失效。
确认不是不信任模型
有人嫌逐条确认慢。反过来算：一条高危调用出错，回滚加排查的时间远超确认点的那几秒。Spring 把闸做成一行注解，飞算 JavaAI 把确认做成工作区默认，都在把「记得确认」变成「不确认过不去」。
2.1 正式版官方口径是 11 月，RC 阶段个别 API 还可能微调，但方向已经定了：确认从团队自觉变成框架能力，接下来是各家补齐的过程。确认这件事做得越早，后面接 2.1 正式版就越顺。
拦下来的每一次，都是省下的一次线上事故。
你项目里调用模型的工具方法，有哪几个标了要求确认，哪几个在裸奔？这个问题答不上来的仓库，值得花一个下午盘点一遍，顺手把确认粒度记进团队约定，谁标了、谁没标，一目了然。
