AI工具调用参数校验：为什么JSON Schema不是形式主义

AI工具调用进入生产后，很多事故看起来像“模型不听话”，实际是工具参数没有边界。用户让模型创建工单，模型把整段对话塞进标题；让它查询订单，模型把自然语言问题直接传给接口；让它调用搜索，模型把内部提示词也带进关键词。这些问题不是靠多写几句系统提示就能彻底解决。

更稳的办法，是把工具调用当成普通API调用来治理：入口有Schema，参数有类型和长度，枚举值有白名单，默认值可解释，失败时有可观测记录。

Schema先管住形状

工具定义里的JSON Schema不应该只是给模型看的说明书，也应该是执行前的硬校验。字符串、数字、数组、对象、必填字段、最大长度、正则格式，都要在工具层重新检查一遍。模型输出看起来像JSON，不代表它就适合直接执行。

例如“发送消息”工具，收件人、标题、正文、附件、是否外发，都应该分开校验。正文可以长一点，标题必须短；收件人必须来自允许列表；附件路径不能随便填本地绝对路径。

枚举比自由文本更适合高风险参数

凡是会影响成本、权限、外发或写入的数据，都尽量不要让模型自由生成。模型名、动作类型、数据源、审批级别、目标环境，都适合做枚举。这样即使模型理解错了任务，也很难凭空创造一个危险目标。

在AI中转站里，模型选择、工具权限和预算策略都可以按Key或项目配置。通过 https://top-api.cc 这类统一入口，开发团队可以把“可调用哪些模型、可走哪些工具、单次最多消耗多少”从业务代码里抽出来，减少每个应用重复实现校验逻辑。

错误修复要可控

模型第一次生成的参数不合法时，可以允许一次修复，但不要无限循环。修复请求要只包含校验错误和必要上下文，不要把完整敏感输入反复送回模型。每次修复都应该记录失败字段、错误类型和最终处理结果。

如果修复后仍然不合法，应该返回明确错误，而不是让业务接口猜测模型意图。

测评清单

• 工具调用前是否执行真实Schema校验
• 高风险字段是否使用枚举或白名单
• 字符串长度、URL、邮箱、路径是否有格式限制
• 参数非法时是否只允许有限次数修复
• 修复日志是否能定位失败字段
• 工具层是否阻止模型绕过默认值和隐藏参数

结语

AI工具调用的可靠性，不只来自模型能力，也来自参数边界。Schema、枚举和失败修复机制做好了，AI Agent才不容易把“看起来合理”的文本变成不可控动作。