准备把 ChatGPT 接入 Slack 的团队，真正该先做的不是把动作全开，而是先把共享连接、写动作审批和频道边界分层。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
如果你的团队已经把 Slack 当成工单入口、通知总线和日常协作台，最近最容易踩坑的不是“能不能连上 ChatGPT”，而是连上以后谁能读、谁能写、哪些动作要审批、哪些 scope 该先挡住。OpenAI 在 2026 年 6 月和 7 月连续更新了 Slack connector actions、Apps 权限和 Workspace Agents 的 Slack 通道能力，现在最值得做的不是抢着全开，而是先把审批边界和共享连接模型理顺。
适用场景
这篇清单适合三类人。第一类是 ChatGPT Business 或 Enterprise 管理员，准备让成员在 ChatGPT 里直接搜索 Slack、加入频道、创建提醒、上传文件或改资料。第二类是已经在 ChatGPT 里启用了 Workspace Agents，想把 agent 部署到 Slack 频道里跑日常流程的人。第三类是安全或 IT 负责人，担心共享连接把个人账号权限带进团队工作流，想先做最小权限上线。
不适用场景
如果你的团队还没有统一的 Slack 工作区管理权、没有明确的频道命名规范，或者目前只想让成员单独在个人聊天里临时试用，而不是组织级上线，这篇文章不用一次做全套。还有一种情况也不建议立刻上线：你们希望 agent 在 Slack 里代发跨部门消息、批量改用户资料、自动上传敏感文件，但还没有服务账号、审批人和日志复核流程。这类高影响写动作应该先收窄场景，再上线。
先看懂这次更新到底变了什么
先分清两个层面。一个是 Apps in ChatGPT 的通用 app 权限。OpenAI 现在把 app 权限做成了四档：Always ask、Any changes、Important actions、Never ask。默认是 Important actions，也就是读类动作大多可直接执行，但会对外部影响大、难回滚或可能暴露敏感信息的动作弹确认。另一个层面是 Workspace Agents。Workspace Agents 可以连 Slack 通道，可以设置 shared auth，可以给 write actions 设 Always ask 或自定义限制，还能给 connector action 加约束。真正的风险往往出在第二层，因为 agent 一旦进了 Slack 频道，触发者不再只是 builder 自己。
再看一个容易忽略的点。OpenAI 的 2026-06-19 Business release notes 已经明确写出，Slack connector actions 不只是“搜消息”，还包括加入频道、创建提醒、上传文件、更新 Slack profile 等动作；某些动作需要额外 OAuth scopes 或 Slack admin approval。也就是说，用户在 ChatGPT 里看到一个动作按钮，并不代表你就应该让它在团队里默认可用。
准备材料
- 一个 ChatGPT Business 或 Enterprise workspace，并确认自己有 owner/admin 权限。
- 一个 Slack 工作区，最好已经有服务账号或专用 bot 账号策略。
- 一张动作分级表，至少列出“纯读取”“低风险写入”“高影响写入”三档。
- 一个试点频道，建议单独建成只给内部员工用的 sandbox 频道，而不是直接进全员频道。
- 一个回滚人和一个复核人。回滚人负责断开 app、停用 agent、撤销共享连接；复核人负责验收日志与权限边界。
步骤一：先决定你要上线的是 ChatGPT 里的 Slack app，还是 Slack 里的 Workspace Agent
很多团队把这两个路径混在一起，结果审批链完全失控。你可以先按下面的判断表拆开：
- 如果你的目标是“成员在 ChatGPT 里查 Slack 内容，偶尔做少量动作”，先上 Apps in ChatGPT。
- 如果你的目标是“把一个固定 agent 放进某个 Slack 频道，让多人在频道里调用”，先设计 Workspace Agent 的 Slack channel 部署。
- 如果你两种都要，先把 App 权限试跑稳定，再给 agent 接 Slack，不要反过来。
原因很简单。前者主要管单个 app 的连接和动作权限，后者还要多一层 channel、shared auth、builder 限制和 trigger 入口。能少叠一层复杂度，就少叠一层误操作面。
步骤二：在 ChatGPT 里把 Slack app 先设成“可控可回退”的状态
Business 默认启用 apps，Enterprise/Edu 默认关闭 apps。无论你是哪种计划，都别急着让成员自己连。先到 Workspace settings > Apps 里检查三件事：
- Slack 这个 app 是否已经对当前角色开放。如果是 Enterprise，先只对试点角色启用，不要一键开放给所有成员。
- Action control 现在是只读、全部动作，还是自定义。团队第一次上线时，建议从只读或最窄自定义开始。
- 新动作的默认处理方式。新增动作别自动放行，优先选择“新增动作先禁用，人工复核后再开”。
这里的关键不是“让成员能连上”，而是“新 scope 或新动作出现时，不会自动穿透你原来的策略”。OpenAI 在 release notes 里已经提醒，Slack 某些动作会因为缺 scope 而要求重新连接或联系管理员，这本身就是一个很好用的安全缓冲层。
步骤三：把权限默认值设在对团队最稳的那一档
对多数团队来说，Slack 不适合一开始就设 Never ask。更稳的做法通常是：
- 个人对话里的 Slack app，默认用 Important actions。
- 只要涉及写动作，先评估是否要降成 Any changes。
- 如果是共享账号、公共频道或跨部门频道，优先用 Always ask 或 Any changes，而不是 Important actions。
为什么公共频道更保守？因为 Slack 里的动作很容易触发对外可见的变化。加入频道、上传文件、改 profile、发提醒，看起来不像删库删号那样惊险，但一旦走的是 shared auth，就可能把 builder 或 service account 的能力暴露给更多触发者。Important actions 的判断本来就依赖上下文，在组织上线阶段，把审批门槛抬高一点，成本远小于回收误操作。
步骤四：如果要把 agent 放进 Slack，先选对认证模式
Workspace Agents 文档把认证分成 end-user account 和 agent-owned account。Slack 通道这件事上，判断原则很直接：
- 只给个人用、每个人都应该以自己身份访问的数据，用 end-user account。
- 要部署到 Slack 频道、让多人共用的 agent，必须规划 shared auth，也就是 agent-owned account。
- 只要是 agent-owned account，就尽量使用服务账号，不要直接拿某个员工的个人 Slack 连接来做共享身份。
OpenAI 在 Workspace Agents 帮助文里写得很清楚：如果你用个人账号来配置 shared auth，其他人在 Slack 里调用 agent 时，可能会通过这条连接触发本不该拥有的动作。这不是抽象风险，而是组织级配置里最常见的权限借道问题。
步骤五：给 write actions 和 connector constraints 单独设“护栏”
把 app 开了，不代表每个动作都能自由跑。真正好用的上线方式，是把 write approvals 和 Connector Action Constraints 一起配：
- 先把 write actions 维持在 Always ask。
- 把高频但低风险的动作单独列出来，例如在固定频道创建提醒。
- 如果确实要放宽，先用 Custom 针对某个具体动作开，不要整组放开。
- 为 connector 加参数约束，例如只允许操作某几个频道、只允许上传到指定项目频道、只允许修改有限字段。
- 对无法约束范围的动作，宁可保持审批，不要为了流畅度把边界删掉。
一个实用经验是：审批解决“要不要人点头”，约束解决“即使点头，也只能在什么范围里做”。两者不是替代关系。只靠审批，用户照样可能在批准时没看清目标频道；只靠约束，低风险动作又会反复卡人。两层一起用，效果最好。
步骤六：在试点频道做一轮完整验收
不要用“我能搜到消息”当成上线完成。最少要验六项：
- 读动作是否按预期工作，例如搜索指定频道历史。
- 需要审批的写动作是否真的弹卡片，而不是静默执行。
- 缺 scope 的动作是否会提示 reconnect 或 admin review，而不是报模糊错误。
- 频道外的目标是否被约束拦住。
- Slack 管理员撤销权限后，动作是否会立即失效。
- builder 修改 agent app 配置时，是否符合文档里关于 Slack 部署期间 owner-only 的限制。
如果这六项只测前三项，正式上线后最容易出问题的就是边界外写入和共享连接遗留权限。
可直接复用的上线检查清单
- 确定是 app 试点还是 agent 试点，不混着上。
- 确认 Business/Enterprise 的默认 app 状态和角色开放范围。
- Slack app 的 Action control 先用只读或最窄自定义。
- 默认权限不用 Never ask，公共或共享场景优先 Always ask / Any changes。
- 部署到 Slack 频道时，所有 app 连接改成 shared auth 前先评估 service account。
- 给高影响动作加 connector constraints，不只靠审批。
- 在 sandbox 频道做六项验收后再扩角色。
- 准备回滚动作：禁用 app、撤销 scope、断开共享连接、移除 Slack 渠道部署。
实际例子：把“每日 standup 汇总”做成低风险 Slack agent
假设你要做一个站会汇总 agent。它需要读固定频道的近 24 小时消息，生成摘要，必要时在同一频道发一条整理后的待办。这个场景的稳妥做法是：
- 只给 agent 接一个服务账号，不用某个经理的个人 Slack 身份。
- 只给它连接 standup 频道，不接全公司频道。
- 读动作放开，发总结这一个写动作保留 Always ask。
- Connector constraints 里把目标频道限制为 standup 频道 ID。
- 前两周不让它自动响应全部消息，只在被提及时执行。
这样做的结果是，团队能先拿到“搜内容和整理内容”的价值，而不会因为一次误触发，把内容发去错误频道或者拿 builder 个人身份去改工作区资料。
常见坑
- 把 Business 默认启用 apps 理解成“所有动作都能安全启用”。默认启用只代表功能可用，不代表动作策略已经替你配好。
- 让 builder 用自己的 Slack 个人账号配置 shared auth。短期最省事，长期最危险。
- 只做 ChatGPT 侧测试，不做 Slack 频道侧测试。很多错误只会在 channel deployment 后出现。
- 看到动作失败就盲目给更多 scopes。正确顺序应该是先确认动作是否真的需要该 scope，再决定是否让管理员批准。
- 把 Important actions 当成“总能挡住风险”。它是默认值，不是组织级最严策略。
排错路径
- 动作按钮可见但执行失败：先看 Slack app 是否真的启用了相应 action，再看 scope 是否已被管理员批准。
- 成员能在 ChatGPT 用，进 Slack 频道后失效：检查是否所有连接都已切换为 shared auth。
- Builder 能改，其他人不能用：检查 Apps 角色开放、Workspace Agents 角色权限和 Slack app 目录是否已对目标角色启用。
- Agent 在 Slack 里能跑，但动作范围太大：回到 Safety 区加 Connector Action Constraints，而不是只改说明文案。
- 换 Slack workspace 后全失效：按照 OpenAI 文档，Slack bot 连接会重置，旧频道部署会被移除，需要重新连接。
后续维护建议
更新日期：2026-07-18。以后每次看到 OpenAI release notes 里出现 Slack app scopes、new actions、Workspace Agents Slack behaviors 更新，都应该重复做三件事：复查 Action control 默认值、复查 shared auth 是否仍是服务账号、复查 connector constraints 是否覆盖了新增动作。真正稳定的团队，不是上线那天配得最全，而是每次功能扩张时都能把边界重新画一遍。