没人能说清他们的AI编码代理今天实际做了什么

企业在大手笔投入AI编码代理，但对它们的实际行为几乎毫无可见性：它们尝试了什么，什么无声地失败了，什么在最终落地前被反复重做了三次。阿里云的回应, , 一款名为LoongSuite Pilot的开源可观测性工具, , 将这一差距视为一个工具问题。很可能确实如此，但工具在投入高到足以引起注意之前并不存在，这一事实更值得玩味。

衡量这些代理的基准测试本身也有问题

一旦你追问这些代理的改进究竟是如何衡量的，可见性差距会进一步恶化。一篇关于自动框架演进（即让代理迭代改进其自身脚手架的做法）的新论文发现，许多报告中的提升看起来更像是过拟合到公开测试集，而非真正的能力提升。在头对头的实验中，简单的测试时扩展方法匹配或超过了演进后的脚手架，而演进后的脚手架对未调优过的任务表现出有限的泛化能力。对于一个经常引用框架演进基准来证明代理购买合理性的行业来说，这是一个严重的发现：如果上升的数字并不代表买家所认为的能力，那么企业已经在努力进行的ROI对话将变得更加难以诚实进行。

而且这些代理编写的代码默认未被检查

阿里云独立推出了会话内代码审查功能，在漏洞进入仓库之前就将其捕获，而不是依赖编码模型避免写出漏洞, , 这作为一个产品只有在AI生成代码默认未经审查的假设下才有意义。这是该公告中隐含的承认：该行业的编码代理一直在将代码直接投入生产仓库，而没有设置安全关卡作为标准做法，而供应商现在才将这一护栏作为可选附加功能而非基本要求来构建。

三个问题，同一个根源

投入无可见性、可能只是测量假象的能力提升、以及默认未经审查就投入生产的代码，纸面上是三个不同的问题。实际上它们共享一个根源：AI编码代理被采纳得太快，以至于用于观察、评估和保护它们的基础设施是在事后才建立的，作为对已表面问题的响应，而非事前预防。对于一个新技术类别来说，这并不罕见。Web应用在安全扫描成为标准之前也经历了同样的滞后，云基础设施在可观测性平台成熟之前也是如此。但不同寻常的是速度：编码代理在大约两年内从新奇事物变成了企业的重要预算项目，快到了工具生态无法跟上的地步。

对于今天正在运行这些代理的任何团队来说，实际含义是：他们目前信任的所有数字, , 投入效率、基准报告的能力提升、代码质量, , 都不应被视为表面价值，除非具备了这三篇文章所描述的可见性和审查层。代理变得很快。对它们实际行为的衡量仍在追赶。