北京
把智能体的代码交给编码智能体去修，结果会怎样？一项来自中美多个实验室的研究给出了一个不太乐观的数字：9%。
这个数字来自一个专门为智能体框架Bug搭建的测试集。研究团队把真实的GitHub缺陷报告，自动转换成可以运行的测试用例，最终形成了一个包含200个Bug的基准，而且这个基准还在持续增长。
为什么这类Bug特别难修
智能体自己的代码，指的是模型之外的那一圈东西：工具调用、记忆、提示词。这些代码的Bug有个麻烦之处——它们依赖实时的模型调用，很难复现，也很难测试。
普通软件Bug有稳定的输入和输出，跑一遍就能看到问题在哪。智能体框架的Bug不一样，同样的代码，模型每次返回的内容可能都不同，问题时有时无。这让自动修复变得格外困难。
研究团队为此搭建了AgentBug-Smith，专门把GitHub上真实的缺陷报告转成可运行的测试。这样一来，原本难以复现的问题，至少有了一个可以反复验证的入口。
9%对比40%，差距在哪
在三个编码智能体中表现最好的那个，也只修好了9%的Bug。作为对照，同一类智能体在普通软件Bug上的修复率大约在40%左右。
差距的来源，指向了智能体框架Bug本身的特殊性：它们和模型的实时行为绑定在一起，不是单纯读代码就能定位的。
不过研究也发现了一个有意思的改善路径。给智能体一份简短的指南，内容是过去修复案例中总结出的经验，效果就变了——在79个没见过的Bug上，同一个智能体从只修对1个，提升到了修对6个。
从1到6，绝对数字依然不高，但方向很明确：过去的修复经验，是可以被复用起来的。
用之前，先拿旧Bug试试
这项研究指向的是一个更长远的目标——能够自我改进的AI智能体，最终需要有能力修复自己的代码。
但在那之前，研究给出的建议很务实：在把一个编码智能体用来处理你自己智能体的代码之前，先拿那些你已经修好的Bug让它试一遍。
这个做法成本不高，却能提前知道它在你这类问题上到底靠不靠谱。毕竟9%和40%之间的差距，不是靠信任能填上的。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
