我构建了一个基准测试,用来检验AI代理是否违反架构规则。结果显示没有违规。(空结果,附带测试工具和数据)
摘要
一项基准研究测试了AI编码代理是否在TypeScript仓库中违反导入边界规则,发现所有模型和条件下均无违规,这挑战了严格执法规则的必要性。
常见的说法是:你的CLAUDE.md/AGENTS.md是指导,lint规则是执行,而AI编码代理会偏离文本,因此你需要确定性的规则。我想量化这个差距。我从近乎全面的24,888个公共TypeScript仓库中挖掘了一个真实的导入边界规则(请求入口文件不得导入UI组件),然后在现实编码任务上运行了Claude、GPT和Gemini,跨四种条件,从无防护的控制到将规则安装为硬性lint错误。接着,我针对最容易出错的情况:让任务更长,并故意引导其趋向违规,在无防护情况下运行了一组更便宜、更弱的模型。在所有运行的模型和条件下:零违规。即使没有规则和指导。即使是较弱的模型。在这个规则上,没有什么需要执行来修复的。这是一个狭窄的结果(一个导入边界,一个仓库),我在文章中对此很谨慎。尽管如此,我还是发布了这个空结果,连同预注册、测试工具和原始运行数据,因为负面结果是我们避免追逐相同死胡同的方式。好奇是否有人能让代理打破我未能打破的推断导入边界。
相似文章
我为编码智能体的“记忆”构建了一个基准测试,期待他人来挑战它
开发者创建了一个名为 continuity-benchmarks 的新基准测试,用于测试 AI 编码智能体在活跃开发过程中保持与项目规则一致性的能力,解决了现有记忆基准测试的空白——这些测试侧重于语义回忆而非实时架构一致性和多会话行为。
@vicky_grok: 这真是不可思议 我们对4种不同的AI代理架构在完全相同的120个任务套件上进行了基准测试。The wi…
对四种AI代理架构的基准测试表明,基于验证的设计达到了100%的成功率,这突显了架构选择比原始步骤预算对性能更为关键。
我用AutoGen、CrewAI、LangGraph和MetaGPT与我的Agent OS进行了基准测试。“LLM-as-a-judge”范式完全失效。以下是本地数据。
本文对五种AI代理框架在严格的Rust编码任务上进行了基准测试,结果显示,使用LLM评委的框架经常失败或幻觉成功,而采用机械验证方法则产生更可靠的结果。
这里每个人都测量进入代理记忆的内容。我测量了代理是否真正遵守它。737 次警告,0 次违规,阈值事先写定。
作者开发了一个名为 scar-cli 的开源工具,用于测量 AI 代理是否真正遵循注入的规则,在自己的仓库中报告了 737 次规则触发,零违规,并邀请社区测试。
AI编码代理是否遇到了瓶颈,还是我们衡量它们的方式出了问题?
本文探讨了AI编码代理的炒作与现实之间的差距,认为它们对于加速工作流程的某些部分有效,但在架构、调试和审查方面仍需人工监督,并质疑当前基准测试是否衡量了正确的东西。