你的框架辜负了你的智能体，但却没有基准来证明这一点

Reddit r/AI_Agents 新闻
ai-agents mcp tool-use benchmarking reliability error-handling

摘要

本文强调了缺乏用于评估智能体框架可靠性的基准测试，重点探讨了与模型本身相比，MCP 实现如何更好地处理工具调用和错误。

你可以针对函数调用、多轮工具使用以及 Schema 遵循情况来比较不同的模型。基本上，在模型层面已经有相当多的公开数据。那么为什么我在框架层面却找不到可靠性数据呢？我想看到的不是哪种模型调用工具的效果最好，而是哪种框架实现在面对格式错误的工具响应时，不会静默吞掉错误；哪种框架的重试机制能真正解决问题而不是使问题恶化；以及哪种框架能以模型能够真正进行推理的格式来暴露故障。我已将 MCP 作为默认的集成层，并开始将 MCP 服务器视为基础设施。但从我所见到的情况来看，MCP 实现的质量参差不齐，这种差异比我们愿意承认的更为显著。模型常常被指责为工具调用行为不佳的罪魁祸首，但很多时候，故障实际上出在它底层的处理层上。有人会对实际实现进行压力测试，而不仅仅是测试位于其上的模型吗？
查看原文

相似文章

停止在不公开执行框架的情况下比较LLM智能体

arXiv cs.AI

这篇立场论文认为，在长期跨度的LLM智能体任务中，执行框架（即围绕语言模型的上下文构建、工具交互、编排和验证的基础设施层）往往比模型本身更能决定性能，而当前的基准测试错误地将框架层面的提升归因于模型改进。它提出了一种框架感知的评估框架，包含披露标准和方差分解协议。

不是能力问题：LLM智能体层级间的控制敏感度是非单调的

arXiv cs.AI

本文通过实证测试了“更结构化的控制（harness）能普遍提高LLM智能体可靠性”这一常见假设，发现不同模型层级间存在非单调关系。它引入了HEAT-24基准，并揭示了严格的控制可能会损害前沿聊天模型，但有利于推理模型。