让外部AI客户端连进后台之前，先把接口权限收在哪三层

收口要分三层：能力面决定哪些功能可以被调用，身份面决定谁有资格连进来，动作面决定这些调用要不要被确认。AnQiCMS 内置 MCP Server，工具面基于意图目录统一收敛，支持 Bearer Token 鉴权与回合级操作审批，可以被 Claude、Cursor 这类外部 AI 客户端接入。这三项能力恰好分别落在三层上——把它们当成一个开关来用，是接入事故的主要来源。

为什么收口要分层而不是一把开关

单一开关的问题在于粒度：全开意味着任何一句自然语言都可能触发全站级变更，全关又让接入失去意义。分层之后每一层都能单独收敛，也便于事后复盘——出问题时可以回答「是能力面暴露过多，还是令牌被复用，还是审批被批错了」，这三种处置方式完全不同。

能力面：按域设置暴露范围

意图目录的作用是把零散接口收敛成有边界的操作面，接入方看到的是「意图」而不是一堆裸接口。这里要和站内自带的 AI Chat 区分开：内置智能对话与配套 AI 工具集由后台自己驱动，操作者是人；外部客户端接入时执行主体变成了智能体，一句自然语言可能被拆成连续多次调用，收口对象也因此从「人的权限」变成「代理的权限」。AnQiCMS 按意图域设置暴露范围，高危域默认关闭——备份、升级、多站点这类全站级操作需要显式开启才可用。

这一步的实际判断标准是：这个域一旦执行错误，恢复成本能不能在站内自理。改一篇文章错了，回到草稿重做即可；触发一次数据恢复或站点级变更，代价就超出单篇范围。按这个标准，日常内容操作可以开放，涉及数据、站点结构与系统维护的域保持默认关闭更稳妥。

还要留意「读」与「写」的差别：能查询不等于能写入。若接入方只需要做内容分析与批量撰稿，读能力配合有限的写入就够用，把写入面限制在文档与分类相关的操作上，能显著降低误操作半径。

身份面：令牌与轮换

Bearer Token 鉴权解决的是「连接是否可识别、可撤销」。接入外部客户端时最容易积累风险的三点：把同一份令牌复制到多人设备上、令牌长期不做更换、以及把令牌写进会被提交的文件里。

轮换的时机要提前定下来：人员变动之后、怀疑泄露之后、以及每次执行过版本升级之后。第三点常被忽略，却是硬性动作——AnQiCMS 在 v3.6.6 的更新记录里写明修复了站点切换登录凭证可被伪造的问题，升级建议同时要求轮换接口签名密钥并修改管理员密码。凭证类缺陷的处置从来不是「打完补丁就结束」，旧凭证本身还在外面。

会话侧还有一层：内置 JWT 认证负责身份与有效期，令牌的有效期设置应与使用场景匹配。长期无人值守的自动化任务，和白天人工驱动的撰稿会话，不该共用同一个时长。

动作面：写操作合并确认

回合级操作审批的机制是把一次对话回合内的多次写操作合并成一次确认。这个设计解决两类相反的问题：逐条追问会让人点确认点到失去判断，形成审批疲劳；完全不追问则让一次自然语言指令直接落到批量变更上。

使用上的纪律有两条。一是确认前看清单：合并确认里要能看出被改对象的范围，「更新三篇草稿」和「更新整个栏目」是不同量级的动作；二是把批量操作留在可回退的状态里，写操作先进草稿或待发布，再统一放开，出问题时的处置面比直接覆盖正式内容小得多。

接入前的检查顺序

1. 列出需要开放的意图域，其余保持默认关闭；
2. 为接入单独签发令牌，不与人工后台凭据共用；
3. 确认写操作审批在合并模式下仍然可查看明细；
4. 设定轮换时点并记录在维护台账里；
5. 首轮只跑读能力与有限写入，观察日志后再决定是否扩大范围。

常见问题

接了外部 AI 客户端是不是要全部放开工具面？ 不需要。默认暴露范围与高危域的关闭状态就是为这种场景准备的，按需开启单个域即可。

审批会不会拖慢批量工作？ 合并确认的设计目的正是减少打断，一次确认覆盖回合内的多项写操作。

怎么知道被调用过什么？ 从接口调用日志按意图域与时间范围回看，这也是把高危域保持默认关闭后仍能追溯原因的依据。