获课：xingkeit.top/16935/

工具调用的硬仗，参数校验和错误重试比模型本身更磨人

做Agent开发这一年多，让我最头疼的不是模型能力不够，而是工具调用这个环节总在关键时刻掉链子。模型明明理解了用户意图，工具也选对了，但就是参数传得不对——要么格式不匹配，要么必填字段漏了，要么类型对不上。更麻烦的是，有些调用第一次失败了，自动重试之后又成功了，但两次结果不一致，你到底信哪一次？工具调用这个环节，仿佛是把所有非确定性风险都集中在了短短几毫秒的时间里，而我们要做的，就是在这片混沌里建立起一套能兜底的秩序。

先说参数校验这件事。模型的输出是概率性的，即使你用最严谨的function calling格式，它仍然有可能生成一个不存在的枚举值、把一个数字字段传成字符串、或者干脆漏掉一个必填参数。面对这种局面，我最深的体会是：不要信任模型给你的任何参数，你必须在代码里重新校验一遍。

这不是对模型的不信任，而是对概率系统的基本敬畏。一个90%的正确率意味着每十次调用就有一次是错的，在生产环境里这不可接受。所以任何工具调用的入口都必须有一个“门卫”——检查参数的完整性、类型、范围、枚举合法性。校验不通过的，直接拒绝执行，把错误信息回传给模型让它重新生成。

但这个校验逻辑怎么写，里面的取舍挺有意思。我们早期的做法特别严苛，参数里多了一个多余字段都报错，结果是模型频繁重试，用户体验很差。后来调整为“宽松校验+模糊容错”：只要核心参数齐全、类型可转换、枚举值能近似匹配，就放行。比如预期是枚举值"week"，模型传了"weekly"，我们用字符串包含匹配而不是完全相等来判断，虽然牺牲了一点严谨性，但大幅减少了不必要的重试。这种工程上的妥协在很多场景下比死守规范更务实。

再说错误重试。工具调用失败的原因五花八门：网络抖动、下游服务超时、参数不合理、业务状态冲突。但最常见的其实只有一种：瞬时性错误，重试一下就能好。我们分析了日志之后发现，大约七成的工具调用失败在第一次重试后就成功了，这说明大部分错误跟模型本身无关，纯粹是调用链路上的偶发问题。

但是重试不是简单地把同样的请求再发一遍，这里面有几个容易忽略的点。第一是重试的幂等性——如果工具做的事是扣款或者发送通知，你重试一次就意味着用户可能被扣两次钱、收两条短信。这类操作绝对不能自动重试，必须走人工确认流程。第二是退避策略——失败后立刻重试，往往还是会失败，因为下游服务还没恢复。指数退避加上随机抖动是比较成熟的做法，给下游留出恢复的时间窗口。

更棘手的是“调用错乱”。这个现象怎么发生的呢？模型在一次响应里决定调用两个工具，分别获取A和B的数据。结果第一个调用成功了，第二个调用参数错了，这时候Agent该怎么处理？我们一开始的简单做法是：第二个失败了就重试，直到成功。但后来发现这会导致“串行依赖陷阱”——第二个工具的重试占用了太多时间，用户早就不在原来的对话上下文中了。

后来我们换了一个思路：对于多工具并发调用，任何一个调用失败，整个批次的执行结果都视为部分失败，只把成功部分的数据返回给模型，同时明确告知哪些工具调用失败了。 这样做的好处是模型可以感知到“有的工具没调通”这个事实，它可以根据这个信息调整自己的决策。比如它原本想结合A和B的数据给一个综合回答，现在B的数据拿不到，它可以选择只基于A来回答，也可以引导用户重新提问。把失败信息完整地暴露给模型，比隐藏起来让它“看起来成功”更负责任。

还有一个细节：调用重试时的上下文丢失问题。很多Agent框架在重试时会把当时的对话状态快照下来，但如果重试过程中用户又发了新消息，原来的重试是否应该继续？我们的做法是：一旦用户有新输入，所有正在进行的重试立即取消。因为用户的新输入意味着上下文的转变，原来的工具调用即使成功了，结果也可能不适用于新的语境。及时放弃比坚持完成更符合对话的交互逻辑。

最后想聊一个不那么技术的话题：工具调用的可观测性。在这个环节，日志的详细程度直接决定了你排障的效率。每一条工具调用日志至少要包含：调用的工具名、传入的参数（脱敏后）、返回的结果或错误信息、耗时、重试次数。有了这些信息，线上的问题基本不用猜，翻开日志一看就知道是模型参数生成错了还是下游服务挂了。很多团队在初期不太在意这个，觉得调试的时候看看控制台就行，等上了生产之后才发现两眼一抹黑。在工具调用这个充满不确定性的环节里，日志不是辅助，而是你的另一双眼睛。

说到底，工具调用是Agent与外部世界交互的窗口，这个窗口的稳定程度直接影响用户对Agent的信任。模型可以偶尔犯傻，但如果工具调用老是出错，用户只会觉得这个系统很“笨”。把校验逻辑写严谨一点、重试策略设计合理一点、失败信息暴露清晰一点，这些工程层面的扎实用心，比一味追求模型能力的提升更能在短期内改善用户体验。因为用户感知到的，永远是你最弱那一环的表现。