摘要： GitHub 宣布将不早于 2026 年 9 月 28 日，把 github.com 上的 Copilot Chat、GitHub Mobile 中的 Copilot Chat 和 Copilot Cloud Agent 重新整合为统一 Copilot 体验，并以一项统一策略管理。最需要管理员关注的不是界面变化，而是数据治理边界：github.com 与移动端的 Chat 将迁入 Agent Sessions 体系，聊天数据由原先保留 28 天改为随账户生命周期保留，与现有 Cloud Agent 体验对齐；统一体验上线后默认启用，若企业或团队选择退出，成员将失去 github.com 和 GitHub Mobile 中的 Copilot 访问。本文面向 Copilot Business、Copilot Enterprise 管理员、安全、法务、隐私、开发平台团队与仓库负责人，给出政策层、数据层、仓库层、MCP/网络层、审计层和用户沟通层的完整检查清单，并区分官方已确认事实、当前文档状态与实施建议。
核心结论
- 关键日期不是“9 月 28 日当天强制切换”，而是“不早于 2026 年 9 月 28 日”。 GitHub 使用的是 no earlier than September 28th, 2026，实际分批发布时间仍应以控制台和后续 Changelog 为准。
- 三种体验将由单一政策管理： github.com Copilot Chat、GitHub Mobile Copilot Chat、Copilot Cloud Agent。原先分别控制它们的政策将被统一政策替代。
- 默认行为是启用。 新体验发布后默认开启；保持现状不要求用户操作。但如果管理员选择退出统一体验，组织或团队成员会失去 github.com 和 GitHub Mobile 中的 Copilot 访问。
- 最大治理变化是数据保留。 github.com 上的 Copilot Chat 会全面迁移到 Agent Sessions，聊天数据从 28 天保留调整为随账户生命周期保留，与 Cloud Agent 现有体验对齐。
- “随账户生命周期保留”不等于管理员已经拥有任意粒度的自动删除能力。 GitHub 当前文档说明：Cloud Agent 会话可以归档但不能删除；本地来源并同步到云端的部分会话可从 GitHub.com 删除。企业必须分别测试每类会话的删除、归档、可见性和审计行为。
- 9 月 28 日前应完成书面决策。 至少要确定：是否启用统一体验、允许哪些组织和仓库、数据保留是否符合内部制度、哪些敏感仓库禁止 Agent、MCP 与网络出口如何控制、谁负责例外审批与事件响应。
核验日期：2026 年 9 月 1 日。GitHub 的发布窗口、设置名称和页面位置仍可能调整，最终以企业控制台实际显示和 GitHub 最新官方文档为准。
这次政策变化到底改了什么
结论是：GitHub 正把网页聊天、移动聊天和云端自主 Agent 从“多个入口、多个策略”重构为“统一会话平台、统一治理策略、共享数据保留逻辑”。这不仅是产品体验合并，也会改变企业对聊天记录、Agent 任务和仓库上下文的风险判断。
GitHub 官方公告确认四项变化：
- 三种体验原有的独立政策将被一项统一政策替代；
- 统一 Copilot 体验发布后默认启用；
- Cloud Agent 将使用 Sandbox，以提供更快的云端体验；
- github.com 上的 Copilot 将完全迁移到 Agent Sessions，Chat 数据从保留 28 天改为随账户生命周期保留。
GitHub 同时提醒 Copilot Business 和 Copilot Enterprise 管理员：应在 2026 年 9 月 28 日前审阅该政策，并确认它符合团队的 Copilot 管理意图。公告给出的设置路径是进入 github.com 的 Copilot Settings，选择即将出现的“Copilot cloud agent”策略，再设置政策选项。由于官方明确标注 coming soon，管理员若暂时看不到完全相同的标签，不应据此判断账号不受影响。
“统一”不代表所有 Copilot 数据都采用完全相同规则
本次公告明确点名的是 github.com、GitHub Mobile 和 Copilot Cloud Agent。IDE 内联补全、IDE 本地 Agent、Copilot CLI、Copilot Code Review、第三方 Agent App、模型供应商特定保留条款，都有各自的数据流和政策条件。企业不应把统一 Cloud Agent 政策误解为“一项开关覆盖所有 Copilot 产品数据”。
例如，GitHub 文档说明 Copilot CLI 会话默认可以同步到 GitHub 账户，用户可通过 remoteExport: false 关闭同步；但这只是 CLI 的会话同步控制，并不能关闭 github.com 统一体验所带来的云端会话保留。又如，某些模型可能出现供应商特定的数据保留提示，仍需按模型逐项审查。
9 月 28 日前必须分清的时间线
| 时间 | 官方状态 | 管理员应做什么 |
|---|---|---|
| 2026 年 8 月 28 日 | GitHub 发布政策与计费变化预告 | 建立跨部门负责人和资产清单 |
| 2026 年 9 月 1 日 | 本文核验日，统一政策尚处发布前窗口 | 截图并导出当前策略、仓库范围和内部制度基线 |
| 2026 年 9 月 28 日前 | GitHub 建议 Business/Enterprise 管理员完成审阅 | 确认启用或退出、仓库范围、保留合法性、用户通知与审批流程 |
| 不早于 2026 年 9 月 28 日 | 统一体验可能开始发布；并非保证当日所有账号同时上线 | 监控控制台、审计日志和 Changelog，执行灰度验证 |
| 2026 年 10 月 1 日起 | 公告中的部分 Business/Enterprise 计费更新开始生效 | 单独核验席位撤销、账期和额外 AI Credits；不要与数据保留决策混在一起 |
这张时间表中最重要的管理原则是：把 9 月 28 日作为内部决策截止日，而不是等待当天再寻找设置。政策可能分批上线，界面标签也可能变化，但数据保留与访问后果已经足以支持提前评估。
数据保留变化：从 28 天到“账户生命周期”意味着什么
结论是：风险从短周期临时聊天，转向长期积累的开发会话资产。聊天中可能出现源代码片段、问题描述、日志、配置、仓库名称、客户信息、漏洞细节、内部链接和用户输入。保留时间拉长后，数据最小化、访问控制、删除能力、法律保留和账户离职流程都需要重新审视。
官方已确认的保留变化
GitHub 明确写道，github.com 上的 Copilot 将全面迁移到以前由 Cloud Agent 使用的 Agent Sessions 体验，因此聊天数据不再按 28 天处理，而是随账户生命周期保留。官方公告没有在这一段给出可由企业自定义的 30 天、90 天或 365 天保留选项，也没有承诺管理员可批量删除 Cloud Agent 会话。
GitHub 当前“Managing agent sessions”文档还说明：
- Cloud Agent 会话停止后可以归档，用于从会话列表中移除；
- Cloud Agent 会话不能删除；
- 来自 Copilot CLI、VS Code、JetBrains 或 GitHub Copilot App 的本地会话可以删除；
- Cloud Agent 会话默认共享，会显示在仓库 Agents 页面的 All sessions 中，对有仓库访问权限的人可见；
- 本地会话默认不共享，但用户可选择为仓库协作者提供只读访问；
- 用户可跨同步会话进行自然语言查询，但能否查询取决于会话同步与“Store local sessions in the Cloud”策略。
“归档”只是隐藏或整理，不应等同于删除、匿名化或满足数据主体删除请求。企业隐私评估必须使用官方实际删除能力，而不能以 UI 中看不到会话作为已经清除的证据。
账户生命周期是谁的账户生命周期
GitHub 公告使用“life of the account”，但在该公告中没有进一步定义离职后、席位撤销后、组织迁移后或企业账户终止后的精细处理时间。因此，下列问题应向 GitHub 支持、客户经理或法务渠道书面确认：
- 撤销 Copilot Seat 是否触发会话删除，还是仍随 GitHub 用户账户保留；
- 用户离开组织但保留个人 GitHub 账户时，企业仓库相关会话如何处置；
- 仓库删除、转移、私有化或访问权撤销后，会话内容和索引如何变化；
- 企业能否统一导出、删除或冻结会话；
- 法律保留、诉讼保全与数据主体请求如何执行；
- 备份、灾难恢复副本和日志中的数据删除周期是什么。
这些问题目前不能凭公告自行推断，回答应记录来源、日期与工单编号。
统一策略对访问控制有什么影响
结论是：管理员今后很难只允许网页 Chat、却完全排除 Cloud Agent 的治理含义。若选择退出统一体验，官方明确的结果是成员将失去 github.com 和 GitHub Mobile 中的 Copilot；若保持启用，则必须按 Cloud Agent 的执行权限、仓库写入、网络访问和会话可见性进行管理。
GitHub 文档显示，Copilot Business 和 Enterprise 的 Cloud Agent 通常需要管理员启用。策略可能由企业层或组织层控制；企业级明确设置会限制组织能否覆盖。启用后，具备 Cloud Agent 访问权且对仓库有写权限的用户可以委派任务；仓库所有者仍可对部分或全部仓库禁用 Cloud Agent。
管理员至少要画出以下控制层级：
| 控制层 | 关键问题 | 推荐证据 |
|---|---|---|
| 企业 | 统一策略是全开、全关还是选定组织 | 企业 AI Controls 截图、变更单、审批记录 |
| 组织 | 哪些成员获得 Copilot Seat，Cloud Agent 与 Automations 是否允许 | Copilot Policies 导出、成员清单 |
| 仓库 | 哪些仓库允许 Agent，是否排除生产、合规和高敏仓库 | Repository access 清单、仓库自定义属性 |
| 身份权限 | 谁有写权限，外部协作者和机器人账号是否可触发 | GitHub Team、Role、Outside Collaborator 审计 |
| Agent | 默认工具、指令、模型、MCP Server 与自动化有哪些 | .github 配置、Agent Profile、MCP 清单 |
| 网络 | Sandbox 能访问哪些域名、包源和内部系统 | Firewall Allowlist、代理日志 |
| 会话 | 谁能看、能否分享、归档与删除如何执行 | Agent Sessions 实测记录 |
Cloud Agent 与 IDE Agent 不是同一个执行面
GitHub 官方将 Cloud Agent 定义为在 GitHub Actions 支持的云端环境中自主完成任务，可以研究仓库、创建计划、修改分支并选择性打开 Pull Request。它与 IDE 中直接修改本地工作区的 Agent Mode 不同。统一政策针对云端体验，不能替代对本地插件、终端权限和开发者设备的控制。
Sandbox、MCP 与网络出口为什么必须一起检查
结论是：数据保留只是“任务完成后留下什么”，Sandbox 与 MCP 决定“任务执行时能接触什么”。如果 Agent 能访问外部主机、内部 API、包仓库或第三方 MCP Server，长期会话中可能同时保留工具参数、错误信息和返回摘要，风险会相互叠加。
GitHub 公告只确认 Cloud Agent 将使用 Sandbox，并称其用于更快的云端体验。公告没有说明所有客户的 Sandbox 网络策略会完全相同，也没有宣称 Sandbox 自动满足企业的数据隔离制度。GitHub 文档允许组织管理 Cloud Agent Firewall，包括启用状态以及允许访问的外部主机和 URL；第三方 MCP Server 也需要单独的企业或组织政策。
建议按最小权限执行：
- 默认拒绝未批准的外部域名，只开放构建与测试确需的主机；
- 生产数据库、客户数据 API、密钥系统和内部管理后台不得直接暴露给通用 Agent；
- MCP Server 建立所有者、用途、数据分类、工具列表、OAuth Scope 和退出机制；
- 对工具参数和返回值进行秘密扫描与敏感字段脱敏；
- 高风险写操作要求人工审批，并保留 Pull Request 与审查门禁；
- 定期检查 Agent Profile、仓库级 MCP 配置与组织级配置合并后的实际权限。
9 月 28 日前完整检查清单
以下清单属于实施建议，不是 GitHub 官方强制模板。企业可复制到 Jira、GitHub Issues、Excel 或 GRC 系统中执行。
A. 政策与负责人
- 指定一名 Enterprise Owner 或 AI 管理员作为最终责任人。
- 邀请安全、隐私、法务、开发平台、采购、HR 离职管理和业务代表共同评审。
- 记录当前 github.com Chat、Mobile Chat、Cloud Agent、CLI、Code Review 和第三方 Agent 的启用状态。
- 明确统一体验选择：启用、选定组织启用，或退出。
- 记录退出后网页端和移动端 Copilot 不可用的业务影响。
- 为例外仓库建立申请、期限、审批人和复审日期。
- 设置 9 月 28 日前的内部决策日期，预留至少五个工作日处理变更。
B. 数据地图与保留制度
- 绘制 Prompt、仓库上下文、工具调用、模型响应、文件变更、PR 和会话索引的数据流。
- 把 github.com/Mobile Chat 从“28 天”更新为“随账户生命周期保留”。
- 区分 Cloud Agent 会话归档与删除，不把归档写成数据清除。
- 确认 Cloud Agent 会话默认共享对仓库协作者是否可接受。
- 评估个人数据、客户数据、商业秘密、漏洞信息和受监管代码是否可能进入会话。
- 更新数据处理记录、隐私影响评估、供应商风险评估和员工 AI 使用政策。
- 向 GitHub 书面确认未明确的离职、撤席、仓库迁移和账户终止处理方式。
- 设计数据主体请求、法律保留和安全事件中的会话检索流程。
C. 身份、组织与仓库范围
- 盘点所有 Copilot Business/Enterprise Seat，移除不再需要的账号。
- 复核 Enterprise、Organization 和 Repository 三层策略的优先级。
- 检查外部协作者、临时员工、服务账号和 Bot 是否拥有写权限。
- 用自定义仓库属性标记 Public、Internal、Confidential、Restricted 等敏感等级。
- 默认排除生产配置、密钥管理、支付、医疗、政府和客户专属仓库。
- 验证用户失去仓库权限后是否仍能看到历史共享会话。
- 对选定仓库执行一次真实权限测试，而不是只检查设置页面。
D. Agent、Automation、MCP 与网络
- 导出当前 Cloud Agent、Automations、Partner Agents 和 Agent Profiles 清单。
- 检查 Cloud Agent 是否能自动创建分支和 Draft PR，分支保护是否继续生效。
- 分别审批第三方 MCP Server 与 GitHub 默认工具，不使用笼统“允许 MCP”。
- 验证 Firewall 允许域名，删除临时测试域名和通配符。
- 禁止 Prompt、日志、Issue 或配置文件携带真实 Token、密码和私钥。
- 给生产写操作、部署、依赖发布和权限修改设置人工审批。
- 检查 Automations 的触发条件、执行身份、频率、预算和停止开关。
- 对提示词注入、恶意 Issue、恶意依赖和工具返回污染执行红队测试。
E. 会话、审计与监控
- 建立网页 Chat、Mobile Chat、Cloud Agent、CLI 同步会话各一条测试记录。
- 验证谁能发现、查看、分享、归档和删除每类会话。
- 测试
remoteExport: false对 CLI 的影响，并明确它不控制网页统一体验。 - 记录政策变更对应的企业 Audit Log 事件。
- 将重要审计日志流式传输到 SIEM；GitHub 文档称企业 Audit Log 默认保留最近 180 天。
- 为异常 Agent 启动、敏感仓库访问、MCP 变更和外联域名建立告警。
- 只记录必要元数据，日志中的 Prompt 与工具参数先脱敏。
- 建立月度复审：Seat、仓库范围、例外、会话共享、MCP 和 Firewall。
F. 用户通知与培训
- 通知用户网页与移动 Chat 的保留期将发生变化。
- 明确禁止提交密码、Token、客户个人数据、未公开漏洞和生产数据。
- 解释 Cloud Agent 会话默认共享及仓库协作者的可见范围。
- 提供“何时使用本地 Agent、何时使用 Cloud Agent”的决策表。
- 告知用户退出统一体验可能导致网页端与移动端不可用。
- 建立误传敏感信息后的报告、撤权、密钥轮换和事件响应入口。
可直接使用的治理记录模板
建议不要只保存一次截图，而是建立可追踪的结构化记录。下面的 YAML 是企业内部模板，不是 GitHub 的真实配置文件：
copilot_unified_experience_review:
verified_at: "2026-09-01"
decision_deadline: "2026-09-23"
github_launch_window: "not-earlier-than-2026-09-28"
decision: "selected-organizations"
owners:
business: "VP Engineering"
technical: "Developer Platform"
privacy: "DPO"
security: "AppSec"
data_retention:
web_mobile_chat: "account-lifetime"
cloud_agent_session_delete: "not-supported-in-current-docs"
archive_is_deletion: false
controls:
restricted_repositories: true
mcp_allowlist: true
network_allowlist: true
human_approval_for_high_risk_writes: true
audit_streaming: true
open_questions:
- "seat revocation and session retention"
- "offboarding and account-lifetime definition"
- "bulk deletion and legal hold"每次变更至少记录：变更人、审批人、时间、旧值、新值、影响组织、影响仓库、回滚办法、官方来源和下一次复审日期。若 UI 设置尚未出现，可先记录预期决策，不要伪造已经执行的状态。
三种决策方案怎么选
| 方案 | 适用团队 | 优点 | 主要代价 |
|---|---|---|---|
| 保持默认启用 | 已接受长期会话保留、Cloud Agent 治理成熟的团队 | 保留网页、移动与云端 Agent 的完整统一体验 | 需接受更长数据保留并强化会话、仓库、MCP 与网络控制 |
| 仅选定组织或仓库 | 大型企业、混合敏感度环境 | 可在低风险研发团队先验证 | 策略层级和例外管理更复杂，需要持续防止范围漂移 |
| 退出统一体验 | 严格短期保留、暂时无法接受 Cloud Agent 风险的团队 | 在完成法律与安全评估前控制新增风险 | 发布后失去 github.com 和 GitHub Mobile 中的 Copilot，影响移动和网页协作 |
编辑建议是：不要把“退出”理解为永久拒绝，也不要把“默认启用”当作被动接受。对多数企业，更现实的路径是先允许经过评估的非敏感组织与仓库，保留 Restricted 类仓库禁用，待数据删除、离职和审计流程验证后再扩大范围。
上线后的验证与回滚演练
统一政策上线后，应由测试组织先做灰度，不要直接依赖全企业默认值。验证步骤如下：
- 使用不含真实秘密的测试仓库启动 github.com Chat，并把会话交给 Cloud Agent；
- 在 GitHub Mobile 检查同一会话的历史、权限和共享状态；
- 让 Agent 创建分支和 Draft PR，验证 Ruleset、必需审查和 CI 门禁；
- 测试允许与拒绝的外部域名，确认 Firewall 不是“配置存在但未生效”；
- 尝试使用未批准 MCP Server，确认策略能阻止；
- 归档 Cloud Agent 会话，记录归档后的可发现性，并验证它没有被当作删除；
- 撤销测试用户的仓库权限和 Copilot Seat，观察会话可见性并向支持确认预期；
- 在 Audit Log 和 SIEM 中核对策略变更、Agent 活动和异常告警；
- 模拟误传测试 Token，执行撤权、轮换、调查和通知流程；
- 若关键控制失败，暂停扩大范围，恢复原政策或禁用相关组织/仓库。
GitHub 公告没有保证所有账号可在同一时间看到新体验，因此测试记录应包含账号、组织、仓库、页面版本、时间与地区。不要把一个测试组织的行为直接推广为全企业事实。
与 9 月 28 日同时出现的 Code Review 变化
GitHub 同一份公告还说明：从 2026 年 9 月 28 日起，Copilot Code Review 的 Default 努力级别将从 Lite 变为 Balanced。组织默认值适用于没有自行设置的仓库；仓库默认值用于自动请求的 Review。若希望继续使用 Lite，应在日期前明确选择 Lite，而不是保留 Default。
这不是数据保留政策的一部分，但会同时影响成本、时延和审查深度。管理员应把它放入同一变更窗口，却用独立审批项跟踪，避免只完成统一 Agent 政策审阅而漏掉 Code Review 默认值。
此外，Business 与 Enterprise 的部分计费更新从 2026 年 10 月 1 日起生效，包括撤销席位不按比例退款、月中新增席位继续按剩余账期比例计费等。GitHub 表示 Copilot Business 和 Enterprise 标价不变。具体账单应以合同、控制台和官方 Quick Start 为准。
常见误区与风险提示
误区一：9 月 28 日后聊天会自动删除
事实正相反。公告称网页 Copilot Chat 将从 28 天保留改为随账户生命周期保留。
误区二：归档等于删除
GitHub 当前文档明确区分归档与删除，并称 Cloud Agent 会话可以归档但不能删除。
误区三：关闭 CLI 同步就解决所有云端保留问题
remoteExport: false 只影响 Copilot CLI 会话同步，不能替代统一网页/移动/Cloud Agent 政策。
误区四：Sandbox 自动等于零信任
Sandbox 是执行隔离的一部分，仍需检查网络出口、MCP、仓库 Token、工具权限和人工审批。
误区五：统一策略只影响管理员
它会改变每个用户在 github.com 和移动端的使用资格、会话保存方式以及历史会话的可用性，应提前通知开发者。
FAQ
1. GitHub Copilot 新政策会在 2026 年 9 月 28 日准时生效吗？
GitHub 的准确说法是“不早于 2026 年 9 月 28 日”重新发布统一体验，因此这是最早启动窗口，不是所有账户同日切换的保证。
2. 哪些产品会被统一政策直接管理？
官方明确列出 github.com Copilot Chat、GitHub Mobile Copilot Chat 和 Copilot Cloud Agent。IDE、CLI、Code Review 与模型供应商特定政策仍要分别检查。
3. 不操作会发生什么？
统一体验上线后默认启用。Business 和 Enterprise 管理员应在 9 月 28 日前确认默认值是否符合组织意图。
4. 如果管理员选择退出会怎样？
GitHub 表示，退出统一体验后，用户或团队将在新体验发布后失去 github.com 与 GitHub Mobile 中的 Copilot 访问。
5. 聊天数据将保留多久？
github.com Chat 将从 28 天保留改为随账户生命周期保留。公告未提供企业自定义保留天数，具体账户终止和离职边界建议书面询问 GitHub。
6. 管理员能删除 Cloud Agent 会话吗？
依据当前 GitHub 文档，Cloud Agent 会话可以归档但不能删除。应把这一限制纳入隐私与合规评估。
7. Cloud Agent 会话默认谁能看？
GitHub 文档称 Cloud Agent 会话默认共享，会出现在仓库 Agents 页面的 All sessions 中，对拥有仓库访问权限的人可见。
8. 关闭统一体验会同时关闭 IDE Copilot 吗？
本次公告明确的退出后果是 github.com 和 GitHub Mobile Copilot 访问。对 IDE、CLI 和其他入口的实际影响，应依据各自策略与控制台进行测试，不能自行扩大解释。
9. 9 月 28 日前最优先做哪三件事？
第一，确认是否接受账户生命周期保留；第二，决定允许的组织和仓库范围；第三，验证会话可见性、Cloud Agent 权限、MCP 与网络出口。
事实依据与来源
- GitHub Changelog：Upcoming changes to GitHub Copilot policies and billing：确认最早发布日期、三种体验统一、默认启用、退出后果、数据保留与 Code Review 默认值变化。
- GitHub Docs：Managing access to GitHub Copilot cloud agent：确认 Business/Enterprise 策略、仓库范围和 Automations 前置条件。
- GitHub Docs：Managing agent sessions：确认 Cloud Agent 会话归档、删除限制、默认共享和历史会话查询。
- GitHub Docs：About GitHub Copilot CLI session data：确认本地会话存储、默认同步、
remoteExport与删除边界。 - GitHub Docs：GitHub Copilot policies for enterprises and organizations：确认企业、组织政策适用范围与层级逻辑。
- GitHub Docs：Adding GitHub Copilot cloud agent to your organization：确认组织启用、仓库控制、Automations 与 Firewall 管理路径。
- GitHub Docs：Reviewing audit logs for GitHub Copilot：确认 Audit Log 最近 180 天保留及向 SIEM 流式传输建议。
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
