自定义 MCP 连接器真正难的不是把 endpoint 填进去，而是把 developer mode、RBAC、OAuth 刷新令牌、草稿测试和 write actions 审批线一次配清。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
很多团队第一次碰自定义 MCP 连接器，会把注意力放在“能不能扫出 tools”，却忽略了真正会在上线后出问题的四个点：谁能开 developer mode，谁能上传草稿，OAuth 刷新令牌会不会过期，写动作到底是默认 ask 还是默认放行。只要这四个点没说清，MCP app 再能干，也会在第一次写入 CRM、工单系统或项目管理工具时把团队拉回人工审批混乱。
适用场景
- 你在 ChatGPT Business、Enterprise 或 Edu 工作区里，准备接入自建或第三方 MCP server。
- 你不只需要 read/search，还希望让 ChatGPT 触发 create、update、assign 这类写动作。
- 你需要把应用发布给工作区成员，而不是只在管理员个人账号里临时测试。
- 你希望把应用治理做成可复用流程，避免每次上线一个 connector 都重新踩坑。
不适用场景
- 你只是个人 Pro 用户，当前 full MCP write/modify 不是你的默认可用面。
- 你只有本地 MCP server，且没有准备 Secure MCP Tunnel 或可访问的远程服务。
- 你的团队还没定义哪些系统允许被 AI 代操作，却想直接开放 Never ask。
- 你期待 agent mode 自动使用 custom apps 处理写动作，这和当前能力边界不一致。
先把 2026 年 7 月这轮变化读清
截至 2026 年 7 月 27 日，OpenAI Help Center 已把 custom apps、full MCP support 和 developer mode 的边界写得很清楚。第一，full MCP write/modify actions 正在 Business、Enterprise、Edu 里以 beta 方式滚动，UI 和权限仍可能调整。第二，App Directory 已在 2026-07-09 迁到 Plugin Directory，插件现在是工作流发现入口，底层 app 仍负责数据和动作。第三，管理员不仅要管 app 本身，还要同时管 plugin 安装、底层 app 的 Action control、角色访问，以及成员何时会被要求确认写动作。
另一个关键区别是计划差异。Business 里只有 admins/owners 能启用 developer mode 与发布 app，而且发布后当前不能原地更新，只能 recreate and republish；Enterprise / Edu 则可以先用 RBAC 给特定成员开放 developer mode，再在发布前后分别控制 access 与 actions。这个差异决定了你不能拿 Enterprise 的治理流程去假设 Business 也能照搬。
准备材料
- 明确工作区计划类型：Business 还是 Enterprise / Edu。
- 一张应用台账：MCP endpoint、用途、读写范围、负责人、上线日期、回滚入口。
- 身份与权限方案：哪些人是 admin / owner，哪些人需要 developer mode，哪些组可以使用应用。
- OAuth 资料：scope、redirect、是否支持 offline_access 或等价 refresh token 能力。
- 最小化测试脚本：至少包含 1 个 search/fetch 场景、1 个 write 场景、1 个失败回滚场景。
步骤一：先决定谁有权创建和发布，而不是先连 endpoint
正确顺序是先定义角色，再碰技术接入。Business 工作区里，启用 developer mode 和发布 app 的主体就是 admins / owners；Enterprise / Edu 则多了一层 RBAC，允许你把 build / test 权限交给指定成员，但最终 publish 仍由 admins / owners 收口。只要这一步没先做，后面所有“谁改了 connector”“谁开放了写动作”都会变成口头解释。
- 列出当前 admins / owners，确认至少有两名能接手发布与回滚，避免单点。
- 若是 Enterprise / Edu，先定义需要 developer mode 的用户组，不要默认全员。
- 把 app owner、业务 owner、审批 owner 分开，避免同一人既发布又自审。
- 把 publish 入口和 disable 入口写进 runbook，后续出问题时能直接执行。
步骤二：开发者模式先开对位置，再做最小连接
OpenAI 文档里最容易被忽略的是启用路径。Business 侧主要从 Workspace settings → Apps → Create 进入；Enterprise / Edu 则可以在 Settings → Apps → Advanced Settings 给已授权用户开启 developer mode。只有先在正确入口下打开，后面的草稿 app、Drafts 列表和 Dev 标签才会出现。
- Business：只让管理员本人开启 developer mode，不要把共享账号当 workaround。
- Enterprise / Edu：先用 RBAC 给组授权，再让组内成员各自打开 developer mode。
- 第一次连 server 时先上最小可用 endpoint，避免一口气暴露所有 tools。
- 如果你的 app 需要多个 tool 面，先分 read-only 草稿和 write-capable 草稿，不要一步到位。
步骤三：OAuth 刷新令牌没配好，后面所有稳定性都会失真
Help Center 在 OAuth 部分给了一个非常实用的提醒：如果 provider 没发 refresh token，原始授权一旦过期，ChatGPT 侧就只能要求用户重新认证。也就是说，你在测试阶段觉得“一切正常”，并不代表两天后还正常。管理员应该在草稿阶段就确认 discovery metadata 是否宣告了 offline_access 或等价 scope，并确保 provider 实际会发 refresh token。
- 检查 `.well-known/openid-configuration` 或 `.well-known/oauth-authorization-server` 是否声明 refresh 能力。
- 把 offline_access 或等价 scope 写进接入文档，而不是只口头说“应该会发 refresh token”。
- 若 provider 不发 refresh token，就把重认证窗口和用户影响写清，不要让成员临时发现。
- OAuth scope 能分层时，先用最小 scope 走草稿测试，再决定是否补写权限。
步骤四：Scan Tools 不是验收终点，草稿测试才是
很多人把 Scan Tools 成功当作上线成功。实际上，它只说明 schema 扫到了，不说明动作边界正确。更稳的做法是让草稿 app 先出现在 Workspace Settings → Apps → Drafts，然后用真实对话去跑：能否选择 app、Dev 标签是否清楚、读动作是否自动、写动作是否会 ask、失败时是否能回退。
- 先从一个新聊天里选中草稿 app，验证成员能否看到它。
- 跑一条 search/fetch 提示，确认不会错误触发写动作。
- 再跑一条 write 提示，观察是 Always ask、Any changes、Important actions 还是 Never ask。
- 记录 ChatGPT 实际弹出的确认文案，看是否足够让用户理解风险。
- 故意触发一个失败写操作，检查日志、错误返回和是否出现脏数据。
步骤五：发布前先配 Action control，再决定要不要给成员默认开放
Apps in ChatGPT 帮助页已经把权限选项说明得很直白。默认推荐是 Important actions：读取可自动，重要变更仍 ask。对大多数工作区来说，这也是最稳的起点。不要因为某个业务团队嫌多一步确认，就把整个 app 直接开成 Never ask。更实用的做法是先按 app 分层：读多写少的维持 Important actions；真正高频但可回滚的内部写动作，再单独评估是否收紧到 Any changes 或放宽。
- 面向工单、项目状态、CRM 修改等外部副作用强的动作，优先保守。
- 如果插件封装了多个底层 app，要分别检查每个 app 的 action control，而不是只看插件壳。
- Enterprise / Edu 在发布前先配置 access groups，避免上线后再补权限。
- Business 无法更新已发布 app 时，更应该把草稿测试做足，否则改一次就要整包重发。
可复制上线模板
工作区计划：Business / Enterprise / Edu
应用名称：
MCP endpoint：
负责人：
是否启用 developer mode：
RBAC 目标组：
OAuth provider：
refresh token scope：
草稿测试通过的 read 场景：
草稿测试通过的 write 场景：
默认 action policy：Always ask / Any changes / Important actions / Never ask
发布日期：
回滚入口：Disable / Remove access / Recreate and republish
首轮复查日期：实际例子：把内部工单 connector 从“可用”改成“可治理”
一个八人运营团队想让 ChatGPT 帮忙创建内部工单。最初他们只验证了 Scan Tools，结果上线后有人发现不同成员对同一个动作看到的确认弹窗不一致，另一些人授权过期后完全找不到原因。后来团队重做流程：先把 Enterprise RBAC 只给两名 builder，再让管理员检查 OAuth 是否支持 offline_access，最后把 write 动作保持在 Important actions，只开放给客服组与项目组。这样做后，工单 connector 才真正成为“可治理”的工作区工具，而不是管理员个人的演示玩具。
验收清单
- 工作区计划与发布权限边界已确认，至少两名管理员可回滚。
- developer mode 的开启路径已按计划类型验证。
- OAuth refresh token 能力已确认，不靠“应该支持”的猜测。
- 草稿 app 已完成 read、write、failure 三类对话测试。
- Action control 已配置，默认不是因为偷懒直接 Never ask。
- Enterprise / Edu 的 access groups 已在发布前设置完成。
常见坑
- 把 Scan Tools 成功误当作应用已经可上线。
- Business 工作区发布后才发现不能原地更新，只能重建重发。
- OAuth 没有 refresh token，过几小时或几天后成员频繁重认证。
- 插件目录可见，就误以为底层 app 的权限也已经安全。
- 把 write-capable app 默认开给所有成员，后面再回头补审批线。
排错路径
- 看不到 developer mode：先查计划类型与角色，而不是先怀疑 UI bug。
- app 只在管理员这里可见：检查 RBAC、workspace access 和是否仍停留在草稿态。
- 授权老掉：回头查 provider 是否真正发了 refresh token。
- 成员写动作不 ask 或 ask 过多：复查 app permissions 与 Action control 设置。
- 发布后要加 tool：Business 走 recreate and republish，Enterprise / Edu 先 Refresh actions 看 diff。
后续维护建议
更新日期：2026-07-27。最值得固定的不是“接入了多少 app”，而是三张表：app 台账、动作审批表、OAuth 复查表。每次 OpenAI 调整 Plugin Directory、Apps 或 developer mode 界面时，先复查这三张表，再决定要不要扩大 connector 范围。对工作区管理员来说，真正稳定的不是接得快，而是知道哪条写动作该被谁看到、谁批准、谁能回滚。