我以为是模型问题的代理bug,结果出在框架上
摘要
作者分享了一次调试经历:代理循环是由框架截断工具输出导致的,而非模型故障,突显了代理基础设施相比模型存在的可靠性差距。
花了三天时间调试一个代理,它反复调用同一个网络搜索工具。第一时间想到的是模型无法处理架构。从Sonnet换成Opus,再换成GPT-5。同样是循环。换了框架。循环不同,但模式相同。最终追踪到问题在于框架在工具输出超过默认token预算时静默截断。工具返回了一个很长的JSON数据块,框架在响应中途将其截断,模型看到似乎是未完成的答案,于是不断再次调用工具。截断操作没有在任何地方记录。追踪只显示调用发出和部分响应返回。在当今这个时代(接近2026年中),模型几乎从来不是工具可靠性的瓶颈。框架层才是。有很多关于模型工具调用的排行榜,但没有哪个框架能最可靠地处理实际工具I/O的排行榜。大家实际部署的最可靠的框架是什么?
相似文章
你的框架辜负了你的智能体,但却没有基准来证明这一点
本文强调了缺乏用于评估智能体框架可靠性的基准测试,重点探讨了与模型本身相比,MCP 实现如何更好地处理工具调用和错误。
升级模型后,你的代理持续出错。Cursor的工程笔记解释了原因。
Cursor的工程笔记揭示,代理失败往往源于框架(脚手架)而非模型本身,不同供应商的工具格式差异会导致静默错误和可靠性问题。
@sydneyrunkle: 假设智能体 = 模型 + 工具套件。不幸的是,好的模型越来越贵!所以你需要一个出色的工具套件来…
关于通过改进工具套件组件来优化AI智能体性能的指南,以补偿昂贵的模型成本,重点关注爬山技术。
你的 AI Agent 没坏,是你的控制框架没配好。来看看我是如何搭建这套系统,让它从“累赘”转变为能交付生产级代码的。
本文指出,AI 编程智能体的失败源于系统设计不佳,而非模型能力限制。文章提出了一套包含知识、护栏和反馈循环的三层“控制框架”,以可靠地交付生产级代码。
模型是CPU,不是整台电脑——为什么智能体性能的提升,框架与模型升级同等重要
文章认为,对于智能体性能而言,框架(模型周围的系统)与模型本身同等重要,并引用了多项基准测试和实验的证据。