用Python搭建编码智能体修复闭环

让 AI 修代码，难点不只是生成一段补丁，还在于它能否识别失败、验证修改，并在修坏时退回去。原文围绕 CodeForge Pro，给出了一条用 Python 串起语法检查、测试执行和自动修复的路线。

这套思路值得借鉴，但「企业级」「沙箱」「100% 回滚保证」需要拆开看：文章展示了两个基础函数和一组修复指标，没有提供足够材料证明整套系统的可靠性。读它最有用的方式，是提取闭环设计，同时认清示例代码的能力边界。

为什么修复闭环要先接上确定性检查

作者的出发点是：LLM 按概率生成代码，代码能不能运行却需要确定的判断。模型给出一个看起来合理的补丁，不代表缩进正确、标识符有定义，更不代表行为符合需求。

他们设计的流程是：先运行测试，提取失败信息，再形成修复假设；候选代码通过 AST（抽象语法树）检查后才写入文件，接着重新测试，失败就回滚。

模型负责提出候选方案，检查器负责判断它是否满足明确条件。

下面这段代码解决的是补丁落盘前的语法筛查：

import ast

def validate_syntax(code_str: str) -> tuple[bool, str | None, int | None]:
    try:
        ast.parse(code_str)
        return True, None, None
    except SyntaxError as e:
        return False, e.msg, e.lineno

要看的是 ast.parse(code_str)：它能发现语法问题，但不能证明变量已经导入、执行不会报错或业务逻辑正确。作者称语法错误可在亚毫秒内被拒绝，却没有交代代码规模和测试环境。

原文还提出三种结构分析：遍历 ast.FunctionDef、ast.ClassDef 提取函数与类；统计 If、For、While、ExceptHandler、With 等节点评估复杂度；扫描 eval、exec 和危险 shell 调用。

这些可以成为筛选信号，但不能直接推出「补丁一定更简单、更安全」。尤其是安全审计，仅扫描几个危险调用，覆盖不了完整的执行风险。

子进程能隔离执行，为什么还不能叫安全沙箱

测试是修复闭环的证据来源。作者不把候选代码放进 Agent 主进程，而是用异步子进程运行，避免测试直接拖垮主流程：

import asyncio
import sys

async def run_test_suite(test_file: str, timeout_sec: float = 10.0):
    proc = await asyncio.create_subprocess_exec(
        sys.executable, test_file,
        stdout=asyncio.subprocess.PIPE,
        stderr=asyncio.subprocess.PIPE
    )
    try:
        stdout, stderr = await asyncio.wait_for(proc.communicate(), timeout=timeout_sec)
        return proc.returncode == 0, stderr.decode("utf-8")
    except asyncio.TimeoutError:
        proc.kill()
        return False, "TIMEOUT: Execution exceeded safety boundary."

这里要看 asyncio.wait_for(..., timeout=timeout_sec)，默认 10.0 秒后终止等待。它提供的是时间限制，代码没有展示文件系统、网络、权限或内存限制，不能据此认定已经具备安全沙箱。

实现上还有两个缺口：超时后调用 proc.kill()，没有继续等待进程退出；虽然收集了 stdout，返回值却只带 stderr。如果测试工具把失败详情写到标准输出，后续诊断就可能丢掉关键证据。

作者反对把 500 行终端输出直接塞给模型，主张提取失败测试、异常类型和出错代码位置。例如定位到 TestCalculator.test_empty_list_zero_division，再附上 ZeroDivisionError、AssertionError 或 IndexError 及对应源码。

这个方向合理：先把日志变成可定位的诊断，再让模型决定修改位置。不过原文没有给出 traceback 解析器，能否兼容不同测试框架，尚无从判断。

自动修复的关键，是验证失败后还有退路

CodeForge Pro 的修复循环包含五步：建立测试基线、结合 traceback 与 AST 符号关系生成替换方案、检查语法、应用补丁并重跑测试、成功后接受修改或失败后回滚。

其中最有价值的是基线。没有修改前的测试结果，Agent 就难以区分原有故障和自己引入的回归。

复杂任务还引入 Tree-of-Thought（ToT，思维树）规划。TreeOfThoughtPlanner 同时探索三个方向：补边界检查、把循环替换为推导式、在函数入口规范化输入，再按结构复杂度与安全指标评分，剪掉不合格分支，优先执行复杂度最低的候选。

但复杂度最低，不等于语义最正确。作者举出的空 try/except: pass 就说明，补丁可以通过掩盖异常让表面结果变好。多分支规划最终仍要接受行为验证。

作者报告，在算术、字符串规范化和边界条件回归任务中，平均诊断时间为 18.2 ms，首次修复成功率为 84.6%，平均总修复时间为 142.0 ms，并宣称有 100% 原子回滚保证。

这些是作者报告的结果。文章没有给出样本量、模型配置、硬件、计时范围或对照方案，也没说明 142.0 ms 是否包含真实模型调用。它不足以代表一般代码仓库中的修复表现，更不能证明任意失败都能完整回滚。

我的判断

我认可它把 AST、测试、诊断和回滚串成闭环的方向。相比生成补丁后直接交付，这种设计让每次修改都有机会接受机器检查，也能减少人工反复搬运错误信息的工作。

但文章把几种不同层次的保证放在了一起：语法通过、测试通过、运行环境安全、仓库状态可恢复，分别需要不同机制。测试通过只能说明已执行的检查通过，不能替代安全隔离和完整性证明。

原文开头拿商业平台每席每月 $20–$50 加 token 费用作对比，宣称纯 Python 可以免除持续 SaaS 开销。免除平台订阅费有可能，模型推理、执行资源和维护成本却没有交代。

文章最后销售完整 codeforge_pro 代码及手册，示例因此更适合作为架构说明。没有开放完整实现和对照数据之前，「企业级」与修复性能都应视为待验证的作者主张，而不是选型依据。

能拿来做什么

• 给日常 AI 修复任务保留修改前的测试结果，再比较修改后的失败项，避免把原有问题误判为新回归。
• 为补丁增加低成本检查。Python 可先用 ast.parse 筛掉语法错误；前端和 Node 项目可借鉴分层验证思路，接入项目已有的语法检查、类型检查与测试。
• 把失败测试名、异常类型、文件位置和相关源码整理后交给模型，同时保留完整日志，方便诊断摘要漏掉信息时追查。
• 从单文件、边界明确的修复开始尝试闭环，提前确定文件恢复方式；涉及不可信代码时，单独设计权限和资源隔离，不能只依赖子进程超时。