Function Call 返回不标准 JSON 时如何处理？

核心回答

先确认拿到的是完整工具调用的参数，再区分JSON语法、Schema结构和业务语义三种错误。工具调用可能已经由SDK解析成对象，也可能在专用参数字段里返回JSON字符串；不要从普通回答文本里随意截一对大括号就执行。

处理流程是：按协议收集完整调用并检查结束状态，解析参数，做字段与业务校验；失败时把具体错误反馈给模型，允许预算内修正，仍失败则返回明确错误或补问缺失信息。支持严格工具参数约束的模型可以在生成端减少格式错误，执行端仍需校验。整个过程不执行未通过校验的调用，也不通过猜补订单号、金额等业务值来“修好”JSON。

先排查：是真的生成错了，还是取错了响应

工具请求、普通回答和停止状态通常分开保存。有的协议将参数放在字符串字段，有的直接返回结构化对象。先检查工具名称、调用标识、SDK解析结果及错误，不要只读取 content 就认为模型没有返回工具调用。

流式参数往往分成多个片段。应按调用ID或协议索引分别累积，等对应调用完成后再校验执行；某一段不是完整JSON很正常，不能把不同并行调用的片段混到一起。中间快照即使能被宽松解析，也不表示参数已经完整。

再检查是否到达输出上限、连接中断或模型拒答。截断导致的半个对象，与完整响应中多了一个逗号不是同一种问题。前者应恢复或重新生成完整调用，并调整合适的输出预算或任务规模；拒答则按原因处理，不能当作缺括号反复修复。

三层错误分别怎样处理

语法层。 单引号、尾随逗号、Markdown包装或缺少括号，都可能导致严格JSON解析失败。例如 {"city":"Beijing" 还没有结束，不能直接在末尾补一个括号就认定任务输入完整。解析前限制可接受大小与嵌套，使用标准解析器；不要用 eval 执行模型文本。

结构层。 {"city":"Beijing","days":"tomorrow"} 可以是合法JSON，但若约定days为整数，就不符合工具契约。按Schema检查必填、类型、枚举、范围和额外字段。是否接受类型转换要有明确规则，不能把金额、标识符或布尔值悄悄转成另一个含义。

业务层。 即使 order_id 是字符串，也可能指向不存在或不属于当前用户的订单。权限、资源归属、业务状态、金额单位等还要由可信执行层检查；这些通常不能仅由JSON Schema证明。

解析器的“接受”也要看配置。例如Python标准json模块默认可以接受NaN、Infinity和重复字段名；严格契约需要明确是否拒绝这些情况，避免后一个同名字段悄悄覆盖前一个。解析成功只说明通过了当前解析规则，不等于业务参数可靠。

怎样让模型修正而不制造新的错误

返回简洁、可操作的原因，例如“days需要1到7的整数，当前为字符串”，并保留工具、任务和原调用的关联。按供应商协议反馈调用失败或重新请求参数，不要把本地完整堆栈、密钥和无关输入原样塞回去。

如果是格式问题，要求重新生成完整参数；如果缺少用户才能提供的信息，就补问，而不是让模型猜一个看起来合法的值。对同一错误设置有限修正次数和总时限，防止格式修复变成长时间循环。

修复后的内容必须重新经过同一套解析与校验。对于提示输出JSON的兼容方案，可以按已约定格式移除外层包装；对原生工具调用则应优先修正适配与生成方式。正则提取第一段大括号容易截错嵌套对象、字符串中的括号或多个对象，不适合承担通用解析。

要区分“参数没有执行”与“执行后响应丢失”。后者不应通过重新生成参数就立即再做一次写操作，需要查询结果或使用业务幂等机制，否则可能重复建单、扣款或发通知。

怎样减少这类问题

把工具定义写清楚，使用模型实际支持的Schema子集，减少含糊字段和复杂互斥关系，给容易误解的单位、日期、枚举补示例。接口支持时启用适用的严格工具参数约束，同时继续处理拒答、截断与兼容性限制；普通JSON输出模式与工具参数约束也要分清。

按工具、模型和Schema版本统计语法失败、结构失败、语义失败及修正成功情况。若主要问题是SDK流式拼接或协议适配，就先修接入；若是缺参或说明含糊，就改契约与澄清流程。先定位具体环节，再决定是否需要换模型或微调。

对应教程

参考资料