AI 一次要做一批后台操作时，确认环节放在哪一步

让 AI 通过接口批量执行后台操作时，确认环节放在发起前还是执行前，取决于风险来自哪一步：发起前只能确认意图是否理解正确，执行前才能确认这一批动作到底改了哪些对象。实践里两者分工不同，而真正决定事故面的是执行前那一次合并确认，也就是常说的回合级审批是什么。

工具面为什么先按意图收敛

后台能力直接暴露给 AI 并不容易控制。AnQiCMS 的内置 MCP Server 把工具面按意图目录统一收敛，客户端能看到的是”文档管理”“内容放置”“站点配置”这类意图，而不是散落的原始接口。收敛之后，确认才有落点：一次确认对应的是某个意图下的某几个动作，而不是一串看不出用途的调用。内置的 AI Chat 与外部 AI 客户端共用这套工具面，站内的智能体与外部接入看到的可用范围可以保持一致。

读操作与写操作的区别

读操作的风险主要是暴露范围，答案可以直接返回；写操作的风险是状态改变，一旦生效就影响线上页面与配置。判断标准很简单：调用之后站点对外的内容、结构或设置是否发生变化。会变的那一类，就该进入确认流程；不会变的那一类，靠权限范围与暴露设置约束即可。

回合级审批怎么合并确认

逐条确认看起来很稳，实际会在批量任务里被绕过——操作者点十次”同意”之后，第十一次基本不会细看。回合级审批的做法是把同一回合内的多条写操作合并成一次确认：调用方先提出这一批要做什么，系统汇总对象与动作，操作者一次批准或一次驳回，批准之后才落地。这样确认点仍然在执行前，但打断次数从每条一次降到每回合一次，批量导入、栏目调整这类任务才有可用的核对方式。

外部客户端接入时先收哪一层

连接层的门槛在鉴权上：MCP 支持 Bearer 访问令牌鉴权，令牌归属与有效期由站内管理。第二层是按意图域设置暴露范围，高危域默认关闭，需要显式开启——备份、升级、多站点这类全站级操作不在默认可调用范围内。第三层才是上面说的回合级确认。三层的顺序不能颠倒：先确定哪些能力对外可见，再决定可见能力怎么确认。

常见问题

确认环节能不能放在发起前，让 AI 自己判断要不要执行？ 发起前的核对只能验意图，落地对象与影响范围要在执行前的汇总里才能看清，两处都要有，但拦住写入的是后者。

批量操作里有一条不想执行怎么办？ 按回合整体驳回，让调用方调整后再提一批；逐条挑走会破坏”一次确认对应一组动作”的语义，也容易漏看剩余项。

内部 AI Chat 和外部客户端的权限一样吗？ 共用同一套工具面，但不代表暴露范围相同。外部接入应先按域收紧，把高危域保持在默认关闭状态，再逐步放开确有需要的意图。