让依赖升级助手每周自动提交 PR

依赖升级工具能跑通一次，还不等于团队会持续使用。作者把 patchpilot 接进 GitHub Actions，让它每周一挑一个过期的 Python 依赖，在沙箱里升级、修复代码，测试通过后自动提交 PR，把「想起来再升级」变成固定流程。

它值得看的地方，是作者怎样限制 AI 的职责、避免重复花钱，以及保护 CI 里的密钥。首次真实运行展示了完整流程，但距离证明它能稳定处理各种项目，还有一段路。

每周自动提 PR，实际跑通了什么

作者提供了一次真实运行的回放：patchpilot 跳过已有升级 PR 的 pydantic，选择把 marshmallow 从 3 升到 4。新版删除了字段参数 missing= 和 default=，导致测试模块在导入时就崩溃。

代理把它们改成 load_default= 和 dump_default=，随后全部 9 个测试通过，再以 github-actions[bot] 的身份创建 PR。

它还发现 README 里保留着「marshmallow 3」，但为了控制改动范围，没有顺手修改。作者认可这个判断。不过，文档版本是否应该同步，仍要看项目要求，不能把少改文件直接等同于判断正确。

接入只需下面这个 workflow，另行配置 Anthropic API key：

name: patchpilot

on:
  schedule:
    - cron: "0 6 * * 1"  # 每周一 UTC 06:00
  workflow_dispatch:      # 添加「Run workflow」按钮

permissions:
  contents: write
  pull-requests: write

jobs:
  upgrade:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: ilmeedesilva/patchpilot@v0.2.0
        with:
          anthropic-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

重点看 permissions 和 anthropic-api-key：这个任务持有仓库写权限，也会接触模型密钥。定时表达式 0 6 * * 1 对应北京时间每周一 14:00，workflow_dispatch 则保留手动触发入口。

哪些交给模型，哪些应该写成规则

patchpilot 没有让模型决定升级哪个包。它先检查 PyPI 最新版本是否落在项目声明的范围之外：例如 pydantic>=1.10,<2 遇到已发布的 2.x，就成为候选；未固定版本的 requests 不会入选，因为按作者的规则，pip 已会安装最新版。

候选包按 patch、minor、major 的顺序选择，优先尝试跨度较小的升级。这个排序容易复现，也无需花钱询问模型；但它只衡量版本跨度，并未体现漏洞紧急程度或依赖的重要性。

防止每周重复劳动的规则同样明确：跳过已有 patchpilot/upgrade-* 分支的包。GitHub runner 上的 actions/checkout 默认不会把这些分支都取到本地，所以要直接查询远端：

git ls-remote --heads origin 'patchpilot/upgrade-*'

注意最后的分支模式。原文用远端分支作为跳过依据，并没有详细交代 PR 关闭后残留分支的清理方式；因此，分支存在与 PR 仍待处理是否始终一致，还需要验证。

能确定性计算的步骤交给代码，需要理解变更和修复代码的步骤再交给模型。

如果所有待升级包都已有 PR，工具输出 Nothing to upgrade，以退出码 0 结束，不调用模型 API。作者称这次空运行约一秒。这里的「不花钱」指没有模型调用费用，不能扩大理解为整个 CI 没有成本。成功退出也避免了无事可做时 Actions 每周报红。

临时 runner 为什么还需要 Docker

GitHub 为每个任务提供用完即删的虚拟机，作者仍保留了 Docker 沙箱。原因很直接：任务执行期间，runner 里有 Anthropic API key，还有能推送仓库的 GitHub token；安装依赖和执行测试时，却会运行第三方代码。

机器事后删除，无法阻止代码在运行当下读取环境变量。

按作者描述，项目代码只在容器内接触仓库的临时副本，看不到存放密钥的宿主环境。这是合理的隔离方向，但原文没有展示容器权限、挂载和网络配置，尚不足以据此评估完整的安全边界。

另外几处实现细节也很实用：

• 输入通过环境变量传递，避免把 ${{ inputs.package }} 直接拼进 run: 脚本，形成 shell 命令注入入口。
• Action 使用 pipx install "$GITHUB_ACTION_PATH" 安装自身源码，让 @v0.2.0 对应 patchpilot 0.2.0，而非运行时再取 PyPI 最新版。
• 本地仍检查 gh auth status，Actions 中则认可 GH_TOKEN 提供的认证，避免认证预检失败却实际能够推送、创建 PR 的情况。
• CI 用没有过期依赖的小项目运行真实 Action，覆盖安装、选包和退出码，无需密钥，也不调用 Claude。

最后一项只能验证不调用模型的路径，无法覆盖代码修复失败、模型输出异常等情况。

我的判断

我认可这套方案对任务边界的处理：一次升级一个依赖，先去重，再在隔离环境里尝试修复，最终交付可审查的 PR。与单纯更新依赖声明的流程相比，它进一步处理了破坏性 API 变更。

但一次 marshmallow 升级、9 个测试通过，只能证明这条具体路径跑通。原文没有提供多项目成功率、模型费用、修复轮数，也没有与人工升级或其他工具做对照。「优先小版本更容易合并」仍是作者的经验判断。

演示准备过程反而提醒了另一个问题：升级跨了大版本，不代表旧 API 已经删除。作者原本选 semver 3，实际安装新旧版本后才发现旧模块函数只是被弃用，于是换成确实删除 missing= 的 marshmallow 4。他还把依赖放进单独的 requirements-api.txt，避开与现有 pydantic PR 对 requirements.txt 的修改冲突。

测试通过是提交审查的依据，不能独自证明迁移正确。

作者也承认，更有说服力的下一步是去真实开源项目验证、人工检查每个 diff，并在提交前征求维护者同意。这部分是计划，尚未成为实测结果。

能拿来做什么

• 如果你维护 Python 服务，可以先用 pipx install patchpilot 在本地尝试一个测试覆盖较完整的依赖，检查生成的 diff，再决定是否接入每周任务。
• 如果你在写前端或 Node 的 AI 编程代理，可以借鉴它的职责划分：用代码完成版本比较、重复任务检测和退出状态管理，让模型集中处理迁移说明与代码修复；原文没有证明 patchpilot 支持这些技术栈。
• 如果代理要执行依赖安装或测试，应检查执行环境能否读取模型密钥和仓库 token，并把这项检查放在启用自动调度之前。
• 审查升级 PR 时，除了测试结果，还应核对 API 语义、文档版本和依赖文件冲突；这些都已经在作者这次演示里出现，适合直接加入日常检查。