TL;DR——2026 年把 issue 指派给 Copilot 的四件事
- 指派只要一次点击：打开 issue，点右侧 Assignees，选 Copilot。它会秒回一个👀，在 GitHub Actions 的临时环境里开工，并立刻开一个 draft PR，你在 issue 时间线里就能跟踪进度。
- GitHub 官方文档现在把它叫 Copilot cloud agent——和 UI、博客里仍写作 coding agent 的是同一个产品。两个名字搜索、提问、查文档都通用，本篇也双名并注。
- 前置条件：付费 Copilot 计划 + 对仓库有 write 权限。免费版账号的 Assignees 列表里根本不会出现 Copilot；Business 和 Enterprise 还需要管理员先打开策略开关。
- 评审权始终在人手里：Copilot 干完会主动请求你 review，评论区 @copilot 就能打回重改，PR 必须人工批准才会 merge。本篇演示那次跑了 8 分 14 秒。
Use GitHub Copilot Coding Agent to Solve Open Issues in a GitHub Repository
频道：:The Code Wolf13:00
How to Get the Most Out of the Copilot Coding Agent
频道：:GitHub1:56
How the GitHub Copilot coding agent works | GitHub Checkout
频道：:GitHub6:58
Starting GitHub Copilot sessions
官方文档：:docs.github.com
About the Copilot cloud agent
官方文档：:docs.github.com
本页所有截图取自上表两段干净的屏幕录制，每张都经过原尺寸逐帧核对。GitHub Checkout 访谈仅作为事实来源——其录屏画面带有出镜者摄像头小窗，故未从中截取任何帧。
截图仅用于说明与评论。《Use GitHub Copilot Coding Agent to Solve Open Issues in a GitHub Repository》© The Code Wolf；《How to Get the Most Out of the Copilot Coding Agent》《How the GitHub Copilot coding agent works》© GitHub。所有产品名归各自所有者商标所有。
指派、跟踪、合并：13 步图文教程
指派之前的准备
- 1
打开仓库 Issues 标签，挑一个范围清晰的任务
issue 通常来自产品负责人、团队或社区。演示仓库里开着三个：Snowflake 连接器、可排序列名、收藏夹命名——每个都是一个 PR 就能交付的功能，这正是 coding agent 最擅长的粒度。也可以同时指派多个 issue，每个都会独立开会话、独立开 draft PR。
演示仓库的 Issues 标签：三个待处理的社区 feature request。视频 9:31 处观看 - 2
把问题描述和验收标准写进 issue
Copilot 只能看到你指派那一刻 issue 的标题、描述和已有评论。好的 issue 要写清问题是什么、为什么重要、验收标准是什么——GitHub 官方示例就列出了逐条可勾选的标准，让「做完没」可以客观判断。写漏了也不是没救，但只能补充到它开的那个 PR 的评论里，因为 agent 之后不会回头重读 issue。
一个合格的 issue：描述、动机、可勾选的验收标准。视频 0:17 处观看 - 3
确认你的账号已启用 agent
只有付费 Copilot 计划才能把 issue 指派给 Copilot。打开 github.com/settings/copilot/features 查看——个人设置页左侧 Copilot 分组下有 Coding agent (Preview) 一项，旁边还有 Copilot in the CLI、Chat in GitHub Mobile 等编辑器预览功能的 Enabled 开关。Copilot Business 和 Enterprise 则要管理员先在组织层面启用策略，选项才会出现。
Copilot 功能设置页：Coding agent (Preview) 的启用状态在这里看。视频 4:00 处观看
把 issue 指派给 Copilot
- 4
打开 Assignees 菜单，选中 Copilot
进入 issue，点右侧边栏的 Assignees。下拉列表除了成员，还展示 additional options——其中包括副标题写着 "Your AI pair programmer" 的 Copilot。像选同事一样选中它即可；官方文档注明指派功能处于 public preview，界面可能调整。偏好命令行的话，gh agent-task create（GitHub CLI 2.80.0+，public preview）能在终端发起同类会话。
Assignees 下拉列表，Copilot——Your AI pair programmer——高亮待选。视频 4:16 处观看 - 5
确认指派，按需补充可选指令
选中后 Copilot 会和人类 assignee 并排显示。指派面板还提供可选加成：optional prompt 输入框（补充上下文、约束和具体要求）、切换目标仓库和起始分支的下拉框——需要对所选仓库有 write 权限且那里已启用 cloud agent——以及 custom agent、模型和 reasoning 档位。全部可跳过：不带任何附加项，Copilot 也能只凭 issue 文本开工。
官方片段：在 Assignees 下拉列表中选中 Copilot。视频 0:04 处观看 - 6
盯时间线，确认 Copilot 已接单
几秒内 issue 就有反应：Copilot 会加一个👀，时间线出现 "Copilot has started work" 事件。这段录像里还能看到指派事件、Copilot 自己的评论，以及一分钟后出现的 "Copilot linked a pull request that will close this issue"——指向新建的 WIP draft。会话推进过程中你还会收到邮件通知。
Issue 时间线：指派事件、Copilot 评论、关联的 WIP PR。视频 5:22 处观看
跟踪后台运行
- 7
去 GitHub Actions 看运行过程
cloud agent 跑在 GitHub Actions 驱动的临时环境里。打开 Actions 标签，能看到以 issue 命名的运行——这里叫 "Fixing issue #5"——其中 copilot job 的步骤依次是 Prepare Copilot、Start MCP Servers、Processing Request、Clean Up、Save Data。注意：Copilot 推送后，你的 CI 可能需要有人点 "Approve and run workflows" 才会执行。
Actions 运行页里 copilot job 的实时步骤。视频 5:00 处观看 - 8
从 issue 时间线打开 draft PR
Copilot 不会闷头干到最后——它会立刻开一个 draft PR 并持续更新。issue 时间线里有直达链接（"a pull request that will close this issue"），PR 正文一开始只是 issue 内容的复制，随着工作推进逐渐长成任务计划清单，逐项打勾。像盯同事的分支一样盯着它就行。
时间线里的 linked-pull-request 事件，直指新开的 draft PR。视频 5:31 处观看 - 9
读 Copilot 写的 PR 说明
会话结束后，这份 draft PR 读起来就像出自靠谱同事之手："Copilot wants to merge 3 commits into main from copilot/fix-5-4"，What's Added 一节拆出核心实现、UI 集成、系统集成三块，还有 Connection String Format 专节。侧栏显示 "Copilot is done——completed after 8m 14s"。这次运行端到端约九分钟。
Draft PR 自写的说明，侧栏标注完成耗时。视频 5:38 处观看
评审、迭代、合并
- 10
检查 Files changed diff
Files changed 标签里是 agent 的全部提交：这里共六个文件，包括新增的 SnowflakeDatabaseService.cs——119 行绿色新增代码，文件头注释标注由 AI 生成——csproj 里加上的 NuGet 包，以及和 Oracle、PostgreSQL、SQL Server 兄弟服务一样注册进依赖注入的服务。像看同事的 PR 一样逐行看。
14 号 PR 的 Files changed：六个文件和新生成的服务。视频 12:15 处观看 - 11
Copilot 请求评审时出手
跑完会通知你——页面顶部横幅写着 "Copilot requested your review on this pull request"，旁边是 Add your review 按钮。可以逐行评论，也可以走正常 code review 流程；Copilot 会接下有 write 权限者的评审评论和 @copilot 提及，把新提交推到同一个 PR。由于它记得同一 PR 上此前几轮的上下文，越改越快。
评审请求横幅下方，是 Copilot 自己写的改动摘要。视频 9:38 处观看 - 12
像普通 PR 一样合并
diff 没问题就正常 merge。合并框还会贴心提醒后果："Successfully merging this pull request may close these issues"——并列出 agent 当初参考的那条 Snowflake feature request。审批权在人：agent 永远不会自己 merge，它触发的 CI 也可能要先点 "Approve and run workflows" 才会执行。
合并框把 PR 关联回最初的那条 issue。视频 12:45 处观看 - 13
用 copilot-instructions.md 驯化后续运行
想立长期规矩，就加一个 .github/copilot-instructions.md——写清代码约定、build/test/lint 步骤、仓库结构。GitHub 官方示例放了 Code Standards 和以 npm run lint 开头的 Required Before Each Commit 清单；Code Wolf 的演示要求详尽且标注 AI 生成的注释，下一份生成 diff 就照做了。Notion、Linear、数据库这类 GitHub 之外的工具，通过仓库 Copilot 设置页配置 MCP server 接入。
copilot-instructions.md：写进文件的代码规范，agent 会照办。视频 0:47 处观看
前置条件：计划档位、权限与启用开关
挡在「Assignees → Copilot」选项前的有三道门。第一道是档位：按 GitHub 官方文档的说法，"Copilot cloud agent is available for all paid Copilot plans"——Pro、Pro+、Business、Enterprise 均可。免费版账号的 assignees 列表里完全不会出现 Copilot，这是「找不到这功能」最常见的原因。
第二道是启用状态。个人账号查 Copilot 设置的功能页（github.com/settings/copilot/features），侧栏 Copilot 分组下有 Coding agent (Preview)。Business 和 Enterprise 则如文档所说 "an administrator must enable the relevant policy"——管理员不开策略，组织里谁都看不到这个选项；组织仓库里找不到它，找管理员，不是 bug。
- 1付费 Copilot 计划（Pro、Pro+、Business 或 Enterprise）——免费版没有指派给 Copilot 的选项
- 2对目标仓库有 write 权限——只能选到你可写且已启用 cloud agent 的仓库
- 3agent 已启用：个人账号看 github.com/settings/copilot/features，Business/Enterprise 看组织策略
- 4仓库可用 GitHub Actions——agent 跑在 Actions 驱动的临时环境里；Enterprise Managed Users 无法在个人仓库使用
第三道是运行规则：指派功能处于 public preview；每个会话在 GitHub Actions 临时环境中执行，硬上限 59 分钟；沙箱默认有防火墙，外网访问受限。卡死的会话超时后，解法就是取消指派再重新指派一次。
Session logs：怎么围观一个后台 agent 干活
每个会话留有三处日志。issue 时间线记录指派、Copilot 评论和 draft PR 关联；Actions 标签展示 copilot job 的内部步骤——准备环境、启动 MCP server、处理请求、清理收尾；PR 本身则是 agent 的状态页：正文先是 issue 的复制，随后长成计划清单，做完一项勾一项。
不需要人肉轮询。draft PR 开好、请求评审时 Copilot 都会发邮件；👀 reaction 加 "Copilot has started work" 时间线事件能在几秒内确认会话真的跑起来了。官方文档的 session log 视图更进一步：可以实时跟踪工作过程，甚至从日志里一键打开 PR。
演示里这个中等规模的功能——横跨六个文件的完整 Snowflake 数据库连接器——agent 计时 8 分 14 秒完成，从指派到 issue 上出现 PR 链接约九分钟。简单改动通常几分钟就回；临近一小时还在跑的，按卡死处理，重新指派。
迭代与护栏：评论、instructions 与 MCP
「指派—评审」这套闭环的默认假设是：Copilot 的第一版不会完美。五个杠杆可以在不打开 IDE 的情况下左右产出：
- 1@copilot 评论——在 PR 评论区 @copilot（需 write 权限、仅限 open PR），它会在同一 PR 上开后续会话；单条评审评论可用 Fix with Copilot 派发，多条可批量
- 2copilot-instructions.md——.github/copilot-instructions.md 把代码约定、build/test/lint 命令、提交规矩带进每一次会话；GitHub 官方示例就带了一份 Required Before Each Commit 清单
- 3MCP server——在仓库 Copilot 设置里配置，把 GitHub 之外的工具交给 agent；GitHub Checkout 演示里它就是靠 MCP 读到了 Notion 上的产品需求文档
- 4指派时的 optional prompt——随 issue 一起带给 agent 的上下文、约束和具体要求
- 5Custom agent、模型与 reasoning 选择器——每次会话在指派面板里切换，或在设置里改默认值
护栏始终在你手里：改动被限制在单个仓库内，agent 不能批准或合并自己的作品，它触发的 workflow 要等 "Approve and run workflows"（除非你加了白名单）。你亲手做的 PR 评审是最后一道安全网——合并按钮永远不会长在 agent 手里。