Copilot Automations 变成团队资产：共享、自我改进与按次成本控制

要点

一、共享型 Automations（Improvement，2026-10-28）

• Automations 从「个人」扩展到「共享」：此前 automations 都是个人的——只有创建者能看见和编辑，且用创建者的身份与 AI credits。现在可以建共享型。
• 三条归属规则同时改变：① 可见性——对仓库有读权限的人都能看见，有写权限的人都能编辑；② 计费——AI credits 记到拥有该仓库的组织或个人头上，而不是创建者；③ 身份——在 GitHub 上的操作归属 Copilot，不归属任何具体用户。
• 「Built to last」：共享 automation 属于仓库，创建者离职后继续运行；变更历史让团队能看到 tools / triggers / prompt 是怎么演化的。
• 组织仓库的前置条件：组织拥有的仓库要跑共享 automation，管理员必须先开启「Allow use of Copilot cloud agent billed to the organization」策略。
• 创建方式：在 github.com、GitHub Copilot app 或 Visual Studio Code 创建时，在 Type 下选 Shared；创建后类型不可更改。
• 放量状态：官方原文 "Shared Copilot Automations are rolling out"，面向 Copilot Pro / Pro+ / Max / Business / Enterprise，可用性随放量进度变化。

二、自我改进（Improvement，2026-10-28）

• Automations 可以从运行结果中学习，并向自己提出改进建议。
• 学习信号来自 GitHub 上的真实结果：issue 分类 automation 学习「人们是否改掉了它打的标签」；代码评审 automation 学习「开发者是否采纳了它的评论」；性能优化 automation 学习「维护者是否合并了它开的 PR」。
• 人是闸门：每次改动先提交给你审阅，接受或拒绝后才应用。
• 可以成组：让 Copilot 建一组协同的 automation，例如「PR 打开时评审」+「每周分析评论采纳情况并提出 refinements」。

三、新触发器 / 新工具 / 成本控制（Improvement，2026-10-28）

• REST API 触发：可以用 GitHub REST API 从外部系统触发 automation（官方举例：Jira 工单分诊、Sentry 新问题、PagerDuty 事故）。
• 新增 24 个 GitHub 事件触发器，覆盖 issues（指派 / 子 issue 新增 / 打标签 / 关闭 / 重开 / 状态变更）、pull requests（指派 / ready for review / 打标签 / 合并冲突 / 评审提交 / 请求评审 / 关闭 / 重开 / 转草稿 / 评审撤销 / 评审线程解决或重开）、discussions（创建 / 更新 / 评论或回复）、安全告警（code scanning / secret scanning / Dependabot 三类创建）。
• 可串联：每个触发器新增 "Can be triggered by" 选项，默认 Only users，可改为 Users and Copilot；另新增 Automation run succeeded / failed 两种触发器。
• 新增 20 个 GitHub 工具：上传图片 / 视频附件、重试 workflow run、合并 PR、更新 issue / PR 评论、把 PR 标为 ready for review 或转草稿、隐藏 / 取消隐藏评论与评审、移除 reaction、读取 discussions 与分类并评论。
• 可接自定义 MCP 服务器的工具。
• 成本控制：可以为每个 automation 设 每次运行 / 每天 / 每周 / 每月 的 AI credits 上限。

背景与分析

从「我的脚本」到「仓库的资产」，变的是三件事而不是一件

共享 automation 最容易被人理解成「多了个可见性开关」，但官方一次改了三条归属，而且三条各自都会改变行为：

计费那条最容易被忽略，也最容易出事。 个人 automation 花的是创建者的额度，天然有「谁用谁承担」的约束；共享之后花的是仓库所有者的额度，而能点「运行」的人远多于能看见账单的人。官方给的对冲手段是第三列——操作署名 Copilot，让审计与责任都能落到非人身份上。

本站未实测：组织仓库需要管理员开启的策略（"Allow use of Copilot cloud agent billed to the organization"）在开启前后对既有个人 automation 有无影响，官方未说明，列为待核实。

自我改进：把「prompt 调优」从一次性工作变成闭环，但闸门仍在人手里

本站反复强调的一个判据是**「模型升级换代比参数量更能预测能力位次」**，automation 的自我改进本质上是同一个道理的工程化版本：决定 automation 质量的不是第一次写的 prompt，而是它被真实结果修正了多少次。

值得肯定的是它的信号选择——用的都是「别人的后续行为」而不是「模型自评」：标签有没有被改、评论有没有被采纳、PR 有没有被合并。这类信号的优点是难被 automation 自己刷出来；缺点是有延迟且稀疏：一个每周只开两三个 PR 的仓库，要积累到能提出有意义的 refinement，可能需要好几周。

「每次改动需人工审阅」这条设计是对的，但要提醒一句成本：如果 Copilot 每周都提一条改动，团队要持续付出评审注意力；无人审阅的提议等于不生效，那么「自我改进」在这类团队里实际是关闭的。建议把它当成一个需要排班的功能，不是一个开了就自动变好的开关。

本站未取得一手说明：改进提议的生成频率、触发条件、以及「每周」这个节奏是否可配，官方原文只给了示例（weekly improvement automation），列为待核实。

24 个新触发器里，真正改变用法的是「合并冲突」和外部 API

触发器变多本身不稀奇，但其中两类改变了 automation 的适用边界：

• PR 合并冲突（merge conflict）：把 automation 从「事件发生后做点什么」推进到「状态恶化时介入」。配合新增的合并 PR 与重试 workflow run 两个工具，理论上能做出一条「冲突 → Copilot 解决 → 重跑 CI → 合并」的闭环。这条链路本站未实测，且它同时具备写权限与合并权限，属于高后果自动化，建议先在非保护分支试。
• REST API 触发：把 automation 的输入从「GitHub 上发生了什么」扩展到「任何外部系统发生了什么」。官方举的 Jira / Sentry / PagerDuty 三个例子正好覆盖工单、缺陷、事故三类，说明 GitHub 想把它做成事件总线的执行端，而不是只服务仓库内部。

「Can be triggered by」默认是 Only users，这一点很关键：它意味着串联是 opt-in。默认关闭能防止「A automation 开了一个 PR，触发 B，B 又开一个 PR」这类无限链条；改成 Users and Copilot 之后，必须自己考虑终止条件（新增的 Automation run succeeded / failed 触发器同样参与这个环）。

成本控制是这次更新里最不起眼、但最该先配的一项

每次运行 / 每天 / 每周 / 每月 四档上限，看似普通，但结合上面两条读就有必要了：共享 automation 花别人的钱、自我改进会让它改自己的行为、串联会让它触发更多运行。三者叠在一起，一个写得不好的 automation 可以持续产生成本而不被任何人注意到。

建议的顺序是：先设上限，再放开共享与串联。

行动建议

1. 想让团队共用的，现在就建共享型：创建时在 Type 下选 Shared；创建后不能改类型，所以要改只能重建。
2. 组织仓库先找管理员开策略：「Allow use of Copilot cloud agent billed to the organization」，否则共享 automation 跑不起来。
3. 先配成本上限再放开能力：给每个 automation 设每天 / 每周的 AI credits 上限，尤其是接了 MCP 工具或要串联的。
4. 要串联的，先想终止条件：Can be triggered by 默认 Only users；改成 Users and Copilot 后必须设计终止条件，并在非保护分支先跑一轮。
5. 自我改进要排班：开了每周改进提议的，明确谁负责审阅提议；没人审阅等于这个功能没开。
6. 外部系统接入走 REST API：Jira / Sentry / PagerDuty 一类可用 webhook handler + Trigger an automation API 接入，不必等官方集成。
7. 审计口径要同步改：操作署名变成 Copilot 之后，按人统计贡献 / 按人归因的报表需要单独处理，别把 Copilot 的提交当成某个人的行为。

待核实

• 共享 automation 与既有个人 automation 在组织策略开启前后的相互影响（官方未说明）。
• 自我改进提议的生成频率与触发条件是否可配（官方原文仅给出 weekly 示例）。
• 「20 个新 GitHub 工具」的完整清单（本文列出的是官方原文中点名的部分，未逐条枚举）。
• 成本上限触顶后的行为：是拒绝运行、排队还是报错（官方未说明）。
• REST API 触发的鉴权方式与速率限制（官方仅说「设置一个 webhook handler 并调用 Trigger an automation API」）。
• 共享 automation 在非组织仓库（个人仓库）上的计费与身份表现。
• Automation run succeeded / failed 是否参与 Can be triggered by 的同一套开关。

相关

• GitHub Copilot 工具卡
• GitHub Copilot 服务到服务认证与云端 Agent Merge
• GitHub Universe 2026 / Copilot Fusion GA 资讯
• Agent 编排
• MCP 协议

AI 之家 观点

这组更新里最值钱的不是「自我改进」，而是那张归属表。

过去一年，AI 自动化在团队里的真实困境不是「不会写」，而是**「写好了也没人敢用」——因为它是某个人的东西**：用的是他的额度、署的是他的名、他一走就断。共享型 automation 把这三条同时换掉，本质上是把 AI 工作流从「个人效率技巧」升级成了仓库里的一等公民：看得见、能改、有历史、换了人还在。

但这套设计把成本责任推给了仓库所有者，而把触发权留给了所有人。 这是本次更新里最需要团队自己补的缺口——官方给的成本控制（每运行 / 日 / 周 / 月上限）不是可选项，是共享与串联的前提。我们的建议很直接：先设上限，再谈共享。

至于自我改进，它值得开，但别指望它自动变好。它学习的是「别人的后续行为」——标签有没有被改、PR 有没有被合并，这类信号干净但稀疏；而每一条提议都要人工审阅，意味着团队必须为它排班。把它当成一个「需要喂养的闭环」，而不是一个「开了就会自我进化」的黑盒。