我以为是模型问题的代理bug,结果出在框架上
摘要
作者分享了一次调试经历:代理循环是由框架截断工具输出导致的,而非模型故障,突显了代理基础设施相比模型存在的可靠性差距。
花了三天时间调试一个代理,它反复调用同一个网络搜索工具。第一时间想到的是模型无法处理架构。从Sonnet换成Opus,再换成GPT-5。同样是循环。换了框架。循环不同,但模式相同。最终追踪到问题在于框架在工具输出超过默认token预算时静默截断。工具返回了一个很长的JSON数据块,框架在响应中途将其截断,模型看到似乎是未完成的答案,于是不断再次调用工具。截断操作没有在任何地方记录。追踪只显示调用发出和部分响应返回。在当今这个时代(接近2026年中),模型几乎从来不是工具可靠性的瓶颈。框架层才是。有很多关于模型工具调用的排行榜,但没有哪个框架能最可靠地处理实际工具I/O的排行榜。大家实际部署的最可靠的框架是什么?
相似文章
我的AI代理在不同会话间不断丢失自身状态,因此我选择重建工具链而非更换模型
作者发现AI代理的可靠性问题源于工具链而非模型,通过分离上下文跟踪、加载和输出检查来改进,同时致力于版本控制以管理跨项目的代码。
你的框架辜负了你的智能体,但却没有基准来证明这一点
本文强调了缺乏用于评估智能体框架可靠性的基准测试,重点探讨了与模型本身相比,MCP 实现如何更好地处理工具调用和错误。
升级模型后,你的代理持续出错。Cursor的工程笔记解释了原因。
Cursor的工程笔记揭示,代理失败往往源于框架(脚手架)而非模型本身,不同供应商的工具格式差异会导致静默错误和可靠性问题。
Claude Code 春季的性能回退是 harness 层的 bug,而非模型问题。我将 Claude Code 的 harness 与另外 11 个生产级代理做了对比。
作者对比了 Claude Code 与另外 11 个生产级 AI 编码代理的 harness 实现,指出三、四月的性能回退是 harness bug 而非模型问题,并总结出薄 harness 层的风险与改进建议。
我见过的最严重的智能体错误,都是我的工具造成的,而不是模型的错。
一位 MCP 服务器开发者分享了从智能体失败案例中总结的经验,指出许多看似是模型犯下的错误,实际上源于设计不佳的工具输出、含糊不清的选项,以及放错位置的指令。每一项修复都落实在工具中,而不是提示词中。