Slack Code 让编码代理实现多人协作——GitHub 仍需要合并门
Slack Code 让团队看见编码代理的工作，但 Slack 不负责控制仓库合并、CI 完整性、构建产物或生产部署。
Slack 推出了专门的 代码频道，团队可以在其中要求 AI 编码代理工作、跟随其计划、检查差异和预览、提供反馈，并将会话保存在可搜索的频道中。这次发布支持 Claude Code、Devin、GitHub Copilot 和 Vercel 代理。
这让代理的工作更加可见。但它并没有让 Slack 变成负责授权仓库合并或生产部署的系统。
重要的边界很简单：Slack Code 是协作和证据界面，而 GitHub 仍然强制执行仓库变更，部署平台控制生产发布。 “已批准”的消息是有用的上下文，但除非下一个系统在行动前验证该批准，否则它不是安全控制。
Slack Code 改变了什么
Slack Code 产品页面描述了一个为单个项目或任务创建的临时频道。团队成员可以观看代理工作、检查其差异、打开实时预览或计划、发表评论并批准结果。工作完成后，频道会被归档，但其上下文仍可搜索。
Slack 当前的代理帮助页面称，用户可以创建公开或私有代码频道，选择受支持的代理，并监测代理是在工作还是需要关注。同一页面说明，所有者可以要求应用审批，应用对 Slack 数据的访问取决于其权限范围，而将应用添加到对话会授予它访问该对话数据的权限。
VentureBeat 和 Computerworld 分别于 8 月 20 日和 21 日独立报道了这种共享工作流。两者都将其描述为围绕合作伙伴代理的协作层，而不是由 Slack 单独托管的编码运行时。它们报道 Slack Code 覆盖各类 Slack 套餐，而 VentureBeat 指出，客户仍需要拥有所选合作伙伴代理的访问权限。
这是一项有意义的产品变化。私人的单人代理会话可能隐藏初始请求、中间假设和失败尝试。共享代码频道则为工程师、产品经理、设计师和其他参与者围绕工作提供一份可见记录。
可见性解决了协调问题。但它本身并不能解决授权、代码质量、软件供应链完整性或发布安全问题。
共享频道不是交付控制平面
控制平面是强制规定谁可以执行某项操作，以及必须先满足哪些条件的系统。Slack 控制 Slack 对话和应用。所选代理提供商控制其运行时。GitHub 控制仓库身份、受保护分支、审查和合并权限。CI 控制检查和构建流程。部署平台控制生产凭据和发布。
Slack 页面称，代码频道使用现有的 Slack 安全和权限控制，包括围绕 Slack 消息的企业治理。这一说法针对的是 Slack 边界。它没有记录每个合作伙伴代理的仓库令牌、沙箱、网络策略、日志留存或云凭据路径。
VentureBeat 报道 Slack 高管称，代理以发起用户的访问权限行动，标准 GitHub 拉取请求保留现有审查流程。同一报道明确了运营边界：Slack 可以降低创建拉取请求所需的工作量，但尽职审查仍在 GitHub 中进行。应把访问模型当作一项需要用组织所选的具体代理验证的集成声明，而不是四个合作伙伴都共享的统一实现。
Slack Code
控制项： 频道成员资格、可见性、应用权限范围和对话上下文。
保留证据： 请求者、所选代理、频道可见性和已批准的数据类别。
代理运行时
控制项： 执行身份、沙箱、网络访问、工具和保留策略。
保留证据： 提供商、集成版本、仓库范围、令牌类型和策略。
GitHub 拉取请求
控制项： 仓库访问、受保护分支、审查和合并权限。
保留证据： 拉取请求、头部提交、必需审查者、检查和绕过状态。
CI 与构建产物
控制项： 可信工作流、测试身份、构建隔离和输出来源。
保留证据： 工作流提交、检查来源、日志和已审查产物摘要。
部署
控制项： 环境审批、发布身份、密钥、滚动发布和回滚。
保留证据： 审批人、发布 ID、目标环境、结果和撤销测试。
推进规则：可见的 Slack 批准是协作证据。只有强制执行的仓库、CI 或部署门才能授权进入下一个边界。
系统之间的交接处正是“多人协作”工作流可能变得含糊的地方。几个人可以在 Slack 中发表评论，但谁授权了仓库访问？代理可能发布预览，但哪个提交生成了它？审查者可能批准一个差异，随后代理又推送另一个提交。绿色 CI 徽章可能来自不可信或名称含糊的检查。已合并的拉取请求可能仍未获得生产授权。
每个答案仍属于执行相关操作的系统。
五个系统仍各自负责五种不同的边界
Slack 工作区管理员控制应用、权限范围、频道可见性和消息留存。合作伙伴代理控制其运行时身份、沙箱、工具和网络访问。GitHub 控制仓库权限和合并规则。CI 确定哪些代码和工作流生成了构建产物，而部署平台控制生产凭据和发布审批。
Slack 的权限范围指南建议使用已发布功能所需的最小权限范围，并区分机器人令牌和用户令牌。GitHub 的 应用安全指南同样建议最小权限、仓库限制、短期安装令牌和安全日志。共享频道不会取代任一边界。
GitHub 仍是合并门
在仓库规则将拉取请求变成门之前，它只是一处审查界面。GitHub 的受保护分支文档支持必需的拉取请求审查、状态检查、对话解决、签名提交、合并队列、部署要求、推送限制，以及防止绕过规则的设置。
受保护分支可以阻止直接推送和强制推送，要求当前审查，在差异发生变化后撤销批准，要求指定检查，并限制绕过权限。这些控制——而不是存在一个拉取请求——让审查变得可强制执行。代理仍可以创建分支并提出变更，却无权合并变更或改写仓库规则。
GitHub 的 CODEOWNERS 文档说明，代码所有者可以针对变更文件被自动请求，并成为必需的审查者。保护 CODEOWNERS 文件本身；否则，对所有权映射的变更可能削弱下一次审查。
“有人看过它”不是足够详细的记录。应记录：获授权的审查者批准了后来通过必需检查并进入合并队列或合并操作的确切头部提交。Slack 反应、频道消息或代理生成的摘要可以链接到该证据，但不应取代它。
CI 和部署仍是分开的信任边界
代理生成的拉取请求可以修改应用代码、测试、依赖、构建脚本和工作流。因此，CI 同时评估提议的产品变更和可能已被修改的评估环境。
Snowflake GitHub Actions 案例说明，绿色自动化结果并不能证明工作流本身安全地处理了不可信输入。对于 Slack Code 试点，应为拉取请求作业提供最小权限，将生产凭据排除在不可信作业之外，固定或以其他方式控制第三方构建依赖，并要求审查工作流、构建、发布和所有权文件。
将任何预览或测试结果绑定到拉取请求的确切头部提交。然后将推广的构建产物绑定到摘要或另一个不可变身份。审查后重新构建可能产生不同输出；部署“最新构建”可能选中审查者从未见过的构建产物。
部署应要求自身的授权。GitHub 的环境文档支持必需审查者、防止自我审查、分支或标签限制，以及在环境保护规则通过前对作业保持不可用的密钥。其他部署平台上的等效控制也有同样作用。
Slack 频道可以通知服务所有者并显示部署结果。但不能仅因为某个聊天参与者能够看到或引导编码会话，就让他成为生产审批者。
Slack 的价值取决于它不拥有的控制
完整路径仍然从 Slack 请求者经过代理身份、拉取请求头部提交、必需审查、可信检查、不可变构建产物、部署审批，最终到达生产结果。Slack 让团队更容易看到这条路径的某些部分，但不会把它们合并成一个权威。
任务接受率、审查时间、失败率、成本和人工修复，比生成的拉取请求数量能揭示更多信息。Mojo 编译器源代码审查提供了相关例子：代码可见性提高了可审计性，但贡献和发布治理仍是不同的问题。
Slack Code 的共享记录可以让代理工作更容易检查和协调。这很有价值。最强的实现会把这种协作证据连接到 Slack 不拥有的控制：范围严格的代理凭据、受保护分支、当前的人工审查、可信 CI、不可变构建产物，以及独立批准的部署。多人编码应该扩大对话的参与范围，而不是扩大那些可以悄悄合并或发布代码的人群。
资料来源
- Slack Code product page
- Slack help for working with AI agents and code channels
- Slack developer guidance on app scope discipline
- VentureBeat report on the Slack Code launch and security model
- Computerworld report on Slack Code workflows and permissions
- GitHub documentation on protected branches
- GitHub documentation on code owners
- GitHub documentation on deployment environments
- GitHub App security best practices