{"meta":{"title":"授予 GitHub Copilot 云代理访问组织中的资源的权限","intro":"通过允许其访问已获批准的 MCP 服务器和内部包，充分利用 Copilot。","product":"GitHub Copilot","breadcrumbs":[{"href":"/zh/copilot","title":"GitHub Copilot"},{"href":"/zh/copilot/tutorials","title":"教程"},{"href":"/zh/copilot/tutorials/cloud-agent","title":"云代理"},{"href":"/zh/copilot/tutorials/cloud-agent/give-access-to-resources","title":"授予对资源的访问权限"}],"documentType":"article"},"body":"# 授予 GitHub Copilot 云代理访问组织中的资源的权限\n\n通过允许其访问已获批准的 MCP 服务器和内部包，充分利用 Copilot。\n\nCopilot cloud agent 可以连接到 MCP 服务器、使用专用包和访问外部服务，但前提是组织的存储库配置为允许它。\n\n尽管下面的大部分配置是在存储库级别完成的，但组织所有者可以控制哪些资源在范围内，以及谁可以配置对这些资源的访问权限。\n\n## 示例方案\n\n组织使用 Sentry 跟踪 Node 应用中的 bug。 新的异常会以议题的形式在 GitHub 上创建，而你的开发人员希望将这些议题分配给 Copilot。\n\n你想要 Copilot ：\n\n* 连接到 Sentry MCP 服务器，以便它可以访问 Sentry 实例的详细信息\n* 安装依赖项（包括托管在上的 GitHub专用包）以生成应用并运行测试\n* 遵循组织的错误处理约定\n\n## 安全地存储机密\n\n默认情况下，身份验证令牌的范围 Copilot仅限于正在运行的存储库。 这意味着 Copilot 无法向外部系统进行身份验证或访问专用组织范围的包。\n\n若要提供 Copilot 对机密的访问权限，存储库管理员可以配置代理机密。 组织所有者还可以在组织级别添加代理机密，以跨多个存储库共享配置。\nCopilot 可以在其设置和执行任务期间访问此数据。 它将无法访问GitHub Actions、Codespaces或Dependabot的机密和变量。 有关详细信息，请参阅“[为 Copilot 云代理配置机密和变量](/zh/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/configure-secrets-and-variables)”。\n\n### 示例：保存机密\n\n存储库管理员保存组织的 Sentry 实例的身份验证令牌。\n\n1. 转到存储库设置的 **“机密和变量** > **代理** ”部分。\n2. 将 Sentry 实例的访问令牌保存在名为 `COPILOT_MCP_SENTRY_ACCESS_TOKEN` 的机密中。\n\n> \\[!TIP] 我们不需要为专用 GitHub Packages 注册表保存令牌，我们将使用标准 GitHub Actions`GITHUB_TOKEN`对其进行访问。 但是，如果您使用外部包管理系统，您需要保存身份验证令牌。\n\n## 配置对 MCP 服务器的访问\n\n组织和企业所有者可以设置一个策略，以允许用户配置对 MCP 服务器的访问。 如果启用此策略，用户可以在存储库设置或自定义代理配置文件中配置 Copilot cloud agent MCP 服务器。 对于组织范围的一致性，我们建议在组织或企业级创建自定义 **代理配置文件** 。\n\n使用自定义代理的会话可以访问存储库设置和代理 **配置文件中配置的** MCP 服务器。 但是，在组织范围的自定义代理中涵盖的用例越多，用户就越不需要在存储库设置中配置对 MCP 服务器的即席访问。\n\n建议浏览 [GitHub MCP 注册表](https://github.com/mcp) 以查找受信任的高度分级的选项。\n\n### 示例：创建自定义代理\n\n组织所有者为 Sentry 代理创建自定义代理配置文件。 它能够访问 Sentry MCP 服务器，并能获取有关组织错误处理惯例的定制指南。\n\n1. 在你的组织中创建一个命名为`.github-private`的存储库。 （可选）企业所有者可以将此存储库设置为企业中所有自定义代理的源。\n\n2. 在存储库中，添加一个 `agent.md` 文件，其内容类似于以下配置文件。 这包括 MCP 服务器的配置，该服务器引用了我们保存的机密。\n\n   ```text\n   ---\n   name: sentry-error-fixer\n   description: Proposed fixes for exception issues raised from Sentry\n   mcp-servers:\n     sentry:\n       type: 'local'\n       command: 'npx'\n       args: ['@sentry/mcp-server@latest']\n       env:\n         SENTRY_ACCESS_TOKEN: ${{ secrets.COPILOT_MCP_SENTRY_ACCESS_TOKEN }}\n   ---\n\n   You are an error resolution specialist. When you're assigned an issue created by our Sentry integration, check for error details and stack traces using the MCP server, then propose a fix.\n\n   Make sure you check that your proposed fix works by building the site with `npm run build` and running the test suite in `npm test`.\n   ```\n\n3. 当开发人员将问题分配给Copilot时，他们可以从下拉列表中选择一个自定义代理。\n\n## 安装专用包\n\n让 Copilot 访问项目依赖项的最佳方式，是通过 `copilot-setup-steps.yml` 工作流文件来安装它们。 此文件定义在开始工作之前 Copilot 如何设置环境。\n\n若要允许工作流拉取您私有且限定于组织的包，需要更新包设置，以确保存储库 `GITHUB_TOKEN` 能访问该包。 这比使用具有组织权限的长期持久性 personal access token 更安全。\n\n### 示例：安装节点依赖项\n\n开发人员创建一个工作流，用于安装存储库 `package-lock.json` 文件中定义的 Node 依赖项。 这包括托管在 GitHub 上的私有、组织范围的包。\n\n1. 开发人员在存储库中创建文件 `copilot-setup-steps.yml` 。\n\n2. 添加用于安装项目依赖项的步骤。 例如：\n\n   ```yaml\n   # ...\n\n   jobs:\n     copilot-setup-steps:\n       # ...\n\n       # You can define any steps you want, and they will run before the agent starts.\n       # If you do not check out your code, Copilot will do this for you.\n       steps:\n         - name: Checkout code\n           uses: actions/checkout@v6\n\n         - name: Set up Node.js\n           uses: actions/setup-node@v7\n           with:\n             node-version: \"20\"\n             cache: \"npm\"\n\n         - name: Install JavaScript dependencies\n           run: npm ci\n   ```\n\n3. 组织管理员通过在每个包的设置中授予存储库访问权限，以确保存储库可以访问组织的私有包。 请参阅“[配置包的访问控制和可见性](/zh/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#github-actions-access-for-packages-scoped-to-organizations)”。\n\n> \\[!TIP] 如果需要访问内部企业网络中托管的包，您可能需要在自托管的 Copilot cloud agent 运行器上运行 GitHub Actions。\n\n## 控制谁可以配置这些设置\n\n现在，你已经了解了如何在存储库和组织级别控制对资源的访问，请考虑要为用户提供多少范围来管理这些设置。\n\n1. **选择哪些存储库有权访问**Copilot cloud agent。 如果您担心特定存储库，您可以阻止所有用户访问它。\n2. **请考虑谁获取** 对这些存储库的管理员访问权限。 可以通过创建具有 **All-repository 管理员** 自定义角色的团队，在组织级别控制这一点。 这些用户将能够管理每个存储库中的配置 *设置*，例如 MCP 配置和代理机密和变量。\n3. **使用规则集和 CODEOWNERS 文件**来控制配置文件的编辑，例如\\_\\_。默认情况下，具有写入访问权限的任何人都可以编辑这些文件。\n4. **查看默认防火墙**。 防火墙不会影响到 MCP 服务器的连接或设置步骤 `copilot-setup-steps.yml`，但它确实限制了 Copilot在任务执行期间对 Internet 的访问。 请参阅“[自定义或禁用GitHub Copilot的防火墙](/zh/copilot/how-tos/copilot-on-github/customize-copilot/customize-the-firewall)”。\n5. **定义插件标准**。 插件是可安裝的包，可通过重用代理、技能、钩子和集成来扩展Copilot。 您可以控制企业的 `managed-settings.json` 文件中允许使用哪些插件和应用市场。 请参阅“[关于企业管理的插件标准](/zh/copilot/concepts/agents/about-enterprise-plugin-standards)”。"}