说出来你可能不信，当我第一次上线带 Function Calling 的 LLM 应用时，最让我头疼的竟然不是模型回答得不好，而是它把工具参数填得乱七八糟。日志里翻一翻全是“经典场面”：一个数字类型的 price 字段，模型认真填了字符串 “19.9”；required 列表里明明写清楚需要 location，结果它只给了一个 time；最离谱的是，我限定 status 只能是 pending / done / failed，模型自作聪明填了个 completed。
那段时间我反复调 prompt、改示例，发现始终治标不治本。和几个也在做 LLM 应用的朋友聊了聊，大家基本都有同感：模型在 Function Calling 里的参数生成，天然就会跑偏，光靠“提示”根本没法根治。直到我下定决心把所有工具参数全部用结构化 schema 严格定义，并在运行时加了一道强校验，错误率才真正被压了下来。这篇文章就是我落这套“schema 约束 + 校验兜底”方案的全过程，从错误类型分析到设计思路，再到直接能抄的校验代码和排障技巧。
1. Function Calling 参数出错，现场远比你想的野
1.1 类型错误：模型好像根本不在乎类型
在 JSON Schema 里，我习惯把价格、数量这类字段定义为 number，在实际返回里却经常看到字符串。比如让模型调用一个查询订单金额的工具，schema 里明明白白写着 “type”: “number”，结果 tool_calls 里传进来的却是 “19.9” 这种字符串。顺着日志往下查，业务代码里 number 相加直接给你做成了字符串拼接，整串数据立马崩掉。
数组类型的错误也相当常见。我给某个工具定义了一个 tags 字段，允许传入字符串数组，模型却把它渲染成了逗号分隔的字符串，类似 “北京, 上海, 广州”。你说它是完全不遵守类型吗？也不是，它只是习惯了人类语言的表达方式，根本没把 schema 里的类型约束当严谨的规则来用。这类低级错误在交互轮次变多之后尤其高发，因为模型生成参数时注意力早就不集中了。
1.2 必填字段说没就没
更让人绷不住的是 required。明明我在 schema 里标了必填数组，比如 required: [“location”, “time”, “keyword”]，模型还是会漏填。我排查过一批日志，发现最容易漏的就是“隐性信息”。用户没说具体时间，模型就自作主张不传 time 字段；用户只是模糊地说“找一下最近的项目”，模型不知道 location 该怎么取，干脆整个丢掉。
一旦业务逻辑里 time 是硬性依赖，漏掉字段带来的就不是报错，而是程序直接抛异常或者查询结果为空。这类问题比类型错误更隐蔽，因为它不会在语法层面暴露，得等下游真正调接口时才爆雷。
1.3 枚举值被模型“再创造”
我最开始以为枚举是最稳的，给了几个可选值，总不会出错了吧？事实证明模型很喜欢“语义等价”的创造性输出。比如限定 status 只能取 pending、done、failed，它能给你造出 completed；限定 type 只能是 official、partner，它能填个 business_partner。后来的我总结出一个规律：模型不会去看你的可选列表，它只根据用户请求里出现的词做一个“最顺口的补全”，而这个补全往往就是你枚举列表之外的那个值。
1.4 结构嵌套与格式混乱
除了上面的常见错误，嵌套结构的参数出错频率也很高。比如自定义工具要求 location 接收一个对象 {city, district, address}，前面的字段都对，但 address 是必填的，模型偶尔会不填，或者把 district 写成了数组。日期格式就更不用提，你让它传 “2025-06-01”，它能给你搞成 “2025/06/01” 甚至带时区的 ISO 格式。当工具多起来之后，这类结构上的小毛病才是最磨人的——单看每个参数都“差不多”，一跑业务流程就是不对。
如果你现在还在裸奔状态，没做过任何参数校验，遇到上面这些现场是迟早的事。
2. 模型为什么总把参数填错：根因拆解
2.1 模型的本质输出逻辑：按语义补全，不是按规则执行
很多同学习惯用“程序员思维”去要求模型：我定义了 schema，你就该遵守类型和必填规则。但模型不是一个规则解释器，它的底层机制是 token 预测。生成参数时，它考虑的是“这串东西在语义上像不像”，而不是“这个值能不能通过运行时校验”。所以你给它 “type: string” 的 price 字段，它会继续生成字符串，因为在大量训练数据里价格被“说”出来的时候就是 “19.9” 这种样子。
理解了这一点，你就不会指望单靠描述和气势去压制模型。真正能约束它的，还得是结构化定义和外部校验兜底。
2.2 上下文过长之后，模型对工具说明“失焦”
在我实际项目的多轮对话里，前几轮工具调用结果、用户反复修改需求、中途插进来的无关聊天，都会把上下文窗口塞得越来越满。模型对最开始那段工具描述和参数说明的关注度会急剧下降，生成的参数就开始放飞。这也是为什么很多开发者在单轮测试时好好的，一到真实长会话里就花式出错。不是模型突然变笨了，是它的注意力确实分不过来。
2.3 工具描述写得含糊，模型只能靠猜
我复盘自己早期的 schema 时发现，很多参数描述写得过于简略，比如就写 “location 字段传地点”，这等于没写。模型看了之后根本不知道你到底要城市、完整地址，还是经纬度。为了自圆其说，它只能用自己认为合理的粒度去填。我当时还试过一个工具，description 写的是“接收用户查询条件”，结果模型把整个用户原话原封不动塞了进来。后来我把每个字段的边界、可选格式、实际示例全部写进 description，错误率下降明显。
2.4 用户输入本身存在多义性和信息缺口
最后必须要承认一点：很多参数错误，根源在用户没说清楚。用户说“查一下明天能不能发货”，“明天”到底是相对哪天？用户没给具体地址，location 到底取用户默认地址还是取对话里某个城市？模型拿到的信息本身有缺口，它只能去猜。这种猜测的结果就是，有些参数填得很合理，有些却完全跑偏，而你作为下游系统又没法凭猜出来的值做业务。
function calling 参数问题的核心矛盾，其实在于生成式模型的“语义合理性”和程序运行要求的“确定性”天然不匹配。我们改变不了模型，就只能把确定性防线建在业务侧。
3. Schema 设计是第一步：把约束做在前面
3.1 我认为 Schema 应该这样写，实测有效
与其说 schema 是给模型看的，不如说它是一份“双方对齐的接口契约”。模型靠它理解工具，我靠它约束模型。经过反复调整，我现在定了一套自己的 schema 设计规范：
- 每个字段必须有完整的 description，明确允许的值、格式参考和示例，不能一句话糊弄
- required 数组里明确列出全部必填项，同时把“非必填但建议填写”的字段说明也说清楚
- 凡是取值有限集的字段，一律用 enum 约束，不留给模型自由发挥的空间
- 结构尽量扁平化，嵌套层级越少，模型生成嵌套结构的出错率就越低
- 参数名本身也要语义清晰，不要用无意义的缩写
3.2 一个可以直接参考的 JSON Schema 示例
拿我之前做过的一个“创建任务”工具举例。当时第一版 schema 写得很随意，模型各种漏参，后来改成下面这样之后，校验通过率明显提升：
{ "type": "object", "properties": { "title": { "type": "string", "description": "任务标题，控制在50字以内，简明扼要。", "minLength": 1, "maxLength": 50 }, "priority": { "type": "string", "enum": ["high", "medium", "low"], "description": "任务优先级，只能从给定枚举值中选择。", "default": "medium" }, "due_date": { "type": "string", "description": "任务截止日期，格式为 YYYY-MM-DD，例如 2025-08-20。", "pattern": "^\\d{4}-\\d{2}-\\d{2}$" }, "assignee": { "type": "object", "properties": { "name": {"type": "string", "minLength": 1}, "email": {"type": "string", "format": "email"} }, "required": ["name", "email"], "description": "任务执行人的姓名和邮箱。" } }, "required": ["title", "priority", "due_date", "assignee"], "additionalProperties": false }看到这段 schema，你可能会觉得“这不就是标准 JSON Schema 吗”，没错，但关键在于我在每个字段的 description 里都注明了格式示例和边界。这样模型在生成参数时，就能看到“具体长什么样”的例子，而不是只有一个干巴巴的类型。实践中，给示例这一招对格式错误和枚举跑偏的改善非常明显。
3.3 类型断言工具 Zod 在设计阶段就能帮你省事
如果你用的是 TypeScript 生态，我特别推荐用 Zod 来定义和校验参数。Zod 的好处是同一份 schema 既能推导出 TS 类型，又能在运行时做数据校验，直接把“接口契约”和“类型安全”合二为一。下面是一个用 Zod 定义同一个任务参数的例子：
import { z } from "zod"; const TaskParamSchema = z.object({ title: z.string().min(1).max(50), priority: z.enum(["high", "medium", "low"]).default("medium"), due_date: z.string().regex(/^\d{4}-\d{2}-\d{2}$/), assignee: z.object({ name: z.string().min(1), email: z.string().email() }) }); type TaskParams = z.infer<typeof TaskParamSchema>;用上 Zod 之后，我在定义工具时就能直接拿到类型安全的任务参数结构，编译期能发现的错误直接在本地解决，不用等模型跑出来才发现。一个很直观的体验是：过去手写 interface + 运行时 if 判断，schema 跟校验逻辑经常对不上，现在改一处就同步生效，省了不少维护成本。
4. 校验落地：把“兜底”真正做进流程
4.1 校验放在哪个环节最稳妥
我在项目里把校验放在了模型返回 tool_calls 之后、业务代码执行之前。流程非常简单：先从模型响应里解析出 tool_calls，然后取出每一个调用的 arguments 字符串，交给对应的 schema 解析。Zod 的 safeParse 方法非常有用，它会返回一个包含 success 标志的结果对象，而不是直接抛异常。
我用一个工具函数统一处理所有校验：
function validateToolArgs<T>(schema: z.ZodType<T>, argsJson: string) { try { const args = JSON.parse(argsJson); const result = schema.safeParse(args); if (result.success) { return { ok: true as const, data: result.data }; } return { ok: false as const, error: result.error }; } catch (e) { return { ok: false as const, error: new Error(`JSON 解析失败: ${e.message}`) }; } }这样所有工具都走同一个入口，校验失败时能拿到结构化的错误信息。同时我还记录了一份完整的校验日志，包括模型返回的原始 arguments、解析后的对象、具体的校验报错，方便后续排查。
4.2 校验失败后的“纠错重试”机制，比硬报错好用得多
校验失败后的处理策略，是整个兜底方案的核心。一开始我试过直接返回报错给前端，结果对话体验十分糟糕——用户明明只想要一个答案，结果看到的是“参数校验失败”。后来我换成了“错误回传模型自纠错”的方式，效果立竿见影：
当参数校验失败后，我会把失败信息拼成一条 system 消息，让模型根据报错信息重新生成工具调用参数。模型读到自己刚才填的参数有误，基本都能立即修正正确。示例代码如下：
const messages = [ ...conversationHistory, { role: "assistant", content: null, tool_calls: [ { id: toolCallId, type: "function", function: { name: functionName, arguments: rawArgsJson } } ] }, { role: "tool", tool_call_id: toolCallId, content: JSON.stringify({ error: "参数校验失败", details: errorDetails }) } ];这段逻辑里，最关键的是把校验错误作为 tool 的返回值传回给模型。模型看到参数错误后，会自动生成一组修正后的 tool_calls，我再走一遍校验，直到通过为止。实际跑下来，绝大部分错误都在第一次重试后通过，整体流程不会拖慢太多。
4.3 策略分级的兜底方案，避免业务流程整体崩溃
虽然“让模型自纠错”很管用，但也不是所有错误都值得无限重试。我在项目里做了分级兜底：第一类是可纠错参数，比如格式错误、枚举越界，交给模型重试两三轮；第二类是非关键参数，比如查询接口里的排序字段、展示信息里的可选标签，校验失败时直接给默认值，不让流程中断；第三类才是关键参数，比如金额、身份证号、用户唯一标识这类涉及核心业务的字段，重试后依然校验失败，就落库记录并转人工处理。
用这套三级策略之后，我发现用户侧真正感受到的“系统报错”少了非常多，因为大部分非关键参数都被默认值消化掉了。关键参数因为重试成功率高，真正转人工的比例极低，整个流程稳了很多。
5. 踩坑实录与排查技巧，帮你少走弯路
5.1 日志里务必保留“原始 arguments”，不能只存解析后的对象
这是我踩过最大的坑。早期调试时，我只记录了校验之后的数据，后来发现模型明明是某个参数没填，但我看解析后的对象根本看不到原始生成结果，排查起来非常费劲。后来我改成把模型返回的 arguments 原始字符串、JSON.parse 后的对象、校验错误详情三层信息全部存进日志，排查效率提升了一个档次。
5.2 不要天真地让模型自己填默认值
有一段时间我试图在 schema 里写默认值，指望模型“不传就自动用默认值”。结论是：JSON Schema 里的 default 只是给人类读者看的说明，绝大多数模型并不会主动读并应用它，该漏还是漏。正确做法是在业务校验层做好默认值兜底，也就是上一节说的非关键参数处理策略，不要在 schema 层面寄托不切实际的期望。
5.3 不同模型厂商的 Function Calling 实现细节差异
我实测过几个不同厂商的模型，对 Function Calling 的参数格式支持并不完全一样。有的模型在 tool_calls 里返回的 arguments 是 JSON 对象而不是 JSON 字符串，直接 JSON.parse 会抛异常，所以我写了统一的处理函数，内部先判断参数是不是字符串，是字符串才 parse。有的模型对嵌套 object 的参数支持很差，经常漏掉内部字段，这种情况我会尽量把嵌套对象拉平，或者把嵌套对象的字段在 description 里写得更明确。
5.4 复杂嵌套参数校验的性能与超时隐患
有一次我上线了一个参数嵌套三层、字段数多达 20 多个的工具，结果发现每次校验耗时接近 30 毫秒，加上模型重试，整体响应时间被打得很高。后来排查发现，主要是嵌套结构里大量 pattern 正则和 email 格式校验拖慢了速度。我的调整办法是：只对关键字段做严格 format 校验，普通字段只做类型和长度校验，性能立刻回落到个位数毫秒。如果你的工具参数很多，一定要关注 Zod 校验的开销。
另外，一个容易忽略的坑是重试次数没有上限。曾经一个工具因为必填字段一直没搞定，让模型重试了十几次，最后把响应时间拖到了半分钟以上。后来我统一给重试机制设了上限（一般是 2 次，最多 3 次），超限后直接走人工兜底流程，整个系统才算真正稳定下来。
5.5 上线后持续监控：用错误分布反哺 schema 设计
最后分享一个我目前仍在用的方法。我会定期统计所有工具的参数校验失败记录，按失败类型和字段维度做聚合。如果发现某个字段频繁出错，大概率是 description 写得不够具体，或者这个字段的定义本身就不够直观。比如我早期有个字段叫 target_date，模型翻车率特别高，后来我把它改名成 delivery_deadline，并写明“格式为 YYYY-MM-DD，例如 2025-08-20”，翻车率直接降了一半。这种基于真实数据的迭代方式，比一个人闷头调 prompt 要高效得多。
我个人在实际操作中的体会是，Function Calling 参数错误不可怕，可怕的是不设防就直接让流程裸奔。schema 约束 + 运行时校验这套组合拳，短期能把错误率压下来，长期还能通过日志反哺出更合理的工具定义。最后再分享一个小技巧：不管用哪个模型，当成“一个合作但有点马虎的同事”来对待，你把它需要的信息说清楚，再在交付前自己复核一遍，这思路放在参数校验上，就是 schema 写透、校验兜底、重试纠错三步走，稳得很。
