我用AutoGen、CrewAI、LangGraph和MetaGPT与我的Agent OS进行了基准测试。“LLM-as-a-judge”范式完全失效。以下是本地数据。
摘要
本文对五种AI代理框架在严格的Rust编码任务上进行了基准测试,结果显示,使用LLM评委的框架经常失败或幻觉成功,而采用机械验证方法则产生更可靠的结果。
我根据它们的网站推测了它们的方案,当然它们实际更复杂。我设置了一个本地的“Agent Arena”(使用RTX A4500上的qwen2.5-coder:14b)来测试5个AI代理框架在超高严格编码任务上的表现。经典的多代理“蜂群”要么幻觉成功,要么在无意义的辩论中消耗50万+代币,要么对完全离题的代码盖章通过。只有依赖机械验证(实际编译器/代码检查工具)而非“LLM评论家”的框架产生了可行结果。挑战:“三重约束”我要求每个框架构建一个Rust中的身份验证和速率限制中间件,必须满足三个矛盾的约束:绝对安全:使用加密哈希(sha2)和时序攻击保护(subtle::constant_time)。性能:在10k请求负载下延迟低于1ms。严格质量:100%单元测试覆盖率和0个clippy警告。黄金规则:所有人使用相同的本地模型(qwen2.5-coder:14b),隔离环境(沙箱),相同的脚手架。禁止通过付费外部API作弊。结果剖析(它们如何失败)1. AutoGen:代币黑洞(盲目辩论)方案:群聊(编码器 ↔ 安全评论家 ↔ 性能评论家)。发生了什么:代理们循环辩论了6轮,消耗了517,000个代币。他们最终达成“共识”……却是一个测量延迟的离题脚本,而非处理身份验证。评论家代理对完全不稳定的测试盖章通过。2. CrewAI:橡皮图章方方案:层级链(架构师 → 质量保证 → 审查员)。发生了什么:代码机械性通过(测试和clippy通过),但逻辑完全偏离。它编码了WebSocket握手,完全忽略了加密哈希和恒定时间执行。质量保证“审查员”看到代码编译通过,就批准了整个东西,而没有检查原始规范。3. MetaGPT:过程幻觉方案:“软件公司”级联(SOP)。发生了什么:它生成了一个几乎空的源文件(1行代码),但写了一份高度详细的912字节的最终质量保证报告,声称测试详尽且基准测试成功。这对自主管道绝对危险。4. LangGraph:诚实失败方案:有限状态机(FSM)/有向图。发生了什么:最确定性的方法。它确实尝试实现安全原语,但在6次迭代限制内未能编译Rust代码。它没有撒谎,循环干净地停止并报告了一个诚实的错误。5. GenOS(我的框架):机械验证方案:并行蜂群(实现、安全、质量保证)+由真实工具(Cargo)守护的中央集成,由基因组特征(如risk_tolerance)驱动。发生了什么:它是唯一交付了三个安全约束(SHA-256、验证、恒定时间subtle)的框架,采用模块化的117行架构。5个单元测试中,3个通过。关键点:不是让“LLM质量保证代理”假装成功,GenOS面对编译器的现实并以坦率的INTEGRATION_INCOMPLETE状态终止。它不对开发者撒谎。原始数据框架代币(输入/输出)LLM调用数安全规范满足?代码行数最终状态AutoGen 517k / 15.4k 14 ❌ 否 22 共识(离题)CrewAI 371k / 6.4k 8 ❌ 否 36 批准(逻辑完全偏离)LangGraph 206k / 6.9k 9 ✅ 是(尝试)43 编译错误MetaGPT 36k / 1.6k 4 ❌ 否 1 幻觉报告GenOS 205k / 8.6k 7 ✅ 是(SHA256+subtle)117 INTEGRATION_INCOMPLETE结论:停止支付多代理税这项测试证明,“LLM-as-a-judge”范式(使用LLM评审另一个LLM的代码)是架构上的死胡同。模型最终会耗尽,失去原始上下文,并验证绝对垃圾内容以退出辩论循环。对于代理系统在生产中可行,出口验证不能来自扮演评论家角色的LLM。它必须来自确定性的机械验证(linter ASTs、退出码、测试断言)。所有原始数据(JSON、日志和测试工具)都是可复现的。还有其他人注意到这种行为吗?当你的代理同意一个糟糕的解决方案仅仅是为了完成任务时?我试图击败SAT/CDCL时就遇到了这种情况。
相似文章
AgentJudgeBench:一个用于评估LLM法官在代理工具调用中的多难度基准
AgentJudgeBench是一个基准,用于评估LLM法官在代理工具调用场景中的可靠性,揭示了结构性上限等限制以及真实情况对对齐的微妙影响。
构建了一个 LLM 在结构上被禁止生成最终输出的 Agent,寻求反馈以及愿意尝试“攻破”它的人
作者描述了一个基于 LangGraph 构建的 AI Agent,旨在复现生产环境中的 Python 崩溃问题。其独特之处在于架构设计:LLM 负责规划行动,而确定性 Python 函数则生成最终测试代码,以确保可靠性。
@LangChain: .@HeggieConnor 在 @unifygtm 的规则:如果代理运行在 GPT 上,那么对其评分的法官需要运行在不同的模型 fa…
文章讨论了 HeggieConnor 在 unifygtm 提出的一条规则,指出在评估 AI 代理时,评分模型应来自与代理模型不同的模型家族,以避免模式崩溃或群体思维。
移动智能体评估中的 LLM 评判器基准测试
本文介绍了 MobileJudgeBench,一个包含 931 条人工标注轨迹的基准,用于系统评估移动智能体任务中基于 LLM 的评判器。研究发现,带有采样屏幕截图的简单基线评判器可与专用方法相媲美甚至更优,而 LLM 主干是质量的主要驱动因素。
超越排行榜:大型语言模型代理中工具使用、规划与推理失败的综合分析
本文综合了2023-2026年间27篇基准测试、分类学和审计论文,形成了一个统一的LLM代理局限性分类体系,识别出六大失败集群,包括工具调用错误、规划失败、长期退化、多代理协调问题、安全性问题以及测量有效性问题。