Copilot 走向常驻：服务到服务认证上线，Agent Merge 进 PR 合并框
GitHub Copilot 于 2026-10-27 起支持服务到服务认证（public preview），10-28 起 Agent Merge 可在云端自动修复失败工作流与合并冲突。
2026-11-01 · GitHub 官方 changelog 两篇原文一手核对（2026-10-27 server-to-server authentication；2026-10-28 agent-merge-watches-and-fixes-pull-requests-in-the-cloud）
发布 2026-11-01核实 2026-11-01要点
一、服务到服务认证（Release，2026-10-27，public preview）
- GitHub Copilot 支持服务到服务认证，适用于安装在组织上的 GitHub App。用 GitHub Copilot SDK 构建的服务与 agent，可以代表组织发起请求，而不再依赖某个已登录用户的凭据。
- 官方把这个身份定义为 workload-owned identity（工作负载拥有的身份）："helps agents and automated services operate reliably at larger scale without tying their authentication or usage to individual users"。
- 接入三步：给 GitHub App 授予只读的
Copilot Requests组织权限 → 把 App 装到组织上 → 把短期 installation access token 传给 Copilot SDK。 - 计费与管控都落在组织侧：用量归属并计费给拥有该 installation 的组织；该组织的模型策略、预算与支出管控同样适用。
- 可审计、可撤销：组织所有者可查看哪些 App 有访问权限，在 AI 用量 CSV 报告里用
app_client_id字段识别 App 归因的用量，并通过暂停或卸载该 App 终止其访问。
二、Agent Merge 进 PR 合并框（2026-10-28）
- Agent Merge watches your pull request and automatically fixes blockers（如失败的 Actions 工作流与合并冲突）。
- 此前已在 GitHub Copilot app 与 Visual Studio Code 提供，现在集成到 GitHub 上的 pull request。
- 用法：在 PR 的合并框里选 Watch and fix，可勾选让 Copilot 修失败的 Actions 工作流、解决合并冲突，或两者都做。选定的阻塞项一出现，Copilot 就在云端开发环境中开工修复。
- 可设为默认：在 Copilot 设置里开启后，你开的每一个 PR 默认都会走 Agent Merge。
- 可与 auto-merge 叠加："Copilot gets and keeps your pull request ready to merge, and GitHub merges it as soon as all requirements are met."
- 可用性：付费 Copilot 计划用户，且受组织与企业策略约束。
背景与分析
服务到服务认证解决的是一个很具体的组织病：AI 用量挂在某个人名下
在这一条之前，用 Copilot SDK 写的服务只有一种现实做法：借一个用户的身份跑。这带来三个具体麻烦——
- 人员变动即故障：那个人的账号离职、换岗、改权限，服务就断。
- 用量归因失真：所有自动化消耗都记在一个自然人头上，组织看到的账单是「某人用了很多」，而不是「某个服务用了很多」。
- 管控绕不过去：个人身份走的是个人额度与个人策略，组织级的预算与模型策略难以真正作用在这类流量上。
workload-owned identity 把这三件事一次性换掉：身份归工作负载、用量记组织、组织策略生效。配合 app_client_id 出现在 AI 用量 CSV 里，「哪个服务花了多少钱」第一次在报表层面可回答。
它仍是 public preview，且官方明确是只读的 Copilot Requests 组织权限——注意是只读权限，但它消耗的是组织的付费额度。权限最小化与成本敞口在这里是分离的：只读 ≠ 便宜。设为默认前先配合组织的预算告警。
Agent Merge 把「Copilot 帮我改」推进到「Copilot 盯着改」
Agent Merge 此前在 Copilot app 与 VS Code 里是人发起的：你说一句，它去修。现在它挂到了 PR 的合并框上，变成状态驱动的：阻塞项一出现就自动开工。
这个差别比看起来大。人发起的自动化有天然的止损点（人不在就不跑），状态驱动的自动化没有。官方给了两个对冲手段：
- 可勾选范围：只修失败的工作流、只解冲突、或两者——范围是你定的。
- 不自动合并：Agent Merge 只负责「让 PR 保持可合并」，真正的合并要么由 auto-merge 在满足全部要求后执行，要么由人点。
本站最担心的是它和 auto-merge 叠加："Copilot gets and keeps your pull request ready to merge, and GitHub merges it as soon as all requirements are met." 这条链路里，Copilot 修的冲突与工作流，最终会被 auto-merge 直接合并——而 auto-merge 的「全部要求」通常指状态检查与审批，不包含「这次冲突是 Copilot 解的、解对了吗」。本站未实测两者叠加后的实际行为，列为待核实；建议开了 auto-merge 的仓库，先别批量开启 Agent Merge 默认，或者在保护分支上要求人工审批。
两条合起来看：Copilot 正在从「会话」变成「常驻服务」
| 维度 | 此前 | 现在 |
|---|---|---|
| 身份 | 借用登录用户 | 工作负载自有身份（server-to-server） |
| 触发 | 人发起 | 状态驱动（Agent Merge 盯着 PR） |
| 归因 | 记在某个人头上 | app_client_id 可归因到 App |
| 规模瓶颈 | 受个人账号与额度限制 | 官方称可 larger scale |
这两条更新本身分属不同团队（SDK 身份 vs PR 工作流），但方向一致：让 Copilot 在没有人的时候也能持续、可归因、可管控地干活。这与本站 10-28 记录的 GitHub Agentic Workflows GA 是同一波浪潮里的三块拼图：身份（本条）、执行（Agentic Workflows）、修复（Agent Merge）。
对团队的真实含义是治理题，不是能力题。 三块拼图拼完之后，「一个 PR 被自动修改、自动合并，消耗由某个 App 记在组织账上」成为常态。这时候必须能回答三个问题：谁授权的、改了什么、花了多少。官方本轮给了后两个（app_client_id 与组织策略），「改了什么」仍依赖 PR diff 与常规代码评审，不建议因为「是 Copilot 改的」就降低评审标准。
行动建议
- 用 Copilot SDK 建服务 / agent 的，尽快从「借个人身份」迁到 server-to-server：给 App 授只读的
Copilot Requests组织权限 → 装到组织 → 传 installation access token。先确认组织的预算与模型策略已配好，因为迁移后这些策略会真的生效。 - 组织所有者先做一次 App 盘点：查看哪些 App 有访问权限；用 AI 用量 CSV 里的
app_client_id字段把自动化用量从个人用量里剥出来。 - 准备撤销路径：确认「暂停 / 卸载 App」这条终止手段在你组织的运维流程里可用且有人知道。
- Agent Merge 先小范围试：在合并框里选 Watch and fix，明确勾选只修工作流或只解冲突，先在非关键 PR 上跑一轮看它改了什么。
- 开了 auto-merge 的仓库先别全量开 Agent Merge 默认：叠加后 Copilot 解完冲突会自动进入合并流程，建议在保护分支保留人工审批。
- 评审标准不要降：Copilot 修的冲突与工作流同样要过 diff 评审——「Copilot 改的」不是免检理由。
待核实
- server-to-server 认证的 public preview 转正时间与 GA 前的 breaking change 风险。
- installation access token 的有效期与轮换要求（官方仅称 short-lived）。
- 哪些 Copilot SDK 能力在 server-to-server 身份下可用，是否全部能力等同用户身份。
Copilot Requests是只读权限却消耗付费额度的具体计费口径（官方未给单价或计量单位）。- Agent Merge 与 auto-merge 叠加后的实际行为：Copilot 解决冲突后是否直接进入合并队列（官方措辞为 gets and keeps ready to merge，本站未实测）。
- Agent Merge 在保护分支 / 需要 CODEOWNERS 审批的仓库上的行为（官方仅说受组织与企业策略约束）。
- Agent Merge 修复失败工作流时的重试次数上限与成本归属（是否计入 AI credits、是否有单次上限）。
相关
- GitHub Copilot 工具卡
- Copilot Automations 共享与自我改进
- GitHub Agentic Workflows GA
- GitHub Universe 2026 / Copilot Fusion GA 资讯
- Agent 编排
AI 之家 观点
这两条更新放在一起读，信号很清楚：Copilot 正在从「一个你打开的对话框」变成「一个常驻在你仓库里的服务」。
server-to-server 认证给的是身份：AI 用量第一次可以归因到「某个服务」而不是「某个人」，组织级预算与模型策略也才真正能作用在这类流量上。Agent Merge 给的是触发方式：从「你说一句它改一次」变成「阻塞项一出现它就开始改」。
能力变强的同时，止损点也在减少。 此前所有 Copilot 行为都有一个天然边界——人不在就不跑；现在身份与触发都脱离了人，唯一剩下的闸门是你勾选的范围和auto-merge 之前的那道审批。
我们的建议是把「先设边界，再开能力」当成默认顺序：服务到服务认证先配预算告警再上线；Agent Merge 先只勾一类阻塞项、先在非保护分支、先不要和 auto-merge 叠加。 这不是保守——当 AI 能自己改代码、自己准备合并时，人类唯一还握着的权力就是「决定它先别动哪些东西」。