Peter Steinberger 最近在 X 上晒了一套极简但狠的玩法——用 Codex 维护仓库，5分钟唤醒一次，把任务直接派发到线程里并行执行。更关键的是他叠加了编排器技能、分类技能、自动审查技能和计算机使用技能，让整个流程几乎不需要人插手。对于做开源项目的人来说，这套东西基本可以直接抄走。
5分钟一次：把 Codex 塞进定时循环
核心机制：唤醒、分配、回收
Steinberger 的方案听上去像是个 cron 任务，但内核完全不同。他让 Codex 作为一个常驻代理，每 5 分钟被唤醒一次，扫描仓库状态、读取待办、然后把工作切片扔进线程池。这种做法的聪明之处在于：不是让 AI 一次性处理所有事情，而是把它拆成一个持续运转的小型工厂，每轮只消化当前能消化的量。
定时循环本身不稀奇，稀奇的是它把 Agent 从"按需调用"变成了"持续在线的服务"。这意味着仓库永远不会积累太多未处理的问题——Issue 进来、PR 待审、Bug 报告堆积，Codex 会在下一轮唤醒时自动接住它们。
为什么是5分钟而不是1小时
这个时间间隔不是随便选的。5分钟足够短，让响应感接近实时；又足够长，避免空转时浪费 token。Steinberger 显然算过账——太频繁会把上下文窗口填满噪声，太稀疏又会丢失时效性。5分钟是一个"刚好让 Agent 有事干又不至于过载"的甜点。
如果你的仓库活跃度更高，可以压到 2-3 分钟；如果是冷门项目，拉到 15-30 分钟也未尝不可。重点是让这个循环跑起来，让它变成仓库运维的一部分，而不是一个额外的工具。
三件套：编排、分类、审查如何咬合
编排器：整个流水线的调度中心
单个技能再强也只是个工具。Steinberger 真正厉害的地方在于他搭了一个编排器技能（orchestrator）来调度其他所有技能。这个编排器知道什么时候该调用分类、什么时候触发审查、什么时候需要人工介入。它不干活，它只管派活。
这种"调度者 + 工人"的分层结构解决了 Agent 系统里一个老难题：上下文爆炸。当所有逻辑都塞进一个 Prompt 时，模型很快就会迷失；但如果把任务拆成可编排的单元，每一步都走自己的上下文，系统的可维护性会指数级上升。编排器技能就是那个把混乱变成秩序的胶水层。
分类 + 自动审查：先排队，再动手
分类技能的作用是把涌入的 Issue 和 PR 快速分桶——这是 Bug 还是 Feature 请求？这是紧急还是低优？分完之后，自动审查技能接手，对代码改动做静态分析、风格检查、潜在风险标记。两步合起来，本质上是在模拟一个资深 Maintainer 每天早上打开 GitHub 时的第一件事：扫一遍收件箱，决定先看哪个。
效率提升肉眼可见。原来人工需要 30 分钟处理的事情，现在 5 分钟内就有结构化结果。Maintainer 不用再被噪声淹没，他们看到的是一份干净的优先级列表和已经打过分的改动。
计算机使用技能：让 Agent 长出"手"
从读到写：跨过那条隐形的线
分类和审查都还停留在"读"的层面——读 Issue、读代码、读报告。但 Steinberger 的方案显然不止于此。他提到的计算机使用技能（computer use）才是整套系统真正炸裂的地方：它让 Agent 不只能分析，还能直接操作。
所谓计算机使用技能，本质上是让模型可以控制终端、运行命令、修改文件、提交 PR。OpenAI 的 Operator 路线、Anthropic 的 Computer Use 能力，都是这个方向。Steinberger 把这些能力接进自己的 Agent 循环，等于给代码审查装上了"自动修复"开关——发现问题的不只是写报告，它直接动手改。
自主落地的边界在哪里
但他用了一个很克制的词：部分工作可以自主落地。不是全部。Steinberger 显然清楚 Agent 当前的能力天花板——让它自动修小 Bug、补单元测试、跑 lint 修复，这些是安全区；但涉及架构调整、依赖升级、API 变更，还是得人来把关。
这套边界划分才是真正值得抄的。不是把 Agent 当成万能助手，而是把它定位成"高级实习生"：能干的让它干，干不了的它会把报告交上来。开源 Maintainer 终于可以从无尽的琐事里抽身，只在关键决策点出手。
抄作业指南：哪些项目适合这套玩法
中型开源项目是最佳试验场
这套编排方案不是万能药。太小众的项目跑不起来——Issue 太少，Agent 空转浪费资源；太复杂的项目又会撑爆——光是让分类技能理解项目结构就得花几周调教。Steinberger 的目标受众很明确：有一定 Issue 流量、有规范 PR 流程、有持续维护需求的中型项目。
如果你手头恰好管着一个 stars 1k 到 50k 之间的仓库，这套东西几乎是为你的场景量身定做的。5分钟循环的 token 消耗完全可控，分类和审查的 Prompt 模板可以一次调好长期复用，整体投入产出比相当可观。
需要提前准备的三样东西
第一是干净的结构化数据。Issue 模板、PR 模板、Label 规范，这些得先有——否则分类技能会一脸懵。第二是权限隔离。Agent 写代码用的 token 必须独立、可追溯、可回滚，万一它抽风了不至于污染主分支。第三是日志和监控。5分钟跑一次意味着每天 288 次执行，不把日志打好，出了问题根本没法回溯。
把这三样备齐，再把 Steinberger 的编排逻辑照搬过去，一个能自主维护的仓库就基本成型了。剩下的就是调阈值、调 Prompt、调唤醒间隔——这些细节每项目不同，但骨架是通用的。
说到底，Steinberger 这套玩法的价值不在于技术多新颖，而在于它验证了一件事：AI Agent 已经能承担开源项目里相当比例的日常运维工作。不是未来时，是现在时。5分钟循环、并行线程、分类审查、计算机使用——这些东西拼在一起，就是一个永不疲倦的数字 Maintainer。而你需要做的，只是给它一个清晰的工作边界和一套可复用的技能模块。
