最近一年大量 AI Coding Agent 出现了。它们可以理解代码、生成代码、修改项目甚至尝试完成比较复杂的开发任务。这当然很有价值但我在实际开发和自动化流程里逐渐意识到并不是所有代码错误都需要一个“大而全”的 Agent 来解决。有一类问题其实更像“运行时故障”而不是“代码创造问题”。比如- 文件路径缺失- 配置文件不存在- Python module 缺失- 命令参数写错- 命令启动失败- 简单运行时异常- 某些环境或依赖问题这些问题的共同点是错误已经真实发生程序已经给出了 stderr/stdout修复动作通常也应该很小。所以我没有继续做另一个 AI Coding Agent而是做了一个更窄的东西RepairLoop。项目地址https://github.com/guohuancui123-a11y/repairloop## RepairLoop 想解决什么问题传统 Coding Agent 的典型流程大概是text理解项目↓生成修改↓希望问题解决RepairLoop 的流程不一样。它从一个已经失败的命令开始textRun → Capture → Repair → Verify也就是text运行失败命令↓捕获真实错误↓生成最小修复↓重新运行验证它关心的不是“能不能生成一段看起来合理的代码”而是一个更具体的问题 这个程序能不能重新跑起来## 为什么不是另一个 AI Coding Agent很多时候我们并不需要模型理解整个项目。比如一个脚本报错textFileNotFoundError: [Errno 2] No such file or directory: demo/generated/config.txt这类错误不一定需要大模型重构项目。更合理的动作可能是1. 识别缺失路径2. 给出创建文件或目录的修复建议3. 默认只预览不修改4. 用户确认后应用5. 重新运行原命令验证。这就是 RepairLoop 的核心思路。它不是要替代开发者也不是要替代 Cursor、Claude Code 或其他 Coding Agent。它更像一个本地的、可检查的自动化维修层。## 设计原则 1Local-firstRepairLoop 的核心引擎是本地优先的。这意味着- 不需要云服务- 不需要 API Key- 不上传源码- 不依赖远程模型才能运行。对于一些内部项目、企业代码、CI 环境或者不方便上传源码的场景这一点很重要。不是所有自动化工具都应该默认把代码交给云端。## 设计原则 2Safe by default自动修复最容易让人担心的一点是它会不会乱改文件所以 RepairLoop 默认是 dry-run。例如bashrepair-loop repair -- python demo/missing_file.py这条命令只会展示修复方案不会真正修改文件。只有显式加上bash--apply才会执行修复。例如bashrepair-loop repair --apply -- python demo/missing_file.py这个设计的目的很简单 自动化可以参与修复但最终修改必须是显式确认的。## 设计原则 3Verification first很多“自动修复”工具的问题是它们告诉你“我改好了”但并没有证明真的好了。RepairLoop 的核心是验证。修复之后它会重新运行原来的命令。如果原命令仍然失败就不能算成功。所以 RepairLoop 的闭环是text失败↓诊断↓最小修复↓重新执行↓验证结果这也是它和普通 patch generator 的区别。## 架构流程可以把 RepairLoop 理解成下面这个流程textUser Command↓Run↓Capture stdout/stderr/exit code↓Diagnose runtime failure↓Generate minimal repair suggestion↓Preview or Apply↓Rerun original command↓Verify success/failure核心点是它始终围绕“真实运行结果”工作而不是围绕一个抽象 prompt 工作。## 一个简单 Demo假设有一个 Python 脚本缺少配置文件。直接运行bashpython demo/missing_file.py报错textFileNotFoundError先预览修复bashrepair-loop repair -- python demo/missing_file.pyRepairLoop 会识别缺失文件并给出修复动作。然后显式应用bashrepair-loop repair --apply -- python demo/missing_file.py它会执行修复并重新运行原命令验证结果。项目 README 里有 10 秒 Demo GIF可以直接看到这个闭环。## 当前能力RepairLoop 目前还处在早期阶段不是一个大而全的修复系统。当前支持的一些方向包括- 缺失文件或路径- 缺失 Python module- 命令启动错误- CLI 参数错误- 简单语法错误- 部分 SQLite / Flask 运行时场景- JSON report 输出方便 CI、自动化脚本或 Agent workflow 集成。我不想把它包装成“什么都能修”的工具。它现在更像一个小而清晰的 repair primitive。## 为什么这个方向值得做因为在很多工程场景里真正需要的是- 可解释- 可预览- 可回滚- 可验证- 可集成。而不是每次都启动一个黑盒 Agent 去大范围修改项目。RepairLoop 的目标不是“让 AI 接管开发”而是提供一个更确定、更窄、更容易信任的修复闭环。对于 CI、自动化脚本、Agent runtime、本地开发工具来说这种小型 repair loop 可能比一个通用 Agent 更容易接入。## 后续计划下一步我更想听真实开发者的反馈而不是继续盲目增加功能。我关心的问题包括- Python 开发中哪些 runtime failure 最值得自动修复- dry-run / explicit apply 这种安全模型是否足够可信- JSON report 对 CI/CD 或自动化流程是否有价值- 哪些修复动作应该永远只建议不应该自动执行项目地址https://github.com/guohuancui123-a11y/repairloop如果你经常维护 Python 项目欢迎体验并反馈你希望自动修复的错误类型。RepairLoop 现在还很早期但它想表达的是一个很明确的工程观点 不是所有代码错误都需要 AI Agent。有些失败更适合进入一个本地、可解释、可验证的 Repair Loop。