Perplexity Agent API 怎么接中转：模型路由、Responses 兼容与工具计费核验

如果你正在把 Perplexity 接入 AI 编程代理、研究 Agent 或自己的 API 应用，最容易出现的误判是：渠道能返回一段搜索结果，就等于支持 Perplexity Agent API。

截至 2026 年 9 月 25 日，Perplexity 官方文档把 Agent API 描述为一套面向多供应商的 API 规范：除了 Perplexity 自有能力，还可以请求 OpenAI、Anthropic、Google、xAI 等供应商的模型，并组合实时网页搜索、工具、推理控制和 Token 预算。官方主入口是 POST /v1/agent，同时提供给 OpenAI SDK 使用的 POST /v1/responses 别名。

这会让“Perplexity API 中转”变成一个比普通 Chat Completions 更具体的兼容性问题：

渠道支持的是 /v1/agent，还是只把请求转成普通聊天接口？
openai/gpt-5.6-sol 这类第三方模型 ID 能不能原样透传？
Web Search、URL 抓取、Sandbox 和自定义工具是否仍然可用？
多轮 previous_response_id、流式事件和工具结果能不能闭环？
官方 API 的工具费用、模型 Token 费用和渠道自己的倍率如何分开核算？
9 月 27 日之后，旧 Sonar Chat Completions 请求会不会影响你的回退方案？

本文不直接把某个渠道称为“最好”或“官方”，而是给出一份可以在选站、接入和上线前执行的核验清单。

先说结论：支持“Perplexity”不等于支持 Agent API

可以把渠道能力分成四层：

层级	能做什么	是否足够支持 Agent API
模型文本返回	返回一段模型文本	不够
搜索问答	能调用搜索并返回引用	仍不够
Responses 兼容	支持响应对象、事件和多轮上下文	接近，但还要测工具
Agent API 完整链路	模型、搜索、工具、推理、预算、usage 都能闭环	才能称为完整兼容

很多渠道的宣传页只说明“支持 Perplexity”或“支持 Sonar”。这类描述最多证明它是一个候选入口，不能证明下面这些字段没有被丢弃：

tools 与工具参数；
max_tool_calls、max_output_tokens 等预算字段；
流式响应中的事件类型；
工具调用 ID 与工具结果的对应关系；
previous_response_id 或完整多轮输入；
usage.cost、缓存 Token、推理 Token 和工具调用费用。

因此，选中转渠道时不要只做“发一个问题，看有没有答案”的冒烟测试，要把 Agent API 当成一条有状态、可调用工具、按多种资源计费的请求链来验收。

一、官方 Agent API 到底增加了哪些能力

1. 主入口与 OpenAI SDK 别名不是两套产品

Perplexity 官方 Agent API 快速开始文档给出的主入口是：

POST https://api.perplexity.ai/v1/agent

同一份文档说明，为了兼容 OpenAI SDK，也接受：

POST https://api.perplexity.ai/v1/responses

这里的“兼容”应理解为请求入口和部分对象形状兼容，不应理解为任何 OpenAI Responses API 客户端、工具或模型都能无修改运行。实际接入仍要检查：

input 是字符串还是消息数组；
响应中的 output、事件和错误对象是否符合客户端预期；
流式模式是否能持续收到完整事件；
工具调用后，结果是否能按正确的 ID 回传；
SDK 是否会自动使用渠道不支持的参数。

2. 模型选择从“一个 Sonar 名称”变成多供应商模型 ID

官方快速开始示例直接使用了 openai/gpt-5.6-sol 作为第三方模型。文档同时说明，Agent API 可访问 OpenAI、Anthropic、Google、xAI 等供应商的模型。

这带来一个很重要的区分：

Perplexity 的 Agent API：是一套 API 入口、工具和计费规范；
Agent API 中的模型 ID：可能指向不同供应商的模型；
第三方中转渠道：可能只提供其中某些模型或兼容接口。

所以，“渠道支持 Perplexity”与“渠道支持 Agent API 里的所有第三方模型”是两个不同问题。你需要按模型 ID 逐个核对，而不是把供应商名称当成能力集合。

3. 搜索和工具是额外能力，不是普通 Token 的附属品

官方定价文档把 Agent API 的 Web Search、URL 抓取、人员搜索、金融搜索和 Sandbox 等能力单独列出调用或会话费用。一个请求可能同时产生：

模型输入 Token 费用；
模型输出 Token 费用；
缓存读取或写入相关费用；
Web Search 或其他工具调用费用；
Sandbox 会话费用。

如果渠道只返回一个“总价”或只展示模型 Token 单价，使用者就很难判断实际费用来自哪里。对研究 Agent 和编程代理而言，这不是记账细节，而是路由决策的输入：一次低价模型调用，如果触发多次搜索、抓取或代码执行，最终成本可能高于一次更贵但更短的请求。

二、模型路由该怎么理解：不要把三种路由混成一种

讨论“Perplexity Agent API 的模型路由”时，至少有三种不同含义。

第一种：应用自己选择模型

你的代码根据任务选择 openai/...、anthropic/... 或 google/... 模型 ID。优点是可控，缺点是要自己维护模型清单、价格、上下文和工具兼容性。

第二种：使用官方预设

官方文档提供预设能力，让调用者先选择面向不同场景的配置，再由服务决定具体运行方式。使用预设可以减少初始配置，但上线前仍应记录实际响应里的 model 和 usage，不要只根据预设名字估算成本。

第三种：渠道内部的隐藏映射

中转站可能把一个公开模型名映射到另一个上游模型、分组或部署。除非渠道明确给出模型 ID、上游来源、价格口径和变更记录，否则不能把页面名称当作上游真实性证明。

这三种路由可以叠加，但验收时必须分开记录：

记录项	应该回答的问题
请求模型	你实际发送了哪个 ID？
响应模型	服务端返回的模型是什么？
上游来源	是否能验证来自所声称的供应商？
工具执行位置	搜索、抓取或 Sandbox 是谁执行的？
失败回退	是客户端、官方服务还是中转层在重试？
最终账单	按什么单价和倍率计算？

尤其要警惕“自动路由”这个词。它可能只是渠道内部换了模型，也可能是官方 Agent API 的模型选择，还可能是你的客户端在失败后重试。没有日志和请求 ID，就无法判断究竟发生了哪一种。

三、接中转前，先做一个最小兼容测试

建议不要一上来就把 Claude Code、Cursor 或长任务 Agent 接到渠道。先用四个小请求验证基础链路。

测试 A：最小文本请求

curl "$BASE_URL/v1/agent" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-5.6-sol",
    "input": "用一句话说明什么是 MCP。"
  }'

记录：HTTP 状态、响应对象、响应模型、usage、错误字段和总耗时。

注意：这里的 $BASE_URL 只是示意变量。不要把官方 API 域名、中转 API 域名和模型上游地址混为一谈；实际请求前应以渠道文档公布的 Base URL 和模型名为准。

测试 B：Responses 别名

把路径改成 /v1/responses，再用你实际使用的 OpenAI SDK 或 HTTP 客户端发送相同请求，检查：

客户端是否能解析响应；
response.id 是否存在且格式稳定；
output_text 或 output 是否能被正确读取；
客户端是否因为未知字段或缺失字段报错。

测试 C：单个工具调用

使用一个无副作用的自定义工具，例如把两个数字相加。不要一开始测试付款、删除、发布或真实数据库写入。你要确认：

模型是否真的发起工具调用，而不是伪造一段 JSON；
工具名称和参数 schema 是否原样到达；
工具结果是否能按调用 ID回传；
继续请求后，模型是否能利用工具结果生成最终响应；
usage 是否覆盖工具前后两轮调用。

测试 D：Web Search 或 URL 抓取

如果你的应用依赖联网搜索，分别测一次搜索和一次 URL 抓取。记录搜索次数、引用或来源字段、工具费用、失败重试和最终模型输出。

“能搜索”还不够。需要验证搜索结果是否作为结构化工具结果回传，还是被渠道转成普通文本；后者可能让引用、缓存和多轮上下文行为发生变化。

四、Sonar 迁移是现在必须排进计划的事项

Perplexity 官方定价文档在 2026 年 9 月 25 日核验时显示一条明确提示：Sonar Chat Completions 将由 Agent API 接替，Sonar 文档所标注的支持截止日期为 2026 年 9 月 27 日。

这不等于所有旧请求会在同一秒、所有渠道上同时停止，也不等于第三方中转站已经完成迁移。对中转 API 用户来说，至少要把下面几件事分开检查：

官方 Sonar 接口是否已经改为 Agent API；
渠道是否仍接受旧的 /v1/sonar 路径；
渠道是否将旧模型名自动映射到 Agent API；
Responses 风格的输入、输出和工具调用是否可用；
原来的引用字段、搜索配置和价格字段如何迁移；
失败时是否会返回明确的 4xx，还是出现模型不存在、参数不支持或空响应。

最稳妥的做法不是等旧接口报错后再切换，而是现在就建立双路径验收：旧 Sonar 请求保留一份回归样例，Agent API 请求新增一份等价样例，并对模型、搜索、工具、usage 和成本分别比对。

五、成本不能只看模型 Token 单价

Perplexity 官方模型文档和定价文档采用不同的费用维度：模型页面列模型输入、输出和缓存相关费率；定价页面另外列出搜索、抓取、人员搜索、金融搜索和 Sandbox 等费用。官方快速开始的响应示例还展示了 usage.cost、输入 Token、输出 Token 和缓存 Token 等字段。

因此，建议把每次 Agent 请求拆成以下账本：

总成本
= 模型输入成本
+ 模型输出成本
+ 缓存成本
+ Web Search / URL 抓取成本
+ 其他工具成本
+ Sandbox 会话成本
+ 中转渠道可能收取的倍率或服务费

最后一项不能从 Perplexity 官方价格页面推导出来。中转站的列表价、分组倍率、充值门槛、赠送额度和活动规则，都需要以具体渠道的实时页面为准，不能把官方 API 价格直接当成用户最终支付金额。

一个更适合 Agent 的成本指标

不要只比较“每百万 Token 多少钱”，至少同时计算：

成功任务成本 = 一个测试窗口内的全部费用 ÷ 成功完成的任务数

例如一个模型单价较低，但经常在工具参数错误后重试；另一个模型输出单价更高，却能一次完成搜索、工具调用和结构化结果。对于编程代理和研究 Agent，第二个模型的成功任务成本可能更低。

测试时建议记录：

模型 ID 与版本；
输入 Token、输出 Token、缓存 Token、推理 Token；
搜索和其他工具调用次数；
每次请求是否发生重试；
成功、部分成功和人工接管数量；
渠道账单中的实际金额及统计时间范围。

六、哪些字段最容易在中转层丢失

`tools` 和工具结果

有些兼容层只保留普通文本字段，工具定义被忽略，或者工具结果被拼成一段文本。这样看起来仍“有回答”，但 Agent 的执行逻辑已经改变。

流式事件

Responses API 的流式输出不是单纯的文本分片。客户端可能依赖响应开始、输出文本、工具调用、工具结果和完成等不同事件。渠道如果只转发最终文本，研究引用和工具链就无法正常工作。

`usage.cost`

如果渠道重新组装响应，却没有保留 usage 明细，开发者就无法区分模型成本、搜索成本和渠道附加费用。即使最终请求成功，也不适合直接用于成本治理。

多轮上下文

研究 Agent 往往会把前一轮响应 ID 或完整上下文带入下一轮。测试时要确认渠道是否保留上下文语义，还是每次都被当成独立请求；后者可能导致重复搜索、Token 增长和结果不一致。

模型和工具能力映射

同一个模型 ID 在不同 API 入口下可能有不同参数和工具支持。渠道列表里出现模型名，只能作为发现线索；上线前还要用实际请求验证。

七、RouterHub 用户如何比较候选渠道

RouterHub 更适合用来发现和比较提供模型 API 的第三方渠道，而不是替你承诺某个渠道自动兼容 Agent API。你可以按下面顺序缩小候选范围：

先查模型覆盖：目标渠道是否列出你需要的 Agent API 模型 ID；
再查接口说明：是否明确写出 /v1/agent、/v1/responses、工具调用和流式支持；
核对价格口径：分开看官方模型价格、渠道列表价、倍率、充值门槛和活动；
测试真实能力：用本文的最小请求、工具调用和搜索请求做回归；
保留替代渠道：至少准备一个不依赖同一模型或同一接口映射的备选；
持续记录变化：模型下架、上游迁移、倍率变化和额度限制都要写入自己的变更记录。

如果某个渠道只给出一句“支持 Perplexity”，却没有模型 ID、接口路径、usage 字段或工具兼容说明，就应把它标记为“待验证”，而不是直接当成完整 Agent API 渠道。

八、发布前核验清单

协议兼容

/v1/agent 或等价入口可用；
/v1/responses 别名可用，或明确说明不支持；
普通输入、消息数组和多轮上下文均有测试；
流式事件没有被压扁成单一文本；
工具调用 ID、参数和结果可以闭环。

模型与路由

目标模型 ID 与大小写已核对；
响应模型与请求模型已记录；
第三方模型来源没有被未经验证地写成“官方直连”；
失败重试和回退由哪一层负责已经明确；
模型变更后重新测试上下文、工具和推理参数。

成本与账单

模型输入、输出、缓存和推理 Token 分开记录；
Web Search、URL 抓取、Sandbox 等工具费用单独核对；
中转倍率、充值门槛和活动有效期按渠道页面记录；
usage 与实际账单可以通过请求 ID 对账；
用成功任务成本而不是单一 Token 单价做比较。

Sonar 迁移

旧 Sonar 请求仍有回归样例；
Agent API 等价请求已跑通；
迁移后的模型、搜索、引用、工具和价格都有对照结果；
9 月 27 日后的故障处理和替代渠道已准备好。

结语

Perplexity Agent API 的变化，核心不只是把一个接口路径从 /v1/chat/completions 换成 /v1/agent。它把多供应商模型、实时搜索、工具、推理、预算和成本明细放进了同一条 Agent 请求链，也让“中转能不能接”从模型名称问题变成协议、工具和账单问题。

如果你只是需要一次带引用的问答，普通搜索 API 可能已经够用；如果你要把它接入编程代理、研究 Agent 或多轮自动化流程，就应该按完整能力验收。先确认模型 ID 和入口，再测试工具与流式事件，最后用真实账单核对成功任务成本，才是比较中转渠道的可靠顺序。

参考来源

Perplexity Agent API 官方快速开始（入口、第三方模型、Responses 别名与 usage 示例）：https://docs.perplexity.ai/docs/agent-api/quickstart
Perplexity Agent API 官方模型目录（模型 ID、输入/输出/缓存费率）：https://docs.perplexity.ai/docs/agent-api/models
Perplexity API 官方定价（工具、搜索、Sandbox 与 Sonar 迁移提示）：https://docs.perplexity.ai/docs/getting-started/pricing
Perplexity Agent API OpenAI 兼容说明：https://docs.perplexity.ai/docs/agent-api/openai-compatibility
Perplexity Sonar 迁移指南：https://docs.perplexity.ai/docs/agent-api/migrate-from-sonar/how-to
Perplexity 官方文档索引：https://docs.perplexity.ai/llms.txt

<!– 选题与核验备注（不作为正文展示）：

sourceCheckedAt: 2026-09-25 UTC
contentAction: create
overlappingContent: 已检查本地 blog-drafts/ 与线上 GET https://routerhub.site/api/blogs 返回的 79 篇文章。未发现 Perplexity/Agent API/Sonar 同意图文章；已有 OpenAI Agents API、MCP 和多模型路由文章，但主题不同。
destinationUrl: https://routerhub.site/
conversionAction: 查找并比较支持目标模型和工具调用的 API 渠道，再按本文清单做兼容性与账单验收。
recommendedCTA: 先比较候选渠道，再用 /v1/agent、Responses、工具调用、搜索和 usage 做回归测试。
confidence: high
missingEvidence: 尚未获得 RouterHub 渠道逐站的 Perplexity Agent API 实测矩阵，因此正文不点名推荐具体渠道，也不宣称任何渠道已完整兼容。
score: 88/100（routerhubFit 23, searchDemand 12, conversionPotential 13, serpOpportunity 8, destinationReadiness 8, freshness 10, sourceQuality 10, contentDepth 4）
dynamicFactsVerifiedAt: 2026-09-25 UTC；Sonar 截止日期仅按 Perplexity 官方定价页提示表述，未扩展为所有中转渠道的统一停服承诺。 –>

Perplexity Agent API 怎么接中转：模型路由、Responses 兼容与工具计费核验

正文

Perplexity Agent API 怎么接中转：模型路由、Responses 兼容与工具计费核验

先说结论：支持“Perplexity”不等于支持 Agent API

一、官方 Agent API 到底增加了哪些能力

1. 主入口与 OpenAI SDK 别名不是两套产品

2. 模型选择从“一个 Sonar 名称”变成多供应商模型 ID

3. 搜索和工具是额外能力，不是普通 Token 的附属品

二、模型路由该怎么理解：不要把三种路由混成一种

第一种：应用自己选择模型

第二种：使用官方预设

第三种：渠道内部的隐藏映射

三、接中转前，先做一个最小兼容测试

测试 A：最小文本请求

测试 B：Responses 别名

测试 C：单个工具调用

测试 D：Web Search 或 URL 抓取

四、Sonar 迁移是现在必须排进计划的事项

五、成本不能只看模型 Token 单价

一个更适合 Agent 的成本指标

六、哪些字段最容易在中转层丢失

tools 和工具结果

流式事件

usage.cost

多轮上下文

模型和工具能力映射

七、RouterHub 用户如何比较候选渠道

八、发布前核验清单

协议兼容

模型与路由

成本与账单

Sonar 迁移

结语

参考来源

`tools` 和工具结果

`usage.cost`