技术 · 熟练
组织下发的 MCP，和用户自加的不一样
三个清单各管一段，混着读必然出错
工具接到一半最常出的错，不是接不上，是「政策看起来上了，其实没挡到该挡的」。新版本给组织加了一个托管设置：可以统一向全体成员下发 MCP 服务器，形状跟个人配置文件一样，但会执行本地命令的条目会被跳过。与此同时，另一个老设置的语义被改窄了 —— 它只管「用户自己加的」服务器，而托管的字面条目一律加载，除非被第三个清单（拒绝清单）挡掉。⇒ 三个清单各管一段，谁覆盖谁必须写清楚，否则同一条策略在不同人机器上会走出两种结果。这一页把这三层拆开，并给一套迁移时的对齐动作。
方法 · 一图看懂
1
先把三个清单的管辖范围写死 — 下发清单管「组织要给你的」· 用户清单管「成员自己加的」· 拒绝清单管「任何人都不许开的」；⛔ 三者的优先级不写清，就必然出现「在 A 机器上被挡、在 B 机器上放行」
2
下发前先过一遍「会执行本地命令」这一条 — 托管下发能带 HTTP / SSE 类服务器，带本地命令执行的条目会被跳过；所以别把「下发成功」当成「目标服务器都在跑」，要逐条核哪些被跳过了
3
迁移期两个设置一起看，不看一个 — 官方明确提示：只改一个可能无意间放出一个服务器、或压掉一个本该生效的；改完要有一份「改前 / 改后」的服务器清单对照
4
把拒绝清单当兜底，而不是当主策略 — 主策略应当是白名单（只放你要的），拒绝清单只用来挡已知的危险项；反过来做，就等于把默认值交给了「谁先写进来」
原理 · 为什么有效
为什么这类设置最容易「上了但没挡到」？因为它的语义改过一次，而改的那一处，正好落在「谁说了算」上。原先那个「允许清单」，多数管理员理解成「总体允许范围」；新口径把它收窄成「只管用户自己加的那些」，而托管的条目改为默认加载。⇒ 如果你按旧理解配置，以为只在允许清单里写三个就万事大吉，实际结果可能是下发清单里那十几个照样全开。
再叠一层同族的历史问题会更清楚：同一批修复里披露，托管设置块里只要有一个嵌套值非法，整块会被忽略；skills / 插件清单曾经能借自己的声明字段给自己预授权。两件事指向同一个结构性弱点 —— 「声明」与「生效」之间没有自动对账。所以本页的第一步不是「怎么配」，而是「怎么证明配上了」：三个清单的管辖范围、优先级、以及一份可核的服务器清单对照。
适用场景
适合：负责给一个团队 / 组织统一下发 AI 工具接入的人；管着一批机器、发现「同一个配置在不同机器上行为不一样」的人；正在把权限与工具接入从「各自配置」收拢到「统一治理」的团队。
不适合：只有自己一台机器、没有治理面的个人用户（三层策略对你就是一层，直接看个人配置文件即可）；以及把「下发成功」当验收终点的人 —— 那正是这一页要纠的读法。
自测 · 5 问
我说得出三个清单各管哪一段、谁覆盖谁吗？
我的下发清单里，有多少条会因为「会执行本地命令」而被跳过？核过吗？
迁移前后，我有一份服务器清单的对照吗，还是只有「改了一个设置」这个动作？
我的主策略是白名单，还是靠一个「拒绝清单」在挡？
有没有哪个成员机器上的实际结果，和中心策略不一致？我怎么知道的？
怎么上手 · 验证步骤
上手第一步只要做一件事：把当前三个清单的实际内容摊在一张纸上。下发清单（组织给的）· 用户清单（成员自己加的）· 拒绝清单（谁都不许）—— 三列并排，逐条写服务器名与传输方式。
接着两件配套动作：① 逐条核「会执行本地命令」 —— 把所有会被跳过的条目标出来，这份标记就是你和团队的预期差；② 定一次对齐窗口 —— 迁移当天取一次「改前清单」、第二天再取一次「实际生效清单」，两份对照，不一致的那几条就是下一轮要处理的。
自检动作：随机挑一台成员机器，问三个问题 —— ① 它现在能连上的 MCP 服务器，和中心策略期望的清单一致吗？② 有没有一条你以为被拒绝清单挡住的，其实在跑？③ 有没有一条你以为下发了的，其实因为会执行本地命令而被跳过了？三个问题里只要有一个答不上来，说明这份策略目前只是「写在文件里」，还没有「被验证过」。把这次抽查明写成清单，下次迁移时逐条复用。