Coding Agent 正在改变开源协作的成本结构。生成代码、修改测试，甚至并行提交多个 Pull Request（PR），所需的时间越来越少。但判断一个 PR 是否值得合并，仍然需要理解行为变化、检查回归风险，以及评估它是否符合项目的长期方向。
Linux Foundation 在 2026 年 10 月发布的调查中，59% 的受访维护者报告开源贡献量有所增长。报告也记录了维护者对低质量 AI 生成 PR 的担忧。这是受访者的观察和估计，不能直接推导出所有项目的情况，但它说明了一个值得重视的变化：提交变更的能力与审查变更的能力，可能以不同的速度增长。
这里存在两种不同的资源约束：运行测试与 Review Agent 需要计算资源；判断证据是否充分、设计是否合理，则需要维护者的注意力。前者可以购买、调度或由不同参与方提供，后者不能简单地用更多模型调用替代。
一个可能的方向是：贡献者提交 PR 时，也可以附带一份用于验证该变更的受限计算预算。项目根据自己的规则使用额度运行测试、问题复现和 Agent Review，最后把可核查的证据交给维护者。它不应成为合并资格或优先权的购买机制。
现有 CI 和 AI Review 还缺少什么？
CI 已经解决了大量重复性检查问题。构建、单元测试、静态分析乃至集成测试，都可以在 PR 到来后自动执行；AI Review 工具也已经能够分析 diff 并给出建议。因此，这个提案的创新点不是再发明一个 Review Agent。
现有实践甚至已经开始调整验证成本的归属。Apache Airflow 的 AIP-120（截至本文写作时仍为草案）提出让外部贡献者在自己的 fork 中先运行 CI，而不是直接消耗项目的 CI 执行能力。该提案还特别纠正了一个早期假设：标准的 GitHub-hosted Actions 在公共仓库中免费运行，因此转移到 fork 后，贡献者主要承担的是执行时间与并发限制，而不一定是费用。
这与计算预算的想法相关，但不相同。把 CI 放到贡献者的 fork 中，主要改变验证在哪里运行；让贡献者提供项目可使用的验证额度，则改变谁为项目定义的验证任务提供资源。这项区别在需要付费模型调用、专用 Runner 或高成本验证环境时尤其明显。
直接使用 Bring Your Own Key（BYOK）也不够。一个通用 API key 只能回答模型调用由哪个账户付费，不能天然限定这个密钥只服务于某个 PR、某次验证和特定任务。真正需要的是将资源授权、项目验证策略和变更身份绑定起来，并让验证结果能够被复核。
为 PR 附带受限的验证预算
高质量 PR 本来就应该说明修改意图，提交必要测试，并尽可能提供复现步骤。这些不是新贡献形式。这里新增的是：贡献者还可以授权项目使用一笔额度，完成原本可能因为资源成本而没有运行的检查。
例如，一个 PR 声称修复队列满载时的重试超时。项目可以使用这笔预算，对基准版本和 PR 版本运行相同的复现测试，再检查相关回归场景，并由 Review Agent 分析尚未覆盖的并发行为。
维护者需要看到的不是「AI 认为这个 PR 没问题」，而是：测试在什么代码版本和环境中运行，基准版本是否出现预期失败，PR 版本是否通过，哪些场景仍然未测，以及模型审查发现了什么可复现的问题。执行成本也应纳入记录。
如果原始问题没有复现，报告就应标为证据不足。即使测试在旧版本失败、新版本通过，也只说明特定测试条件下观察到了修复效果，并不证明所有相关行为正确。
计算预算增加了执行验证的机会；验证是否可信，仍取决于任务设计和证据质量。
证据从哪里来，决定了能信任到什么程度
把测试命令、日志和 Commit SHA 写进报告，是必要的，但不足以证明报告真实。贡献者完全可以在自己的环境里运行另一套测试，或者上传与提交代码不对应的结果。
因此，要区分「贡献者提供的验证材料」与「项目认可的验证结果」。前者帮助项目理解和复现问题；后者应由项目认可的执行环境产生，并明确记录被测的 Commit SHA、所用的验证策略版本、执行器身份、任务输入与输出摘要。必要时，可以为执行结果附带可验证的来源证明（provenance / attestation）。GitHub 的 artifact attestation 文档提供了相关机制的参考。
来源证明回答的是「谁在什么条件下产生了这份结果」，不是「测试断言一定充分」或「Agent 的判断一定正确」。可信执行记录与软件行为的正确性，是两个不同的问题。
这也要求验证流程本身受到保护。项目策略应来自可信的仓库版本，而不是允许 PR 修改策略后再用新规则评判自身。PR 的代码、依赖、测试、文档及日志都可能是恶意输入，不能让它们控制 Agent 的权限，也不能让执行不可信代码的环境接触模型密钥或仓库 Secret。GitHub 关于不可信 PR 工作流的安全说明展示了这种权限混用的风险。
一种最小的实现方式
不需要先建立算力交易市场。初期可以是一个 GitHub App、仓库策略文件、预算代理、隔离执行器和结构化报告服务。
PR（代码、意图、测试，绑定 Commit SHA）
|
v
可信项目策略 + PR 范围内的验证授权
|
v
任务编排器
/ \
v v
不可信代码沙箱 受控 Review Agent
构建与测试 通过模型网关调用
\ /
v v
执行记录 + 验证结果 + 成本
|
v
Maintainer 决定是否合并在这里，「贡献 API tokens」不意味着把原始 API key 放进 PR 或测试容器。预算代理可以提供一次性的受限授权，绑定仓库、PR、Commit SHA、可执行任务、有效期和费用上限。额度检查和实际模型调用由可信网关实施；不可信沙箱默认不接触密钥，网络访问也应按任务需要明确限制。
项目定义验证任务和公开报告的规则，贡献者负责授权额度。系统需要在执行与报告发布时落实这条权限边界，避免贡献者改变验收标准或选择性隐藏失败结果。恶意 PR 还可能借由无限循环、测试脚本和 Agent 提示注入消耗额度，因此资源和调用次数都需要硬上限。
这些设计不等于安全性已经得到保证。它们只是让这一机制具有可以进一步实现和审计的信任边界。
自动验证与预算分担，是两个独立的假设
这项提案的效果不能从「Agent 可以运行更多检查」直接推导出来。至少需要分别验证两个假设。
第一，增加自动验证能够减少维护者的工作量。 这取决于测试是否覆盖真正的风险、Agent 的发现是否准确，以及报告能否帮助维护者更快地作出判断。如果只是多生成几十条缺少证据的 Review 评论，人类的负担可能反而上升。
第二，让贡献者提供验证预算能够改善项目的资源供给。 即使自动验证有效，贡献者出资也不一定必要。公共仓库可能已经拥有足够的免费 CI 能力；真正受限的可能是特定付费模型、昂贵的集成环境，或者仅仅是维护者的注意力。只有当资源供给确实限制了有用的验证任务时，重新分配计算预算才有直接价值。
这意味着实验不能只比较「普通 PR」与「贡献者付费且使用 Agent 的 PR」，否则无法区分效果来自验证方式还是资金来源。
更清楚的对照是：先比较现有 CI 与由项目预算支付的增强验证流程，判断增加检查是否减少人工审查时间；再让同等验证流程改用贡献者授权额度，评估费用归属、可持续性以及参与门槛。第二组对照如果执行了完全相同的任务，就不应期待验证质量因付费方不同而改变。
值得记录的不仅是单次模型费用，还包括维护者的实际审查时间、可复现的缺陷发现、误报和遗漏、排队等待，以及新贡献者是否因此流失。不同 PR 的规模和风险必须在比较时加以控制。
不能把开源贡献变成付费通道
计算预算应是可选的贡献方式，而不是所有人的准入条件。项目基金、企业赞助或平台额度也可以支付同样的验证任务，让资源有限的贡献者不至于失去参与机会。
同样，更多预算不应带来更高的合并优先级。验证可以帮助确认某个行为是否发生，却无法代替维护者判断需求的价值、架构的取舍和未来的维护责任。
还需要考虑反向激励：如果每个 PR 都附带一笔预算，项目是否会因此鼓励提交者用算力替代自己应该完成的测试？合理的流程仍应要求清楚的意图与基本验证材料，再决定是否值得投入额外检查。
从代码贡献到可验证的变更
这个方向不是要求贡献者为所有 Review 工作买单，也不是认为更多算力自然带来更可靠的软件。它尝试建立一种分工：贡献者可以提供受限资源，项目控制验证策略，自动化系统执行可重复的检查，维护者依据证据承担最终判断。
Code + Compute + Evidence 可以概括这个设想，但三者并不等价。代码描述变更，计算资源支持验证，证据让结果能够被复核；没有可信执行与合理测试，预算再高也无法补上证据的缺口。
如果实验表明它只能转移费用，却无法减少维护者负担，或者明显提高了新人参与门槛，那么它就不值得成为一项通用贡献要求。反过来，如果受限预算能使项目持续执行原本负担不起的验证任务，同时保持可信性和开放性，它可能成为现有 PR 工作流的一项补充能力。
当代码越来越容易生成，值得探索的开源基础设施不只是如何接收更多变更，还包括如何让有价值的变更以可负担、可审计的方式得到验证。