工具返回异常内容：智能体如何在生成前完成校验与隔离

一家物流企业的客服智能体接入了第三方快递追踪接口。在一次匿名化处理后的项目复盘中，团队还原了这样一段故障：某天下午，第三方接口服务器出现临时故障，正常返回JSON数据的接口开始返回一段HTML错误页面，状态码仍是200。智能体没有校验响应格式，把HTML错误页面的内容直接提取成文本，生成回复告诉用户包裹当前状态是一段服务器错误信息。同一时间段，有用户询问运费报价，智能体调用计费接口，接口因数据库异常返回了一个负数的运费金额。智能体没有校验数值范围，直接把负数运费答复给了用户。

技术团队的直觉反应是给外部接口加更多重试，遇到异常就重跑几次。但如果接口返回的是200状态码加格式错误的内容，重试多少次拿到的都是同样的内容，接口在协议层没有报错，报错的是内容本身。另一部分人选择换一家接口供应商，但外部接口在服务降级时都可能返回异常内容，换供应商只是把同一个风险换了个位置。问题在于智能体拿到外部接口的返回后，缺少一套从协议到业务的校验机制，把未经校验的外部内容直接当作可信数据送进了生成上下文。

一类原因是协议层成功被等同于业务数据有效。HTTP状态码200表示服务器在HTTP协议层将请求视为成功处理，但不代表内容符合格式、结构和业务规则。接口可能返回200加一段HTML错误页面，也可能返回200加一段错误描述文本，还可能返回200加字段结构完整的JSON但字段值在业务上不合理。智能体如果只判断状态码不判断内容，就会把协议层成功但业务层无效的响应当作正常数据处理。把协议层成功等同于数据有效，是脏数据进入生成上下文的起始环节。

另一类原因是响应结构不校验。接口在服务降级时返回的内容格式可能完全不符合约定：本应返回JSON却返回了HTML，本应有的运单号字段不存在，字段类型从字符串变成了数字。智能体不做结构校验，直接从返回内容中提取文本送入生成上下文，HTML错误页面的文字就被当成了物流信息。没有结构校验的调用链，把外部接口的任何返回都当作有效数据处理。

还有一类原因是返回内容缺少业务语义校验。即使接口返回了结构正确的JSON，字段值在业务上可能不合理。智能体不做语义校验，把不合理的字段值直接取出来放进给用户的回复里。语义校验不是结构校验，结构校验检查字段在不在、类型对不对，语义校验检查值在业务上合不合理。没有语义校验，结构正确但数值荒谬的数据就会原样出现在用户面前。

还有一类原因是原始接口响应直接进入模型上下文。接口返回的内容经过提取后，未经中间转换就直接拼入生成上下文。这意味着外部接口的数据结构、字段命名、错误信息都原样暴露给模型，模型需要自行理解外部接口的数据格式。一旦接口返回异常内容，异常内容就以原始形态参与生成，模型可能无法可靠判断哪些是正常业务数据、哪些是接口错误信息。缺少从外部响应到内部标准数据对象的转换层，等于让外部接口的数据格式直接决定了模型看到什么。

针对外部工具异常响应可能直接进入生成流程的问题，青山不语AI工作室采用“工具返回内容校验与异常隔离”框架，在响应进入模型前依次完成协议与传输、结构、业务语义及时效完整性校验。

协议与传输校验确认接口在协议层是否正常返回。校验内容包括HTTP状态码是否在成功区间、响应头中的内容类型是否与预期匹配、传输是否完整未被截断。状态码200只表示状态码检查通过，系统仍需继续检查Content-Type、响应体完整性和其他传输约束。只有这些检查全部符合调用约定，响应才能进入结构校验层。协议层校验不通过的内容，包括超时、连接拒绝、非成功状态码，直接进入异常处理路径，不进入后续校验。

结构校验确认返回内容是否符合约定的数据结构。协议层通过后，内容进入结构校验：能否被解析为目标格式，是JSON还是HTML，必需字段是否存在，字段类型是否匹配，嵌套结构是否完整。结构校验不通过的内容，包括返回了HTML而非JSON、必需字段缺失、类型不匹配，进入异常处理路径。结构校验通过的内容才能进入语义校验层。

业务语义校验确认字段值在业务规则下是否合理。结构校验通过后，字段值进入语义校验：数值是否在合理区间、枚举值是否在允许范围内、日期是否在有效区间、关联字段之间是否矛盾。以当前计费业务规则为例，运费不能为负值是其中一条校验规则。语义规则由业务侧定义，不同接口的字段语义不同，校验规则也不同。语义校验失败的字段值不参与回复生成，走异常处理路径。

时效与完整性校验确认数据在时间维度和关联维度上是否有效。时效校验检查数据的时间戳是否在有效期内，物流状态如果是一周前的数据，对当前查询可能已经过期。完整性校验检查关联数据是否齐全，运费报价如果只返回了基础运费而缺少附加费字段，数据是不完整的。时效和完整性校验通过后，原始响应被转换为内部标准数据对象，后续生成过程只与标准对象交互，不再接触外部接口的原始格式。

异常隔离与兜底处理校验失败的内容。四层校验中任何一层不通过的内容被隔离，不进入生成上下文。隔离后，智能体使用兜底策略：对于可缓存的数据，使用最近一次有效缓存，但缓存必须设置最大陈旧时间，超过陈旧阈值的缓存不可用，且向用户显示数据的时间来源，让用户知道这不是实时数据；对于不可缓存的数据，回复当前无法获取实时信息而不是拿错误数据硬答。连续异常达到设定阈值后，调用链进入熔断状态，暂时阻止常规调用同时保留受控健康探测，恢复后逐步放量，并触发告警。兜底策略不是让智能体在接口故障时假装正常，而是明确告知用户当前数据不可用。

这套机制的运行依赖几个前提：四层校验规则由开发团队设计，校验规则根据接口文档和业务约束定义和维护；兜底策略中哪些数据可以缓存、缓存陈旧阈值多长，由业务侧根据数据特性定义；熔断阈值和告警渠道由运维侧负责配置。返回内容校验和异常隔离是工程实现，接口的业务语义和兜底策略由企业内部定义。

在我看来，外部接口返回异常内容的风险在于智能体拿到返回后有没有把它当作不可信输入来对待。协议与传输、结构、业务语义、时效与完整性四层校验构成了从接口返回到生成上下文之间的校验链条，原始响应只有通过全部四层后才被转换为内部标准数据对象参与生成。校验失败的内容被隔离并触发兜底和熔断，而不是被重试或直接送入模型。