外部 AI 客户端接入站内 MCP，鉴权和回合级审批分别怎么配

外部 AI 客户端接入站内 MCP 时，鉴权解决的是「谁能进来调用」，回合级审批解决的是「这一轮改动要不要执行」，两者不能互相替代。配置顺序建议是先收工具面、再配鉴权、后设审批：工具面按意图目录收敛到需要的能力域，鉴权用 Bearer Token 固定下来，最后让写操作在回合层面统一确认。

接入前先看清工具面怎么收敛

AnQiCMS 内置 MCP Server，它的工具面不是把每个后台动作单独开放，而是基于意图目录统一收敛——同一个业务意图对应一个稳定的调用入口。这一层设计的意义在接入外部客户端时才显现：客户端的能力来自它能看到的工具集合，你不必担心提示词把模型带到没准备的路径上，只需要在意图目录这一层决定开放哪些域。站内自带的 AI Chat 与 AI 工具集走的是同一套编排方式，外部客户端接入后并不获得额外特权。

鉴权配在哪一层

MCP 接入使用 Bearer Token 鉴权，配置要落在服务端而不是客户端：token 由站方生成、按接入方分发、可随时失效。三条实践要求容易在试点阶段被忽略。其一，外部客户端（Claude、Cursor 之类）与站内 AI 助手不要用同一份凭证，否则一次泄露两头的会话都失去可信度。其二，凭证不要出现在共享提示词、截图或工单正文里。其三，验证要真的验证——拿一条无鉴权头的请求确认被拒，而不是假设网关已经拦下。

回合级审批管住什么动作

写操作合并确认是这套审批的核心：模型在一轮里产生的多个改动不会逐个自动落库，而是汇聚成一个回合，由人确认后一并执行。它挡住的不是恶意调用，而是模型常见的连续误操作——批量改名、连带调整分类、把不该动的草稿一起提交。配置上要注意两点：审批的粒度是回合而不是单次调用，所以一个回合里塞的动作越多，人工确认的核对成本越高；只读查询不必占用审批，把审批留给真正会改数据的动作。

高危域默认关闭的意义

按意图域设置暴露范围时，备份、升级、多站点等全站级操作属于默认关闭的一类，需要显式开启。这一点对外的解释很直接：外部客户端的能力边界应该等于你愿意让自动化承担的责任范围。日常内容运营用不到全站级操作，就把它们留回默认状态；确实要开，也只在明确的维护窗口临时开启，用完关回去。先收暴露范围、再谈审批细节，顺序反了就会出现「审批很严但入口很宽」的错配。

接入后的最小权限验证

收尾用三个问题检验配置是否达成：这个客户端能不能只完成内容任务而不触及站点级操作？它的写操作是否确实停在回合确认这一步？它调用的日志能不能按接入方区分，出问题时能不能单独撤掉这一份鉴权？三问都是「是」，接入才算闭环。

常见问题

问：外部客户端支持自定义工具描述，还需要收意图目录吗？ 答：需要。工具描述只影响模型怎么选，不限制它能调什么；真正划边界的是服务端按域设置的暴露范围。

问：只读接入是不是可以不配审批？ 答：可以，但要把域收紧到只读能力上。审批是给写操作准备的，只读接入的风险点在于读取范围而不是执行确认。

问：接进来以后模型连续改坏了内容怎么办？ 答：先靠回合确认拦下未执行的改动；已落库的部分按回收站与备份恢复处理，两种手段覆盖的范围不同，前者是文档级，后者是数据与静态文件级。