工具调用不能只看演示效果
工具调用演示顺畅，并不代表它已经适合真实用户。演示里通常只有一个明确问题、一个工具和一组规范参数；真实环境中，模型可能选择不该使用的工具、漏掉字段、混淆单位、重复调用，工具本身也可能超时、返回空结果或遇到权限限制。若把模型输出直接传入业务函数，错误往往会从一次格式异常迅速升级为越权操作、重复写入或难以解释的用户体验。
工程化的重点不是让模型“永远输出合法 JSON”，而是把模型生成内容当作不可信输入。工具注册、参数校验、权限判断、调用预算和结果处理都应由控制层负责。模型可以提出动作请求，系统决定该请求是否允许执行。
工具接口先要有清楚的契约
每个工具应说明用途、输入字段、类型、允许范围、默认值、返回结构、可能错误和副作用。描述越模糊，模型越容易用错误参数碰运气；描述再清楚，也不能替代运行时校验。工具契约应由代码中的模式或类型定义表达，并在调用入口统一验证。
输入校验不只是检查 JSON 能否解析。字符串长度、枚举值、数值范围、时间格式、资源标识、列表大小和字段组合都可能影响安全与成本。对于需要用户身份或上下文的操作，还要验证该身份是否有权访问目标资源，不能仅凭模型生成一个看似正确的标识就执行。
输出也需要稳定结构。调用方应能区分成功、输入不合法、权限拒绝、暂时不可用、资源不存在和内部错误等情况。把所有失败都拼成一段自然语言，会让后续模型和用户界面难以作出正确处理。
解析失败时要克制，而不是猜测修复
模型有时会在结构化结果外加说明、代码块或多余文本。若接口允许这种包装，控制层可以从明确的协议边界中提取有效部分；如果结构不满足协议，应返回可诊断错误或要求模型重新生成。解析规则必须保守，避免从一段混合文本里“猜出”一个可能错误的动作。
所谓自动修复尤其需要谨慎。简单替换引号、删除逗号或截取括号，可能在低风险只读工具中改善体验，却也可能改变参数含义。对写操作、金融、权限、文件删除或外部消息发送，不应依据模糊修复后的内容直接执行。应要求结构化重新确认，或转为人工和规则校验。
不要使用执行任意字符串的方式处理模型输出。即使内容来自看似受控的会话，也可能被用户输入、工具返回或上下文污染影响。模型产物只能作为数据解析，绝不能作为脚本、表达式或命令直接运行。
工具注册表是允许清单，不是名称匹配
系统应只暴露明确注册且已审核的工具。模型提出的名称需要在允许清单中精确匹配，不能因为名称相近就自动选择某个函数。废弃工具、内部调试接口和高权限管理操作也不应随意出现在模型可见的工具集合中。
不同任务应看到不同的工具集。回答产品说明的 Agent 不需要修改账户的能力，分析日志的 Agent 不需要拥有部署权限。按任务、用户和环境缩小工具可见范围，能减少模型误选和提示注入带来的影响。工具数量越多，选择错误的概率和测试成本也会增加。
工具版本同样需要管理。接口字段或行为变化时，模型描述、校验模式和执行实现要同步更新；新旧版本并存时，应有明确迁移策略。仅修改底层函数而不更新契约，常会造成模型仍按旧格式调用。
每次调用都要经过权限和业务门禁
参数合法不代表操作可以执行。一个“创建订单”“导出数据”或“发送通知”的请求，还需要检查发起身份、目标资源、环境、审批状态、频率限制和业务前置条件。门禁应独立于模型，不接受模型自称“已获得授权”作为证据。
有副作用的工具需要幂等键、操作记录和可回退或补偿策略。网络超时后，客户端可能不知道调用是否已经完成；若系统直接重试，可能产生重复写入或重复发送。执行前后的状态查询、稳定的操作标识和有限重试，是处理不确定结果的基本手段。
高风险操作可先生成计划或预览，再由规则或人工确认后执行。确认必须绑定具体参数和有效期，不能让一次模糊批准覆盖后续任意动作。若等待期间资源状态变化，也应在执行前重新校验。
调用预算与超时防止失控
模型可能因为工具错误或不完整结果反复尝试。为会话和任务设置工具调用次数、总耗时、并发和费用预算，达到上限后停止并返回当前状态。限额不是为了惩罚用户，而是防止一个坏分支持续消耗资源或对下游造成压力。
超时和重试应按工具类型区分。查询类工具可能允许有限重试，写操作则需要先确认上次结果；外部服务限流时，应该退避或转为稍后处理，而不是立即并发重发。重试理由和次数应留在任务记录中，人工接手时才能理解系统已经做过什么。
工具结果也应限制大小和敏感内容。大量原始日志或文档直接送回模型，会增加上下文成本并可能泄露数据。控制层可以提供摘要、分页或受限查询，让模型按需获取信息，而不是一次读取全部内容。
观测和测试覆盖失败路径
生产环境需要知道哪些工具被调用、成功率如何、参数校验失败是否增加、调用是否超时、预算是否触发、哪个模型或版本发起了请求。观测事件应使用任务标识和脱敏参数摘要，不要把完整用户内容、凭据或敏感结果写入通用日志。
测试不能只验证一次正确调用。还要覆盖未知工具、缺失字段、类型错误、权限拒绝、外部超时、重复请求、异常结果和调用上限。对每种情况确认系统是否拒绝在正确位置、用户是否得到可理解提示、是否没有产生副作用。回归测试应锁定工具契约和控制规则，而不是强依赖模型某一段原始措辞。
工具调用的可靠性来自清楚的契约和严格的控制层。模型负责表达意图，系统负责验证、授权、执行和记录；演示环境中看不见的失败路径，才是真正决定产品能否上线的地方。
