我构建了一个本地控制系统，用于处理代理故障、修复、评估和门控，以使类似自动研究的自我改进循环在实际代理代码库中生效

我一直在试验面向代理的自动研究风格循环：运行代理，检查跟踪，找出问题所在，提出修复方案，重复。这个想法很好。编码代理已经能够查看跟踪、发现故障模式并提出修复方案。但我越尝试在实际代理代码库中使用它，遇到的挑战就越多。真正的困难在于围绕循环建立一个系统： * 哪些故障实际上在不同运行中重复出现 * 每个问题有哪些证据支持 * 提出了哪些修复方案 * 运行了哪些检查和评估 * 哪些通过了，哪些失败了，哪些回退了 * 哪些允许自动更改 * 哪些需要人工审查 因此，我围绕代理改进循环构建了一个完全本地的控制系统。它捕获代理运行，发现重复故障，将其转化为有证据支持的问题，让Codex/Claude Code起草修复方案，并仅在通过检查和评估后通过门控应用更改。工作流程是： 1. 捕获代理运行/跟踪 2. 发现跨运行重复的故障 3. 将其转化为可审查的问题并提供证据 4. 让Codex、Claude Code起草修复方案 5. 重新运行失败的跟踪，运行确定性检查，比较评估结果 6. 仅当通过门控时才应用修复，否则暂停以供审查 默认情况下所有内容都是本地的：SQLite数据库、仪表盘、跟踪、问题、提案、评估。对于分析和修复起草步骤，它可以使用您已有的编码代理CLI，因此无需单独托管服务或额外的模型API密钥。自我改进循环在理论上很酷，但除非您围绕它们构建基础设施，否则很难迁移到生产环境。