Vercel 网关接入 DeepSeek 搜索与抓取

Vercel AI Gateway 新增了 DeepSeek Search 和 DeepSeek Fetch：前者找网页，后者把网页正文取回来交给模型。接入它们只需一个 AI Gateway API key，不必另开 DeepSeek 账号，切换模型提供商时也能继续使用同一套工具。

对正在给 AI 应用补联网能力的程序员，这次更新的价值是减少接入工作。但它也有一个需要看清的边界：让模型按顺序尝试多个搜索工具，只是尽力执行的策略，并不等于程序已经实现了严格的重试流程。

搜索结果和网页正文，为什么需要两个工具

DeepSeek Search 返回相关页面的标题、URL 和摘要；DeepSeek Fetch 则获取页面内容，并以 Markdown 形式提供给模型阅读。

这两个步骤解决的问题不同。搜索负责找到候选资料，Fetch 负责拿到可以进一步分析的正文。摘要适合筛选页面，但要解释公告中的配置、限制和计费规则，通常还需要读取原页面。

工具与模型也可以分开选择。原文明确表示，任何支持工具调用（tool calling）的模型都能使用它们，无须限定为 DeepSeek 模型。第一个示例使用的是 deepseek/deepseek-v4.1-flash-1017，第二个则换成了 zai/glm-5.3-flash。

模型提供商可以更换，搜索和正文获取工具可以保留。

接入要求是 AI SDK v6 的 6.0.321 及以上版本，或 v7 的 7.0.160 及以上版本。原文给出的更新命令是 pnpm add ai@latest，还需要设置 AI_GATEWAY_API_KEY。已有项目更新时，应先确认自己使用的主版本。

多个搜索工具能兜底，但顺序由模型决定

原文第二段示例把 DeepSeek Search、Exa Search 和 Parallel Search 一起交给模型，并要求搜索成功后用 DeepSeek Fetch 读取结果 URL。下面保留代码内容，去掉原文混入的行号并恢复换行：

import { gateway, streamText } from 'ai';
const result = streamText({
  model: 'zai/glm-5.3-flash',
  system: 'Try deepseek_search, then exa_search, then parallel_search on errors. After search succeeds, use deepseek_fetch on a result URL.',
  prompt: 'Find the latest Vercel AI Gateway announcement, fetch it, and summarize it.',
  toolChoice: 'required',
  tools: {
    deepseek_search: gateway.tools.deepseekSearch({ count: 3 }),
    deepseek_fetch: gateway.tools.deepseekFetch(),
    exa_search: gateway.tools.exaSearch({ numResults: 3 }),
    parallel_search: gateway.tools.parallelSearch({ maxResults: 3 }),
  },
});
for await (const text of result.textStream) {
  process.stdout.write(text);
}

要重点看 system 那一行：搜索提供商的尝试顺序写在提示词里，而不是由应用代码逐步执行。原文也明确提醒，这种回退由模型主导，提供商顺序和重试上限都只能尽力遵循。

toolChoice: 'required' 不能被理解成严格执行上述顺序的保证。如果业务要求固定尝试次数、明确的超时边界或可复现的失败处理，就需要在应用层补上控制逻辑。

另一个实用细节是，DeepSeek Fetch 可以读取这几个搜索工具返回的结果 URL。搜索失败后换一家，并不要求连正文获取工具也一起更换。

每千次 0.75 美元，只覆盖工具请求

DeepSeek Search 和 DeepSeek Fetch 的价格分别是每 1,000 次计费请求 $0.75。失败请求、超时和空结果不收取工具费用，模型 token 另行计费。

因此，「搜索后读取正文」涉及两种工具，不能把整个流程当成一次 Search 请求估算。正文进入模型之后，还会产生独立的模型费用。

AI Gateway 同时提供模型调用、用量与费用跟踪，以及路由、重试和故障切换配置；认证可以使用 AI Gateway API key，也可以携带自己的提供商密钥。但这些平台能力，不应与上面由模型决定的搜索回退混为一谈。

我的判断

这次更新适合已经使用 AI Gateway、又需要为应用增加网页检索能力的团队。统一认证、保留工具配置，确实能减少切换模型时的接线工作。

不过，原文是一则功能公告，没有提供搜索质量、正文提取完整度、延迟或成功率的对照数据。它证明了工具可以怎样接入，没有证明 DeepSeek Search 比其他搜索方案更适合你的资料来源，也没说清复杂网页的抓取边界。

我的取舍是：探索性问答可以先尝试模型主导的回退；需要稳定执行的业务流程，则更适合由 Node 服务控制搜索顺序、超时和重试次数。后者需要多写代码，但执行路径更容易检查。

能拿来做什么

• 已使用 AI SDK 的项目，可以先核对版本和 AI_GATEWAY_API_KEY 配置，用「查找公告、读取正文、生成摘要」跑通完整流程。
• 给日常 AI 编程助手补充资料时，可以让 Search 找到候选页面，再用 Fetch 读取正文，避免只根据搜索摘要解释 API。
• 需要多个搜索来源兜底时，可以复用同一个 DeepSeek Fetch；如果重试顺序属于业务要求，就把它写进 Node 控制逻辑。
• 评估成本时，应分别统计 Search、Fetch 和模型 token，结合实际调用记录判断开销。