8 月 20 日，Salesforce 旗下 Slack 发布 Slack Code。它干的事很直观：在团队频道里 @ 一个 Claude Code、Devin 或 GitHub Copilot，这个 coding agent 会自动开一个专属代码频道，把工作计划、代码改动前后的 diff、实时 HTML 预览、上线前的审批，全部摊在团队成员面前。Slack 不做模型、不做运行时、不做 agent 框架，只做一件事——把 AI 编程从「一个人的深夜副本」，搬回团队原本就在用的协作流里。
一、过去一年的 coding agent，多是「单人副本」
过去一年多，AI 编程的体验高度个人化：你开一个 Copilot 或 Claude Code，自己跟模型聊，改完自己合，再把结果截图丢给产品同学。问题随之而来——开发改了 40 分钟做出一版，产品说不对，开发回去继续跟 Agent 聊，设计师甚至不知道中间发生过什么。Slack 产品副总裁 Katie Steigman 的点评很到位：线程适合「一两条消息就能答」的场景，但 coding 会话时间长、参与人越来越多，塞进线程会「把线程炸掉」；传统频道又太持久，而 Agent 的编程会话通常有终点。于是 Slack 新增了一种有清晰生命周期、且当前不允许人类自建的代码频道类型。
二、频道即工作台
Slack Code 的工作方式把「聊天框」变成了「工作队列」。需求在哪儿开的，代码就在哪儿写，评审也在原地完成，不用再跨好几个工具搬上下文。一个真实的代码频道里包含：Agent 的当前计划、实际修改了哪些仓库与分支、代码 diff、PR 信息、实时 HTML 预览，以及上线前的确认环节。团队成员可以随时请求修改或叫停；任务完成后频道自动归档，但归档后仍可搜索，充当审计日志。关键设计是——目前人类用户无法自行创建这种代码频道，它只能由被 @ 的 agent 触发，把入口牢牢交给了协作流程本身。
三、Slack 的赌注：抢「派活」的入口
Slack 的算盘很清楚：一个团队往往同时用两三个 coding agent，而大家本来就在 Slack 里讨论需求。那「派活」的入口也该在这里。Slack 构建的只是一个 API，允许合作方的 agent 创建和管理这种新频道类型——模型、运行时、仓库、部署流水线，各家还是各卖各的。这一思路背后，是 Salesforce 一整年的 agent 基建：MCP server、实时搜索 API、Slackbot MCP Client 陆续就位，Slack Code 只是把管道变成了产品。它押注的核心是：AI 的价值不在单打独斗，而在嵌进团队真实的协作流里——这是和「All in Agent」的 Benioff 一贯逻辑一致的落子。
四、创始伙伴与门槛
Slack Code 即日起在所有 Slack 套餐（含免费版）上线，接入 Slack 应用市场里的各类 AI 智能体。创始合作伙伴包括 Claude Code、Devin、Vercel Agent、GitHub Copilot，ChatGPT 随后接入。一个有意思的细节是，这套集成并不基于 MCP 或 A2A 协议运行（Slack 为其他目的另提供 MCP server）——它选了自建的轻量 API 来定义这种频道类型，而非强绑定某条互操作标准。对买方而言，这意味着上手门槛极低：不用换 IDE、不用新装客户端，在原本的协作用具里就能让 Agent 进场干活。
五、透明不等于质量自动过关
把 Agent 写代码的过程摊在明处，并不等于代码质量自动达标。Slack 自己也强调，把代码推上生产这种高利害动作，必须有人在频道里签字放行。代码 diff、实时预览、审计日志全部公开，谁改了什么、谁批的，留痕可查——这解决了「黑盒协作」的问题，却拦不住烂代码本身，最终把关的仍是人。客观看，Slack Code 的价值不在于让 Agent 更聪明，而在于把「可见、可审、可回溯」补进 AI 编程的组织环节。当软件开发的门槛，从「会不会写」慢慢变成「会不会派活、会不会审」，这类「统一前台」产品，可能比又一款更强的 coding agent 更贴近企业的真实工作现场。