北京
让AI智能体自己修自己的代码，听起来是个闭环的好主意。但一项来自中美多个实验室的研究给出了一个不太好看的数字：面对智能体框架里的真实Bug，表现最好的3个编码智能体，只修好了9%。
作为对比，这些编码智能体在普通软件Bug上的修复率大约是40%。同一个工具，换了个场景，成绩掉了一大截。
为什么智能体自己的Bug这么难修
智能体的代码，指的是模型之外的那一圈东西：工具调用、记忆、提示词。这些代码的Bug有个麻烦的特性——它们依赖实时的模型调用。
模型每次返回什么，会影响Bug是否复现。这让问题很难被稳定地重现，也就很难写成测试用例。修Bug的第一步是复现，这一步卡住了，后面都无从谈起。
研究团队的做法是把真实GitHub上的Bug报告，自动转换成可以运行的测试。他们为此构建了一个叫AgentBug-Smith的工具，产出的成果是一个包含200个Bug的基准测试集，而且这个集合还在持续增长。
一份经验清单，把1次修对变成6次
研究里有个更值得注意的细节。他们给智能体配了一份简短的指南，内容是过去修复案例中总结出的经验教训。
在79个此前没见过的Bug上，这份指南把一个智能体的正确修复数从1次提升到了6次。
这说明问题不完全出在能力上。智能体缺的可能不是推理能力，而是关于"这类Bug通常长什么样、该怎么下手"的上下文。经验被显式地喂进去，表现就变了。
在信任它之前，先做一件事
研究给出的建议很直接：在你把智能体框架的代码交给编码智能体之前，先拿你已经修好的Bug去测它一遍。
用已知答案的题目摸底，比直接让它上手真实问题要稳妥得多。9%这个数字不是判决书，它更像一个提醒——自我改进的智能体要真正成立，得先学会修自己身上的毛病，而这件事目前还差得远。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
