工具调用状态应该由模型持有还是应用持有?
摘要
一场关于开发实践的讨论:将工具调用的运行时状态交由 LLM 维护(提示词更简洁,但重试处理易出问题),还是由应用自己管理(控制流更清晰,但智能体的自主性随之减弱),其中超时后出现重复或过期的工具调用是最典型的故障模式。
我在一个小型应用中反复遇到这个问题。如果由模型来持有运行时状态,提示词会更简洁,但重试和部分失败的情况很快就会变得混乱。如果由应用来管理状态,控制流更干净,但智能体又开始感觉像一条写死的脚本流程,而不是真正的 agent。我反复遇到的故障模式是:超时后出现重复或过期的工具调用——尤其是当前一个工具修改了状态、而后一个工具却假定它没有被修改的时候。
相似文章
当工具调用超时,你的智能体如何知道它是否真的执行了?
一位从业者提问:智能体框架应如何处理写操作工具的超时?需要权衡幂等键、读回验证以及当下游 API 不支持幂等时的人工介入等方案。
在生产环境中,你们如何在代理执行错误工具调用之前捕获它们?
关于在AI代理执行到生产环境之前检测和防止错误工具调用策略的讨论。
当给 agent 增加工具越来越多时,它开始调用错误的工具。让模型自己写代码来调用它们,是解决办法。
文章认为,随着 agent 的工具集不断膨胀,直接调用工具的方式会逐渐失效。更稳健的解决方案是让模型在沙箱中编写代码,把工具当作函数来调用——这能减少上下文中的 schema 噪音、降低错误调用率,代价则是需要关注沙箱安全问题。
AI代理的工具调用是否应在执行前进行检查?
讨论AI代理的工具调用是否应在执行前进行检查,探讨安全性和验证方面的考虑。
代理的重试逻辑会随代理一起消亡
作者分享了将一个具有写入权限的 AI 代理投入生产环境后的经验教训,指出当进程终止时,代理循环内部的重试逻辑会失效。他们主张将有副作用的工具调用视为带有幂等键的持久后台任务。