AgentLoop AgentLoop 通过启动 Codex worker 和 critic 进行循环构建与测试，帮助开发者自动化修复代码错误，提升开发效率。 热门评论 PH 用户Hey Product Hunt，我是 Edward，AgentLoop 背后的独立开发者。我做这个项目是因为自己一直在当 ChatGPT 和 Codex 之间的传话筒：规划、粘贴、检查、返回意见、重复循环。只要我不盯着，质量就往下掉。AgentLoop 把这个传话筒过程自动化了，而且不隐藏工作细节。只要设置一次目标和 GUIDELINES.md 准则。每个循环启动一个全新的 Codex worker，然后新的检查者对照你的准则测试结果，给下一个 worker 写下具体修复意见。项目文件在不同干净上下文之间保持记忆，本地 dashboard 让每个循环都可视、可取消。证明这个想法有效的时刻是一次没有强制失败的评估。第一个 worker 跑过了 9 个测试，但新检查者仍然发现了一个真实的混合百分比解码缺陷。下一个 worker 修复了它，添加了回归测试，通过了 11 个测试，拿到了 PASS。我是在 OpenAI Build Week 期间用 Codex CLI 和 GPT-5.6 设计并构建了 AgentLoop。它是开源的、零依赖的 Node.js 项目。你会放心让一个可见的循环来处理什么编码任务，然后自己走开？PH 用户新 worker + 新检查者循环是我最想先测试的部分。长智能体对话通常几轮上下文之后就开始变得奇怪；用项目文件做内存感觉更干净，但我好奇你怎么防止检查者成为大型 repo 上的瓶颈。PH 用户每轮用全新的 worker 和全新的检查者是个聪明的办法，能避免长运行智能体对话常见的上下文腐蚀问题——它会开始认同自己之前的错误。我好奇的是准则本身，GUIDELINES.md 的好坏完全取决于你事先写了什么。如果检查者通过了技术上符合准则但实际有问题（一种你写准则时没预料到的错误）的东西，除了事后发现然后重写文件，还有什么办法能抓住它？PH 用户项目文件做内存这个想法对我来说很有意思。我遇到过相反的问题：太多对话上下文导致智能体反而更不可靠。到目前为止，哪种任务质量提升最大——修 bug 还是多文件功能？PH 用户翻来覆去的问题确实关注了循环之间的一致性，但更关键的是单次检查者犯错——它把实际上正确的代码判错，下一个 worker 就会去“修复”它，改掉本不该改的东西，可能为了追一个幻影 bug 而引入真正的 bug。既然 worker 完全信任修复意见当作事实，没有反驳的途径，那么有没有什么机制让 worker 可以质疑检查者的失败判罚？还是一个坏的检查者判断跟好的一样是最终的？PH 用户恭喜发布！如果你在运行过程中从仪表盘取消一个 cycle，它会回滚 worker 正在进行的更改，还是部分编辑会留在磁盘上，直到下一个 cycle 来处理？ 热门产品Edward Yi2026-07-23原文 打开互动版
我做这个项目是因为自己一直在当 ChatGPT 和 Codex 之间的传话筒：规划、粘贴、检查、返回意见、重复循环。只要我不盯着，质量就往下掉。
AgentLoop 把这个传话筒过程自动化了，而且不隐藏工作细节。只要设置一次目标和 GUIDELINES.md 准则。每个循环启动一个全新的 Codex worker，然后新的检查者对照你的准则测试结果，给下一个 worker 写下具体修复意见。项目文件在不同干净上下文之间保持记忆，本地 dashboard 让每个循环都可视、可取消。
证明这个想法有效的时刻是一次没有强制失败的评估。第一个 worker 跑过了 9 个测试，但新检查者仍然发现了一个真实的混合百分比解码缺陷。下一个 worker 修复了它，添加了回归测试，通过了 11 个测试，拿到了 PASS。
我是在 OpenAI Build Week 期间用 Codex CLI 和 GPT-5.6 设计并构建了 AgentLoop。它是开源的、零依赖的 Node.js 项目。
你会放心让一个可见的循环来处理什么编码任务，然后自己走开？
我遇到过相反的问题：太多对话上下文导致智能体反而更不可靠。
到目前为止，哪种任务质量提升最大——修 bug 还是多文件功能？