DeepSeek · 官方更新与接口解读 · 2026-10-17
原文：10 月 17 日更新 · Search & Fetch 指南
这次更新值得关注什么
DeepSeek 在 10 月 17 日同时更新了 V4.1 Flash，并开放自研搜索引擎的 Search 与 Fetch 接口。对 Agent 工程而言，后者提供了一种新的接入方式：应用可以分别获取候选网页和网页正文，把联网取证显式接到自己的执行流程中。
这与只给模型一个“联网搜索”开关有不同的工程含义。应用能够记录查了什么、选择了哪个来源、最终读到了哪段内容，也能在搜索质量与网页读取之间设置不同的处理逻辑。模型更新与工具开放是两项变化；本文集中解释工具接口，不能把模型榜单成绩当成搜索接口带来的收益。
官方文档公开了调用方式和返回字段，没有公开搜索引擎的内部系统架构。以下讨论基于可见接口；关于取证、缓存和验证的建议是工程解读，不声称已在生产中复现。
Search 与 Fetch 分别交付什么
| 环节 | 官方端点 | 主要输入 | 主要输出 |
|---|---|---|---|
| Search | POST /v1/tools/search |
检索问题及可选约束 | 候选页面列表、URL、摘要和相关元数据 |
| Fetch | POST /v1/tools/fetch |
单个网页 URL | 网页标题与 Markdown 正文 |
两个端点都使用 https://api.deepseek.com，采用与 DeepSeek API 相同的 Bearer 认证，返回原始 JSON。它们本身并不会替应用完成一次完整的模型问答。
Search 的 query 必填，count 控制返回数量；need_content 默认关闭，因此返回记录中的 content 为空并不一定是失败。需要正文时可以请求附带内容，也可以先挑选 URL，再调用 Fetch。后者将“发现来源”和“读取来源”分开，使应用能够避免对每个候选页面都做同样的后续处理。
这个分工适合论文资讯、RAG 和故障调查等场景：先缩小资料范围，再对选中的一手来源取正文。是否采用两阶段流程，仍应由结果质量、请求开销和延迟决定，不能假设多一步调用一定更好。
从一个问题到一条可追溯的证据
可以把使用过程分为四步：提出明确查询；取得候选来源；读取选中页面；将证据交给模型生成回答。前两步解决“去哪里找”，后两步才接近“实际依据是什么”。
例如，想了解一篇新论文的系统贡献，检索标题可以定位论文页、作者项目页和转述文章。排序靠前的转述便于发现线索，但对核心机制和数值，仍应回到原文。Search 返回的 snippet 或 summary 也不等同于作者论文中的完整论证。
在自己的流程中，建议同时保留原始问题、查询、最终 URL、获取时间和实际使用的正文快照。这是本文提出的记录方式，便于之后解释“为什么当时得出这个结论”；它不是接口自动提供的审计保证。网页更新之后，仅有 URL 往往不足以还原先前看到的内容。
查询约束怎样影响检索
指南列出了 site:、排除站点、短语、语言以及日期范围等查询操作符。例如，按官方站点限定检索，通常比只依赖标题中的产品名更接近一手信息；同时使用日期范围，有助于减少旧版本说明混入。
但约束并不是越多越好。过窄的站点或时间范围可能把相关来源一起排除，文档的发布时间也可能缺失。合理做法是先从任务意图确定约束，在结果不足时有解释地放宽，并记录最终采用的条件。
返回字段中的相关性分数、来源评级和日期可以辅助排序，却不能替代事实核验。特别是工程问题，版本、硬件、实现配置和实验环境通常需要进入正文才能看见。一个高分结果能帮助选择阅读顺序，不能直接证明其中的结论适用于当前系统。
空结果、缺正文与请求失败要分开
接口集成里很容易把这些情况混成一个“搜索失败”：查询正常完成但没有命中；找到页面但没有正文；目标站点无法获取；请求本身因认证、限流或参数问题失败。
官方说明中，Search 无匹配时可以正常返回 HTTP 200 和空列表。need_content: false 时正文为空是预期行为；即使请求了正文，内容也可能不可用。Fetch 则受到目标站点可达性、访问策略和内容类型的约束。应用需要分别处理这些状态，避免模型拿着空证据继续给出确定结论。
重试也应有边界。指南将超时、限流和部分服务器错误列为可等待后重试的情况；参数或认证错误则应先修正原因。对 Agent 来说，这种区别还影响是否继续调查、改换来源，或者明确告诉用户证据尚不充分。
把检索接入 Agent，需要观察哪些结果
本文更建议观察一次完整任务，而不是只盯着单次 API 成功率。可以记录检索后有多少候选真正被采用，关键结论是否能回到原始出处，以及加入取证步骤后用户等待多久。
还需要区分缓存的对象。缓存一份网页正文、复用一组搜索结果和复用模型的 KV 状态，是不同层面的优化；它们各自具有更新、失效和有效性条件。不能因为某次查询曾成功，就无限期复用旧网页来回答涉及新版本的问题。
联网资料也应作为待分析的数据，而不是应用控制指令。来源中的示例命令或描述不应自动变成 Agent 的操作授权。对于研究资讯，最实际的收益是让来源链条更清楚，并让证据不足成为可见状态，而不是隐藏在一段流畅回答后面。
怎样看待同日的模型升级
官方更新说明还列出 DeepSeek-V4.1-Flash-1017 的多项评测结果，并注明部分任务使用的 harness 或评测条件。这里没有进行独立复现，也不把不同榜单数字合成统一的“Agent 能力提升”。如果已有业务使用该模型，更有价值的是用自己的任务、工具接口和成本口径做前后比较。
这次值得跟踪的变化，是应用能更显式地控制网页证据的获取过程。 开放 Search/Fetch 带来了可组合的接口，但来源选择、有效性判断、错误恢复和回答验证仍需要应用完成。本篇未调用付费接口，也没有给出未经测量的延迟或成本收益。