ChatGPT 桌面版 macOS 无法调用私有插件工具的问题分析与应对建议

在最新的 ChatGPT macOS 桌面客户端中，开发者发现自己通过 window.openai.callTool 调用的插件专用工具不再生效。这些工具在后台声明了 openai/visibility: "private" 以及 openai/widgetAccessible: true，按照 Apps SDK 文档它们应该是可以被小部件调用的。然而在桌面端调用时，Promise 会被直接拒绝，后端的 MCP 服务器根本没有收到任何请求。同样的代码在网页版、iOS 和 Android 客户端上却能正常工作，说明问题只出现在最新的 macOS 桌面程序里。
影响的版本信息已经在问题报告中明确给出：ChatGPT 桌面应用的内部版本号是 26.924.22138，运行的操作系统是 macOS 26.6.2（Apple Silicon）。受影响的插件名为 Steer Astro，它提供了两类工具：一类是用于读取和修改用户资料的 updateProfile 与 createProfile，另一类是用于渲染编辑表单的 getProfileForEdit 与 showCreateProfileForm。前两者被标记为只读提示 false、破坏性提示 true，后两者则相反。所有工具共享的元数据包括 _meta 中的 openai/visibility: "private" 和 openai/widgetAccessible: true，而表单渲染工具还有额外的 openai/outputTemplate 指向本地 HTML 文件。
复现步骤相当直接：在 macOS 桌面客户端中打开与 Steer Astro 的会话，让模型打开编辑资料的小部件；表单正常渲染后，修改任意字段并提交。此时小部件内部会执行 window.openai.callTool('updateProfile', {...}) 或者 window.openai.callTool('createProfile', {...})，但返回的 promise 会立即进入 reject 状态，开发者在自己的 MCP 服务器日志里根本看不到对应的调用请求。换到网页版或移动端重复同样的操作，后端会收到完整的工具调用并正常更新资料，这表明问题并不在于工具本身的实现，而在于桌面客户端对特定可见性声明的处理方式。
开发者推测，新版桌面客户端可能已经改变了工具可调用性的判断逻辑。它似乎只承认使用较新的 _meta.ui.visibility: ["app"] 这一字段作为工具能被小部件调用的依据，而把之前文档中仍被列为兼容字段的 openai/visibility 与 openai/widgetAccessible 当作无效内容忽略掉。这也解释了为什么直接由大模型发起的工具调用（不经过小部件）仍然可以成功——那些调用走的是另一条代码路径，仍然认得旧版键值。
影响范围不止于单个插件。所有仍然使用旧版可见性声明的已上架应用都会遇到同样的症状：用户能够看到表单界面，但在尝试保存时只会得到一个泛化的失败提示，后端毫无察觉。若想快速恢复功能，唯一的办法是把工具的元数据迁移到 _meta.ui.visibility: ["app"]，这意味着需要重新提交应用并经过审核流程。对于已经在商店里发布的产品来说，这不仅增加了工作量，还可能导致版本间的功能断裂。
基于以上观察，建议采取两层应对措施。短期内，开发者可以在 issue 跟踪器或官方渠道中请求恢复对 openai/visibility: "private" 与 openai/widgetAccessible: true 的支持，使得现有已上架插件在不改动元数据的情况下继续工作。长期来看，若平台真的计划淘汰旧键值，则应当提前给出明确的迁移指南和宽限期，并提供一种不需要完整重新提交的方式来更新工具元数据——比如仅修改元数据的轻量审核通道。这样既能保护开发者的投入，也能让用户在升级客户端后继续享受完整的插件功能。
总之，问题的核心在于桌面客户端对旧版可见性声明的支持缺失，而非插件代码本身的错误。只要平台方面能够兼容旧字段或提供便捷的迁移路径，受影响的插件就能够恢复正常的工具调用，用户也能够在编辑资料后看到实际的保存结果。希望后续的更新能够尽快把这一回归放进修复计划里。