GitHub 在 Universe 2026 上正式提供 Copilot Fusion，并公测 Copilot…

GitHub在2026年10月28日至29日举办的“GitHub Universe 2026”上宣布，整合自动模型选择与多模型协作的Copilot Fusion正式提供。面向桌面的GitHub Copilot应用则开始Projects的公开预览，用于汇总资料与智能体的工作。除自动化、代码审查、安全对策相关功能的追加与正式提供外，还公布了GitHub Enterprise的合约方式以及Git与Actions基础设施方面的变更。

GitHub Universe 2026: Evolving every layer of the stack - The GitHub Blog

此次发布不仅包含新功能的公开预览，还包括既有预览的正式提供以及所支持工具与运行环境的扩展。下文将按从委派工作的入口，到模型选择、知识传承、自动化、成果确认的顺序，介绍主要变更。

GitHub Universe 2026，第一天的开幕主题演讲

连接从计划到发布的开发构想

GitHub在Universe 2026上展示了连接从计划到实现、验证、发布的“software delivery system”构想。其重视的成果是完成功能追加、缺陷修复、安全修复等变更并交付给用户。开发者确定方向、做出判断，并对成果负责。智能体则负责实现并验证变更。

各工序未必按固定顺序推进。代码变更、同事的请求、生产环境的指标等，都会在不同工序中成为开始工作的契机，开发者与智能体会根据课题在工序之间来回切换。由此获得的信息将用于持续学习，并推动下一次工作的改进。

GitHub列举了该构想所重视的三点：

速度（Velocity）：减少将想法变为成品软件所需的时间与成本，提高效率。

知识活用（Intelligence）：结合平台上与开发相关的信息，从过去的工作中持续学习，改进下一次工作。

质量（Quality）：从一开始就确保安全性，在发布前发现缺陷。

此外，GitHub还开放了支撑产品的技术，使开发者能够构建自己的机制。例如，已提供的Copilot SDK可将通用的智能体运行基础嵌入自己的应用。据称，将哪些工作交给智能体、使用哪些工具、花费多少成本，均由开发者决定。

用Copilot开始工作，连接工具与成果物

用Projects汇总资料与智能体的工作

GitHub Copilot应用内的Projects是一项将相关资料、仓库、智能体的工作与成果物集中到一处的功能。只要告知想要达成的目标，Copilot就会协调所需的工作。该功能已作为公开预览开始提供。

Copilot Projects 📋

Bring sessions, pull requests, and repositories together around one goal. Copilot Projects gives you one place to see where the work stands and direct what Copilot takes on next.https://t.co/4DDsl7Euf1 pic.twitter.com/fwCwfAbYHE— GitHub (@github) October 28, 2026

会话是让智能体承担单项工作的单位。在Projects中，可根据目标运行所需的会话，并与相关资料、成果物及定期作业一同管理。例如，可以处理调查客户意见、探讨改进方案并推进到实现的一系列工作。对于特定缺陷修复等对象与工作已确定的情况，也可以不创建Projects，直接从仓库或文件夹开始会话。

Projects可从侧边栏“Projects”旁的“＋”创建。也可以不使用开始画面的选项，直接在底部输入栏中写下目标或最初的请求来开始。还可以通过输入栏的“＋”传入本地文件夹。文件夹或仓库的指定并非必需，使用GitHub上的仓库时，可通过所有者名或仓库名搜索并添加。

图1 在GitHub Copilot应用中打开新项目的画面。按下侧边栏“Projects”旁的“＋”后会添加“New project”，中央显示开始画面。“Start with one or more repositories”是添加GitHub上的仓库的入口，“Work on parallel tasks”是并行执行与Issue或PR相关工作的入口，“Triage recent issues”是确认、整理近期Issue的入口，“Automate routine work”是定期执行重复工作的入口，“Research and work with docs and messages”是利用文件、聊天、会议信息进行调查的入口。右侧的“Overview”可确认进展情况。当要求其掌握本地文件夹的内容后，“New project”这一临时名称自动变成了与内容相符的项目名。

在创建的项目中给出目标和必要资料后，Copilot会根据需要并行运行多个智能体并协调工作。也能处理跨多个仓库的更改。用户无需持续向各个会话发出指示，即可确认项目整体的进展，并参与必要的判断和评审。

Library是用于在项目内保存、确认用户添加的资料以及智能体生成的成果物的场所。如果看不到Library标签页，可按下右侧面板上部的“＋”，在菜单的“Open tabs”中选择“Library”即可打开。

从聊天输入栏的“＋”传入本地文件夹后，Library中也显示为“Attached in chat”。打开该文件夹后，可以确认其中的稿件、参考资料和图片列表。

在使用资料的工作中，例如可以传入功能规格书和客户反馈，要求其对困扰事项进行分类并列出接下来要调查的项目。保存的资料和成果物在继续同一项目的工作时也可使用。还可以从项目的对话中设置资料每周摘要等定期作业。

进展情况在Overview中确认。将需要用户判断或评审的工作、已打开的拉取请求（PR⁠）⁠、正在执行的工作、已完成的工作分开显示，也可向各个会话发送追加指示。

关于项目的创建和资料的添加，可在Projects的官方文档中确认。

更换设备或工具后⁠，仍可继续同一云端会话

继续工作的场所也在扩大。GitHub从28日起，面向付费Copilot计划陆续开始正式提供可跨设备、跨工具使用同一云端会话的功能。可从github.com、GitHub Mobile、GitHub Copilot应用、CLI、VS Code等访问，在智能手机上委托的工作可在PC上确认并发出追加指示。在此期间，智能体也会在云端继续工作。

该云端会话默认在GitHub管理的云沙箱中运行。沙箱停止时会将工作状态保存为快照，之后可恢复会话。不过，使用Actions的自托管运行器或copilot-setup-steps.yml时，需要选择Actions而非云沙箱作为会话的执行环境。

除了有料Copilot计划的费用之外，云沙箱的计算资源也将从2026年11月起按使用量计费。即使不运行Actions工作流，只要使用云沙箱，使用量也会被计入。不过，由于可以动用与Actions共用的附带使用额度，在额度范围内不会产生计算资源的额外费用[1]。超出部分将按照费用、预算和支付设置进行处理。

在VS Code中⁠，汇总确认多个智能体的作业与成果

VS Code正在增加让智能体承担作业、并确认其进展与成果的功能。28日公开的“VS Code Wrapped”配合此次发布，回顾了自上次Universe以来一年的更新。

执行环境除了云端之外，还可以选择自己的PC或连接目标机器。新的Agent Host将会话从各个窗口中分离出来，因此即使关闭窗口也能继续作业。不过，在本地或远程机器上运行时，该机器和Agent Host必须处于运行状态。

Harness是推进智能体处理、让模型能够使用工具和作业所需信息的执行基础。在VS Code中，基于Microsoft Copilot SDK的Copilot Harness已成为在编辑器和Agents窗口中启动的新会话的默认选项。它与CLI和GitHub Copilot应用使用共同的基础，减少产品之间智能体行为的差异。通过Agent Host还可以使用Claude和Codex的Harness，从而在VS Code中处理使用各自执行基础和功能的会话。

在Agents窗口中，可以并行运行多个会话，并集中确认进展情况和变更内容。当需要编辑或调试代码时，可以在保持同一Copilot会话的情况下转移到编辑器，然后再返回Agents窗口。此外，还以预览形式提供“Compare Models”，可将同一课题交给多个模型或Harness，并并列比较结果。

确认和修正作业结果的方法也在扩展。“⁠VS Code Wrapped”介绍了迄今新增的功能，包括用户与智能体可以查看同一页面并进行操作的集成浏览器，以及可直接编辑所显示的计划书和文档、并留下面向智能体评论的Markdown编辑器。

Canvases是一项预览功能，可在聊天旁边打开可操作的画面，让用户与智能体确认和更新相同的信息。例如，用户可以在看板形式的板上移动卡片，智能体则拆解作业并添加卡片。该功能以使用Copilot Harness的本地会话为对象，适用于VS Code桌面版。启用“⁠chat.canvases.enabled”并开始新会话，通过“⁠/create-canvas”请求所需的画面后，智能体会创建用于画布的扩展功能并打开该画面。

在面向IDE的更新方面，JetBrains也宣布正式提供本地沙箱和显示下一个编辑候选的Next edit suggestions等。

将作业范围扩展到外部服务⁠、图像⁠和桌面应用

用于从Copilot使用外部服务的资料和工具的连接器，也将面向所有Copilot计划依次以公共预览形式提供。GitHub将其验证过的MCP服务器称为“连接器”。MCP是AI利用外部工具和信息源的连接方式。使用连接器时，用户无需寻找对应的服务器并单独设置，只需选择服务并登录即可连接。

最初支持 Slack、Figma、Sentry、Linear 等 26 项服务。一旦连接，即可在 GitHub Copilot 应用、CLI、VS Code、云端和 GitHub Mobile 中共享使用，无需在各处重新设置连接。在 Business 和 Enterprise 中，需要管理员允许预览功能。[2]

在图像生成与编辑方面，当在对话中提出请求时，所选中的对话用模型会调用使用“GPT Image 2.5 Flare”的专用图像生成工具。生成的图像预览会显示在对话中，并将图像保存到工作文件夹。该功能可在 VS Code、GitHub Copilot 应用和 CLI 中使用，发布会上将其介绍为面向 Pro、Pro+、Business 和 Enterprise 的公共预览。图像生成与编辑的费用与对话用模型的费用分开计算，并根据图像 token 数消耗套餐的 AI 额度。

GitHub Copilot 应用和 CLI 的 Computer Use 自 10 月 1 日起在 macOS 和 Windows 上提供公共预览。通过读取应用内容并进行点击和文字输入，也可以将没有 API 或 MCP 的桌面应用纳入操作对象。开始操作前会请求用户批准，组织可以通过管理设置将其禁用。在 28 日面向 VS Code 的发布中，还介绍了在 Agent Host 上的 Copilot 会话中使用的 Computer Use 作为实验性功能。

通过 Issue artifacts⁠，将计划书和调查结果保留在 Issue 中

能够将计划书和调查结果等作为单独成果物添加到 Issue 中的 Issue artifacts 也已进入公共预览。该功能除了在 Issue 正文或评论中撰写说明外，还能独立更新和引用相关文档。例如，附加实现计划并根据讨论更新内容后，即可将团队和后续智能体参照的计划及变更历史保留在 Issue 中。

可作为成果物添加的内容包括：保存此类计划书和调查报告的 Markdown 文档、指向外部服务的链接以及 HTML 文档。指向外部服务的链接，是将 Slack 或 Teams 中的讨论、已公开的原型等 URL 本身登记为一个成果物。HTML 文档可处理图表、流程图、可交互的可视化等内容，并可在 github.com 上切换显示结果与 HTML 源码进行确认。

成果物可在 github.com 上创建、编辑和删除，并可通过每个成果物的链接进行共享。GitHub CLI 中也新增了 gh issue artifact 命令，使智能体和开发工具能够管理成果物。

通过 Replica⁠，制作可试用产品界面和操作的原型

GitHub 以 MIT 许可证公开了由 GitHub Design 开发的 Replica。这是一套用于制作和共享可试用产品界面和操作的原型的工具集，包含面向 GitHub Copilot 应用的插件、应用模板以及用于共享的服务器等。设计师、产品经理和工程师可用它将方案做成可实际运行的形式并进行探讨。

Replica 的 README 对主要构成要素说明如下。

Starters：作为原型起点的应用模板。也包含 Copilot 用的通用技能。提供可按照自身设计改造的小型模板，以及配备 Microsoft CoreAI UI 组件的模板。

Replica plugin：向 GitHub Copilot 应用添加 Replica 用画布，并在对话旁显示正在运行的原型的插件。

Replica Hub：用于公开制作好的原型，让团队成员进行操作并留下评论的共享服务器。可根据需要自行部署和运维。

GitHub build action：用于构建要发布到 Hub 的原型的 GitHub Actions 操作。本地制作时不需要。

提供的模板是使用 JavaScript UI 库 React 和 TypeScript 构建的 Web 应用，并包含用于美化外观的 CSS[3]。

模板并非必须使用，文档也介绍了从现有 Web 应用开始的方法。这种情况下，需保留现有应用的文件、结构和启动方式，并添加用于连接 Replica 画布的设置以确认显示效果。

模板或现有 Web 应用启动后，准备团队的 UI 组件、设计模式和文档。在 GitHub Copilot 应用中用自然语言描述想要制作的界面或行为，Copilot 便会以此为依据编辑代码和样式，制作原型。可以在画布上边试运行边修改，无需引入 Hub，仅凭本地环境即可开始。

选择模型⁠，组合使用的 Copilot Fusion 正式提供

Copilot Fusion 是一套按课题决定所用 AI 模型及其组合方式的机制。现已开始正式提供，可在 VS Code、GitHub Copilot 应用、CLI、JetBrains IDE 中使用。

Route and orchestrate models with GitHub Copilot Fusion - GitHub Changelog

其前身 Project HydraFusion 于 9 月 4 日启动研究预览，并于 10 月 14 日追加了 Max。此次将此前的自动模型选择与 HydraFusion 的多模型协作整合到 Fusion 中。若此前选择的是 Auto、HydraFusion、HydraFusion Max，将自动切换至对应的 Fusion 处理级别。

Copilot Fusion 🧬

Choose High or Max effort, and Copilot Fusion can coordinate multiple models and workflows when one model alone isn’t enough. In the @ArtificialAnlys Coding Agent Index, Copilot Fusion Max scored within two points of Claude Code with Opus 5.5 Max at about half… pic.twitter.com/QGsBwCkdw1— GitHub (@github) October 28, 2026

用户选择 Standard⁠、High⁠、Max 处理级别

处理级别是用于指定质量、等待时间和费用平衡的设置。据 Fusion 文档说明，Standard 面向日常工作，使用单一模型。High 面向复杂但范围确定的修改，Max 面向需要深度推理和细致分析的工作，并根据需要组合多个模型。

在 GitHub Copilot 应用中，点击输入框下方显示的模型名称即可打开模型选择菜单。开启“⁠Copilot Fusion”后，可选择 Standard、High、Max 处理级别；关闭后，可选择单独的模型[4]。在应用中选择的模型设置，也会成为之后创建会话的默认设置。

在 VS Code 中，可从 Copilot 聊天输入框的模型选择菜单中选择 Fusion。[4]

图2 VS Code 的模型选择菜单（左）与选择 Fusion 处理级别的界面（右）。选择“Copilot Fusion”，并在“Effort Level”中切换 Standard、High、Max。图中选择了 Standard。左侧排列的单独模型名称为手动选择用列表，并非 Fusion 的候选列表。

所用模型与执行方式由 Fusion 自动决定

Fusion 根据用户选择的处理级别和提示内容决定所用模型，并从以下 3 种执行方式中自动选择。执行方式并非由用户在菜单中直接指定，同一会话中也可能因请求不同而变化[6]。

Single：由单一模型处理。

Cascade：由注重效率的模型先给出回答，再根据评估结果将处理移交给性能更高的模型。

Critique：由多个不同模型并行审视最初的回答，汇总意见后由原模型进行修正。

候选模型并非固定不变，会根据新模型的出现和 GitHub 的评估进行更新[5]。

Fusion Max 在 Terminal-Bench 4.0 中取得高分

据 GitHub 称，在 Artificial Analysis Coding Agent Index 中，Fusion Max 的得分为 60，与使用 Opus 5.5 Max 的 Claude Code 结果相差在 2 分以内。该评估中每项任务的平均 API 费用约为其一半，所需时间约缩短 40%。

据实施评估的 Artificial Analysis 于 28 日发布的文章，使用 GitHub Copilot CLI 的 Fusion Max 设置，对 3 个基准进行等权加权计算综合得分。其中 Terminal-Bench 4.0 为 71%，在该文章列出的比较对象中位居首位。

从 Artificial Analysis 的 Coding Agent Index v2.0 及评估明细中摘录 Fusion、Claude、GPT 的主要配置。2026 年 10 月 30 日确认。均为数值越高成绩越好。评估为模型与执行平台的组合。

执行平台 模型・处理级别 综合得分 Terminal-Bench 4.0 FrontierCode v1.1 SWE-Atlas-QnA-AA

Claude Code Claude Opus 5.5（Max） 62 63% 56% 66%

Claude Code Claude Sonnet 5.5（Max） 59 66% 48% 64%

Claude Code Claude Fable 5.1（Max） 58 58% 49% 66%

Codex GPT-6 Astra（Max） 55 56% 49% 59%

Codex GPT-6.1 Sol（Max） 54 53% 49% 60%

Codex GPT-6.1 Terra（Xhigh） 48 46% 45% 54%

综合得分上 Claude Code 的 Opus 5.5 更高，在 FrontierCode 和 SWE-Atlas-QnA-AA 上也超过了 Fusion。Codex 的 GPT-6 Astra 和 GPT-6.1 Sol 在 SWE-Atlas-QnA-AA 上也高于 Fusion，可见不同评估项目各有优势。

Frontier performance at a fraction of the cost.

In the @ArtificialAnlys Coding Agent Index, Copilot Fusion Max scored within two points of Claude Code with Opus 5.5 Max at about half the API cost per task.

适用方案与使用费用

Fusion Standard 可在所有 Copilot 方案中使用，但 High 和 Max 仅适用于 Copilot Pro+、Max、Business、Enterprise。

Fusion 本身不收取额外费用，而是根据所用各模型的费用计费。当 High 或 Max 使用多个模型时，AI 积分的消耗可能多于 Standard。在付费 Copilot 方案中，截至 2026 年 11 月 30 日，Fusion 所用模型的费用可享受 30% 折扣。

向本地模型分流为实验性预览

在 Fusion Standard 中，还以需用户启用的实验性预览形式，提供区分使用受支持的本地模型与云模型的功能。无需按请求手动切换模型，也可利用本地终端的计算资源。不过，将处理交给哪个模型由云端判断，因此这种自动选择需要互联网连接。

在 GitHub Copilot 应用中，在设置的“Model providers”里从“Add provider”中选择“Windows ML”，然后按下 MAI Code 1.1 Flash 的“Download”进行获取。使用需要满足受支持的 GPU 和足够的内存等要求。接着启用实验性功能设置中的“Local model auto routing”，并在新会话中选择 Fusion 的 Standard，本地模型也会成为分流目标。

在 CLI 中启用实验性模式，并从“/model”进行设置。也有在 Windows、macOS、Linux 上手动配置受支持模型来使用的方法[7]。在 VS Code 中启用“chat.copilot.localModel.enabled”。

通过 GitHub intelligence，将过去的工作和相关代码用于下一次开发

GitHub intelligence 是一组让智能体能够使用仓库代码、开发历史和团队知识的功能。在本次发布中，介绍了继承知识的 Memory、审视其内容和作业方针的 Dreaming，以及跨相关仓库进行代码搜索的功能。

GitHub intelligence puts your code, context, and history to work - GitHub Changelog

Memory 正式提供，Dreaming 开始预览

自 1 月起处于公开预览的 Memory 正式提供，同时新开始了 Dreaming 的公开预览。Memory 会记住个人偏好和仓库规则，使其可在其他会话或客户端中使用。Dreaming 会回顾过去的对话和工作，整理和更新这些记忆，同时还会建议改进智能体遵循的技能和指令文件。

Memory 在有偿 Copilot 方案中提供。例如，如果记住测试的执行命令和 PR 说明的写法，就能减少在下一次工作中重复相同指示的麻烦。不仅用户可明确要求记住，Copilot 也会从会话中的交流自动创建和整理记忆。在正式提供的发布中，说明可在 GitHub Copilot 应用、CLI、VS Code、云智能体、代码审查，以及 Slack、Teams、GitHub Mobile 中创建记忆。

使用已保存信息的范围因类型而异。关于仓库的信息适用于该仓库的工作，个人偏好则跨仓库使用。用户或管理员可根据设置查看和删除保存内容[8]。

在 Dreaming 的审视中，会根据需要添加、更新、删除个人或仓库的记忆。还有将反复被采纳的代码审查意见反映到今后审查方针中的功能。对仓库中保存的技能和指令文件的更改不会直接应用，而是作为供团队确认的 PR 提出[9]。

Dreaming 需要启用，执行会使用 AI 积分。在组织或企业中还会应用管理员策略。

跨相关仓库搜索代码

GitHub intelligence 还具有从多个相关仓库中查找代码、配置和文档的功能。无需将全部内容 clone 到本地，即可搜索字符串和符号，还支持用自然语言指定处理内容的语义搜索。

发布中举例说明了调查横跨支付服务、公共库和后台处理的 retry 处理。使用“/research”请求后，可确认各仓库的实现和调用方，调查哪里可能重复进行 retry。可在开始更改之前，用于掌握分散在多个仓库中的处理之间的关系。

为 Copilot Automations 增加团队共享和改进支持

以团队方式管理 Copilot Automations

在 Copilot Automations 中，将指示作业的提示词、启动条件以及允许使用的工具组合起来，在云端运行 Copilot。例如，可以设置这样的处理：创建 Issue 后尝试复现缺陷，收到监控服务的通知后调查故障。

使用 Copilot Automations 为团队构建共享工作流 - GitHub Changelog

除以往的个人用途外，还将陆续提供由团队管理的共享 Automations。拥有仓库读取权限的人可以查看设置，拥有写入权限的人可以编辑。GitHub 上的操作以 Copilot 的名义记录，AI 积分和 Actions 的执行时间向仓库所有者计费。由于共享 Automations 属于仓库，因此即使创建者离开团队，处理也能继续。

适用对象为 Copilot Pro、Pro+、Max、Business、Enterprise。发布中表示，可在拥有写入权限的任意仓库中创建[10]。对于组织所有的共享 Automations，还需要允许向组织计费的管理员设置。

添加启动条件和工具，并根据结果提出改进建议

在 Copilot Automations 中，可指定为执行触发器的 GitHub 事件增加了 24 种。可以在 PR 发生冲突或创建安全警报等情况下，启动所设置的处理。

还可以使用 REST API，从外部系统传递相关信息来启动 Automation。此外，通过将某个 Automation 的成功或失败设为另一个 Automation 的启动条件，可以组合多阶段处理。

可使用的 GitHub 工具新增了 20 种，包括重新运行工作流、合并 PR、附加图片和视频等。还可以连接自定义的 MCP 服务器，并按每个 Automation 选择允许使用的工具。对外部服务能做什么，也取决于连接目标的设置和认证信息。

可以为每个 Automation 设置 AI 积分使用量的上限。达到每次执行的上限时，将停止该次执行。还可以设置每日、每周、每月的上限，达到上限时，在切换到下一个统计周期之前不会启动新的执行。

此外，还新增了根据执行结果制定改进方案的功能。请 Copilot 创建想要自动化的工作，以及回顾其结果并加以改进的机制，即可组合用于工作的 Automation 和用于改进的 Automation。

例如在 PR 审查中，准备一个在创建 PR 时确认变更并发表评论的 Automation，以及一个每周分析开发者对这些评论的应对情况、制定审查方法改进方案的 Automation。如果是分类 Issue 的 Automation，人们是否修正了所添加的标签；如果是改进性能的 Automation，所创建的 PR 是否被合并，这些都可作为评估结果的线索。

当用于改进的 Automation 提出对用于工作的 Automation 的提示词、工具、启动条件的更改时，GitHub 会向用户发送通知。用户确认提案后选择接受或拒绝，接受的更改将被应用。

VS Code 此前支持在本地运行的个人用定期执行，此次也支持创建和管理云端 Automations。由于在云端执行，即使关闭 PC 电源也能执行定期处理。在 VS Code 1.144 及更高版本中启用设置“chat.automations.cloud.enabled”后，可从 Agents 窗口的“Automations”标签页创建和管理。

Agentic Workflows 正式提供，将定义与代码一起管理

GitHub Agentic Workflows 是一个在 GitHub Actions 内运行编码代理的开源项目，经过 6 月的公开预览后正式提供。用自然语言的 Markdown 定义想要自动化的处理，它就会转换为标准的 Actions 用 YAML，并可在现有的运行器组和策略下执行。可用于整理 Issue、分析 CI 失败、更新文档、创建测试等。

Copilot Automations 在 GitHub 上仓库的“Agents”标签页等处创建和管理。其设置不作为仓库内的文件提交到 Git，而是与代码分开保存。另一方面，Agentic Workflows 会同时提交 Markdown 定义和生成的 .lock.yml，因此自动化定义本身可以与代码在同一历史中管理，并可通过 PR 确认更改。

GitHub 列举了公开预览之后的更新，包括支持使用 Actions Runner Controller 和 Docker-in-Docker 的自托管环境，以及改进 AI 费用预测。费用预测命令 gh aw forecast 已结束实验阶段。预测中包含了威胁检测所消耗的 AI 积分，月度 AI 积分使用量的估算现在带有一定范围。

此外，现在可以为每个工作流选择使用模型的服务。例如运行 Claude Code 时，除了直接使用 Anthropic API 的配置外，还可以选择通过 GitHub Copilot 使用 Claude 模型的配置。还提供了根据课题类型和难度分配模型的机制。

作为公开预览以来的改进点，还介绍了在轻量虚拟机上运行代理的选项，以及处理多个仓库时防止数据泄露的隔离功能。

Agentic Workflows 中运行的代理对 GitHub 的访问权限默认是只读的。执行环境在沙箱中隔离，通信目标也受到限制。创建 Issue 等对 GitHub 的写入通过名为 safe outputs 的机制进行，在验证代理的输出后，由具有必要权限的另一个作业执行。当威胁检测发现问题时的处理方式，取决于所配置的模式[11]。

提供对象为 github.com 上的 GitHub Free、Team、Enterprise。标准 Copilot CLI 引擎需要 Copilot 许可证，使用其他支持的引擎时，需要分别进行必要的认证并满足使用条件。

另外，Actions workflow dependency lockfiles 也经过 14 天的公开预览后于 28 日正式提供。这是与 Agentic Workflows 不同的功能，它将工作流调用的动作以及该动作所依赖的动作的执行提交记录到 actions.lock 中。工作流内可以保留易读的标签或分支名。即使这些标签或分支之后指向其他提交，执行时也会使用已记录的提交，因此可以防止依赖对象的意外更改[12]。

更新代码审查与 PR・Issue 管理

为 Copilot 代码审查添加 Max，审批功能正式提供

Copilot code review 新增了作为审查处理级别的 Max，继 Lite、Balanced 之后以公开预览形式提供。另一方面，用于批准 PR 的 Copilot approvals 经过 9 月以来的公开预览后正式提供。

Copilot code review: Merge with confidence with Max and approvals - GitHub Changelog

在 Max 中，由使用不同提供方模型的多个代理独立进行审查。随后，由汇总代理确认指摘之间的分歧与准确性，并整合为一份审查结果。相比 Lite 和 Balanced 的审查，处理耗时更长，AI 点数消耗也更多。GitHub 将其定位为面向认证处理、多个服务共用的库等需要详细确认的变更的处理级别。

Copilot approvals 默认处于禁用状态，但管理员启用后，Copilot 可基于审查结果批准 PR。还提供了将该批准计为合并所需批准的设置。[13]批准后若有新提交被 push，批准将被撤销，需要重新审查才能获得新的批准。Max 和 approvals 可在 Copilot Pro、Pro+、Max、Business、Enterprise 中使用。

通过 Agent Merge 修复 Actions 失败与合并冲突

即使审查完成，CI 失败或冲突也可能阻碍合并。继 GitHub Copilot 应用和 VS Code 之后，用于监控并修复此类问题的 Agent Merge 也已集成到 GitHub 上的 PR 中。

在 PR 的“Watch and fix”中，选择要修复的对象：Actions 工作流失败、合并冲突或两者兼有。当选定的问题发生时，Copilot 将在云环境中推进修复。此外，若启用 GitHub 的自动合并功能（auto-merge），修复后当所需的审查批准和检查等条件齐备时，GitHub 将自动合并。云端的 Agent Merge 面向付费 Copilot 套餐，组织或企业设置的政策同样适用。

PR 发布限制的豁免条件与 Issue 管理权限

在协作管理方面，为限制无写入权限投稿者创建 PR 数量的功能新增了豁免条件。以账号创建后的经过天数、投稿者的 PR 在该仓库中被合并的件数等为基准设定条件，满足已启用条件中至少一项的人可以超过上限创建 PR。可在组织或仓库设置的“Moderation”→“Interaction limits”中设置条件与基准值。

此外，还介绍了可在不授予代码访问权限的情况下委派 Issue 编辑与管理的 Moderate 角色，但据 28 日的补充说明，该角色尚未提供，计划在未来数周内开始提供。

安全对策：从本地修复到公开信息监控

GitHub Advanced Security 的产品群分为处理代码漏洞的 Code Security 和防止机密信息泄露的 Secret Protection，可分别单独签约。

在 GitHub Copilot 应用中审查本地更改并修复现有警报

作为公开预览提供 GitHub Copilot 应用的 Security 扩展。它具备在打开 PR 前审查本地更改的功能，以及确认并修复仓库现有代码扫描警报的功能。

Security extension for the GitHub Copilot app - GitHub Changelog

本地更改审查可在所有 Copilot 套餐中使用，无需额外签约 Code Security。在应用的“Customize”中搜索并安装“github-security”，然后通过 /security-review 发起请求。在 Business・Enterprise 中，管理员设置的应用使用许可和插件限制同样适用。

要处理现有警报，需在仓库中启用代码扫描，且用户需拥有警报的查看权限。私有仓库还需要 GitHub Code Security 许可证。可在应用内请求警报的说明或修复，修复时 Copilot 会修改本地工作副本。由于不会执行提交或 push，用户可在确认更改后再反映。

说明、修复和本地更改的审查会使用应用中选定的模型，并像普通请求一样消耗 AI 额度。查看或驳回警报不会消耗 AI 额度。

面向 AI 应用程序的代码扫描会检测间接提示注入、敏感信息泄露、向代理授予过多权限等问题。例如，它会调查来自不受信任文档的指令到达可访问外部工具或数据的 AI 的代码路径。启用代码扫描和面向 AI 应用程序的检查后，它会在创建 PR 时与现有 CodeQL 分析并行运行，并提供用于处理所检测问题的信息。

在公开预览中，需要 github.com 上的 GitHub Advanced Security 许可证。根据官方文档，运行检查时也会消耗 AI 额度。

另一方面，面向仓库的 AI Scan 是一项公开预览功能，使用 AI 检查默认分支的最新提交。它也覆盖 CodeQL 不支持的语言和框架，补充检测基于规则的解析难以发现的漏洞。

启用面向仓库的 AI Scan 后，拥有代码扫描写入权限的用户可从界面启动检查。检查有运行时间上限，会重点调查可能存在漏洞的位置。结果会显示在代码扫描的警报列表中，合并修复后可通过重新扫描确认问题已解决。

AI Scan 不需要 Copilot 许可证，但会消耗 Code Security 的 AI 额度。组织的 private、internal 仓库需要 Code Security 或 Advanced Security，不支持个人拥有的非公开仓库。针对 PR 更改的 AI Scan 已于 15 日正式提供，其启用设置与此次面向仓库的功能不同。

Dependabot 分析调用脆弱函数的可能性

10 月 28 日，Dependabot 的可达性分析开始公开预览。该功能会从应用程序代码中寻找通往依赖包内脆弱函数的调用路径，不仅显示依赖包是否存在漏洞，还会显示应用程序调用该位置的可能性，便于确定应对优先级。

对象为 GitHub Enterprise Cloud 上的 JavaScript、TypeScript，需要 npm、Yarn、pnpm 的 lockfile。预览期间免费，无需 Advanced Security 许可证。分析所用的 Actions 运行时间也不计费。结果只是警报的补充信息，不会自动关闭警报或判断为无需处理。

防止机密信息泄露，发现公开仓库和 Issue 中的泄露

使用 AI 检测机密信息并防止通过 push 泄露的功能也已进入公开预览。专用 AI 分类器会调查机密信息候选在周围代码中的使用方式，也能检测不符合已知字符串模式的机密信息。检测到后，GitHub 会拒绝该更改并告知相应位置。

此阻止功能默认禁用。需要在启用现有 push protection 和 AI 机密信息扫描的基础上，再启用阻止 AI 检测到的机密信息。对象为在 github.com 上拥有 Secret Protection 或 Advanced Security 的组织，push 时的 AI 检测会使用 AI 额度。

调查公开后泄露的 Public monitoring 经过 7 月开始的公开预览后正式提供。在 Enterprise Cloud 中使用 Secret Protection 或 Advanced Security 的企业可免费使用。

它不仅搜索企业拥有的仓库，还会搜索泄露到个人 fork、公开 Issue 写入等 github.com 公开内容中的机密信息。它使用企业成员信息和已验证域名来判断应向哪家企业通知泄露[14]。

在正式提供之前，22日已支持可选择数据所在地的Enterprise Cloud，23日又新增了警报管理、自动验证泄露凭据的有效性以及API和Webhook支持。由此，可以管理泄露发现后的应对状况，并通过API和Webhook与现有的事件响应系统联动。

将Copilot使用资格纳入GitHub Enterprise

此前，Copilot Business和Copilot Enterprise的使用席位需要与GitHub Enterprise合同分开签约和管理。此次，GitHub Enterprise Cloud引入了将各用户的Copilot使用资格纳入GitHub Enterprise许可证的合同方式。首先，通过GitHub或Microsoft销售负责人签约的企业，可以在新签约或从现有合同迁移时使用。

GitHub Enterprise now includes access to GitHub Copilot - GitHub Changelog

这种方式可减轻分别管理Copilot席位和AI使用量的负担，以企业的AI预算为中心管理使用。功能和模型相当于Copilot Enterprise，但不附带按席位计算的月度AI额度，AI使用量从第一次请求起就计入企业预算。即使预算用完，代码补全和Next edit suggestions仍可使用，而聊天、代码审查和云端Copilot则需要有可用预算。

面向自助服务合同的提供将今后分阶段推进，不影响当前的自助服务合同[15]。

支撑日益增加工作的Git与Actions基础设施更新

GitHub在汇总Universe发布的文章中说明，为应对智能体开发的增加，除增强容量外，还将改变基础设施的设计本身。在Git基础设施方面，提出了简化构成要素、分离存储与计算、最小化协调处理这三项原则。

领导Microsoft CoreAI的Jay Parikh在配合Universe发布的帖子中说明，正在推进对基础设施的投资。作为正在进行的举措之一，他提到了能够应对当前180倍处理量的新Git架构。

此外，GitHub CTO Vladimir Fedorov在关于Git基础设施扩展的帖子中，就单个仓库的处理量发问：“如果能做到每秒7200次push，会怎样？”

在智能体并行修改代码的环境中，不仅是代码读取，push和合并的集中也会给基础设施带来负载，因此GitHub正在保持运行的同时重新设计Git基础设施。

Building Git infrastructure for agent-scale development - The GitHub Blog

据该文章介绍，此前是将仓库的完整副本放在多台服务器上，同时用于存储和读取处理。增加读取用副本时，写入时需要协调的对象也会增加，因此难以同时增强读取和写入。

因此，新设计将存储分离到Azure Blob Storage，并让负责读取的worker可以独立增减。写入时，仅在更新分支等引用目标的部分进行协调，以确保更新内容不冲突。使数据的存储和检查能够与其他写入并行推进，并将繁重的数据整理从处理常规Git请求的服务器中分离出来[16]。

GitHub正在将运行基础设施迁移到Azure的多个区域，并在Universe上表示，这一迁移预计于2027年初完成。

Actions将目标Linux作业分散到Azure和AWS

除Git基础设施的变更外，还宣布了将GitHub Actions的托管运行器扩展到多个云端的变更。GitHub Actions会将目标Linux作业自动分配到可用的Azure或AWS执行环境。通过增加执行目标，减少拥堵时的等待时间和计算资源不足。现有的运行器标签和工作流语法不变[17]。

对象为标准2核和4核Linux运行器，以及不具备特殊配置的相应2核和4核大型运行器。Windows运行器以及使用私有网络等特殊配置的运行器不在对象范围内。Free、Pro、Team会自动应用于对象运行器，Enterprise Cloud则由管理员启用AWS的使用。

Universe相关发布列表可通过GitHub Changelog的Universe '26标签查看。