症状：Slack 或 Teams 里 Agent 回复了，仓库里却找不到能证明它理解了哪段讨论、改了哪个项目的证据。
最快解法：可以从低风险任务开始试点，但先核实预览资格、上下文、仓库绑定和中断恢复；聊天线程不能直接视为可放行的代码变更，涉及 Xcode 的交付还要单独验证真实 macOS 构建环境。
谁该看这篇：开发团队，正在从 Slack 或 Microsoft Teams 发起 issue、PR 或编码任务。
谁该看这篇：企业管理员，负责 Copilot cloud agent、云端沙箱及应用策略。
谁该看这篇：平台工程师，需要核验长任务、仓库切换和断线恢复风险。
⚠️ 本文依据 GitHub 于 2026 年 9 月 25 日发布的更新及当前接入文档整理；最后更新于 2026 年 9 月 27 日。预览状态、套餐口径和分批开放情况以更新公告、Slack 接入文档、Teams 接入文档及你的实际租户页面为准。
GitHub Copilot Slack Teams 更新验收：先核对预览资格，不要按套餐名称猜
这次更新补充了 Slack 附件、文件和消息链接等上下文入口；Teams 侧涉及行内图片、转发消息以及频道和线程历史。GitHub 还提到重复问题检查、产物直达链接和任务恢复方面的改进，但这不等于所有租户同时获得相同能力。
更需要先处理的是资格口径：更新公告称公开预览面向 Copilot Business 和 Copilot Enterprise 组织，而 Slack、Teams 的接入文档写的是所有付费 Copilot 计划可用。两种说法并不完全一致，不能自行推断哪一种适用于你的租户。
| 核对项 | 更新公告的口径 | 接入文档的口径 | 你该如何验收 |
|---|---|---|---|
| 预览状态 | 公开预览，部分能力分批开放 | Slack 与 Teams 页面均标为公开预览 | 登录目标租户检查功能入口，并记录当前可见能力 |
| 套餐资格 | Copilot Business、Copilot Enterprise 组织 | 写明所有付费 Copilot 计划 | 不按套餐说明直接批准上线，以实际租户状态复核 |
| 管理员策略 | Slack 要启用 cloud agent 策略；Teams 还要启用云端沙箱 | 两者都要求相应云端能力和应用接入前提 | 保存策略页面、应用安装范围和试点账号的核验记录 |
这类差异会带来实际运维成本：团队可能按文档完成安装，却在组织策略处被拦截；也可能看到入口，却因部分能力尚未推送而无法复现公告中的行为。先让管理员确认策略、GitHub 应用可访问的仓库范围及沙箱状态，再安排试点，而不是让开发者各自反复重装应用。Copilot cloud agent 的组织访问策略说明 Business 和 Enterprise 环境受组织或企业策略控制；云端 Agent 防护设置文档还建议提前规划仓库范围、Runner 和工作流审批。
初次连接：把 GitHub 身份、共享频道和仓库默认值分开验收
接入时，先确认 Slack 或 Teams 中连接的是哪个 GitHub 账号，再查看默认仓库及目标分支。默认值不是“这次任务自动选对仓库”的保证：Slack 文档说明任务会使用默认仓库，除非提示中明确指定；Teams 允许为频道设置默认仓库，而频道未配置时，首次会话使用的仓库可能成为该频道默认值。
身份也要按入口区分。私聊中，Agent 可以使用关联个人账号的权限执行操作；在共享频道或线程中，生成的产物可能归到应用身份下。只有对目标仓库有写权限的人才能触发代码变更，其他参与者仍可能影响讨论上下文。共享会话生成的 PR 如果归于应用身份，且仓库规则本来要求至少一次审批，合并前还可能需要额外审批。相关差异见Slack 权限与会话说明和Teams 权限与会话说明。
首次连接时，留存以下证据，后续才有办法定位“为什么这个 PR 开到了这里”：
- 试点账号、GitHub 组织和应用安装范围。
- 频道默认仓库、目标分支，以及任务中明确指定的仓库。
- 发起人是否有写权限；共享会话生成的产物归属何种身份。
- 管理员策略是否启用了 Copilot cloud agent 与所需云端沙箱。
首个任务：用无敏感内容的样例验证上下文是否能溯源
不要从含客户信息、密钥或未公开路线图的真实线程起步。先准备一个边界清晰的文档修改或小型缺陷任务，在提示中写清仓库、分支、预期产物和验收条件，然后检查 Agent 实际引用了哪些讨论材料。
要特别注意“支持上下文”与“只读取你刚 @ 提到的那句话”并不是一回事。接入文档称整条线程可能成为决策上下文，并可能保留在生成产物中；Slack 更新涉及受支持的附件和消息链接，Teams 更新涉及行内图片与转发消息。遇到敏感内容时，先缩小讨论范围，使用私聊或新线程，不要把整个频道历史当作无风险输入。
首个任务至少核对三处关系：原始消息或线程能否从 issue、PR 或任务页面回查；产物所在仓库是否与提示一致；Agent 对附件、图片或转发内容的处理是否符合你的预期。若答案只在口头回复中、产物没有清晰回链，就不能算完成溯源验收。
协作与恢复：更新说明不等于每次重连都能无损续跑
更新公告提到模型选择可以延续到当前对话，Slack 还增加默认负责人和仓库设置；对于长任务，GitHub 说明改进了实施计划状态、过期回复处理和闲置后的重连体验。Teams 侧则提到更可靠地保留线程历史、减少重复回答，以及改善图片和大型频道的处理。
这些是产品更新说明，不是对每个任务的成功保证。试跑时，应记录发起任务后的计划状态、模型、仓库、issue 或 PR 链接；模拟暂时断开后，先回原线程查看状态，再判断是否继续。仓库切换后，确认旧会话不会继续对旧仓库执行操作；若状态不明，不要靠重复发送同一提示来“催进度”。
另一个需要纳入长任务设计的边界是：GitHub 当前的云端 Agent 说明将单次会话最长执行时间列为 59 分钟，并说明一次任务只处理一个仓库、一个分支，最多创建一个对应 PR。这个上限不代表每次任务都会运行到上限；它意味着超过单次会话边界的大任务应拆成可独立检查的子任务，而不是把“重连”当作无限续跑机制。具体限制以云端 Agent 行为与限制说明为准。
验收评分与扩大试点条件：证据齐全再放大仓库范围
对试点结果按“通过、待核、暂停”标记即可，不必把主观满意度伪装成性能数据。每项都要能指向一条实际记录：资格和策略截图、账号与仓库配置、上下文来源、产物链接、恢复状态、用量归属。
| 评分项 | 通过 | 待核 | 暂停 |
|---|---|---|---|
| 预览与策略 | 租户入口可见，管理员策略和应用范围有记录 | 文档与租户界面仍有差异 | 无法确认资格或沙箱未获批准 |
| 身份与仓库 | 发起账号、执行身份、仓库和分支相符 | 默认仓库行为尚未验证 | 出现越权访问或产物落入错误仓库 |
| 上下文与回链 | 原讨论、issue/PR 和仓库能相互核对 | 附件、转发内容或线程范围不清 | 产物使用敏感或无关讨论且无法控制 |
| 中断与代码门禁 | 状态可检查，重复操作有人工防线，PR 保留审查 | 过期回复或重连行为未复现 | 重复创建产物、旧仓库会话仍活动或绕过门禁 |
你的扩大决策可以按下面的条件分支执行：
- 若预览入口、管理员策略、应用范围和试点账号都已核实，则只在隔离或低风险仓库继续小范围试点；否则暂缓接入，先由管理员解决资格或策略差异。
- 若提示中明确指定的仓库、分支与最终产物一致，且源讨论能回链，则允许进入常规 PR 审查；否则限制为只读研究或 issue 起草，并修正默认仓库配置。
- 若中断后能查到原任务状态，且重试前确认没有重复产物，则保留恢复流程；否则要求人工先核对 issue、分支和 PR，再决定是否重启。
- 若仓库有确定性测试、代码审查和合并门禁，则可以评估扩大范围；否则不要把“Agent 创建成功”当成代码正确或可以合并的证据。
Copilot 对话、云端沙箱任务和 GitHub 产物是不同层次：讨论上下文说明任务从何而来，GitHub 身份和仓库权限决定能对哪里操作，沙箱负责执行代码任务，PR 则仍须通过团队自己的测试和审查门禁。官方的云端 Agent 防护说明也强调 Runner、工作流审批和规则集需要纳入组织治理，不能把这些控制交给聊天界面代替。
如果交付包含 Apple 平台构建，还要把构建环境作为独立验收项：确认真实构建所需的 macOS 与 Xcode 环境、项目 scheme、目标设备或模拟器，以及签名和测试条件。Xcode 构建系统本身负责将项目代码和资源转换为应用产物，具体构建流程可对照Apple 的 Xcode 构建系统文档。这一步不是 Slack 或 Teams 集成的前置条件，而是 iOS、macOS 项目交付的另一条验证链。
常见问题
Slack 和 Microsoft Teams 里的 Copilot cloud agent 怎么接入？
先让管理员核对组织策略、云端沙箱和 GitHub 应用访问范围，再由试点成员连接 GitHub 账号。连接后指定低风险仓库，并用明确写出仓库和分支的任务验证权限、默认值与产物回链。由于公告与接入文档对套餐资格的表述不完全一致，能否使用应以租户实际入口和试跑结果为准。
整个 Slack 或 Teams 线程都会进入任务上下文吗？
接入文档说明，线程内容可能作为决策上下文，相关内容也可能出现在生成的产物中。更新公告还提到 Slack 附件和链接、Teams 图片及转发内容等上下文能力。你应在无敏感材料的样例上核对具体输入范围；要缩小上下文时，优先使用新线程或私聊，不要默认机器人只读取被点名的单条消息。
Teams 中生成的 PR 如何确认仓库没有选错？
检查任务状态显示的仓库、PR 所属仓库、目标分支和源对话链接，并与提示中明确写出的仓库名逐项比对。还要核对频道默认仓库是否由管理员或首次会话设置、触发者是否有写权限，以及共享会话中的应用身份是否符合仓库规则。任一项不一致，就先停止后续扩围，避免错误产物进入常规审查。
对话中断后怎样判断 Agent 有没有重复执行？
先回到原线程查看计划状态、任务回复和已有产物链接，再检查目标仓库是否已经出现对应 issue、分支或 PR。不要仅因回复过期或界面暂时没更新就再次提交同一任务；更新改善了部分恢复行为，但不应被当成不会重复的保证。无法确认状态时，暂停重试并由人工比对会话和 GitHub 产物。
如果你现在主要依赖聊天线程触发任务，常见短板是默认仓库容易被误用、上下文可能比单条提示更宽、断线后状态需要人工确认，而且创建 PR 本身并不等于测试通过。对普通代码任务，保留 GitHub 云端 Agent、确定性测试和人工审查通常更合适；只有确实要验证 Xcode 或 Apple 平台构建时，才需要另找真实 macOS 环境。若团队要补齐这段交付链，可继续看远程 Mac 与 Xcode 构建验收边界；临时验证确有 macOS 工具链需求时，再按MacPull 租赁方案评估，别把 Mac 当作 Slack 或 Teams 集成的必需条件。
常见问题
Slack 和 Microsoft Teams 里的 Copilot cloud agent 要怎么开通？
先确认企业租户能看到该公开预览，再由管理员核对 Copilot cloud agent 策略、云端沙箱和应用安装权限。接着连接试点 GitHub 账号，指定低风险仓库并确认写权限。公告与接入文档对套餐范围的说法有差异，因此不能只凭订阅名称判断资格，应以实际租户开关和可执行的试跑结果为准。
Copilot 会读取 Slack 或 Teams 的整条讨论吗？
官方接入说明称，任务会使用对话线程作为决策上下文，相关上下文也可能保留在生成的产物中。Slack 的更新还支持部分附件和消息链接，Teams 更新涉及行内图片及转发内容。若线程含敏感或无关讨论，不要直接触发任务；改用范围更窄的私聊或新线程，并检查产物是否回链到预期讨论。
Teams 里生成的 PR 怎么确认对应正确仓库？
不要只看机器人回复成功。检查 Teams 会话显示的仓库、PR 页面仓库归属、目标分支和源对话链接是否一致；测试任务中明确写出仓库和分支，并核对 GitHub 账号的写权限及管理员配置的应用访问范围。频道默认仓库可能影响未指定仓库的任务，首次会话也可能成为默认值，所以每个试点频道都要单独核验。
Copilot 对话断开后怎么排查重复执行？
先查看原线程中的任务状态、实施计划和产物链接，再到目标仓库检查是否已经创建 issue、分支或 PR。恢复时优先沿用原会话，不要因回复过期或暂时没有消息就重复发送同一任务；同时确认仓库切换后旧会话没有继续对旧仓库操作。记录时间、会话链接和最终产物，若无法判定状态，就暂停重试并由人工核对。