GitHub Copilot Automations 怎样设置每次运行的 AI 额度上限

如果你给 GitHub Copilot Automations 配了定时触发器或事件触发器，最容易失控的不是“能不能跑”，而是一次运行会消耗多少 AI credits。直接做法是：编辑自动化时展开 AI credit limits，先设置 Per run，再根据运行频率补充 Daily、Weekly 或 Monthly。其中 Per run 最低为 30 AI credits，达到阈值时会停止当前运行；周期限额达到后，只会阻止新的运行启动。

官方地址：https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/create-automations

更新说明：https://github.blog/changelog/2026-10-28-new-tools-triggers-and-cost-controls-for-copilot-automations/

想限制单次任务成本，就设置 Per run；想限制一天、一周或一个月能启动多少次，就配置对应周期限额。两者要配合使用，不能互相替代。

先把四种限额看成两道闸门

Copilot Automations 的额度设置可以分成“当前运行闸门”和“后续启动闸门”。Per run 绑定一次具体执行：当这次运行达到设定值，运行会停止。Daily、Weekly、Monthly 绑定时间窗口：达到窗口预算后，系统不再启动新的运行，但已经开始的运行不会因为周期额度刚好用完而被中途切断。

第一步：先确认自动化由谁承担额度

创建自动化时，先选择它是 Personal 还是 Shared。Personal 自动化只有创建者可见，AI credits 计入个人；Shared 自动化对有权限访问仓库的人可见，额度计入仓库所有者或组织。这个选择会影响后续预算归属，而且创建完成后不能再改类型。

因此，个人调试用的小自动化可以先选 Personal；面向团队的 issue 分类、拉取请求整理或定时检查，应该先确认仓库所有者是否接受这笔预算，再选 Shared。不要只盯着单次上限，却忘了自动化可能被多人或高频事件触发。

第二步：在创建或编辑页面展开 AI credit limits

在仓库的 Agents 或 Automations 页面创建、编辑自动化，先填写名称、类型、触发器和 prompt，再选择真正需要的工具。工具范围直接影响 Copilot 能做什么，也会影响一次任务需要多少推理和操作。GitHub 的官方流程把 AI credit limits 放在自动化配置中，创建后也可以重新编辑。

配置顺序可以压缩成下面四个判断：

1. 触发器是不是高频事件，例如每次 issue 更新都触发。
2. prompt 是否要求读取大量上下文、反复修改或调用多个工具。
3. 工具是否超过任务所需范围，是否真的需要推送代码或创建拉取请求。
4. 额度是按个人承担，还是由仓库所有者承担。

第三步：设置 Per run，给单次任务设硬边界

在 AI credit limits 区域填写 Per run。官方要求最低值为 30 AI credits；空着表示不设置这项上限。刚开始可以按任务复杂度分档：只做标签判断的自动化设较小值，需要查代码、运行工具并产生改动的任务设更高值，然后通过几次手动运行观察是否经常触顶。

这里的关键是“触顶会停当前运行”。如果 prompt 里写了多个连续目标，达到 Per run 后可能只完成前半段，所以应该把一个自动化的职责收窄。例如先让它分类和补充标签，把代码修改交给另一个有独立额度的自动化，而不是让一次运行同时分析、改代码、运行测试和创建 PR。

# 这是配置思路示例，不是 GitHub API 的可直接粘贴请求
# Per run 负责截断单次运行，数值必须不低于 30
per_run = 60

# 周期限额负责阻止后续启动，按 UTC 窗口计算
daily = 300
weekly = 1200
monthly = 4000

# 单次预算优先于周期预算，用于控制一条任务的最大消耗
if current_run_credits >= per_run:
    stop_current_run()

上面的伪代码只帮助理解边界，真正设置要在自动化的 AI credit limits 区域完成。不要把它当成 GitHub Actions YAML，也不要把 stop_current_run() 当成公开 API。

第四步：用周期限额约束高频触发

如果只设置 Per run，却给自动化绑定了高频事件，很多次合法的小运行叠加后仍可能超过预算。这时补充周期限额。Daily 在每天 00:00 UTC 重置，Weekly 在每周一 00:00 UTC 重置，Monthly 在每月第一天 00:00 UTC 重置。它们的作用是“达到上限后不再开始新运行”，不会中断已经在执行的任务。

配置时可以先用一个简单估算：

# 用预计平均消耗估算周期预算，避免只凭感觉填写
expected_runs = 20
average_credits = 40
buffer = 1.25

# 预算覆盖预计运行量，并保留少量波动空间
daily_limit = int(expected_runs * average_credits * buffer)
print(daily_limit)

如果每天事件次数不可控，周期限额应优先保护预算；如果任务本身容易陷入长链路，Per run 应优先保护单次风险。两者同时设置时，读者要记住它们的时间粒度不同：一次运行触顶是即时行为，周期限额触顶是下一次启动时才生效。

第五步：手动运行一次，检查策略是否和任务匹配

保存自动化后，可以从 Automations 页面手动运行，不必等待事件或计划触发。测试时选择一个真实但低风险的资源，观察它是否能在额度范围内完成预期动作，并确认所选工具没有越过任务边界。

重点看三件事：

• Per run 是否太小，导致每次都在完成主要动作前停止。
• Daily、Weekly、Monthly 是否因为 UTC 重置时间而和团队本地工作日错位。
• Shared 自动化的额度归属是否已经得到仓库所有者或组织认可。

如果一次运行总在边界附近结束，不要第一时间只提高额度。先缩短 prompt、减少工具、拆分职责，再决定是否上调 Per run。这样可以把额度设置变成架构约束，而不是给一个不断膨胀的自动化续费。

常见误区和一张配置清单

误区一：把 Daily 当成单次运行上限。 Daily 不会停止已经开始的运行，单次成本要靠 Per run。

误区二：把空白当成零。官方页面把空白定义为不设置该项，不等于允许一次运行只消耗 0 credits。

误区三：忽略自动化类型。 Personal 与 Shared 的可见范围、操作身份和计费归属不同，预算应该在选类型时一起确认。

误区四：只限制额度，不限制工具。工具越多，任务边界越宽；先选完成目标必需的工具，再用额度做最后一道保护。

相关问题

Per run 最低可以填多少？官方文档给出的最低值是 30 AI credits。

Daily 达到上限会杀掉当前任务吗？不会。Daily、Weekly、Monthly 达到上限后阻止新运行，已经在执行的运行不会被它们中途停止。

怎样移除已经设置的限额？编辑自动化并清空对应的限额字段。

为什么设置了 Per run 还需要 Monthly？Per run 只限制单次，多个小运行累积后仍会形成月度消耗，所以长期运行还需要周期预算。