GitHub Copilot 支持在 Slack 和 Teams 中跨多个仓库协作

GitHub 于 10 月 15 日发布更新，让 Copilot 在 Slack 和 Microsoft Teams 中可以在同一段对话里跨多个仓库回答问题。GitHub 给出的例子包括列出待处理的开放拉取请求、汇总多个仓库已合并的工作，以及排查横跨前端和后端代码库的议题。

这一变化取消了对话层面的仓库边界，用户不必再为每个仓库单独开启线程。GitHub 同时表示，@GitHub 可以出现在消息任意位置，仓库切换更顺畅，Slack 对话上下文利用更好，任务恢复也更可靠。跨仓库支持不会带来新的仓库访问权限，可见范围仍由关联身份和企业管理员的配置决定。

跨仓库对话能力

此次更新让 Copilot 在同一段 Slack 或 Teams 对话中，可以同时检索多个仓库的拉取请求、议题和活动。

对维护者而言，实际收益在于综合：围绕一组相关仓库提出一个问题，就能得到合并后的回答。此前每个仓库需要单独开启线程，如今对话层面的仓库边界被取消，问题本身跨越项目组合或服务边界时不必再拆分提问。

权限与身份边界

GitHub 的 Slack 集成文档说明，私信操作使用关联的个人 GitHub 账号，而共享上下文产生的工件可以归应用身份所有。用户需要写权限才能启动云端代理工作，企业管理员决定 Slack 应用可以访问哪些仓库。

Teams 文档描述了同样的核心边界：GitHub 连接、Copilot 方案和云沙箱策略必须就位，且只有具备写权限的用户才能触发代理变更。因此管理员应分别测试检索与操作：用户可能可以汇总某个议题，却不被允许创建拉取请求；应用安装覆盖的仓库范围也可能小于个人账号的权限范围。验收证据中应记录实际执行身份、所选仓库以及生成工件的归属者。

共享上下文的隐患

本次发布强调更好地利用共享的 Slack 消息和线程作为上下文。GitHub 的 Slack 与 Teams 指南指出，整段对话都可能影响代理的工作，并且这些上下文会存储在代理生成的工件中。当同一段对话还横跨多个仓库时，这一点的后果更为明显。

线程中可能包含客户信息、事件记录或计划，这些内容对某个项目合适，却不该被复制到另一个仓库的议题或拉取请求中。仓库访问控制并不会自动对协作频道里的每条消息做分类。建议为边界明确的任务使用新线程，明确列出仓库名称，并在调用应用前移除无关的敏感讨论；需要更窄的上下文时，GitHub 建议使用私信。团队在分享或合并生成的工件前，也应检查其中是否复制了对话内容。

如何验证回答完整性

一个实用的验收测试，从两三个仓库中已知的一组拉取请求或议题开始。要求给出限定时间范围的汇总，再把引用的条目与 GitHub 原生的仓库视图比对。需要验证私有仓库和已归档仓库的表现是否符合预期，以及被拒绝访问的仓库不会悄悄表现为没有匹配的工作。

排查议题时，应要求为每个结论提供指向具体议题、拉取请求、提交或工作流运行的链接。对于“没有活动”这类说法，应把它视为需要给出分母的声明：搜索了哪些仓库、分支和日期？如果回答无法说明范围，应缩小提示词，而不是把它当作运营报告使用。发布中的可靠性改进可能减少启动和中断错误，但并不能证明语义上的完整性，因此应分别衡量任务成功启动、引用对象准确、遗漏仓库和人工纠正的比例。

风险最低的用法是跨仓库检索：开放拉取请求、近期合并、关联议题和项目活动。可以先从同一归属者和同一数据分类的仓库开始，确认 Copilot 遵守预期访问范围并给出可追溯的链接；只有这些证据稳定后，团队才应测试创建议题或云端代理工作。同时应保留常规规则集和代码所有者审查，并区分汇总回答与改变工件的操作。在共享的 Slack 或 Teams 上下文中，启动前要确认结果将归个人身份还是应用身份所有。

要点

• GitHub 于 10 月 15 日发布该更新
• Copilot 可在同一对话中检索多个仓库的活动
• 跨仓库支持不新增仓库访问权限
• 直接消息操作使用关联的个人 GitHub 账户
• 企业管理员决定 Slack 应用可访问的仓库