@akshay_pachaar：关于循环工程。这周大家都在说同一件事。你不再提示代理，而是设计循环来提示它们……

关于循环工程。 这周大家都在说同一件事。你不再提示代理，而是设计循环来提示它们。 但循环把这份工作又交回给了你。 无人值守运行的循环，也是无人值守失败的循环。 循环工程让你摆脱了提示工程。它让你摆脱了整理上下文。它让你摆脱了照看单次运行。但它并没有让你摆脱调试。它只是把调试移到了更糟的地方——那些你从未监视过的运行中，而且数据量太大，无法手动通读。 就连那些循环工程的文章自己也承认这一点，通常是在接近结尾的地方。只有当你信任那个检查循环的东西时，你才能放心离开循环。一个你不信任的检查器会让你重新回到手动阅读每一条输出的状态，而这恰恰是循环本该替你分担的工作。 所以，把层次堆叠起来：提示、上下文、框架、循环，而有一项工作在所有这些层次中都幸存了下来——即闭环处理失败。杠杆点移动了，但调试依然在原地。 就在昨天，在今天的循环话题兴起之前，我恰好写到了这个缺口。想法很简单：让调试自身成为一个循环。一次失败会引出根因、一个建议的修复、针对恰好导致故障的输入重新运行，以及一个永久锁定该问题的测试。这个检查器是根据你真实的失败构建的，而不是事先猜测的。 Opik——我写到的那个工具——正是做这件事的。内置的代理读取追踪，找到根因，提出差异，你批准后，那个失败就成了一个永久性的回归测试。每次你调试的故障都会让下一次循环更难被打破，这正是循环工程人群一直强调的、在你放手离开之前所需要的检查器。 如果你正在设计你确实打算放手离开的循环，那么这值得一看。 Opik 是 100% 开源的，采用 Apache-2.0 许可证。 GitHub 仓库：https://github.com/comet-ml/opik （别忘了点星标 ） 循环工程移动了杠杆点。但它并没有消除工程师——当出现问题时，仍然需要工程师来闭环处理。 完整文章《你的代理框架应该自我修复》引用如下。