Theo 谈编程智能体循环：审查、协调与成本

Pete 说，开发者应该设计循环来提示编程智能体。Ralph 循环之类的早期实验帮助我想象智能体如何工作更久，但也大幅提高了修改的错误率。于是我又回到亲自提示智能体、阅读计划、指导每一步，并手动传递审查反馈的方式。

我一直欣赏 Pete 对智能体的实验方式，即使成果还很粗糙。最近我开始用循环审查和修改代码、监控拉取请求与议题，并通过 Hermes Agent 将上下文带给我。我仍然会写提示，但现在认为许多单独的智能体运行不必由我亲自写的提示启动。

让我真正理解这一点的是 Peter Steinberger 的一篇帖子：他描述了一个定期唤醒、检查仓库并将工作分配给不同会话的协调器。我之前不知道一个 Codex 会话可以创建另一个。这让我有了思考并行工作和监督的新方式。

我们从向聊天机器人索取代码、再把答案复制进项目，转向让智能体直接编辑代码。工作流和子智能体又推进了一步。我对给每个工作智能体预设身份持怀疑态度，因为我看重智能体按具体任务构建所需上下文和方法的能力。

闭环又走得更远：模型可以选择工作、审查结果、传回反馈并重复。我并不是说所有代码都应该在没有监督的情况下生成。我想先尝试一个有限的版本，看看它在哪里有帮助。

处理一次大型重构时，我让智能体将工作分给子智能体，并要求它监控拉取请求。此前我一直亲自把审查工具的评论复制给智能体。使用独立 worktree 后，我可以让它监控并处理评论，而不阻塞主工作目录。

监控持续了六个多小时，带来了改进，于是我继续探索。我也试过让一个智能体调用另一个审查者并处理反馈。但单个 PR 只是工作的一种形式；有些问题需要多个相互依赖的变更。

在调查 Lakebed 的隔离层时，一项分析指出数据架构可能先成为瓶颈。每次数据变更都可能导致许多订阅重新运行。建议的改进包括依赖感知失效、批处理、共享结果以及限制刷新频率。

我问这些变更应该放在一个 PR 还是多个 PR 中，以及应该并行还是串接。智能体建议拆成多个 PR，以串接为主，也有一些并行机会。我让它写成 HTML 计划，再为第一个变更创建新会话。

第一个 PR 经过审查、由我合并后，我让它为下一部分创建新会话。接着我想到，能否自动化流程本身：一个会话实现，另一个审查，实现会话处理评论，协调会话在 PR 准备好后继续下一项。

拟议工作流用定期心跳检查实现状态、发现 PR、针对新的头部修订启动新审查、传回可执行的问题并审查修复。合并之前会检查 CI 和所需批准，然后更新基础版本，再启动下一个 worktree。

我睡前启动了它，醒来时四个串接的 PR 已经经过审查并合并。它也严重干扰了我的编辑器。结果令人兴奋，但我暂时不会建议在服务数百万用户的生产代码库中给予这种程度的自主权。

最让我印象深刻的是，工作流根据具体问题创建了更小的循环，而不是把固定的审查模式套到每个变更上。这与静态冲刺流程形成对比：流程可以围绕工作来塑造，而不必让所有任务都适应同一种形式。

同样的思路可以用于监控 PR，或者按计划推送有用的更新。我曾用循环关注 5G 热点方案，它提醒我注意到一个新套餐。在开发案例中，我仍然编写了最初的提示、阅读回复，并决定尝试提出的流程。

看看智能体完成任务之后你会做什么。我过去会运行应用、检查结果、提交、推送、创建 PR、收集审查反馈、询问团队，然后合并。其中一些步骤可以委派：让智能体运行和检查应用，或者收集并处理审查评论。

我还建议考虑，人在花时间读代码之前，自动审查能否先找出明显问题。目标是让人有更多注意力处理更难的问题。这是我偏好的工作流，并不意味着智能体审查能保证正确性。

一个重要问题是成本。循环会消耗更多 token；如果方向错了，可能在有人发现之前继续运行更久。有一次，不到十分钟的审查产生了一个运行八小时、消耗超过 300 万 token 的工作流，只为处理三条小评论。

尽管运行了几个循环，我当时的订阅用量碰巧仍低于限额，但这只是当时我自己账号和套餐的快照。限额、价格和允许的使用方式可能不同。我提醒过，按 API token 付费时，这种实验方式可能很昂贵。

单个会话中的持续目标，与创建多个独立工作项的动态工作流不同。我也在尝试一个长期运行的 Hermes Agent Rust 重写项目，希望减少资源消耗。这是实验；我并不认为循环运行得久就意味着结果可以用于生产。

我展示了多台机器和多个订阅的大量推理用量估计，并把它看作实验空间。这些估计不等于实际节省的现金，也不能预测其他人的成本。我的实际建议是看看下一步手动工作，问问智能体能否帮忙，然后检查它实际做了什么。

循环的价值在于让智能体承担流程中的更多工作。试着让它完成下一步，看看在自己的情况下效果如何。我的实验让我惊讶，但结果仍需要评估。