Peter如何用N个Codex持续维护OpenClaw
Peter 讲 OpenClaw 的时候，最核心的不是“他们用了很多 AI”，而是他们在尝试一种新的软件项目运行方式：把 Codex 放进项目的日常流程里，让它持续参与开发、审查、验证、整理和维护。
他的问题很直接：如果 token 成本不再是主要限制，我们会怎么做软件？在这个前提下，很多过去因为人力不够而不会做、做不细、做不及时的事情，现在都可以交给 agent 持续处理。比如每个 PR 都有人看，每个 commit 都有人查安全问题，每个 issue 都有人判断是不是重复，每个性能回归都有人验证，每个历史 issue 都有人回头检查是否已经被修复。
Peter 的做法不是只让 Codex 写代码，而是让很多 Codex 分别负责项目里的不同环节。有的 Codex 负责 review PR，有的负责检查安全问题，有的负责 issue 去重和聚类，有的负责扫描评论里的 spam，有的负责跑性能 benchmark，有的负责在 Discord 里报告性能 regression，有的负责根据符合项目方向的新 issue 自动创建 PR，然后再由另一个 Codex 去 review 这个 PR。
这就把 Codex 从一个“临时工具”变成了项目里的“常驻角色”。过去人类工程师需要定期去看 issue、看 PR、查日志、跑测试、复现 bug、整理会议结论、检查性能指标，现在这些事情可以被拆成一个个小的持续任务，交给不同的 agent 做。agent 不是等人想起来才工作，而是一直在项目旁边观察和处理。
一个很具体的例子是，他们有一个叫 clawsweeper 的东西。如果主分支上某个修复已经合入，它会去发现这个修复其实解决了一个 6 个月前的旧 issue，然后把那个 issue 关掉，并附上准确的引用。这件事不复杂，但很有代表性。很多项目里的旧 issue 并不是没人想管，而是没人有时间持续回头检查。Peter 用 agent 把这种长期维护工作自动化了。
另一个例子是复杂问题的复现。他提到，他们的 agent 可以重建复杂环境，启动临时机器，登录 Telegram，录制修复前和修复后的视频，然后把视频贴到 PR 里。这说明他们不是只让 AI 在代码层面推理，而是让 agent 进入真实的运行环境，像 QA 一样复现问题、验证修复，并把证据带回开发流程。
这件事很重要。因为很多 bug 不是看代码就能确认的，尤其是涉及 UI、外部服务、登录状态、复杂环境配置的时候。过去这种事情需要人手动搭环境、手动操作、手动截图或录屏。Peter 的做法是让 agent 具备这些操作能力，让它不仅能“写修复”，也能“证明修复有效”。
他们还在做 clawpatch.ai，把项目拆成一个个功能单元，用来做 review、找 bug、找 regression。这个动作说明他们并不是简单地把一堆 Codex 扔进代码库里，而是在把项目整理成 agent 更容易理解和处理的结构。项目被拆成明确的功能单元以后，agent 才能更准确地判断哪个地方出了问题，哪个改动影响了哪个模块，哪个功能可能出现回归。
Peter 的系统里，issue 也不只是一个待办列表，而是一个持续输入的信号源。agent 会读新 issue，判断是否重复，把相似问题聚类，并汇报当前最紧迫的问题。这样一来，用户反馈不会只是堆在 backlog 里，而会被持续整理成更清楚的模式。哪些问题反复出现，哪些反馈指向同一个根因，哪些 issue 符合项目方向，都可以被 agent 先处理一遍。
会议也进入了这个流程。他提到，有 agent 会监听会议。当团队讨论新功能时，agent 可以主动开始工作，比如创建 PR。这不是普通的会议纪要，而是把会议里的明确行动直接接到工程系统里。只要项目有清楚的方向和文档，agent 就可以判断某个讨论是不是已经足够明确，是否可以转成实现任务。
Peter 这样做的结果，是项目里很多原本需要人持续盯着的环节，都变成了自动运行的流程。PR 有人看，commit 有人查，issue 有人整理，性能有人跑，spam 有人拦，旧问题有人回头处理，会议里的新想法有人推进，复杂 bug 有人复现并录视频。这些事情单独看都不夸张，但合在一起，就让项目的日常维护方式发生了变化。
他最后说，这些自动化让他们能够用非常精简的方式运行项目。这句话很关键。他不是说 AI 花费不重要，而是在说这些花费换来的是更少的人力协调成本和更少的注意力消耗。一个项目里有大量事情并不难，但非常消耗时间，比如检查、确认、整理、追踪、复现、报告、回填信息。agent 可以把这些事情长期接住，人就可以把精力放在方向、架构、优先级和关键判断上。
所以 Peter 的做法可以概括为：他把软件项目里的很多日常工作拆出来，交给一组持续运行的 agent。每个 agent 负责一个相对明确的环节，并且把结果回写到项目系统里。它们不是孤立地回答问题，而是围绕 PR、issue、commit、benchmark、会议、环境和文档持续工作。
这套系统真正依赖的，不只是 Codex 本身的能力，也包括项目环境的设计。agent 要能看懂项目方向，要能访问代码和 issue，要能运行测试和 benchmark，要能启动临时环境，要能复现用户场景，要能把结果写回 PR 或 Discord，还要能被其他 agent 或人类审查。没有这些配套，开很多 agent 也只是增加混乱。
Peter 的实践给人的启发是，AI 编程不一定只发生在“写代码”这个动作上。它可以进入整个软件项目的运行过程：从发现问题到判断优先级，从创建 PR 到 review，从复现 bug 到验证修复，从性能监控到安全检查，从会议讨论到工程推进。
这就是他所谓“如果 token 不重要，我们会怎么做软件”的实际答案：不是让 AI 一次性完成一个大任务，而是让很多 agent 在项目中长期、持续、分工明确地工作。项目不再只是人推动一下才动一下，而是有一套持续运行的机制，不断观察、整理、修复和反馈。
说得简单一点，Peter 是在把 OpenClaw 做成一个由 agent 参与运转的软件项目。人仍然负责方向和判断，agent 负责大量持续性的执行和维护。这个变化不神秘，也不夸张，本质上就是把过去很多靠人盯、靠人记、靠人查、靠人补的工作，变成了项目里自动运行的一部分。
夜雨聆风
