解决AI幻觉：豆包搜索API+MCP工具让Agent搜索更稳
先跟大家报个喜：我开源的女娲skill项目，GitHub星标已经快冲到30k，马上就要迎来新的里程碑了。
不过随着项目关注度提升，我也收到了不少用户反馈，主要集中在两个核心问题上：一是工具并没有真正执行联网搜索，蒸馏生成的内容很多都是AI凭空编造的；二是在一次蒸馏任务中，agent还没完成全部流程就因为上下文窗口溢出直接崩溃了。
经过仔细排查，我找到了问题的根源：当用户给Claude Code接入国产模型时，原本自带的内置搜索功能会直接失效。由于subagent无法获取真实的调研数据，又必须交付符合要求的结果，只能依靠自身的预训练知识库进行脑补，最终生成了与事实不符的内容。
事实上，Claude Code以及不少主流agent自带的搜索功能，都是和自家模型服务深度绑定的。一旦更换为通过外部API调用的国产模型，这层内置的搜索能力就会完全失效。而近半年来国产模型的编码能力大幅提升，越来越多开发者选择接入国产模型，遇到这个问题的用户也越来越多。
既然现有的工具无法满足需求，那不如自己动手打造一个适配的解决方案。我基于豆包搜索开放的API封装了一个MCP工具，目前每月可以享受500次免费搜索额度，基本可以满足日常使用需求，让接入国产模型的agent也能拥有稳定可靠的联网搜索能力。这个工具已经开源，只需要一条命令就能完成安装，相关地址会放在文末。
关于大模型的幻觉问题
很多人好奇大模型为什么会生成虚假内容，也就是我们常说的“幻觉”。其实这和模型的训练数据截止时间密切相关：模型预训练时摄入的知识有一个明确的时间节点，通常在模型发布前半年到一年左右，在这之后发生的所有事件，模型都完全无法知晓。如果让它去调研昨天刚发布的产品、或者最新的赛事结果，没有联网搜索的支持，模型只能依靠旧有的记忆硬撑，实在撑不住的部分就会凭空编造，这就是幻觉的核心来源。
之前刷屏的梁文锋四小时会议实录中，他也专门提到了这个问题：大模型的幻觉确实有解决方法，但这是一个长期的命题，在DeepSeek内部被归类为产品优化问题，会逐步推进解决，但暂时不会作为核心优先级。
我认同幻觉的解决需要长期投入，但对于我们这些每天使用agent进行工作的人来说，根本等不及模型厂商慢慢迭代。现阶段最务实的解决办法，就是让agent主动去联网获取实时的、可溯源的真实信息，从根源上减少幻觉的产生。
我之前使用的是海外的Tavily搜索服务，这是专门为agent设计的搜索工具，我已经用了很长时间。但每次想推荐给读者时都会遇到阻碍：一是国内访问不稳定，批量运行agent时经常出现超时；二是计费以美元结算，需要办理海外信用卡才能使用。而我的很多读者正是因为无法使用Claude才转向国产模型，再让他们为了一个搜索工具去办海外卡，相当于绕回了原点，这显然不是一个可行的方案。
所以我当时对搜索工具的需求非常明确：第一，国内可以稳定访问；第二，返回的结果可以直接被agent读取使用；第三，最好能够免费或者低成本，让用户拿来就能直接上手。在那个时候，符合这些要求的工具其实很难找到。
豆包搜索开放API，实测体验
不过最近一年多来，我注意到一个有趣的趋势：很多人已经不再依赖传统搜索引擎，遇到问题时更习惯直接用自然语言向豆包提问，比如询问前一天的赛事结果、当前各地的政策变化等等。我自己也经常和读者用豆包搜索的结果进行讨论，能明显感受到豆包的搜索能力做得相当不错。
前不久，我发现豆包搜索正式面向企业和开发者开放了API，每个账号每月赠送500次免费搜索额度，对于个人开发者日常使用来说完全足够，超额之后的计费也非常实惠。
如果不想写代码，可以直接在网页端体验：https://console.volcengine.com/search-infinity/web-search-exp
拿到API接口之后，我首先将它和Claude Code自带的搜索功能放在一起，用相同的关键词进行测试，最终发现了三个非常明显的优势。
第一，返回的正文内容非常充足。 给agent使用的搜索API，返回网页内容只是基础操作，真正的差距在于返回内容的完整性和整洁度。豆包搜索会在服务端就将每条搜索结果解析为干净的纯文本正文，我实测搜索中文热点话题时，每条结果平均有一千一百字左右，agent可以直接读取，不需要再去原网页二次抓取信息。
第二，结果自带精确到秒的时间戳和可溯源的原始链接。 我随便搜索了近期豆包新推出的Doubao-Seed-Evolving模型的进展，返回的十条结果里有八条明确标注了发布时间，比如2026-07-21 23:53:38、2026-07-19 02:16:32。通过时间戳，agent可以轻松分辨哪些是几小时前的最新内容，哪些是半个月前的旧闻，这对于时效性要求高的调研任务来说至关重要。
第三，每条结果都会标注所占用的token数量。 返回的结果里每个条目都带有ContentTokenCount字段，我当时搜索返回的十条结果中，短的只有五百多token，长的则达到六七千。一开始我没太在意这个细节，后来才反应过来这完全是为agent量身定制的设计：agent的上下文窗口有严格的token预算，知道每条内容占用的token数，才能合理规划哪些信息需要保留、哪些可以舍弃。之前收到的上下文溢出的差评，很大一部分原因就是搜索返回的内容过多，直接撑爆了agent的上下文窗口。
这些公开的字段给开发者带来了极大的便利，可以根据自己的需求自由提取和加工需要的信息，我后来做的MCP就是基于这些字段进行了封装和优化。从这些设计细节可以看出，豆包搜索的API完全是针对agent的使用场景打造的，和面向普通用户的搜索引擎有着完全不同的设计思路。
之后我又将豆包搜索和我之前一直在用的Tavily进行了对比，用同一批关键词分别测试。搜索中文热点话题时，豆包搜索每条结果平均一千一百字，每条都带有时间戳和token计数；而Tavily基础版本每条平均只有七百余字，既不返回发布时间，也没有token计数。对于agent来说最关键的两个参数——时间戳和token预算，豆包搜索都是默认提供的。而且在中文内容的搜索效果上，豆包搜索也明显更优秀，所以我很快就无缝切换到了豆包搜索。
本来我也想对比一下两者的响应速度，但由于我的服务器走的是公网链路，跨境网络的抖动非常大，同一批关键词前后两次测试的结果甚至能相差一倍，这种环境下对比延迟没有实际意义，所以就没有列出具体数据。
另外需要说明的是，豆包搜索开放了两个版本的API：Global版和Custom版，使用同一个API Key就可以调用，每月的500次免费额度是两版通用的，只是接口地址和参数写法略有不同。两个版本的定位也有区别：Global版是开箱即用的通用搜索，内置了标准的搜索规则，不需要额外配置；Custom版则是为企业场景定制的，可以根据业务需求自定义搜索规则，对于复杂的业务场景会更适用。
我分别用两个版本测试了同一批关键词，发现两者的能力侧重有明显区别：Custom版返回的正文内容更长，搜索中文热点时平均每条有三千七百字，而Global版只有一千一百字；响应速度也更快，在同一台服务器上连续测试时，Custom版的表现更稳定。除此之外，Custom版的每条结果还带有信源权威度标注，分为四个等级，agent可以根据这个标注来判断信息的可信度。而Global版虽然没有权威度标注和更长的正文，但它独有一个非常实用的功能：每条结果的token占用量，也就是我之前提到的第三个优势，我开发的token预算器就是依靠这个字段实现的。
所以我现在的使用习惯是，日常通用搜索用Global版，遇到需要严格把控信源的调研任务时，再切换到Custom版。大家可以根据自己的实际需求选择合适的版本。
花叔-豆包搜索MCP工具
既然豆包搜索的API返回的信息已经非常完善，我觉得与其每次让agent直接调用原始API，不如根据自己的使用需求，定制一个更符合agent使用习惯的MCP工具。
整个开发过程其实非常简单：我将豆包搜索的API文档交给Claude Code，告诉它我需要一个MCP服务器，能够接收搜索请求、调用豆包搜索API，并将结果整理成agent容易读取的格式。从编码、调试到文档编写，全部都是由Claude Code自动完成的。
这个工具就是huashu-doubao-search。它本质上是我根据自己的使用需求，对豆包搜索API进行的一层封装和调整，搜索、正文解析、时间戳这些核心能力都由豆包搜索提供，我只是将原始的API结果转换成agent更容易适配的格式。使用这个工具之前，你需要先在火山引擎控制台开通豆包搜索的API服务，获取API Key，之后只需要执行一条命令就可以完成安装：
安装完成之后，在Claude Code中直接说“用豆包搜索查一下xx”，agent就可以自动联网进行搜索了。
实际使用场景演示
场景一：调研持续更新的AI热点
前几天我想了解Doubao-Seed-Evolving模型的最新进展，让agent使用这个MCP进行搜索，几秒内就返回了十条结果，其中八条都带有精确到秒的时间戳：最新的一条是前一天晚上23:53发布的，内容是关于有人使用该模型消耗5.1亿token、一次性跑完三万行代码的实测；而官方发布公告的时间则停留在半个多月前。由于时间戳清晰明确，agent生成的摘要首先介绍了昨晚的最新动态，而不会将半个月前的公告当成最新消息。如果使用只返回链接的搜索工具，agent根本无法判断内容的新旧，只能按照链接顺序进行排序，很容易混淆最新和旧的信息。
场景二：撰写文章前的深度调研
这是我使用频率最高的场景。以前在写文章之前，想要理清一个话题的脉络，我需要打开十几个浏览器标签页，逐个阅读相关内容；现在只需要让Claude Code使用豆包搜索一次性返回十几篇文章的正文摘要，直接阅读这些整理好的内容，几分钟就能搭建出文章的框架。最直观的区别在于搜索轮次：以前agent拿到一堆链接之后，需要逐个点击读取，发现信息不足还要再次发起搜索，来回五六次都是常有的事；现在正文内容一次性全部返回，只需要一两轮就能完成框架搭建，节省了大量agent反复调用的次数和token消耗。
场景三：多信源交叉验证
这是我后来给MCP新增的功能。在调研和写作过程中，最担心的就是单一信源的信息不可靠，所以我增加了cross_check交叉核查模式：agent会针对同一个问题从多个角度并行发起搜索，将不同来源的信息放在一起进行比对，最终输出一份包含共识和分歧的详细报告。
比如我让agent核查Doubao-Seed-Evolving的上下文窗口长度，搜索返回的结果出现了矛盾：有的信源说是256K，有的则说是1M。如果agent直接相信第一条搜索结果，就会得出错误的结论。而通过交叉核查模式，矛盾的信息被直接摆在了台面上，结合时间戳还能得到合理的解释：该模型在6月刚发布时上下文窗口为256K，7月升级后扩展到了1M，两种说法都没有错误，只是对应的时间节点不同。有了这一步，agent就不会直接照搬第一条搜索结果写入报告了。
信息比对和整理的环节，我使用的是豆包自家的模型，并且可以根据需求自由指定。我默认使用的是最新的Doubao-Seed-Evolving模型，这个模型的特点是没有固定的版本号，使用同一个模型名就可以始终调用到最新版本，拥有1M的上下文窗口，专门针对编码和agent这类需要长上下文的任务设计，用来对大量信源进行细致的比对完全绰绰有余。
一些延伸思考
面向agent的搜索和面向用户的搜索引擎，本质上是两种完全不同的产品。 面向用户的搜索引擎通常只会返回一列蓝色链接，默认让用户自己判断、点击跳转、翻页浏览。agent虽然也可以使用这类工具，但并不擅长处理点击、翻页这类操作，而且工具调用本身就会消耗时间和token。agent真正需要的，是可以直接读取的完整正文、明确的时间戳，以及每条内容占用的token数量。再往深一层想，面向用户的搜索引擎往往会用最少的文字吸引用户点击，因为平台需要提升用户的停留时长；而面向agent的搜索则恰恰相反，需要一次性提供足够完整的信息，让agent不需要再进行额外的跳转操作。豆包搜索的返回结构，处处都体现了面向agent的设计思路。
上下文窗口的长度对于agent来说至关重要。 每个模型能处理的token总量是有限的，每一条输入的信息都会占用预算。同样一个事实，用300个token和3000个token说清楚，成本相差十倍。女娲项目一次蒸馏任务需要6个subagent分别搜索大量资料，如果使用的搜索工具返回的都是冗余信息，agent的上下文窗口很容易就会被撑爆。我后来给MCP增加了token预算器功能，可以根据上下文窗口的预算自动筛选和压缩内容，每条结果只保留来源、时间、链接和关键句子，将返回的内容控制在agent够用且尽量节省token的范围内。这个设计能够实现的前提，正是豆包搜索会主动提供每条结果的token占用量。
信源筛选是整个搜索流程中最困难的环节。 网络上的信息质量参差不齐：有权威媒体的报道，也有营销号的洗稿内容，还有AI批量生成的虚假信息，甚至有专门伪造的信息来误导agent。普通用户搜索时可以自己辨别信息的真伪，但agent默认会直接相信搜索到的所有内容，如果喂给它一篇AI编造的假新闻，它就会将其当成真实信息写入报告，这也是之前315晚会曝光相关问题的核心原因。之前提到的交叉核查功能能够生效，前提是搜索工具本身已经对信源进行了初步的筛选和整理，agent才能对不同来源的信息进行有效的比对。至于按照权威度对信源进行分级、将低质量的营销内容后置、拦截恶意注入的虚假信息，这些用户看不到的工作，其实最耗费精力，也是不同搜索工具之间拉开差距的核心所在。我没办法拆开验证豆包搜索在这方面的具体做法，但从我使用至今的体验来看，还没有遇到过明显的洗稿或虚假信息，这也是我愿意继续使用它的重要原因。我开发的这个MCP工具本质上只是一个转接头，核心的搜索和信源筛选能力，还是依赖于豆包搜索本身。
写在最后
目前豆包搜索已经正式面向企业和开发者开放，每月提供500次免费搜索额度，超出之后可以选择按量付费或者订阅月卡，月卡还可以和火山引擎的Agent Plan等开发者套餐绑定使用。
如果你也遇到了agent联网搜索的问题，或者想要一个更适配国产模型的agent专用搜索工具，现在有两个不错的选择：要么直接安装我开源的huashu-doubao-search，只需要一条命令就能完成；要么直接使用豆包搜索的API，根据自己的业务场景定制专属的工具，我的这个仓库也可以作为参考实现，底层的核心能力都是一样的。
我的MCP工具仓库地址：https://github.com/alchaincyf/huashu-doubao-search
豆包搜索的体验地址：https://console.volcengine.com/search-infinity/web-search-exp
