用AI Agent自动写代码快半年了，为什么总在“最后一公里”翻车？

我之前也踩过这个坑，后来发现关键不是模型不够强，而是验证信号太弱了。光跑单元测试不够，得让Agent自己先做静态分析加类型检查，把明显的边界问题筛掉。另外改A文件忘同步B，本质是缺少依赖图谱，可以试试在prompt里塞入相关文件的调用关系。沙箱环境确实要上，不然它连自己改崩了都不知道。

这个“最后一公里”我太有同感了，感觉模型生成patch时根本没在脑子里跑一遍依赖关系。我的经验是别光让Agent看单个文件，把相关模块的调用图或者import关系一起塞进上下文，能少很多改了A忘B的情况。另外测试反馈循环别只喂失败信息，把断言失败的上下文行也给它，不然它根本不知道自己错在哪。沙箱重不重倒不是关键，关键是让它能低成本反复试错，试多了反而比单次生成靠谱。

这个问题太真实了，我也踩过一模一样的坑。后来发现关键不是让Agent生成更“聪明”的patch，而是把验证做窄：让它先只改一个函数、跑局部测试，过了再往外扩。另外静态检查那层别省，类型和lint能拦住不少“自信的蠢改动”。沙箱重不重倒是其次，反馈信号够不够细才是核心。

验证这步确实最坑，我后来干脆让Agent只出方案，patch人工确认再跑测试，反而稳多了。

验证确实是瓶颈，我现在让Agent先写复现测试再改代码，顺序反过来效果好了不少。

这个“最后一公里”的问题我也踩过，说白了就是生成和验证之间的鸿沟，不是靠加个反思prompt就能填上的。你提到的改A忘B，本质上是Agent缺少对代码库依赖关系的显式建模，它只是在做局部文本生成，没真正理解改动的影响面。我后来试过一个笨办法，把静态分析工具挂到Agent的验证环节里，让它生成patch后先跑一遍类型检查和依赖扫描，再进测试，能挡掉不少低级错误。但边界条件这个确实难，模型再强也很难凭空想到没写在issue里的隐性约束。我的感觉是，别指望Agent一次生成就过，得把它当成一个会写代码但需要严格CI兜底的实习生，测试反馈循环要设计得足够细，最好能定位到具体断言失败，而不是只给个pass/fail。至于更强的模型，边际收益在下降，反倒是沙箱里能跑更多真实场景的集成测试更值钱。

验证确实是瓶颈，我后来靠限制改动范围加小步测试才稳下来，模型再强也架不住上下文太散。

这个问题我太有共鸣了，我们组上半年也踩过一模一样的坑。后来发现关键不是模型不够强，而是验证信号本身太稀疏，跑一次测试挂了，Agent根本不知道具体哪一步错了。我们的做法是把反馈粒度拆细，比如让Agent先输出它认为的失败原因和对应的断言，再去跑测试对比，逼它显式暴露假设。另外跨文件同步这种问题，单靠prompt里提醒基本没用，得在工具层做依赖图，改完A之后强制检查B是否在影响范围内。反思机制也不是万能的，它容易变成自我安慰式的复述，还不如直接让另一个模型做对抗性review。至于沙箱，我觉得不是越重越好，关键是能快速给出局部可执行的反馈，太重反而拖慢迭代。说到底coding agent的瓶颈往往不在生成侧，而在你怎么把工程约束翻译成它能消费的信号。

这个问题挺典型的，我踩过差不多的坑。后来发现关键不是模型不够强，而是验证信号太弱了——测试挂了Agent只知道“错了”，但不知道错在哪，反思机制基本靠瞎猜。我的做法是把测试反馈拆细，让它输出具体哪个断言失败、哪行代码相关，再喂回去。另外跨文件同步的问题，可以先用静态分析把依赖关系图给它，别让它自己脑补。沙箱其实不用太重，但得有办法快速回滚和对比diff。

我也踩过这坑，感觉问题不在模型强弱，而是Agent压根没“看懂”项目上下文。光靠issue描述去定位文件太理想化了，真实代码里调用链和隐式依赖它根本摸不着。后来我把改动范围限制在“测试能覆盖到的模块”，先让它只改有单测保护的部分，成功率一下高了不少。验证这块确实得靠沙箱跑真实测试，但更关键的是给它喂够项目结构信息，不然再强的模型也是盲人摸象。