豆包开放搜索能力，支持 Agent 调用

豆包 APP 里的搜索能力，现在要走出豆包了——

一头扎进面向企业和开发者的 Agent，目标是想让 Agent 获取信息的这件事情，变得更加靠谱。

我们先用最近大热的话题菲尔兹奖，来看下走出来的豆包搜索，实力到底几何。

这类题目看上去不算复杂，真要做好，却得同时满足几个条件。

信息得足够新，获奖名单和研究贡献不能出错；来源也得足够可靠，官方公告、媒体报道和人物资料最好能够相互印证。

这次豆包搜索返回了 3 条与问题直接相关的资料，分别来自政府官网转载、科技日报，以及西蒙斯基金会的相关内容。

重点不只在于找到了哪些页面。每条结果还同时带回了信源名称、权威分级、发布时间、围绕当前问题生成的正文摘要，以及能够直接引用的原文 Markdown 节选。

从用途来看，第一条资料适合核对获奖名单和官方获奖理由；第二条补充了两位中国数学家的研究方向与成果；第三条则提供了国际组织和专业机构对本届获奖者的评价。

若继续交给 Agent 处理，它可以先利用权威分级和发布时间判断资料是否可靠、是否足够新，再直接从正文摘要和原文节选中提取获奖名单、研究贡献和媒体评价。

这也是豆包搜索和只返回网页入口的搜索有所不同的地方。Agent 拿到的不只是一串链接，还包括判断资料能不能用所需的关键字段。

大模型很擅长理解、归纳和推理，但它天然有知识更新时间的边界。只要问题碰到新事件、新版本和新价格，单靠模型脑子里的“存量知识”就不够用了。

这时候，如果搜索只给出网页入口，Agent 还要继续打开页面、理解正文、抽取信息。豆包搜索想省下的，正是中间这段反复读取和处理网页的过程。

所以，到了 Agent 阶段，搜索能力的关键已经不只是能不能找到网页，还要看返回的信息能否直接进入下一步任务。

简单理解，火山引擎是把豆包 APP 背后的搜索能力单独拆出来，再通过 API、MCP、Skill 等方式，接进更多模型和 Agent 里。

据了解，目前豆包搜索已经正式面向企业和开发者开放，每月会赠送 500 次免费搜索额度，同时支持按量后付费和订阅月卡。

为了了解豆包搜索的更多能力，一波实测，走起～

在正式开始之前，先简单交代一下这次的实测环境。

我们在 Mac 本地搭建了 OpenClaw，并接入 Doubao-Seed-Evolving 作为 Agent 模型。搜索这一侧，则单独安装了火山引擎提供的 byted-web-search Skill。

npx skills add https://skills.volces.com/skills/bytedance/agentkit-samples -s byted-web-search —agent openclaw

随后，再到火山引擎豆包搜索的控制台创建 API Key，完成接口配置。

接下来的三个 Case 都在 OpenClaw Dashboard 里完成。我们会在 Prompt 中明确指定调用 byted-web-search，并在截图中同时保留用户输入和搜索结果。

为了方便观察，豆包搜索每次只展示 3 条代表性资料。除了标题和来源，结果里还会带回权威分级、发布时间、正文摘要和原文 Markdown 节选。

至于 Agent 后续会采用哪些资料、每条资料分别能支撑什么结论，我们放在文字中简要说明。

第一个 Case，正好撞上了一条刚刚发生的新消息。

就在昨天深夜，Kimi K3 迎来正式开源。新消息出来得足够近，也很适合测试豆包搜索对最新事件的反应速度，以及它能否迅速定位到官方信息。

从结果来看，豆包搜索返回了 3 条与 Kimi K3 开放权重直接相关的资料，而且都带有明确的发布时间。

第一条来自新浪财经旗下的国是直通车，发布时间为 7 月 28 日 10 时 54 分，摘要中提取出了模型权重、技术报告，以及 MoonEP、FlashKDA、AgentEnv 等训练基础设施。

第二条来自 IT 之家，发布时间为 7 月 27 日 23 时 14 分，进一步补充了模型参数、GitHub 和 Hugging Face 入口、部署要求及 API 价格。

第三条发布于 7 月 28 日 6 时 32 分，重点解释了 Kimi K3 License 及这次开放的边界——公开的重点是模型权重，并不等于完整训练代码同步开源。

若继续交给 Agent 加工，第一条适合确认权重发布及技术信息，第二条可以补充仓库入口、部署和 API，第三条则用于校准许可证及开源具体指什么。

这轮测试说明，面对一条刚刚发生的新消息，豆包搜索可以迅速把权重、技术报告、许可证、仓库入口和部署要求等关键信息抽取出来。Agent 不必重新逐页阅读长文，就能直接基于这些字段继续处理。

第二个 Case，我们把问题拉到了行业研究。

新能源汽车的信息分布很散。政策可能来自监管机构，企业动作散落在公司新闻和媒体报道里，销量数据、机构预测又来自另一批行业信源。

所以，这一轮主要看的，是豆包搜索能不能把行业和企业信息找回来，同时让 Agent 知道这些内容分别来自哪里。

这次豆包搜索返回了 3 条来源类型不同的资料，而且都带有权威分级和发布时间。

第一条来自新华网，发布时间为 6 月 11 日，主要涉及新能源汽车安全监管和相关国家标准，适合用于观察政策与监管动向。

第二条来自凤凰网汽车转载的行业报道，发布时间为 5 月 20 日，重点梳理了全球车企竞争加剧，以及不同企业在新能源转型中的战略分化。

第三条来自中国驻匈牙利大使馆经济商务处转载的国际能源署报告，发布时间为 6 月 21 日，其中给出了 2026 年全球电动汽车销量预测和区域市场趋势。

若交给 Agent 继续处理，第一条可以支撑政策监管，第二条适合补充车企竞争格局，第三条则用于判断全球市场趋势。

三条结果分别来自政府网站、行业媒体和国际机构报告。豆包搜索提前返回信源类型、权威分级、发布时间、摘要和原文节选，Agent 可以直接判断每条资料适合承担什么角色，而不必重新打开页面逐一理解。

第三个 Case，我们继续追一个变化更快的领域——AI Coding。

这类信息最麻烦的地方，往往不是搜不到，而是新旧消息混在一起。产品功能、套餐价格和使用规则都可能频繁调整，几个月前的内容放到今天，结论就可能已经变了。

在 AI Coding 案例中，豆包搜索同样返回了 3 条资料，每条都带有明确的发布时间。

三条内容分别发布于 6 月 25 日、6 月 3 日和 7 月 11 日，均处于 Prompt 设定的近三个月范围内。

第一条来自腾讯云开发者社区，聚焦 AI 编程产品订阅策略的变化。摘要中提到，Claude Code、GitHub Copilot、Cursor、Windsurf 等主流工具在今年 3—6 月间陆续收紧“无限使用”，计费方式更多转向时长、Token 或点数。

第二条来自科技媒体对 Codex 更新的报道，重点涉及 Agent Plugins、Skills 等新能力，以及 Codex 在企业内部的使用情况。它更适合用来观察 AI Coding 如何从个人编程工具，进一步走向企业级 Agent 平台。

第三条同样来自腾讯云开发者社区，梳理了近期一批开源 AI 编程工具的演进。OpenSquilla 等项目开始强调自我验证，多 Agent 协作和网络依赖也更频繁地出现在工具链中，说明 AI Coding 正在从单点代码生成继续向完整 Agent 工作流延伸。

若交给 Agent 继续加工，这三条资料可以分别对应价格变化、企业应用和行业趋势。发布时间帮助它先确认资料是否符合范围，权威分级用来判断来源，正文摘要和原文 Markdown 则让它快速提取每条信息真正能够支撑的结论。

把这些 Case 连起来看，搜索和 Agent 之间的关系已经比较清楚了。

豆包搜索先围绕用户输入返回相关资料。除了标题和信源，结果中还提供权威分级、发布时间、正文摘要和原文 Markdown 节选。

Agent 拿到这些字段后，可以先判断信息是否足够新、来源是否可靠，再决定每条资料适合支撑什么结论。

菲尔兹奖案例中，不同资料分别用于核对获奖名单、研究贡献和机构评价；Kimi K3 案例中，Agent 可以从摘要和原文中提取权重、许可证、仓库入口和部署信息；新能源汽车案例中，三种信源分别对应政策、市场和机构判断；AI Coding 案例则进一步体现了时间范围筛选的重要性。

所以，评价 Agent 搜索不能只看最后的答案写得是否完整。

更重要的是，搜索返回的信息是否相关，字段是否足够丰富，以及 Agent 能不能直接利用这些字段继续完成任务。

前面的 Case 展示的是最后效果。真正决定这些结果能不能直接交给 Agent 的，还是搜索之前的数据加工。

互联网里的信息并不整齐。网页、PDF、图片、图表和表格混在一起，同一条消息还可能被反复转载。豆包搜索需要提前完成内容解析、去重、时间判断和结构化处理，再从中找到与当前 Query 真正相关的部分。

豆包搜索除了返回网页入口，还会结合用户当前的问题生成正文摘要，并提供权威分级、发布时间和原文 Markdown 等字段。像前面的 K3 案例，Agent 要找的是开源进展，摘要会优先提取权重、许可证、仓库入口、部署和 API 等与当前问题直接相关的内容，而不会把整篇网页原封不动塞进上下文。

对 Agent 来说，这类结果离直接可用更近。它少了一轮打开网页、理解页面和重新抽取信息的过程，也能减少无关内容带来的 Token 消耗。

除了网页摘要，豆包搜索还提供如意卡片等结构化数据。股票、金价、汇率、航班、火车和演出信息，可以直接以价格、时间、状态等字段返回。Agent 不需要再从一大段自然语言中寻找数字。

豆包搜索会随结果返回权威度描述，并支持按照行业、时间范围、站点和权威等级进行检索。到了 AIGC 内容越来越多的今天，官方公告、权威媒体、行业报道和普通转载混在一起，这些标签至少能帮助 Agent 先完成一轮来源判断。

权威度当然不是唯一标准。最终是否采用一条结果，还需要结合相关性、时效性和内容本身来判断。因此，是否能够返回更全面的信息维度，对 Agent 的加工处理至关重要。

通用信息加工解决的是搜索结果能不能用，垂类建设则决定能够把任务做多深。

金融投研更需要企业数据和官方信息，商品洞察会关注用户讨论和平台趋势，出行、娱乐等场景则更适合直接返回结构化卡片。目前豆包搜索覆盖金融投研、商业情报、商品洞察、创作营销和办公自动化等方向。

最后，这些能力还需要以 Agent 友好的方式开放出来。

时间范围、指定站点、屏蔽站点、行业分类、权威等级和 Query 改写，都可以由上层 Agent 根据任务灵活调用。搜索负责把工具准备好，Agent 决定这次该搜多新、搜多广，以及优先相信哪些来源。

这些能力最终有没有效果，还得放到不同类型的评测中检验。

除了前面的三个 Case，豆包搜索还被放进了四组不同类型的搜索评测中。

为了尽量排除模型能力带来的干扰，这组测试统一使用 Seed 作为模型底座，并采用各评测集的官方打分器。空白对照指的是不接入搜索工具时的表现，图中的百分比，则代表不同搜索产品接入后，相对空白对照带来的增幅。

先看主要考察事实准确性的 SimpleQA，豆包搜索接入后，相比无搜索能力接入的基础模型提升了 70%：

事实问答看似简单，真正考验的是搜索能否找到与问题直接相关的资料，同时避开错误、过期或相互矛盾的信息。搜索结果一旦偏离，接入搜索反而可能给模型带来更多干扰。

更强调最新信息的 FreshQA 的结果如下：

这也对应了前面几个实测中体现出的效果。面对刚刚发生的产品开源、近期价格变化和行业动态，模型内部知识很难始终保持同步，搜索的信息更新速度和时间判断能力会直接影响最终结果。

再往下，是更复杂的中文浏览和深度检索任务 BrowseComp-ZH：

相比只需定位单一事实的问题，这类任务往往需要连续检索多个页面，再把分散的信息拼接起来。几款搜索产品都带来了明显改善，豆包搜索的增幅仍然排在最前面。

最后是面向中文深度搜索和职业场景的 Xbench-2505：

这类任务通常带有更复杂的行业语境，需要搜索理解用户究竟想解决什么问题，再去寻找对应的政策、企业、市场或专业资料。中文信息处理、信源覆盖和 Query 理解能力，都会影响最终结果。

四组结果放在一起看，豆包搜索的提升覆盖了事实问答、最新信息、复杂浏览和深度搜索场景。

Agent 能做的事情越多，对外部信息的依赖也会越强。

模型可以理解需求、拆解任务、规划步骤，也能把搜回来的内容重新整理成一份报告。但现实世界一直在变化，产品会更新、价格会调整、政策会发布，企业和市场每天都有新动向。只靠模型内部已有的知识，很难长期跟上这些变化。

这时候，搜索就成了 Agent 连接外部世界的入口。

前面的几个 Case 已经能说明这一点。追 Kimi K3 的凌晨开源进展，要迅速找到官方发布和模型仓库；研究新能源汽车行业，要分清政策、企业和市场信源；梳理 AI Coding 动向，又得利用发布时间判断哪些内容仍然有效。

模型负责理解任务、筛选资料和组织结果，搜索则把最新、可追溯的信息送进工作流。两边配合起来，Agent 才能持续处理现实世界里不断变化的任务。

对开发者来说，上手也不算复杂（地址：https://console.volcengine.com/search-infinity/web-search-exp）。

在 OpenClaw 或其他 Claw 环境中，通过一条命令安装 byted-web-search Skill，再到联网搜索控制台创建 API Key，就可以把豆包搜索接进自己的 Agent。

个人用户每月可以获得 500 次免费搜索额度。额度用完后，也可以在控制台开通正式服务，按调用量继续使用。

简单问答里，这套流程可以很轻。模型发现自己缺少最新信息，临时联网搜一下，再把答案组织出来，普通用户基本感受不到背后的调用过程。

可一旦进入投研、办公、编程、商业分析等复杂场景，事情就没这么简单了。

开发者往往要限定搜索时间、指定信源范围，还得考虑一次任务要搜几轮、花多少 Token、哪些结果可以直接引用。API、MCP 和 Skill 的价值也就在这里，它们让搜索能够被单独控制，并嵌入一条更完整的 Agent 工作流。

因此，模型自带的搜索能力和独立搜索服务，大概率会长期共存。

前者更方便，适合日常问答和轻量任务；后者更灵活，也更适合企业把搜索范围、调用策略和成本管起来。对于一个真正要稳定运行的 Agent 来说，“能联网”只是门槛，能否把搜索过程控制得足够细，才会影响最后的效果。

豆包搜索选择在这个时候走出豆包 APP，背后的逻辑也很清楚。

过去，用户是在豆包里直接使用 AI 搜索；现在，这层能力被单独抽出来，开始面向企业和开发者开放。

它背后连着豆包模型、字节系内容资源和火山引擎的企业服务，也可以在火山引擎 Agent Plan 里与 Doubao-Seed-Evolving 模型配合使用。模型负责理解和执行，搜索负责提供外部信息，两者可以被接进同一条任务链路里。

再往后看，真正拉开差距的，会是 Agent 究竟能看到什么信息，能不能判断哪些来源更值得信，以及能否少绕几步，就把搜到的内容变成下一步可以直接使用的结果。

从这个角度看，豆包搜索走出豆包，瞄准的也不只是多一个搜索入口。

它更想成为 Agent 干活时，随时能够调用的那层信息工具。

北京说 Agent 已经能造世界，杭州却说它是刚发明的电灯泡 2026-07-25

妙啊！无人机直连卫星传 Token 2026-07-18

1.5B 开源通用 VLA 模型，冲进具身智能第一梯队 2026-07-20

全球首个「具身原生」预训练模型发布，从物理世界出发为机器人造大脑！2026-07-10

为药物研发工作者提供数据、算法、算力三位一体的一站式解决方案

量子位 QbitAI 版权所有 © 北京极客伙伴科技有限公司 京 ICP 备 17005886 号-1