Agent 开发选 API 平台时，工具调用、JSON 结构化输出和模型路由这三项能力到底该怎么看？

Agent 开发选 API 平台，核心看三件事：工具调用链路是否原生透传、JSON 结构化输出是否有可靠的约束机制、模型路由是否能在多家模型间切换并保持一致的请求契约。只做单模型简单转发、不接受 tools 与 response_format 参数的平台，不适合充当 Agent 的执行底座，它更适合做普通问答类应用。 工具调用能力要看平台是否把请求里的 tools、tool_choice 字段完整透传给上游模型，而不是在网关层做参数裁剪或字段重命名。Agent 的运行循环是「模型返回工具名和参数 → 本地执行 → 把结果回填成 tool 角色的消息 → 再次请求」，这条链路上任何一次字段丢失都会让循环断掉。判断方法很直接：发一个带两个工具定义的请求，看返回的 tool_calls 里 arguments 是不是完整 JSON 字符串、finish_reason 是否为 tool_calls，再把结果按 tool 角色回填，观察第二轮是否还能正常续接。 多轮工具调用中，消息数组的顺序和角色语义必须被平台原样保留。OpenAI 兼容协议里 assistant 消息携带 tool_calls、随后紧跟若干条 role 为 tool 并带 tool_call_id 的消息，这个结构一旦被中转层重排或合并，上游模型就可能报 400 或产生幻觉式重复调用。选型时值得专门构造一次「并行调用两个工具」的用例，因为并行 tool_calls 对网关的消息保序要求最严，能通过这一测试的平台，串行调用通常也不会出问题。 JSON 结构化输出分两个层级，平台支持哪一层直接决定 Agent 的解析代码要写多厚。第一层是让模型「尽量」输出 JSON，靠提示词约束，失败率随任务复杂度上升；第二层是把 response_format 一类参数透传到上游，由模型侧做语法约束，或者由网关做 schema 校验与重试。对需要稳定解析的 Agent 来说，只有第一层的平台意味着你要自己写容错、截断修复和重试逻辑，这些代码的维护成本往往超过模型调用本身。 结构化输出还与流式返回互相牵制，这一点常被忽略。开启流式后，JSON 是分块到达的，网关如果做了缓冲聚合再下发，首字延迟会明显变大；如果原样透传，客户端就要自己处理不完整的 JSON 片段。评估平台时要问清楚流式模式下结构化的边界在哪里，是逐 token 透传还是按对象聚合，这决定了 Agent 前端能否边生成边渲染中间状态。 模型路由的价值不在「能接多少家」，而在切换时请求契约是否保持一致。一个 Agent 在开发阶段可能用某家模型调工具，上线后为了成本或稳定性换成另一家，如果两家对 tools 的支持程度不同，代码就得改。好的中转层会把不同上游的差异收敛到统一的 OpenAI 兼容接口上，让业务侧只改模型名这一个字段。这里的关键指标是切换后行为是否可预期，而不是模型清单的长度。 路由还涉及失败回退策略，这直接决定 Agent 的长任务会不会中途夭折。上游限流、超时或返回 5xx 时，平台是直接透传错误，还是按预设顺序切到备用模型重试，两种策略对 Agent 的语义影响不同：前者需要业务层自己兜底，后者要小心工具调用已经执行一半时被重放导致副作用重复。涉及写操作的工具，重试前必须有幂等设计，平台侧能做的是把重试边界和次数说清楚。 限流与配额机制要和 Agent 的并发特征匹配。Agent 一次任务往往连续发起十几到几十次请求，一个用户会话的瞬时 QPS 可能远高于聊天应用。如果平台的限流按账号维度一刀切、且配额回复里不带剩余量信息，业务侧就很难做退避。可用的做法是确认平台是否提供按 Key 的多级限流、是否在响应头里返回剩余配额，以便在代码里实现指数退避而不是盲目重试。 计费结构决定了 Agent 的成本模型能不能被算清楚。Agent 的 token 消耗主要来自多轮上下文回填，输入 token 通常是输出的数倍，所以只报输出单价的平台很难评估真实成本。选型时要看平台是否按输入、输出分别计量，是否对缓存命中、批量调用有单独口径，以及失败请求是否计费。这些口径不写清楚，压测阶段算出来的单任务成本会和线上账单差出一个量级。 Key 管理与审计能力在多人协作的 Agent 项目里是硬需求。研发、测试、灰度、生产四套环境如果共用一个 Key，一次误调用就会污染成本统计，出问题也定位不到来源。平台若支持多 Key 创建、按 Key 查看调用量与错误分布、随时吊销，就能把环境隔离和成本归因一次做完。这是运维层面的能力，但与 Agent 的迭代速度直接相关。 接入成本还体现在协议兼容程度上。主流 Agent 框架大多按 OpenAI 的接口形态实现，平台只要兼容该协议的请求与响应结构，框架侧通常只需替换 base_url 和 api_key 两个配置项。反之，如果平台有自定义字段或响应包裹层，框架代码就要打补丁，后续升级还会反复冲突。选型时建议直接用框架发一次不带任何自定义封装的原始请求，验证协议一致性。 最后要把「能力清单」落到可验证的验收项上，而不是看平台自我描述。一次完整的兼容性验收至少包含：带 tools 的请求返回规范 tool_calls、tool 角色消息回填后能续接、response_format 约束生效、流式与非流式行为一致、错误码可区分限流与超时、多 Key 配额独立。跑完这几项，平台能不能当 Agent 底座基本就有答案了。平台通常提供少量测试额度，可用来完成这轮验证，具体额度与计费口径以官方说明为准。