MartinLoop

做得不错！JSONL 记录是只捕获了已提交的路径，还是也包括被拒绝的路径？

嘿 Product Hunt，我在看到那些好用的编程智能体以最昂贵的方式失败之后——它们会一直重试——就做了 MartinLoop。一个循环看起来可能很高效，但实际上却在烧 token、重复同一类错误、修改超出范围的代码，或者停下来却不留下任何可追溯的证据。

MartinLoop 就是围绕这个循环的开源控制层。它加入了硬性的预算上限、经过验证器把关的下一次尝试准入、针对作用域/密钥/验证器命令的安全策略、可回滚的证据，以及你可以检查或稍后恢复的 JSONL 运行记录。

目标很简单：保持自主智能体的速度，但让每一次运行都可被问责。如果你在实际项目中运行 Claude Code、Codex、OpenCode 或类似的编程智能体工作流，我真的很想听听你的反馈：在放心让一个长时间运行的智能体通宵干活之前，你需要看到什么样的凭证？

有一件事我真的很想听听发布日测试者的反馈：在放心让一个编程智能体通宵干活之前，你需要什么样的证明？是预算收据、验证器结果、回滚路径，还是文件级别的 diff 追踪？MartinLoop 的设计目标就是让这些运行变得可检查，而不仅仅是快。

给发布日测试者的一个小更新：现在尝试 MartinLoop 最快的方法是：

npx martin-loop demo

我最想得到的反馈很简单：当 AI 编程运行失败之后，什么样的证明能让你信任下一次尝试？

对新手友好的智能体用户体验，主要在于可预测的停止状态。如果工具能说清楚发生了什么、它检查了什么、为什么停止，人们会原谅一个小失败。但如果运行一直继续却没有新的信号，他们就会失去信任。

一个小规则可以揪出大量虚假进展：如果智能体无法用一句话解释清楚自上次尝试以来发生了什么变化，那它很可能还不应该获得再次重试的机会。这听起来很严格，但能省下大量预算，避免那些只是在反复重排同一失败原因的“忙碌”循环。