07 · Cloud Agent 到 PR 的闭环
解释 Cloud Agent 如何从 prompt 或 issue 出发，研究仓库、建分支、改代码、给出 diff 并进入 PR 审查。
📖 本篇术语速查表
| 英文 / 缩写 | 中文 | 一句话解释 |
|---|---|---|
| Cloud Agent | 云端代理 | 在云端异步跑、直接产出 PR。 |
| PR 闭环 | pr loop | 从任务到 PR 再到审查合并。 |
| 人工把关 | gate | PR 由人审查后合并。 |
不想读完？把下面这段提示词丢给 AI 帮你跑完——帮你用 Copilot Cloud Agent 跑通从任务到 PR 的闭环。
你是 Copilot Cloud Agent 顾问。
【角色】
Copilot Cloud Agent 顾问，按最小够用、安全优先的原则给可落地方案，每条结论都落到能照做的步骤或示例，不停留在空泛建议。
【输入】
- 想让它异步完成什么任务：___
- 涉及的仓库和分支：___
- 团队的 PR 审查流程：___
- 权限要求：___
- 经验水平：___
【工作流程】
1. 判断任务适不适合云端异步
2. 说明任务到 PR 的流程
3. 强调 PR 必须人工审查
4. 按最小给权限
5. 给验证
【输出规范】
▌一、是否适合云端异步
▌二、任务到 PR 流程
▌三、PR 人工审查
▌四、权限 + 验证
【硬约束】
- 云端产出的 PR 必须人工审查后合并
- 权限按最小必要
- 异步任务设计成低介入
- 不要替我臆测情况或编造不存在的能力，信息不全先问清
- 不确定的配置或接口一律以官方文档为准，禁止照搬过时写法Cloud Agent 最适合的不是你盯着屏幕等三分钟的小改，而是可以异步推进、最后回到 branch 和 PR 审查的仓库任务。GitHub 官方说明，Copilot cloud agent 能完成"研究仓库 → 制定实现计划（implementation plan）→ 在分支里改代码"这条链路，并在你准备好时创建 pull request。
本章目标：你会把 Cloud Agent 当成 GitHub PR 工作流的一部分使用，而不是当成一个“帮我自动写完”的黑箱。
1. PR 闭环
flowchart TD
Source["Issue / Prompt / Agents tab"] --> Research["Research repository"]
Research --> Plan["Implementation plan"]
Plan --> Branch["Agent branch"]
Branch --> Diff["Diff / commits / test output"]
Diff --> Iterate{"需要继续改?"}
Iterate -->|是| FollowUp["Follow-up prompt"]
FollowUp --> Branch
Iterate -->|否| PR["Create pull request"]
PR --> Review["Human review / checks"]
Review --> Merge{"通过?"}
Merge -->|是| Ship["Merge"]
Merge -->|否| More["Comment / request changes"]
More --> Branch这个闭环里，Cloud Agent 的产物不是“回答”，而是可审查的 branch、commits、diff、checks 和 PR 讨论。
2. 两种启动方式
官方启动任务页有一个重要分工：
- Assign issue to Copilot（把 issue 直接指派给 Copilot）：适合 issue 已经写清目标、范围和验收标准；Copilot 会基于 issue 标题、描述和已有 comments 工作，并创建 PR 或请求 review。
- Agents prompt / Agents tab（在 Agents 标签页里发起 prompt）：适合任务还需要研究和迭代；默认先在 branch 上工作，你可以 review diff、继续追加 prompt，然后再决定是否创建 PR。
一个容易踩的坑：issue assignment 后新增到 issue 的 comments，Copilot 不一定自动看到。后续上下文要写到它创建的 PR 或 session 里。
3. Prompt 要像 issue spec
Cloud Agent prompt 不应该是“帮我优化一下”。它至少要包含四件事：
目标：
修复登录错误提示不清楚的问题。
范围：
只处理 Web 登录页和 auth 错误映射。
不要改：
认证协议、数据库 schema、billing、workflow。
验证：
运行 auth 相关测试，说明未覆盖风险。如果任务包含 UI 差异，可以附 screenshot 或 mockup。上传前要遮住账号、客户数据、token、内部 URL 和生产信息。
4. Research、Plan、Iterate
Cloud Agent 的高质量用法不是直接 PR，而是先 research、plan、branch iterate，再 PR。
Research 阶段：
- 让它列相关文件、测试、入口和不确定点。
- 明确“不要改代码”。
- 检查它是否读到了正确模块。
Plan 阶段：
- 看目标和非目标是否清楚。
- 看文件范围是否合理。
- 看测试命令是否真实存在。
- 看开放问题是否需要你回答。
Iterate 阶段：
- 审 branch diff。
- 要求撤销无关改动。
- 补测试或收窄范围。
- 准备好后再创建 PR。
5. 什么任务适合 Cloud Agent
适合：
- backlog 里的中低风险改进。
- 文档、测试、技术债、错误提示。
- 能通过 branch、CI、PR review 验收的小功能。
- 需要先读仓库再给方案的任务。
不适合：
- 本地未提交现场。
- 必须依赖本机登录态、私密 UI 或本地环境。
- 生产部署、数据迁移、权限调整。
- 没有测试和 review 路径的模糊需求。
Cloud Agent 在 GitHub Actions 驱动的临时开发环境中运行，但临时环境不等于没有风险。它仍然可能改 workflow、依赖、权限配置或业务逻辑。
6. 审查清单
PR 出来后，至少检查：
- 是否符合 issue 或 prompt 的范围。
- 是否新增依赖、workflow、权限或配置。
- 是否删除测试或跳过失败。
- commit 和 diff 是否可理解。
- checks 是否跑过并通过。
- Copilot 的说明是否和代码一致。
- 是否需要人工补充测试或回滚说明。
Cloud Agent 能提高异步吞吐，但不能替代代码负责人。
本章自检
你应该能回答：
- 这个任务应该 assign issue 直接 PR，还是先 prompt 到 branch 迭代？
- prompt 是否写清目标、范围、不可触碰内容和验证方式？
- PR 前是否已经审过 branch diff 和测试输出？
- 失败时能否关闭 PR 或人工接管分支？
通过标准：Cloud Agent 的每一步都能被 GitHub 对象追踪，而不是只靠自然语言总结。
官方来源
- About GitHub Copilot cloud agent：官方 cloud agent 能力、运行环境和适用边界。
- Kick off a task with Copilot agents on GitHub：官方任务启动入口、issue assignment 和 prompt 分工。
- Research, plan, and iterate on code changes with Copilot cloud agent：官方 research、plan、iterate、PR 流程。
- Responsible use of GitHub Copilot cloud agent：官方 responsible use 和安全边界。