GitHub Copilot 进 Slack/Teams：多人 Agent 协作真的来了

# GitHub Copilot 进 Slack/Teams：多人 Agent 协作真的来了 ## 文章摘要 GitHub 在 2026 年 8 月 21 日同时推进了 Copilot 在 Slack 与 Microsoft Teams 中的多人协作能力。团队现在可以直接在频道、线程或私聊中 `@GitHub` 发起 Copilot cloud agent session，让 Agent 基于对话和已授权的 GitHub 上下文调查问题、更新 Issue、实现代码、运行验证并创建 Pull Request。更关键的是，这个 Session 不再是某个开发者私下和 Agent 的一对一对话：频道里的其他人可以继续补充上下文、改变方向、查看结果，GitHub 还允许仓库管理员对 Agent 创建的 PR 额外增加审批要求。这代表 Coding Agent 正从“个人生产力工具”变成“团队共享执行者”。 --- 过去两年 Coding Agent 的典型使用方式是： ```text 开发者 ↓ IDE / CLI ↓ Agent ↓ 代码修改 ``` 无论用 Copilot、Claude Code、Codex 还是其他工具，Agent Session 往往属于一个人。 问题在于，真实研发工作很少属于一个人。一次线上事故可能同时涉及后端、前端、SRE、产品、测试和安全。大家真正讨论问题的地方往往不是 IDE，而是 Slack、Teams、Issue、PR 和会议。 GitHub 这次更新真正改变的，就是把 Agent 移到了“团队形成共同意图”的地方。 ## 从问答机器人变成共享 Agent Session 在 Slack 或 Teams 中提到 `@GitHub` 后，不只是得到一段回答。Copilot 可以启动 cloud agent session。 例如： > @GitHub 帮我查一下昨晚 checkout-service 500 错误突然升高的原因。 Agent 可以： 1. 查看相关 Repository； 2. 读取近期代码变更； 3. 调查失败； 4. 在安全 Cloud Sandbox 中尝试修改； 5. 跑测试； 6. 创建 PR； 7. 把结果发回原线程。 这已经不是普通 Chatbot，更像频道里多了一个可以真正执行研发任务的虚拟工程师。 ## Slack 和 Teams 的共同变化 ### 会话上下文直接成为任务上下文 过去常见流程是： ```text Slack 讨论 ↓ 复制到 Agent ↓ 重新解释仓库 ↓ 重新解释约束 ``` 最容易丢失的恰恰是：为什么要改、谁提出、哪些方案已经被排除、业务限制是什么。 现在可以在原讨论里直接启动任务，Agent 可以继续利用对话与已授权 GitHub 上下文。 ### Agent 在云沙箱里异步工作 Copilot cloud agent 不要求你的笔记本一直开着，可以在安全云环境中继续读代码、修改、测试和准备 PR。 人可以继续开会、通勤或处理其他工作。 ### Session 是多人可见的 传统 Coding Agent 是： ```text 一个用户 ↓ 一个 Agent ``` 现在变成： ```text 多人 ↓ 一个共享 Agent Session ``` 参与者可以补充信息、纠正方向、停止任务或继续迭代。 这就是“Multiplayer Agent”。 ## Slack Code 为什么值得关注 GitHub 同时成为 Slack Code 的 Launch Partner。Slack Code 是面向 Agent 工作流设计的新型 Channel。 如果 Agent 在普通项目频道里连续输出计划、Diff、测试结果和 Preview，很快会把主讨论刷屏。 更合理的结构是： ```text 原始业务线程 ↓ 启动 Agent ↓ 专用 Code Channel ↓ Plan / Diff / Preview / Review ↓ 最终 PR ``` 业务讨论和代码执行分离，但仍然互相链接。 ## Teams 更适合“会议到执行” Teams 的一个典型场景是： ```text 会议 ↓ 发现 Action Item ↓ 会议还没结束 ↓ @GitHub 开始调查 ``` 过去流程常常是开完会后建 Ticket，再等某个开发者有空处理。 现在，会议结束时 Agent 可能已经有了初步调查结果。 这会压缩“决定要做”到“真正开始执行”之间的等待时间。 ## 真正变化的是协作模型 传统软件团队： ```text 人讨论 ↓ 人接任务 ↓ 人在 IDE 执行 ↓ 结果回到团队 ``` 多人 Agent 模式： ```text 人讨论 ↓ 共享 Agent 直接开始执行 ↓ 团队持续监督 ↓ 结果进入 PR ``` Agent 被嵌入了团队的沟通路径。 ## 谁可以让 Agent 真正改代码？ 权限仍然来自 GitHub，并不是频道里任何人都可以要求 Agent 修改仓库。 正确关系应该是： ```text Slack / Teams Identity ↓ Linked GitHub Identity ↓ Repository Permission ↓ Cloud Agent Permission ``` 而不是： ```text 能进群 = 能改代码 ``` 这是企业落地必须守住的边界。 ## Agent 创建的 PR 为什么值得额外审批 GitHub 已经允许 Repository Admin 要求由 Teams/Slack Copilot integration identity 创建的 PR 增加额外审批。 例如仓库本来要求两次审批： ```text 普通 PR → 2 Approvals Agent PR → 3 Approvals ``` 这个设计很合理。Agent 可以快速改很多文件，也能连续执行。它的效率越高，越需要在 Ship 前保留明确的人类责任节点。 ## 企业至少要管四层权限 第一层：谁能启动 Cloud Agent。 第二层：Agent 能访问哪些 Repository。 第三层：能否使用 Cloud Sandbox。 第四层：PR 能否 Merge。 Branch Protection、CODEOWNERS、Required Checks 和 Extra Approval 仍然是必要控制，Agent 不应该绕开传统软件交付规则。 ## 成本也开始从个人订阅变成团队预算 GitHub 当前 Public Preview 会消耗 AI Credits，Cloud Sandbox Usage 也可以设置预算。 企业不能只看： ```text Credits Used ``` 更应该看： ```text Cost per merged PR Cost per resolved bug Cost per closed incident Cost per accepted change ``` Agent 的价值最终必须落到工程结果。 ## 多人 Agent 也会带来一个新问题：谁在指挥？ 一个 Session 里可能出现： - 后端要求方案 A； - SRE 反对； - 产品要求先上线； - 安全要求停止。 所以高风险任务最好明确： ```text Session Owner ``` 其他人可以补充上下文，但最终方向由 Owner 确认。 推荐流程： ```text 业务讨论 ↓ 确认问题与 Owner ↓ 启动 Shared Agent Session ↓ Agent 生成 Plan ↓ 团队确认方向 ↓ Sandbox 执行 ↓ 测试 ↓ PR ↓ 额外人工审批 ↓ Merge ``` ## 哪些任务最适合多人 Agent？ - Bug Triage； - 小型修复； - Issue 整理； - Incident Follow-up； - 文档与代码同步； - 测试失败修复。 不适合直接交给聊天 Agent 的，则包括：大规模架构重构、生产数据库操作、高敏感安全修改和需求本身还没定义清楚的任务。 ## 最终判断 GitHub 把 Copilot cloud agent 同时带进 Slack 和 Teams，真正值得关注的不是“又多了两个入口”。 而是 Coding Agent 的工作方式开始从： ```text Single-player ``` 变成： ```text Multiplayer ``` Agent 不再只属于某个开发者的 IDE，它开始存在于团队讨论、会议、Channel、Thread 和 PR 之间。 对企业来说，以后需要管理的不只是“谁能用 Copilot”，还包括谁能启动 Agent、哪个仓库可用、Cloud Sandbox 如何收费、Agent Session 谁负责，以及 Agent PR 如何进入正式审批。 治理跟得上，多人 Agent 会明显缩短“讨论 → 执行”的时间；治理跟不上，它也会放大团队原本就模糊的责任边界。 想继续了解 GitHub Copilot、Coding Agent 和企业 AI 开发流程，可以访问 **智元选**：https://www.zyentorpicks.com/。我们会持续把新功能拆成真正可以落地的工程实践。