例如某制造企业场景，采购智能体接入供应商报价接口，接口持续返回JSON格式的报价数据，智能体据此自动生成比价单。假设某天供应商升级接口，返回字段从unit_price改成price，还多嵌套了一层data对象。智能体没有察觉，仍按原字段名解析，拿到空值却在比价单里填上0元。采购员看到某供应商报价为零，以为对方免费供货，险些据此下单。
这类问题在智能体接入外部系统时并不少见。接口返回格式变化、字段增减、数据类型改变，任何一项都可能让智能体拿到错误数据。不少团队认为做好接口文档管理就行。但外部接口往往不在己方控制范围内，供应商升级未必提前告知，文档更新和解析逻辑调整之间也存在时间差。这类故障的常见原因之一，是返回数据进入智能体上下文或业务流程前缺少契约校验和异常隔离。一类原因是系统对返回数据不做结构校验，接口结果直接进入上下文，不检查字段是否存在、类型是否匹配，字段缺失时静默使用空值。另一类原因是接口契约没被固化成可执行的校验规则，预期返回结构只存在于文档里。还有一类原因是系统把字段缺失、值为null、类型错误和合法的0这四种状态混为一谈，统一当空值处理：合法的0被当作异常丢弃，真正的缺失被当作0填入比价单。
本文基于青山不语AI工作室在部分企业AI Agent开发与外部系统集成项目中的实践，将接口返回数据校验归入工具返回内容校验与异常隔离框架，以"接口契约校验与响应降级"作为该框架在接口场景下的子机制展开讨论。
校验链路分为三个阶段：HTTP/语法解析、Schema契约校验、业务字段提取。起始阶段处理传输层和语法层问题，检查HTTP状态码是否正常、响应体是否符合约定格式，本文以下以JSON接口为例。语法解析失败时不进入后续阶段，直接标记该接口本次调用不可用。接下来按Schema契约逐项校验返回结构，契约在接入阶段固化为结构化规则，记录每个字段的完整路径、数据类型、是否允许为null、是否必填以及嵌套层级。Schema校验覆盖嵌套路径------data对象下的price字段与顶层的price字段是不同路径，契约按完整路径匹配，不因字段名相同就误判。允许为null的字段值为null时不视为异常，不允许为null的字段出现null视为校验失败；必填字段缺失视为校验失败，可选字段缺失不阻断。最后从通过Schema校验的结构中提取业务字段，提取时严格区分四种状态：字段在返回结构中不存在为missing，字段存在但值为null为null状态，字段存在但类型与契约不符为type error，字段存在且类型正确值为0为合法0。四种状态不能混：missing不等于null，null不等于0，type error不等于missing。系统对四种状态采取不同处理------missing和type error属于结构异常，高风险字段如金额、数量、日期出现这两种状态时智能体不继续生成涉及该字段的回复，改为告知用户该数据当前不可用；null状态按业务规则判断该字段是否允许为空，不允许则为异常；合法0是正常的业务值，正常进入下游流程，不能因为"看起来像空"就丢弃。
接口无显式版本号时，系统在己方维护契约版本。一种实现方式是根据字段路径、类型和嵌套层级计算Schema指纹，用于检测结构变化。每次接口返回后，系统比对实际Schema指纹与己方记录的指纹：指纹一致说明结构未变，指纹变化只说明响应结构发生了变化，不能直接判定契约失效。新增可选字段这类向后兼容的变化如果仍能通过当前Schema校验，系统允许继续处理，不触发降级。只有必填字段缺失、字段路径变化、类型不兼容、禁止结构出现，或无法匹配任何已知契约时，系统才判定为破坏性契约漂移并进入降级路径。未知字段是否允许由additionalProperties或等价规则控制：允许时新增字段不阻断流程，禁止时未知字段出现即视为结构异常。破坏性契约漂移触发告警，系统不自行用旧契约解析新结构，而是标注该接口当前结构未知。降级路径中系统不拿缓存旧值冒充当前值，而是明确标注该字段不可用，等待契约更新或人工介入。
接口返回格式变化导致解析失败的核心矛盾，是外部接口不在己方控制范围内而智能体又依赖其返回数据。把校验拆成三阶段链路，把missing/null/type error/合法0四种状态分开处理，在无显式版本号时用Schema指纹检测契约漂移，是降低这类风险的方向。企业选择AI Agent开发或定制服务时，不能只看接口能不能调通，还要看接口异常、字段变化和第三方系统升级后有没有契约校验、异常隔离和降级机制。