Claude Code GitHub Actions 实战：配置、费用与权限控制

这套流程真正改变的是：谁还需要一直守着任务。过去，开发者得打开仓库、启动 Claude，再把结果带回 GitHub，还得保持本地会话运行。接入 Action 后，维护者只需留下范围明确的请求，稍后回来查看评论或代码修改建议。任务可以在开发者下班后启动，但检查结果所需的时间并不会因此消失。

本文依据 Anthropic 的现行文档编写，核对日期为 2026 年 10 月 15 日。下文的工作流刻意收紧了权限和执行范围，适合作为起步配置，并不意味着所有 Issue 都能在无人值守的情况下解决。

给仓库配一个随叫随到的助手

可以把 GitHub App 理解为门禁卡，工作流是任务单，runner 则是临时工作台。工作流是告诉 GitHub 何时启动任务的配置文件；runner 是实际执行任务的机器。

在 Issue 或 PR 中提及 Claude，就能触发这个 Action；如果提供 prompt，则会变成自动执行的任务。对小团队来说，先用明确的请求探索哪些任务值得交给它，比一开始就为每次变更付费审查更容易找到价值。参见 Action 使用说明。

如何配置 Claude Code GitHub Actions？

拥有仓库管理员权限时，可以使用引导式安装。先通过 gh auth login 为已安装的 GitHub CLI 完成身份验证，在仓库目录中打开 claude，然后运行 /install-github-app。选择工作流，以及 API 密钥或订阅身份验证方式，再创建并合并准备好的工作流 PR。安装在本地完成，后续任务则在 GitHub 上运行。参见官方快速配置指南。

手动配置也能得到相同的结果：

1. 在选定仓库上安装 Claude GitHub App。
2. 打开仓库的 Settings → Secrets and variables → Actions（设置 → 机密和变量 → Actions），从下表中选择一种身份验证方式，添加对应的仓库 Secret。
3. 将 Anthropic 的可用示例复制到 .github/workflows/claude.yml，选择与 Secret 对应的身份验证输入参数，然后合并该文件。
4. 留下一条包含 @claude 和具体请求的评论。

以上沿用官方手动配置步骤，并明确列出了凭据选项。参见 Action 配置指南。

如果使用订阅，在本地运行 claude setup-token，将输出保存为 Secret。Anthropic 的文档列出了 Pro、Max、Team 和 Enterprise 套餐对这种方式的支持。生成的令牌有效期为一年，应明确由谁负责续期。参见令牌身份验证。

**计费方式由凭据决定：**使用 API 密钥的任务按 API 计费；使用 OAuth 令牌的任务消耗 Claude 订阅用量，GitHub Actions runner 的用量另行计算。订阅令牌归生成它的个人所有；对于需要在多个仓库间共享的 Secret，Anthropic 建议使用 API 密钥。参见身份验证与费用。

采用默认的 App 配置时，不需要个人 GitHub 访问令牌。GitHub 访问授权与 Claude 身份验证是两回事：前者由 App 提供，后者由所选的 Secret 提供。参见身份验证输入参数。

先从按需触发的小范围工作流开始

这套配置适用于可信团队仓库中的小范围文件修改。它可以读取、编辑文件，并通过 GitHub API 提交变更。由于没有向 Claude 开放 shell 工具，它无法在这套配置下执行测试命令。测试仍交给常规 CI，也就是针对待合并变更运行的自动化检查。

将以下内容保存为 .github/workflows/claude.yml。其中引用的 actions/checkout@v6 和 anthropics/claude-code-action@v1 均出现在 Anthropic 的当前示例中。五轮上限和十五分钟超时是本文选用的起步设置，并非 Anthropic 的默认值。参见官方工作流。

name: Claude on request
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    timeout-minutes: 15
    concurrency:
      group: claude-small-team
      cancel-in-progress: false
    permissions:
      contents: write
      issues: write
      pull-requests: write
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          use_commit_signing: true
          claude_args: |
            --max-turns 5
            --tools "Read,Glob,Grep,Edit,Write"
            --disallowedTools "Bash,WebFetch,WebSearch"

如需使用订阅计费，将 anthropic_api_key 这一行替换为 claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}，只保留一种方式。默认 GitHub App 身份验证需要 id-token: write，请保留这一权限。参见官方工作流与身份验证、输入参数参考。

这些控制项各有分工：

• --tools 决定 Claude 可以使用哪些内置工具。Read、Glob 和 Grep 用于查看文件，Edit 和 Write 用于修改文件。它不会限制 MCP 工具；后者是单独连接的工具，Action 通过它们与 GitHub 交互。
• --allowedTools 允许指定工具无需询问即可使用，但它并不是完整的工具白名单。这里通过显式设置 --disallowedTools 禁用 shell 和网页工具。
• --max-turns 限制智能体的工作轮数，不限制 token 数量或美元费用。达到轮数上限时，任务可能以错误结束，工作也可能尚未完成。参见 CLI 参考。

use_commit_signing: true 让提交经由 GitHub API 完成。因此，即使没有向 Claude 开放基于 shell 的 git 命令，这套配置也能保存变更，而且不需要额外的签名 Secret。Action 的 GitHub 工具仍然可用，所以这套配置具备写入能力。参见提交签名、Action 实现。

固定的并发组让每个仓库同一时间只能运行一个来自此工作流的任务。在默认排队机制下，新进入等待状态的请求可能替换较早的待执行请求，因此不能把它当作持久化任务队列。超时设置限制的是任务经过的总时间，包括准备阶段。参见 GitHub 并发控制、工作流语法。

可以试试 @claude review this PR for missing permission checks; report findings without changing files。针对 Issue，可以试试 @claude fix the null handling described above, change only the parser and its regression test, and state which checks were not run。

默认情况下，触发者需要拥有仓库写入权限，机器人触发会被拦截。针对 Issue 修复，应预期得到一个分支，以及供人工创建 PR 的链接。团队使用说明中应写清这一点。参见 Action 安全说明。

试用有效后，再接入自动代码审查

在 /install-github-app 安装过程中选择审查工作流，即可配置自动 PR 审查。其代码审查插件通过 --comment 和下方的评论工具授权发布发现的问题。参见官方审查示例。

在这个独立的审查工作流中，Action 的输入参数包括：

plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
plugins: "code-review@claude-code-plugins"
prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
claude_args: >-
  --max-turns 5
  --allowedTools "mcp__github_inline_comment__create_inline_comment"

这些输入参数应放在官方的 pull_request 工作流中，不适用于上面的提及触发工作流。保留官方工作流的检出步骤、身份验证和任务权限，添加任务超时，并使用 if: github.event.pull_request.head.repo.full_name == github.repository 跳过来自 fork 的 PR。轮数上限应视为试运行设置：审查耗尽轮数，就意味着审查尚未完成。文档中的审查技能还会跳过部分 PR，包括草稿。

安装范围和工具权限，要分别控制

先只在选定的仓库上安装。官方 Claude App 的权限由多项 Claude 功能共用，GitHub 不允许只接受其中一部分。YAML 中较小的 permissions 配置块，并不会缩小 App 安装时获得的权限范围。参见 App 权限模型。

如果默认 App 的安装权限过宽，可以按文档创建自定义 App，授予 Contents、Issues 和 Pull requests 访问权限。这种方式需要增加 APP_ID 和 APP_PRIVATE_KEY 两个 Secret，并增加一个步骤来创建 App 令牌，将其作为 github_token 传入。对于准备移除静态 Claude API 密钥的团队，配置指南还介绍了工作负载身份联合验证：用 GitHub 任务身份换取短期 API 访问凭据。参见自定义 App 与联合验证配置。

添加一份简洁的 CLAUDE.md，写明审查重点、允许修改的范围，以及修复必须提供哪些证据。指令负责引导工作，仓库权限和工具限制负责约束访问。启用无人值守运行前，应审查已配置的 hooks（在生命周期事件发生时自动执行的命令），以及额外的工具服务器。参见项目指令。我们的 Claude Code 评测指南讨论了更全面的选用考量，斜杠命令指南则解释了配置时会用到的命令。

六类值得尝试的任务，按这个顺序推进

先挑选容易说清楚、结果也容易核验的任务。以下是工作流建议，不代表经过测量的效率收益，也不是效果保证。

起步配置无法安装依赖，也无法运行测试套件。如果任务需要这些能力，应针对可信代码增加一套经过单独审查的执行配置，明确允许的命令，并设置独立的限制。即使测试命令获得了许可，执行的仍然是仓库代码；命令名称看起来无害，并不代表代码安全。

增加触发条件前，先排除这些故障

来自 fork 的 PR 可能无法读取 Secret。 对由 fork 触发的 pull_request 和 pull_request_review_comment 运行，GitHub 通常不会提供 Secret。这类任务中的 Claude 凭据为空，是信任边界在起作用。不要为了拿到 Secret，就改用 pull_request_target 并执行 fork 中的代码。由维护者触发的 issue_comment 任务也可能拿到 Secret，因此评论者可信，并不等于 PR 中的文件可信。参见 GitHub 的 fork 安全指南。

限制工具，不能消除项目启动代码的风险。 Action 会从基准分支恢复部分 Claude 配置，但脚本和其他项目文件仍可能来自 PR。除了 Claude 获准使用的工具，还要审查 hooks 和工具服务器配置。参见 Action 的信任边界。

Runner 运行时间仍需单独管理。 公共仓库使用标准 GitHub 托管 runner 免费。私有仓库受套餐额度限制，超额部分付费；额度耗尽且未配置付款方式时，任务可能停止。查看 Claude 用量时，也要一起查看 Actions 用量页面。参见 GitHub Actions 计费说明。

配置正确，也可能因速率限制而中断。 API 按分钟限制请求数，以及输入和输出 token 数；token 是模型处理的文本片段。遇到带有 retry-after 的 429，应等待后再重试，并减少同时运行的任务。如果 429 是由用量层级的支出上限引起，且没有该响应头，就需要处理计费或限额问题，反复重跑没有用。使用订阅进行身份验证，同样受套餐用量限制。参见 API 速率限制、Claude 用量限制。

机器人没响应，与后续 CI 没运行，是两类故障。 如果没有响应，检查默认分支上是否存在该工作流、Actions 是否启用、Secret 是否与输入参数匹配，以及评论者是否拥有写入权限。提及时要完整写出 @claude。如果后续 CI 没有启动，检查是否有人把 App 身份验证替换成了 github_token: ${{ secrets.GITHUB_TOKEN }}：GitHub 会抑制该令牌产生的许多事件，而且部分 PR 工作流需要批准后才能运行。参见 GitHub 令牌行为。

围绕这套流程，可以做哪两类产品？

最值得尝试的是面向小团队的代码审查配置与托管服务。 潜在买家是希望审查发现有价值、责任归属清晰、运行限制可预期的工程负责人。2026 年 10 月 15 日获取的 DataForSEO 美国英语市场估算显示，“ai code review”的月搜索量为 1,300。这能说明有人关注，并不代表客户数量。可售卖的首版服务可以包括：配置一个仓库、写明审查重点、用历史 PR 评估审查结果，并持续提供用量与故障报告。难点在于误报会消耗团队耐心；真正需要长期投入的，是在代码库不断变化时维持审查质量。单纯包装一个通用提示词，很难给客户持续使用的理由。

技术服务公司可能需要一套能复用到客户仓库的审查策略包。 在同一市场中，DataForSEO 对“ai code review tools”的估算为每月 590 次搜索，对“github ai code review”的估算为 140。最小可用产品可以组合可复用的工作流、按客户定制的指令模板、凭据责任人记录，以及运行限制缺失检查，帮助服务团队在项目交接时维持一致的配置。难点是每个客户的权限和测试环境都不同，模板必须持续维护和评估才有价值。这些搜索词的受众存在重叠，不能把搜索量相加当作市场规模。

GitHub Actions、云端会话和定时任务，怎么选？

如果任务由仓库事件驱动，而且团队希望将配置、权限和日志纳入 CI 一起管理，选择 GitHub Actions。如果是一次性任务，希望合上电脑后仍能通过浏览器发起并指导执行，选择云端会话。如果任务需要保存并反复运行，例如每晚检查待办事项，而你更愿意使用 Claude 托管的调度和配置，不想维护工作流 YAML，可以选择定时例行任务（routine）。Routines 也支持 GitHub 和 API 触发，因此有调度需求并不意味着必须使用 Actions；routines 仍处于研究预览阶段。参见云端会话、routines。

周一可以先让仓库管理员安装 App，并合并这套带有限制的工作流。给它一个已知 bug，再发起一次范围明确的审查请求，将输出与团队自己的判断对照。只有当结果值得投入相应的注意力和用量时，再增加触发条件。

如果希望为团队搭建并维护这套工作流，可以寻求 AI 自动化服务。