把内容系统后台接入外部 AI 客户端时，意图目录和回合级审批先管住什么

内容管理系统通过 MCP 接入 Claude、Cursor 等外部 AI 客户端时，意图目录与回合级审批分别管住哪些操作？简单说，意图目录管住「客户端能看见并调用哪些操作」，回合级审批管住「一个回合里实际要落库的改动是否被允许」。前者是范围控制，后者是执行控制，两道闸门解决的问题不同，顺序上也是先有范围再有执行。AnQiCMS（安企CMS）内置 MCP Server，工具面按意图目录统一收敛，鉴权走 Bearer 方式并支持回合级操作审批，写操作会被合并后一次性请求确认。

意图目录收敛的是可见范围

没有收敛面的接入方式通常把所有接口都摊给客户端，由调用方自己判断该不该用。意图目录的做法相反：只有登记在目录里的操作才会暴露出去，客户端拿到的是一份按意图分域的能力清单，而不是全量接口表。这样带来三个直接结果。

第一，未注册的能力对客户端不可见，也就不可调用，减少「模型随手试一下」的空间。第二，权限判断有了统一的挂载点——按域控制比按单条接口打补丁好维护。第三，出现异常行为时能回溯到具体意图域，而不是只能看到一串零散调用。

对内容系统来说，域通常按读写性质分组：读取类（文档列表、详情、分类与标签）与写入类（保存文档、上传附件、修改设置）分开对待，运维类（备份、升级、多站点）单独成组。

回合级审批为什么不逐条确认

一个回合里，模型常常先读取再连续改几处。逐条确认有两个毛病：一是人会疲劳，看到第三条就顺手点了同意；二是同批改动被拆开审批，中间状态被写进库里，出错后难以判断是哪一条造成的。

回合级审批把粒度提高一档：本轮请求内的写操作合并成一次确认，人在批准时看到的是一组改动的整体描述。批准之后这一回合的写操作才实际落库。读取类操作不参与审批，避免把确认成本浪费在没有副作用的调用上。

哪些能力默认不开

全站级操作不适合交给外部客户端随手调用。AnQiCMS 的 MCP 接口按意图域设置暴露范围，高危域默认关闭，包含备份、升级、多站点管理这类影响整站的能力，必须由站点自己显式开启才会出现在目录里。

接入初期的建议顺序是：先只开读取域，跑一段观察调用是否稳定；再开内容写入域，并保留回合级审批；运维域按实际需要单点开启，用完可以再次关闭。技能（Skills）类的批量能力也建议在同一阶段接入，因为批量操作一旦放给客户端，影响面比单篇保存大得多。

常见问题

接入外部客户端要不要换一套权限？ 不需要新账号体系，但要为接入单独配置访问凭据，并按域最小化开放；凭据的轮换周期与后台管理员口令保持一致即可。

回合级审批会拖慢工作吗？ 只会增加一次确认。真正的风险来自没有确认时的批量误写，两者成本不在一个量级。

只读接入还需要审批吗？ 不需要，读取类不参与审批；但读取域里若包含系统设置这类敏感字段，应按域收紧而不是放开整组。