Cloud agent 试点与保护规则
准备范围明确的仓库试点，核对 rulesets、runner、秘密与 workflow 审批，再逐步扩大。
组织试点应先验证 cloud agent 是否适合现有流程。官方建议选择明确、范围有限的任务，例如补测试、修复小型缺陷或偶发失败、更新配置和文档，由团队审阅代理提出的 PR。
准备试点范围
选择跨角色的参与者，以及隔离或风险较低、但具有真实项目上下文的仓库。全新空仓库也需要补充团队约定、依赖和环境信息，否则无法代表实际工作。
确认成员与企业 Agent 开关和仓库访问，然后准备仓库指令、开发环境与验收步骤。试点期间记录 AI credits 和 GitHub Actions minutes，费用应按计费与预算的实际规则评估。
先审阅保护规则
cloud agent 已有限制直接推送默认分支和合并 PR 等保护措施，同时受仓库 rulesets 约束。可根据仓库风险增加必要的扫描与质量检查，但也要判断规则是否会无意阻止代理工作。
使用 CODEOWNERS 保护重要的 Copilot、MCP 和 setup 配置文件，并启用 Require review from Code Owners。仅添加 CODEOWNERS 文件，不等于所有修改都必须经对应团队批准。
官方特别指出，自带模型 API Key 的 Custom models 政策与 Private MCP registries 政策不适用于 cloud agent。不要以客户端配置页中存在同名功能为依据，推断云端已经执行相同控制。
核对 runner、秘密与 workflow
| 项目 | 试点前检查 |
|---|---|
| Runner | 官方建议 GitHub-hosted runners；使用 self-hosted 时建议 ephemeral runners |
| 代理所需凭据 | 使用 Agents secrets/variables，并核对仓库范围 |
| 不提供给代理的值 | 区分 Actions 与 Agents 类型，避免误放到代理可读取的位置 |
| PR workflow | 默认需要有 write 权限的人批准后运行；仓库管理员可以调整此设置 |
| Setup token | 检查 setup workflow 的 GITHUB_TOKEN 权限，采用所需的最小范围 |
GITHUB_TOKEN 的企业默认权限政策会影响 copilot-setup-steps.yml 的初始化步骤，不等同于改变 cloud agent 会话自己的 token。具体配置见环境准备、运行器和Agents Secrets。
在试点中迭代
给 Issue 写清目标、上下文与验收条件，分配给 Copilot 后由成员审阅改动并提出反馈。持续记录哪些失败源于任务描述、缺少工具、环境准备或上下文访问，再分别改进对应配置。
需要外部信息时才增加经批准的 MCP 接入。内置 GitHub MCP 提供工作仓库的上下文，并不自动打通其他系统的身份认证或网络限制。
试点达到预先定义的目标后，再扩大仓库与参与范围，并继续收集反馈。cloud agent 的小范围仓库试验与企业新功能试点侧重点不同：前者先建立可靠任务流程，后者还需验证许可、政策与完整计费周期。