Copilot 进入 Slack 和 Teams：聊天窗口能开 Agent，但别把审批也丢进去

聊天工具变成入口，不等于聊天消息变成授权

Copilot Slack Teams 的新体验把“讨论问题”和“启动实现”放进同一条会话，但最重要的边界没有改变：聊天可以提供上下文，真正的代码权限仍应由仓库和服务端控制。GitHub 在Slack 公测公告中介绍，用户可通过 @GitHub 调查问题、实施和验证改动，Agent 在云端 sandbox 工作后打开 PR；Teams 公告则强调，会话可让讨论参与者共同查看和引导，有仓库写权限的人才能要求它改代码。

这类入口真正节省的不是打字时间，而是上下文搬运。过去有人在群里描述故障，另一个人再复制到 issue，开发者重新解释给 Agent。现在讨论本身可以成为起点，参与者继续补充日志、验收条件和业务约束。Agent 异步工作时，团队仍能在原对话里看方向是否跑偏。

最适合从群聊发起的三类任务

第一类是信息已经集中在一条讨论里的问题，例如某个错误的复现步骤、影响范围和相关仓库都已明确。第二类是可由 PR 完成且容易回滚的小改动，例如补日志、更新文案、增加一条边界测试。第三类是先调查再决定是否改代码的任务，Agent 可以整理相关文件与可能原因，但不必一开始就获得写权限。

不适合直接发起的，是需求仍有多种产品选择、涉及生产数据、要发送外部消息或需要跨仓库高权限的任务。群聊里的“顺便上线一下”不是审批记录。理解 Agent 为什么会把一个简单问题扩成多轮工具调用，可以先读Agent 调用与普通模型调用的差异，再决定任务边界要写到多细。

把共享上下文和共享权限拆开

Teams 公告里的协作价值在于所有人都能看见调查并补充方向，但能看到会话的人不应自动获得相同仓库权限。服务端应按发起者身份检查组织、仓库和写权限，Agent 使用的凭据也只覆盖这次任务。频道成员新增一句话，不能让已有会话突然获得另一个仓库或生产环境的访问权。

同样，聊天附件、网页预览和复制来的日志都属于不可信输入。它们可以作为证据，却不能改变系统规则。涉及删除、发布、合并或外发信息时，应在 GitHub 或独立审批面板展示具体 diff、目标仓库和动作，而不是让群里一个“可以”承担全部授权。

用 PR 作为可审查的交付边界

GitHub 的两份公告都把云端工作和后续代码协作连接起来。对团队而言，最清晰的完成定义仍是一个可检查的 PR：描述问题、列出改动、附上验证结果，并让 CI 与代码所有者继续把关。Agent 在 sandbox 里执行成功，只能说明那次环境没有报错，不能代替目标仓库的检查。

长任务还需要阶段性收口。调查完成后先输出证据和方案，确认方向再允许写代码；实现完成后冻结需求，只做验证和修复。上下文越来越长时，可用长会话上下文管理的方法压缩已确认事实，避免后来的群聊噪声覆盖最初验收条件。

上线前检查四件事

第一，谁可以从聊天启动会话；第二，Agent 实际拿到哪些仓库与工具；第三，哪个动作必须在聊天之外批准；第四，最终结果在哪里审查和回滚。四项都有明确答案，Copilot Slack Teams 才是缩短协作路径。少一项，它就可能只是把原来可见的交接成本，换成一个更难追踪的权限问题。