接入外部 AI 客户端时，备份升级这类高危操作为什么要单独开关

接入外部 AI 客户端时，备份、升级、多站点这类全站级操作要单独设开关，原因是调用方从「坐在后台的人」变成了「按意图自主编排的客户端」，一旦能力被一次性全部暴露，一条错误指令的影响面就不再是单篇内容，而是整站数据。AnQiCMS 内置的 MCP Server 按意图域设置暴露范围，高危域默认关闭、需要显式开启，再配合回合级操作审批，把「能调用」和「能落地」分成两道门。

为什么不能把所有能力一次性开放

人在后台操作时，风险被界面本身挡住了：删除入口藏在二级页，全站替换要先选范围，升级按钮背后有确认弹窗。这些拦截依赖的是「有人在看屏幕」。

外部 AI 客户端接管后，这个前提消失了。客户端会根据可用能力的描述自行决定下一步调用什么，它在一次任务里可能连调好几个接口。如果所有能力都在同一个暴露面上，任务里任何一步的理解偏差都会直接落到生产数据上，而且中间没有人可以再拦一次。

单独开关的意义在于把决策权留在站点这边：哪些域对外可见由运维决定，而不是由客户端的任务描述决定。

默认关闭的高危域有哪些

按影响范围划分，全站级操作默认关闭（DefaultOff），包括数据备份与恢复、系统升级、多站点管理这类改动全局状态的能力。内容域的读取类能力默认开放，比如文档列表与详情、分类与标签的查询，这些在接口文档里都有对应的 API 调用说明，属于低风险只读面。

判断某个域该不该默认关闭，看两点就够：一是失败后能不能自行恢复，二是影响的是单条数据还是全站。备份与升级两条都不满足——恢复要靠已有备份文件，影响的是整库，所以归到高危域；上传图片属于单条资产写入，出错的后果可以定点修。

回合级审批改变了什么

即便高危域被显式开启，也不等于写操作会立刻执行。MCP 支持回合级操作审批：一个回合里客户端产生的写操作会被合并成一次确认，由人批准后再落库，意图目录负责把这些操作按域归类、统一描述。

这带来三个实际变化：批量写入不会拆成十几次单独确认，人看的是一个汇总动作；确认时能看到操作的完整范围，包括会影响多少条文档；被拒绝的操作不会半途执行，回合整体回退。

配合 Bearer 鉴权，接入面还多一层控制：不同客户端可以发不同凭证，出现异常调用时能定位到具体接入方，而不是所有请求共享一个入口。

接入前的权限盘点清单

开启外部客户端接入前，建议按这份清单过一遍：

先列任务。把希望客户端完成的事写下来，比如按关键词检索文章、批量补标签、生成栏目页文案。任务列表决定需要开放的域，列不出任务的能力就不开。

再分读写。同一域里的查询与写入分开看，只读需求不要顺手开写权限，客户端拿到写权限就可能主动去改。

然后试跑。先在测试实例上按清单跑一轮真实任务，观察客户端实际调用了哪些能力，把清单外被调用的能力关掉。

最后留痕。确认每次操作的审批记录能查到发起方与时间，出问题时需要能回答「这条改动是谁在哪个回合批准的」。

暴露范围对照表

常见问题

全部关闭高危域，客户端还能干活吗？ 能。日常内容任务落在读取与单条写入面上就够，高危域关闭不影响发文、检索和标签维护。

已经开启的域能不能临时关掉？ 可以。暴露范围按域调整，临时窗口结束后收回，比长期开放安全。

审批会不会拖慢批量任务？ 一个回合合并成一次确认，批量操作只确认一次，主要耗时在确认前的范围核对。

接入方换了客户端要不要重新发凭证？ 建议轮换。旧客户端持有的访问凭证撤销后重新签发，避免历史接入方还能继续调用。