Linear Issue 直达 Draft PR：Copilot Cloud Agent 正式可用后的协作边界

GitHub 于 2026 年 7 月 23 日宣布 Copilot cloud agent for Linear 正式可用。GitHub 官方公告描述了一条从项目协作到代码交付的异步链路：团队把 Linear Issue 分配给 Copilot，Agent 读取任务上下文，在独立临时环境中工作，创建 Draft PR，并把进度与完成通知回传到 Linear。

这项变化的意义不是把 Issue 自动变成“完成的功能”，而是把任务分派、后台执行、PR 交接放进同一条可追踪流程。真正的交付仍发生在 GitHub Pull Request 中，现有评审、测试和合并规则不会因为入口来自 Linear 而消失。

从 Issue 到 Draft PR 的链路已经可以异步运行

被分配任务后，cloud agent 会分析 Issue 内容并创建 Draft PR，在由 GitHub Actions 支持的临时开发环境中探索代码、修改文件，并可运行自动测试与 lint。执行进度会写回 Linear 的 Activity 时间线，完成后再请求人工审查。

GitHub cloud agent 概念文档说明，这类第三方集成直接以创建 Pull Request 为目标；在 GitHub.com 上先研究、规划、反复讨论再决定是否建 PR 的能力，并不等同于 Linear 集成中的默认流程。cloud agent 还被限制在一次任务指定的仓库和一个工作分支内，每个任务只创建一个 Pull Request。

模型、Agent 与分支可以按 Issue 或工作区控制

正式可用版本允许团队在 Linear 中选择任务使用的模型、指定仓库内的自定义 Agent、设置目标 base branch 与工作分支，并在执行中通过评论继续引导。重复规则可以写入 Linear agent guidance，在工作区或团队范围统一设置默认仓库、首选模型、自定义 Agent 和分支命名习惯。

GitHub 的 Linear 集成文档进一步说明，agent guidance 会在每次触发时自动传给 cloud agent。它适合固定交付约束，但仍属于提示上下文，不应被当成分支保护、必需检查或仓库权限的替代品。

base branch 与 working branch 控制解决的是“改动提交到哪里”和“PR 面向哪里”，并不授予合并权，也不会自动满足代码所有者审批或 CI 检查。团队应把这些 GitHub 门禁继续留在 PR 端，让 Linear 负责分派与回传，而不是让项目管理入口承担代码仓库的最终授权。

安装与触发条件决定了谁能启动任务

安装 GitHub Copilot for Linear App 需要 GitHub 组织或企业所有者权限，以及 Linear workspace admin 权限。App 在组织内安装一次后，成员仍需要连接自己的 GitHub Copilot 账号。Copilot cloud agent 适用于 Copilot Pro、Pro+、Business 与 Enterprise 等付费计划；Business 或 Enterprise 环境还可能要求管理员启用相应策略。

第一次从 Linear 使用时，用户要选择 cloud agent 操作的 GitHub 仓库。只有对该仓库有写权限的用户才能触发 Agent；没有写权限的 Issue 参与者仍可通过评论补充上下文，但不能启动该仓库中的 cloud agent 任务。这个边界意味着团队不能只审核“谁能编辑 Linear Issue”，还要核对 GitHub 写权限和 Copilot 策略。

GitHub cloud agent 文档还说明，后台任务会消耗 GitHub Actions 分钟和 AI credits；在套餐包含额度内不一定产生额外费用，但这不等于任务没有资源成本。团队在扩大 Linear 自动分派前，应同时记录任务失败重试、Actions 用量与 AI credits，避免只看节省的界面切换。

Issue 描述与评论会进入执行上下文

官方文档明确提示：当用户在 Linear Issue 中提及 @GitHub 或把 Issue 分配给 Copilot 时，Agent 会把完整 Issue 描述和评论作为请求上下文，并把这些上下文存入 Pull Request。对包含客户信息、内部链接、访问凭据或尚未公开产品计划的 Issue，这不是普通的界面便利，而是数据流边界。

因此，接入前至少应建立三条规则：

1. 明确哪些 Issue 可以交给 Agent，敏感字段在分配前如何移除或替换。
2. 把 acceptance criteria、目标仓库、base branch 和不可修改范围写进 Issue 或 guidance。
3. 把 Draft PR 当作待验证交付，要求测试、权限检查、代码所有者评审和人工合并。

这些是基于官方流程给出的治理建议，不代表本稿已经在真实 Linear workspace 中完成实测。

“可追踪异步协作”不等于“无需人工交接”

Linear 集成减少了复制 Issue、创建分支、启动后台任务和追踪进度的切换成本，也让任务上下文与 Draft PR 建立可见连接。但公告没有提供代码正确率、一次通过率、节省工时或业务结果数据。

团队更适合从低风险、范围清晰、能自动测试的 Issue 开始，记录 Agent 是否理解需求、PR 是否通过检查、人工修改量和从分配到可评审的时间。只有这些真实数据，才能判断异步链路是否改善交付；GA 证明的是产品入口与控制项正式可用，不是每个 Issue 都适合无人值守执行。