AISIX 1.3.0：让 AI 智能体在不同模型提供商之间完成结构化工作流

一个发票审核智能体根据发票信息和采购订单事实，向人工审核员返回结构化建议。更换模型提供商时，需要验证的远不止提示词能否到达模型：证据、要求的 JSON 格式和安全策略都必须继续可用。在下文的共同评估步骤中，应用先提取发票文本并查询采购订单，再将这些事实作为文本提交到独立的建议生成请求中。由模型驱动的工具循环和直接文档输入，则需要按具体路由另行检查。

AISIX 1.3.0 于 2026 年 9 月 18 日发布，扩展了网关对这一工作流的支持。更丰富的 Responses 转换、面向更多提供商的结构化输出，以及明确的对话级安全护栏控制，共同构成了评估本次发布的主要理由。下文的发票审核智能体是用于说明评估方法的示例场景，并非性能基准或 AISIX 内置应用。

整个过程中都要分清产品与部署边界：AISIX 提供网关流量处理能力；AISIX Cloud 在此基础上增加控制面、控制台、组织管理和集中式使用情况视图，并提供 On-Premises 与 Hybrid Cloud 两种部署方式。无论采用哪种方式，网关都由你在自己的环境中运行。

核心要点

• AISIX 1.3.0 扩展了结构化输出和 Responses 转换。能否跨提供商采用，仍取决于所选适配器；桥接字段更丰富，不代表完整的多模态或工具调用工作流都能成立。
• 团队可以选择输入安全护栏检查哪些对话轮次，但必须重新确认工具结果的检查范围，以及哪些内容仍不在检查范围内。
• 请求结束时的访问日志和客户端断开后的使用事件，让智能体请求的最终结果更加清晰；控制台基线与日志处理逻辑也需要相应调整。
• 升级时应关注配置缓存持久化改为显式启用、先升级控制面的顺序，以及 API 和部署兼容性变化。

为智能体的证据选择受支持的路径

先看生成审核建议的请求。使用 /v1/responses 的应用，可能访问原生支持 Responses 的提供商，也可能需要通过 Chat API 转换。AISIX 根据提供商密钥的 API 接口配置选择路径，再由所选适配器决定哪些内容最终到达上游。

在 1.3.0 中，Responses 桥接会将 input_image、input_file 和 input_audio 映射到中间 Chat 格式，序列化 JSON 形式的 function_call_output，并转换受支持的工具选择参数和自由格式自定义工具。这些变化扩展了桥接能力，但后续适配器仍可能丢弃内容，或缺少维持工具循环所需的状态：

• 通过 Google AI Studio 使用 Gemini： 不要通过 /v1/responses 或转换后的 /v1/messages 执行 Gemini 3 多步骤工具循环。这些桥接不会回传 tool_calls[].extra_content.google.thought_signature，后续请求可能返回 400。继续该工具循环时，应使用 /v1/chat/completions，并完整保留助手返回的工具调用对象，具体见 Gemini 集成指南。
• 通过 Vertex AI 使用 Gemini： 当前 Vertex Gemini 适配器只处理文本，不会将函数声明或工具结果序列化为工具交互。它不支持发票审核智能体由模型驱动的订单查询循环，Responses 路径也不例外。前述 AI Studio 替代方案不适用于该适配器，请核对 Vertex 端点与内容限制。
• 通过 Chat 转换访问 Anthropic： 该适配器会丢弃非文本消息部分。如果图像或文档内容必须到达 Claude，应使用 Anthropic 转换指南所述的原生 Anthropic 风格 /v1/messages 路径，不能假设 Responses 桥接的中间表示会让这些内容端到端保留下来。

基于文本的建议生成步骤无需依赖上述多模态和工具循环路径。应使用这份输入测试实际适配器与模型。桥接还会丢弃仅以 file_id 表示的图像、工具结果中的非文本部分、托管工具以及 previous_response_id。allowed_tools 选择只保留模式，指定的工具子集会丢失，因此不能把它当作工具授权边界。离开原生端点之前，请阅读 Responses 桥接的完整限制。

受支持的证据到达模型后，下一个问题是：应用能够从答案中读取什么结果？

请求结构化结果，再由应用验证

假设发票审核智能体最终需要返回三个字段：发票标识、审核建议和解释。在 1.3.0 中，Responses 请求的 text.format 会先转换成 response_format，再映射到所选提供商使用的结构化输出机制。

选择结构化输出路径时，既要看模型，也要看适配器：

表中的 Gemini 映射属于 Vertex 适配器。Google AI Studio 通过 AISIX 的 openai 适配器访问 OpenAI 兼容端点，因此不能用这些 generationConfig 转换来描述 AI Studio 路径。

Anthropic 和 Bedrock 会将 Schema 缩减到各自支持的子集，把移除的约束写入属性描述，并设置 additionalProperties: false。Vertex Gemini 2.x 及以上版本不会进行这项改写；1.x 转换则会移除不支持的关键字，将部分约束写入描述，同时保留受支持的约束。这些路径都会保留调用方的 required 列表。自然语言描述中的约束不等于解码器强制执行。每份返回的 JSON 建议都应按应用自己的接口契约验证。

在 Anthropic 合成工具路径中，AISIX 会在调用方工具列表中追加 json_tool_call。除非调用方提供了非 null 的 tool_choice（包括 auto），或启用了扩展 thinking，否则网关会强制选择该合成工具。仅提供业务工具，并不会让它获得优先权。Bedrock 能否强制选择合成工具，还取决于模型发布方：Claude 和 Amazon Nova 支持显式选择；其他受支持的模型系列只会获得该工具，不会被强制选用。具体见 Bedrock 结构化输出行为。

应将建议生成请求与采购订单查询分开；如果要合并，先验证显式工具选择的行为。合成工具路径上的流式请求会先以非流式方式完成上游调用，再向客户端流式返回完整结果，因此首字节等待时间会增加。这并不是上游原生流式输出。

团队由此可以制定明确的验收标准：同一份受支持的输入到达每个候选模型，返回结果通过应用验证。这不代表所有提供商都会遵守每一项 Schema 约束，也不代表它们会得出相同结论。

明确安全护栏读取对话的哪些部分

生成建议后，审核员可能继续提问，应用也可能重放对话历史。如果策略命中了某条旧消息，即使后续请求的新输入符合要求，也可能继续被阻断。

AISIX 1.3.0 为每种安全护栏增加了 input_messages。默认值 all 保留整个请求的输入检查窗口。latest_turn 则将窗口缩小到最后一条助手消息之后的消息，并排除系统消息；末尾用于让模型续写的助手预填内容仍属于当前轮次。该设置只影响输入检查，在 AISIX Cloud 中，将 input_messages: latest_turn 与 hook_point: output 同时配置，会收到 400 INVALID_REQUEST。

对发票审核智能体来说，如何选择取决于规则的目的。只关注新指令的规则可以检查最新轮次；负责对整个对话中的敏感信息进行掩码处理的规则则应保留 all，因为 latest_turn 会让之前的历史消息原样转发。如果被阻断的消息再次发送，而中间没有助手回复，它仍属于当前轮次，仍会被检查。缩小检查窗口不会自动解除被阻断的对话。

工具处理还有一项升级时必须关注的变化。在 /v1/responses 中，AISIX 现在会把重放的 function_call 名称和参数归类为助手项目，把 function_call_output 归类为工具结果，因此配置为检查相应角色的安全护栏可以读取这些内容。此前，工具调用的名称和参数会被跳过；function_call_output 则被错误归类为用户文本，因此会被默认的 semantic 和 Azure 审核设置扫描。它们的默认 text_source 现在只读取用户角色消息，因此会同时排除助手工具调用的名称和参数，以及工具角色的结果；如果需要检查这些项目，应选择检查所有消息的设置。其他会读取所有角色的安全护栏可以直接检查这些内容。输入窗口和安全护栏的文本来源选择都会限制实际检查范围。

在发票工作流中启用强制策略之前，应确认以下边界：

• 上传文件： /v1/files 的上传和下载绕过输入与输出安全护栏检查。需要检查的文件内容应在到达该路由之前完成检查；文件引用被转发，不代表文件内容已经被检查。
• 生成的推理内容： 即使转换层将模型生成的推理作为 Responses 推理条目返回，它仍不属于输出扫描和掩码处理范围。重放的可读推理内容具有不同的输入检查范围；加密推理载荷仍不会被扫描或修改。
• 流式输出： 启用输出安全护栏后，网关会缓存流以便检查，影响用户收到内容的时间。网关无法解析的已缓存帧会被丢弃；如果没有剩余内容，则以 422 拒绝响应。

请根据安全护栏行为参考，测试实际的关联配置、输入窗口、文本来源和执行动作。结构化答案格式有效，与安全护栏检查完成，是两个不同的判断。

观察请求最终如何结束

人工审核员可能在智能体仍在处理时关闭页面。此前，客户端断开连接可能只留下访问日志，没有使用记录；而在响应头产生时就写出的流式访问日志，可能在流被中断之前已记录 200。

在 1.3.0 中，如果客户端在 AISIX 发送响应头之前断开连接，访问日志会以 499 和 error_kind = "client_disconnected" 记录，且不包含 Token 字段；对应的使用事件则使用 error_class = "client_disconnected"，Token 数和费用均为零。这种响应前取消不能与已经开始传输的流混为一谈：流式响应中途断开时，仍会生成一条 499 使用事件，其 Token 数覆盖断开前已交付的内容。流式请求会在结束时写入完成相关记录，因此运维人员可以区分未完成的流和已交付的响应，而不必把最初的响应头当作完成标志。

响应前的记录不证明提供商没有执行工作或不会收费。对于中途断开的流，应按已记录或估算的使用量解读费用、预算和 Token 限流；即使客户端放弃响应，该使用量仍属于相应的计量范围。在 AISIX Cloud 中，计算请求总数和成功率时应明确纳入这些 499 事件；延迟分位数原本就只统计成功记录。

访问日志现在区分 duration_ms 与 latency_ms：前者表示请求占用网关的完整时长，后者在流式请求中仍表示首个 Token 的等待时间。日志也会标识实际选中的上游模型和提供商密钥。模型组缓存命中不再归因到实际未被调用的提供商。调整控制台和解析器时，可参考访问日志与请求关联指南。

上线发票审核智能体时，应分别测试一次正常完成的响应、一次策略拒绝、一次缓存命中和一次中途断开的流，核对客户端结果及对应记录。

按实际部署方式制定升级计划

除了智能体工作流，本次发布还增加了稳定的资源 ID 引用、共享定价文档、组织导出与导入、私有端点地址、多代理监听器和 ARM64 镜像。这些能力解决的是运维与部署问题，并不会增强结构化输出的保证。

请遵循升级流程，并阅读跨越的每个版本的发布说明。受支持的升级起点是 0.12.0，更早的安装需要先进行一次中间版本升级。升级 AISIX Cloud On-Premises 控制面前，应备份数据库，再按先控制面、后网关的顺序升级。回滚顺序相反，并依赖数据库备份。Hybrid Cloud 用户需要协调由 API7 托管的控制面升级步骤，而不是自行操作控制面。

上线前请检查以下事项：

完整的 1.3.0 发布说明 列出了具体 API 变化和部署条件。迁移组织配置前，尤其要阅读导出与导入的授权规则；这些是控制面操作，不属于独立网关功能。

验证一次完整的智能体交互

从共同的建议生成步骤开始：输入发票文本和采购订单事实，输出通过验证的建议，并记录可观察的最终结果。在每个计划使用的适配器和模型上重复这一过程，同时测试输入被拒绝和流被取消的情况。由模型驱动的工具循环与多模态输入，应在支持它们的路由上分别评估；应用授权与结果验证仍需明确落实。

AISIX 1.3.0 让这段交互的更多环节能够跨受支持的提供商路径运行。是否采用，应取决于实际工作流中已验证的兼容性与策略覆盖范围。可以从 Responses API 指南开始，再将升级检查应用到自己运行的部署中。