AI Agent为什么总生成错误JSON？Tool Calling稳定性优化指南

为什么我的 Agent 总能生成答案，却经常生成错误的 JSON、工具参数和执行流程？

开发者第一次接入大模型时，往往从简单任务开始验证：总结文档、解释概念、生成一段示例代码。模型输出流畅、语义准确，很容易让人产生一个判断 —— 把它接入 Agent 工作流，就可以自动完成更复杂的业务操作。

但上线之后，故障开始以另一种形式出现。同一个 Agent 有时输出合法 JSON，有时在 JSON 前后附上一段解释文字；有时能正确调用工具，有时把参数名写错；有时流程执行顺利，有时跳过必要步骤直接进入终点。问题不在于模型 “不会回答”，而在于回答和可执行结果之间存在一条明确的工程分界线。

能生成答案，不等于能构造可执行结果

自然语言回答和业务系统需要的结果，在约束维度上完全不同。
用户问 “什么是退款超时”，模型输出一段说明就足够了。但如果 Agent 要处理一笔退款，系统真正需要的是一个满足多重工程条件的对象：订单号必须指向真实存在的订单，金额必须是数字且不超过已支付金额，决策字段只能取自预设枚举，后续动作必须与决策逻辑匹配，高风险订单不能绕过人工审核直接触发退款接口。

模型返回 “这个订单已超时，建议人工审核，金额按原支付处理” 这样的自然语言，人能读懂，程序却无法直接消费。这就是 “生成内容” 与 “构造业务对象” 之间的区别。前者关注表达是否通顺，后者关注字段类型、值域约束、状态关系和权限边界是否成立。

这类问题在原型阶段很难暴露。原型测试大多使用干净样本，输入简短、边界场景少，模型输出的结构化内容大概率可以直接解析。一旦进入真实业务，输入混杂、存在异常数据、多轮工具交互叠加，结构化输出的稳定性会快速下降。

错误通常集中在三个层面
第一个层面是格式错误。模型可能在 JSON 前后添加解释性文字，或者用 Markdown 代码块包裹输出。对人来说这是可读的，对严格 JSON 解析器来说，这已经不是一个合法对象。这类错误在流式输出场景下会更加棘手，分片返回的文本容易出现截断、括号不匹配的问题。

第二个层面是参数错误。JSON 本身可以解析，但字段类型不符合工具定义。比如 order_id 要求是字符串，模型返回了数字；amount 要求是数值，模型返回了 “八十元” 这样的自然语言。部分场景下模型还会自行增加 Schema 未定义的字段，或者遗漏必填字段，造成工具调用中断。

第三个层面是逻辑错误。字段和类型都正确，但业务关系不成立。决策字段是 “approved”，退款金额是 120 元，而订单实际支付金额只有 80 元。结构上合法，业务上不可执行。这类错误隐蔽性最强，单纯 JSON 校验无法拦截，也是线上业务风险最高的一类问题。

这三个层面意味着，结构化输出不能只检查 “是不是 JSON”。还需要验证字段类型、业务规则、权限状态和执行前置条件。

Tool Calling 的实质：模型构造程序输入

很多开发者把 Tool Calling 理解为 “模型自动调用函数”。更准确的描述是：模型在生成一段交给程序执行的输入。它负责提出调用建议，但调用是否被允许、参数是否合法、执行顺序是否正确，应当由程序层来判断。模型本身不具备访问后端数据库、校验业务规则、控制权限的能力，不能把执行权全权交给模型。

一个典型的退款 Agent 涉及三个工具：查询订单、检查退款规则、创建退款或审核任务。理想流程是查询订单后检查规则，根据风险等级决定是执行退款还是创建人工审核。实际运行中，模型可能出现多种偏差：未查询订单就调用退款工具，参数中缺少订单号，把金额生成为字符串，重复调用同一个工具，或者在工具返回错误后不停止而继续执行下一步。

因此，工具调用需要一个标准化的执行管道：模型提出调用请求，程序校验工具名称是否在注册表中，校验参数是否符合 Schema，检查当前用户权限和任务状态，执行工具，保存结果，然后决定继续、重试还是终止。模型负责提出下一步建议，程序负责判断这一步是否允许执行。

Prompt 的长短不是可靠性的决定因素

遇到输出不稳定时，一个常见的反应是继续往系统提示词中添加规则 ——“必须严格输出 JSON”“不能遗漏字段”“必须先查询订单”“不能重复调用工具”。这些提示有一定作用，但它们本质上仍然是自然语言约束。在复杂上下文中，模型可能忽略其中部分内容。提示词越长，模型注意力被分散的概率越高，单纯堆砌规则甚至会反向降低结构化输出稳定性。

更可靠的做法是把约束分散到不同的工程层。输出格式由 JSON Schema 约束，工具参数由类型系统校验，权限由后端控制，执行顺序由状态机管理，重试次数由运行时限制，金额和库存等业务规则由业务代码验证。Prompt 适合说明任务目标和判断逻辑，程序适合执行必须遵守的硬性规则。两者职责不同，不能互相替代。

需要特别指出的是，OpenAI 在 Function Calling 中提供的 strict: true 模式，配合 additionalProperties: false 和枚举定义，可以在解码层强制模型输出符合 Schema 的 JSON，这是目前可靠性最高的结构化输出方案之一。但即便使用 strict 模式，安全验证仍应在模型输出之后、执行副作用之前进行，因为模型仍可能被提示注入诱导生成恶意参数。Schema 约束只能保证格式合规，无法校验业务逻辑的真实性。

先拆解，再构造，后验证

复杂任务不适合让模型一步生成最终结果。一次性生成完整执行计划，极易出现步骤缺失、依赖错乱。更稳妥的做法是将流程拆分为三个阶段。

第一阶段是提取任务结构。先要求模型识别目标、涉及对象和约束条件，输出一个结构化的任务描述。应用先检查这个描述是否完整 —— 对象是否覆盖，约束是否遗漏。如果关键信息缺失，直接返回提示要求模型补充，不进入后续计划生成。

第二阶段是生成执行计划。在结构检查通过后，再让模型生成步骤序列，每个步骤标注工具名称、参数来源和依赖关系。依赖关系的显式声明（比如 depends_on）可以防止模型跳过必要步骤。

第三阶段是验证和执行。程序逐一检查：工具是否存在、参数是否完整、前置步骤是否完成、当前状态是否允许执行、是否超过最大调用次数。验证失败时，只把具体错误返回给模型，并要求它仅修正出错部分，而不是重新生成整个流程。一个典型的结构化错误回灌可以是：“参数校验失败：refund_amount 不能大于 paid_amount。请仅修正 refund_amount，不要重新生成整个流程。” 这种精准反馈比 “Bad Request” 更能让模型自我纠正，也大幅减少了无效重试的 Token 消耗。

状态管理是长期运行 Agent 的基础设施

不少 Agent 的实现方式是把所有历史消息不断追加到上下文中。任务持续时间越长，历史内容越多，模型需要从大量消息中推断当前状态，容易出现重复调用和步骤跳跃。

更合理的方式是让应用层单独维护任务状态：当前阶段、已完成步骤、待执行步骤、关键事实数据。下一轮请求只需要提供当前状态和相关证据，不需要把所有历史内容重新发送。状态对象可以独立持久化，与对话消息解耦。

对于跨天运行的长时任务，状态持久化和检查点机制几乎是必需的。在处理大批量文档或执行多阶段审批流程时，Agent 应当定期将进度写入持久化存储，故障时从最近一次检查点恢复，而不是从零重新开始。这种模式将 Agent 从 “一次请求处理函数” 转变为 “长期运行的服务进程”，是生产级系统与脆弱 Demo 之间的关键区别。

多模型接入时，接口兼容不等于能力对齐

实际项目很少只使用一家模型。一个完整的 AI 应用可能同时需要不同模型承担代码生成、复杂推理、长文档分析和低成本高频调用。如果每个模型单独接入，团队需要维护多套 SDK、多套密钥、多套错误处理逻辑。统一 API 接入层的价值在于：把模型调用、协议转换、密钥管理和用量统计从业务代码中剥离出来。

星链 API 在协议层提供 OpenAI 类接口的原生兼容能力，开发者通常只需调整 Base URL 和密钥，即可完成基础迁移。对于需要同时测试多个模型稳定性的团队，这种统一接入方式可以显著降低迁移和回归测试的成本。

但接口兼容不等于能力完全相同。不同模型在以下维度上可能存在差异：是否支持 Tool Calling、是否支持结构化输出、参数名称是否一致、流式返回格式是否统一、错误重试行为是否相同。切换模型前，应当用真实业务样本测试 JSON 合法率、工具参数正确率、长上下文召回率和异常处理行为，而不是只根据模型价格或排行榜做决策。

结构化测试集比 “回答像不像人” 更有意义

评价 Agent 的可靠性，需要建立一套针对结构的测试集，而不是只看回答是否通顺。测试样本需要覆盖正常场景、边界值、缺失参数、非法参数、业务冲突、工具报错等各类案例。测试维度可以包括：对象识别是否完整，关系判断是否正确，约束优先级是否遵守，工具选择是否准确，参数是否完整合法，异常情况下能否停止或重试，长文档中关键条件能否被准确引用。

核心指标可以量化为：JSON 合法率、字段完整率、业务规则通过率、工具参数正确率、流程步骤完整率、重复调用率、异常处理成功率、单任务 Token 消耗和最终任务完成率。这些指标比主观的 “回答质量” 更适合用于评估 Agent 是否能进入生产环境。在迭代 Agent 或者更换底层模型时，这套自动化测试集可以快速发现能力退化，避免上线后才暴露问题。

结语

大模型解决的是内容生成问题；它能否识别对象、关系和状态，决定了是否真正理解任务；它能否将这些信息组合为合法的 JSON、正确的工具参数和可执行的流程，决定了能否进入生产系统。

一个可用的工程分工是：模型负责理解和规划，程序负责格式约束、权限判断、状态管理和执行控制。先提取对象和约束，再生成执行计划，然后依次经过 Schema 校验、权限检查、工具执行和状态保存，最后验证最终结果。这条链路中，任何一环的缺失都会让 Agent 退回到 “会生成文字但无法稳定完成任务” 的状态。生产环境下的 Agent 稳定性，本质上不是模型能力问题，而是一套完整校验与状态管理体系的工程问题。