很多人的 coding agent 工作流有个断点：agent 在 IDE 里写得很欢，CI 一红，流程就退回人工。 翻日志、本地复现、改一行、推送、等重跑，如果挂掉的是测试和 lint 这类机械问题，这套动作其实不值得你亲手做。 GitHub 从 2026 年 5 月 18 日起给 Business 和 Enterprise 订阅者的失败 Actions job 加了 Fix with Copilot 按钮，6 月 4 日 Pro、Pro+、Max 用户也拿到了同一个入口。[4][3]

按钮背后是 Copilot cloud agent。 它跟你 IDE 里的 agent mode 不是一回事：后者在你本地环境同步改代码，前者在 GitHub 托管的临时环境里独立干活，研究仓库、做计划、在分支上改代码，然后开 PR 等你 review。[2] 官方 changelog 的定位很直白：把修测试、改 linter 这类简单但耗时的活交给 Copilot，你专心做真正想写的东西。[3]

闭环是怎么转的#

打开失败的 workflow run，进到失败 job 的页面，点 Fix with Copilot。 官方文档的描述很朴素：Copilot 开一个新会话，调查失败原因，把修复推到你的分支。[1] 它的工作环境由 GitHub Actions 驱动，能自己执行自动化测试和 linter，在推送前先验证改动，而不是盲改一通。[2][5] 中文排障文档也写了同样的话：处理任务时它可以访问自己的临时开发环境，在其中运行自动化测试和 linter 来验证工作。[5]

第一次用你会撞上一个很像 bug 的现象：agent 推完 commit，PR 还是红的，CI 压根没重跑。 这是设计，不是故障。默认情况下，Copilot 推送到 PR 的改动不会自动触发 Actions 工作流。[1] GitHub 的理由很实在：workflow 可能有特权、能访问敏感 secrets，所以人得先检查改动，尤其要警惕 .github/workflows/ 目录里的变更。[1] 想放行，去 PR 的 merge box 点 Approve and run workflows。[1] 所以完整闭环是：点按钮，agent 调查并推修复，你读 diff，批准重跑，CI 绿了再合并。 agent 从头到尾只把活干到一个 PR 里然后请求 review，它自己不会合并。[3][1]

不止按钮：另外两个入口#

Fix with Copilot 只是入口之一，同一个 agent 还能从两处进场。 一是 issue 分配：把 issue 的 assignee 设为 Copilot，它会收到标题、描述、已有评论和你附加的指引，干完开 PR 并请求 review。[1] 有个细节值得记牢：一旦分配，issue 上之后新增的评论它不会再读，补充需求要写进它开出的 PR 里。[1] 二是 PR 评论：在任意 PR 上 @copilot 让它改东西。 只有仓库写权限者的评论会被响应，响应时评论上会出现眼睛表情，时间线里多一条 Copilot has started work 事件。[1] 它记得同一 PR 之前会话的上下文，追问一次比一次快。[1]

三个入口收敛到同一个模型：所有改动最终都变成一个 PR 加一次 review，没有任何路径能绕过你。 这跟让 agent 在本地无限改是两种协作姿态，后者赌模型自觉，前者把验收留在你手里。 另外这个按钮不止修 CI：PR 出现合并冲突时，merge box 里同样有 Fix with Copilot，也可以直接评论让 @copilot 解决冲突。 它会分析两侧改动、处理冲突并验证构建、测试和 lint 仍然通过，再请求你确认后才谈得上合并。[1]

想让它一次修对，先喂仓库上下文#

修得准不准，一半取决于它对你仓库的了解。 官方排障文档的建议是给明确指示，而最佳载体是仓库里的 .github/copilot-instructions.md。[5] 分配任务时附带的指引会被使用，[1] 仓库里配置的自定义指令同样会被读取。[2] 再往上还有 custom agents、MCP 服务器、hooks、skills 可以继续定制它的行为。[2] 动手前也值得知道几条硬限制：一次任务只能在一个仓库、一个分支上改，一个任务最多开一个 PR。[2] 单个会话最长 59 分钟，超时即停，大任务记得拆小。[2] 费用走 GitHub Actions 分钟和 AI credits。[2] 安全上也不用太担心它乱联网：默认情况下 agent 对互联网的访问受防火墙限制，官方说明这是为了管理数据外泄风险，防止异常行为或恶意指令把代码泄露到远程位置。[5] 别指望它解决所有失败：机械、可复现的最划算，官方举的例子就是修测试和 linter。[3] 要跨好几个文件追踪数据流的深层 bug、环境性 flaky、依赖的服务宕机，它手里的日志往往不够，别浪费时间。

快速上手#

挑一个今天真的红掉的 PR，走完这四步，全程不用自己写修复代码：

# .github/copilot-instructions.md（先放好，agent 每次任务都会读）
- 安装：pnpm install --frozen-lockfile
- 验证：pnpm lint && pnpm test
- 只改与任务相关的文件，禁止改动 .github/workflows/ 与 migrations/

# 1. 打开失败 run 的 job 页面
# 2. 点 Fix with Copilot，等它请求 review（通常一两分钟）
# 3. 读 diff：重点检查 workflow 文件，再点 Approve and run workflows
# 4. CI 变绿后自己合并

还红就补一条评论：@copilot 加上它缺的上下文，例如“失败来自依赖版本变更，改 package.json，别动调用方”，它会带着之前的记忆继续。[1] 把流程固化成习惯后，backlog 里边界清晰的小 issue 也可以直接 assign 给 Copilot，配一句 optional prompt 写清改哪里、不许碰哪里，回头验收 PR 就行。 CI 红了不再打断你，它只是排队等你 review。

Sources#

[1] https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/use-cloud-agent-on-github — Using Copilot cloud agent on GitHub — GitHub Docs [2] https://docs.github.com/copilot/concepts/about-assigning-tasks-to-copilot — About GitHub Copilot cloud agent — GitHub Docs [3] https://github.blog/changelog/2026-06-04-fix-with-copilot-for-failing-actions-now-in-pro-pro-and-max — Fix with Copilot for failing Actions now in Pro, Pro+, and Max — GitHub Changelog [4] https://github.blog/changelog/2026-05-18-one-click-fixes-for-failing-actions-with-copilot-cloud-agent — One-click fixes for failing Actions with Copilot cloud agent — GitHub Changelog [5] https://docs.github.com/zh/copilot/how-tos/use-copilot-agents/coding-agent/troubleshoot-coding-agent — GitHub Copilot 云代理故障排除 — GitHub Docs 中文