金磊 发自 凹非寺
量子位 | 公众号 QbitAI
豆包APP里的搜索能力，现在要走出豆包了——
一头扎进面向企业和开发者的Agent，目标是想让Agent获取信息的这件事情，变得更加靠谱。
我们先用最近大热的话题菲尔兹奖，来看下走出来的豆包搜索，实力到底几何。
这类题目看上去不算复杂，真要做好，却得同时满足几个条件。
信息得足够新，获奖名单和研究贡献不能出错；来源也得足够可靠，官方公告、媒体报道和人物资料最好能够相互印证。
这次的结果里，有一个地方需要先讲清楚。
这次豆包搜索返回了3条与问题直接相关的资料，分别来自政府官网转载、科技日报，以及西蒙斯基金会的相关内容。
重点不只在于找到了哪些页面。每条结果还同时带回了信源名称、权威分级、发布时间、围绕当前问题生成的正文摘要，以及能够直接引用的原文Markdown节选。
从用途来看，第一条资料适合核对获奖名单和官方获奖理由；第二条补充了两位中国数学家的研究方向与成果；第三条则提供了国际组织和专业机构对本届获奖者的评价。
若继续交给Agent处理，它可以先利用权威分级和发布时间判断资料是否可靠、是否足够新，再直接从正文摘要和原文节选中提取获奖名单、研究贡献和媒体评价。
这也是豆包搜索和只返回网页入口的搜索有所不同的地方。Agent拿到的不只是一串链接，还包括判断资料能不能用所需的关键字段。
大模型很擅长理解、归纳和推理，但它天然有知识更新时间的边界。只要问题碰到新事件、新版本和新价格，单靠模型脑子里的“存量知识”就不够用了。
这时候，如果搜索只给出网页入口，Agent还要继续打开页面、理解正文、抽取信息。豆包搜索想省下的，正是中间这段反复读取和处理网页的过程。
所以，到了Agent阶段，搜索能力的关键已经不只是能不能找到网页，还要看返回的信息能否直接进入下一步任务。
简单理解，火山引擎是把豆包APP背后的搜索能力单独拆出来，再通过API、MCP、Skill等方式，接进更多模型和Agent里。
据了解，目前豆包搜索已经正式面向企业和开发者开放，每月会赠送500次免费搜索额度，同时支持按量后付费和订阅月卡。
为了了解豆包搜索的更多能力，一波实测，走起~
Agent都会上网，开始拼“怎么搜”和“搜什么”
在正式开始之前，先简单交代一下这次的实测环境。
我们在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真正相关的部分。
这一步会直接影响Agent拿到什么。
豆包搜索除了返回网页入口，还会结合用户当前的问题生成正文摘要，并提供权威分级、发布时间和原文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能做的事情越多，对外部信息的依赖也会越强。
模型可以理解需求、拆解任务、规划步骤，也能把搜回来的内容重新整理成一份报告。但现实世界一直在变化，产品会更新、价格会调整、政策会发布，企业和市场每天都有新动向。只靠模型内部已有的知识，很难长期跟上这些变化。
这时候，搜索就成了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模型配合使用。模型负责理解和执行，搜索负责提供外部信息，两者可以被接进同一条任务链路里。
AI会搜索，很快就会成为基础能力。
再往后看，真正拉开差距的，会是Agent究竟能看到什么信息，能不能判断哪些来源更值得信，以及能否少绕几步，就把搜到的内容变成下一步可以直接使用的结果。
从这个角度看，豆包搜索走出豆包，瞄准的也不只是多一个搜索入口。
它更想成为Agent干活时，随时能够调用的那层信息工具。