我把豆包搜索做成MCP装进了Claude Code，开源！

先说个好消息：我开源的女娲skill，GitHub星标快冲到30k了，马上就是下一个里程碑✌️

没用过的朋友我一句话介绍下：女娲是个蒸馏思维的工具，输入一个人名，AI自动去调研他的访谈、文章、播客，把他的思维方式蒸馏成一个能对话的人物视角。每蒸馏一个人，它会调用6个subagent，分头去搜集不同渠道的资料。

不过star涨归涨，负面反馈我也真没少收，主要是两类：

1、女娲根本没真的去搜，蒸馏出来的内容很多是瞎编的

2、agent跑不完一次蒸馏，上下文就撑爆了...

我仔细排查了下，发现问题所在：他们给Claude Code接了国产模型之后，搜索能力失效了。subagent搜不到东西，又非得交付结果，就自己想办法，把它想象中的调研结果脑补了出来

这...老实说，用的工具不行，我也没招。Claude Code和很多agent里自带的搜索，是跟自家模型服务绑在一起的，你把模型换成外部API，这层搜索就跟着没了。而这半年国产模型的coding能力集体上来了，接国产模型的人越来越多，撞上这个问题的自然也越来越多。

工具不行，那就换个工具...

所以我动手做了一个：拿豆包搜索开放的API封装了个MCP，基本能免费用（每月500次免费搜索额度），让接国产模型的agent也有像样的联网搜索。已经开源，一条命令就能装，文末有地址。

一、关于模型的幻觉

模型为什么会脑补？它肚子里的知识是预训练时喂进去的，有个截止日期（通常在模型发布前半年到一年左右），那天之后的事它一概不知。你让它调研一个昨天发布的模型、本届世界杯的赛果，没有搜索，很多时候它就只能拿记忆里的东西硬撑，撑不住的部分现编。这就是幻觉。

前几天刷屏的那篇梁文锋四小时会议实录里，他专门说到这事：大模型的幻觉有方法解决，「但这是一个长命题」，在DeepSeek内部被归为产品问题，会去解决，但不是重点。

我同意幻觉是长命题，模型厂可以慢慢解，但我们这些每天拿agent干活的人等不了啊。现阶段治幻觉最实在的办法，就是让agent自己去查：把此刻的、真实的、能溯源的信息喂给它。

查，就得有个搜索。我以前遇到一些agent无法搜索的问题是，自己用的方案是Tavily，海外专门给agent做的搜索服务，我用了挺久。但每次想推荐给读者都卡住：国内访问不总是稳，agent批量跑的时候偶尔超时；计费按美元走，得先办张海外信用卡。我的读者里不少人本来就是因为用不上Claude才换的国产模型，再让他为一个搜索去办海外卡，这不是绕回去了吗。

所以我要的其实很清楚：1、国内能稳定访问；2、结果agent能直接读；3、最好基本免费，读者拿来就能用。那会儿还真不好找。

二、豆包搜索开放了，我上手试了试

其实最近一年多来我观察到个有趣的趋势是，很多人都已经不再使用搜索引擎了，遇到问题时反而更习惯拿起豆包用自然语言问一嘴。比如问前一天的世界杯比赛谁赢了，问现在不同地区对OPC的政策等等，我也经常遇到不少人会拿豆包搜索获取到的结果和我沟通讨论的。我自己的体感也是豆包的搜索能力做得真挺好的。

然后前不久，我发现豆包搜索正式面向企业和开发者开放了，每个月送500次免费额度，个人开发者日常用基本够（超额了也很便宜）。

不写代码的朋友想先感受一下，网页上就能直接试：

https://console.volcengine.com/search-infinity/web-search-exp

拿到接口，我干的第一件事是把它和Claude Code自带的搜索放一起，用同样的问题问它们。试下来有三个发现。

第一，正文给得很充分。给agent用的搜索API，返回网页内容是基本操作，差别在给得全不全、干不干净。豆包搜索在服务端就把每条结果解析成了干净的正文文本，我实测查中文热点，每条平均一千一百字，agent拿到直接读，不用再fetch原网页再次获取信息：

第二，结果自带精确到秒的时间戳和可溯源链接。我随手查了下最近豆包一个新模型Doubao-Seed-Evolving的进展，返回十条里八条把发布时间标得明明白白：2026-07-21 23:53:38、2026-07-19 02:16:32。哪条是几小时前的、哪条是半个月前的，agent一眼能分。做时效性强的调研，这个太有用了。

第三，它告诉你每条结果占多少token。返回里每条都标着ContentTokenCount，我那次查回来的十条，短的五百多token，长的六七千。一开始没在意，后来反应过来这是专门为agent准备的：agent的上下文有预算，知道每条占多少，才能精打细算决定塞哪些、丢哪些。女娲那类撑爆上下文的差评，主因其实就是搜索返回的结果塞了太多东西。

这些字段全摊在明面上，对开发者还有个好处：想自己抽哪几个字段、怎么加工，都很方便，我后面那个MCP干的就是这个活。所以这几个方向结合在一起，豆包搜索api所体现的意图还挺清楚的：就是这是照着agent的需求做的搜索，跟给人用的搜索引擎是两个东西。

然后，我又把它和之前一直在用的Tavily摆一起，同一批问题各跑一遍。查中文时效热点，豆包每条正文平均一千一百字，条条带时间戳和token数；Tavily基础档平均七百字，既不返回发布时间，也没有token计数。对agent最要紧的那两样，时间戳和token预算，是豆包默认就给的。以及对中文内容的搜索表现，豆包搜索也是明显好出一层，所以对比起来，我就无痛切换到豆包搜索了。

速度我本来也想比一比，但我这台机器走的是公海网络，跨境链路的抖动太大，同一批query前后跑几次，数字能差出一倍来。这种环境下比延迟没什么意义，就不列了。

对了，接的时候还有个东西顺便说一句：豆包搜索开放出来的其实是两个版本，Global版和Custom版，同一个API Key都能调，每月那500次免费额度也是两版共用的，只是接口地址和参数写法不一样。两版的分工大致是：Global版是开箱即用的通用搜索，搜索规则内置好了，不用做任何配置；Custom版是给企业场景做的规则版本，搜索规则可以按自己的业务配，场景越复杂可能会越需要。

我两版都跑了同一批问题，能力侧重挺不一样。Custom版返回的正文明显更长，查中文热点那道题平均三千七百字，Global版是一千一；响应也更快，同一台机器、同一批query连着跑，另外Custom版每条结果还带一个信源权威度的标注，分四个等级，agent能拿它判断这条该信几分。

Global版这些都没有，但它独有一样东西：每条结果占多少token。也就是我前面说的第三个发现，我那个token预算器就是靠它才做得起来的。

所以我自己现在的用法是Global版打底，碰上需要严格控信源的调研任务再切Custom版。你接的时候可以按自己的需求差异选择不同版本。

三、花叔-豆包搜索MCP

以及，因为豆包搜索API返回的信息很充分，所以，我觉得相比每次让agent调API，不如结合我自己的需求定制个能力更个性化，更符合我自己需要的MCP好了。

当然，其实过程也就是我把豆包搜索的API文档丢给Claude Code，告诉它我要一个MCP server：接收搜索请求，调用豆包搜索API，把结果整理成agent好读的格式返回。编码、调试、写文档，全是它自己干的。

这就是huashu-doubao-search。它本质上是我按自己的需求，对豆包搜索API做的一层封装和调整，检索、正文解析、时间戳这些能力全在豆包搜索那一侧，我只是把它翻译成agent顺口的样子。所以用它之前，你需要先去火山引擎开通豆包搜索的API、拿一个key，然后一条命令：

claude mcp add huashu-doubao-search -- npx -y github:alchaincyf/huashu-doubao-search

装完在Claude Code里说一句「用豆包搜索查一下xx」，它就联网了。

四、跑几个真实的活儿 场景一：查一个还在持续更新的AI热点

前几天我想知道Doubao-Seed-Evolving最近到底什么进展，让agent用豆包搜索去查。几秒返回十条，八条带着精确到秒的时间戳：最新一条是头天晚上23:53的（一篇讲有人拿它烧了5.1亿token、一口气跑完三万行代码的实测），发布公告那条停在半个多月前。因为时间是明摆着的，agent给我的摘要开头就是昨晚的最新动态，而不是把半个月前的公告当成新消息。换成只返回链接的搜索，它根本判断不了新旧，只能瞎排。

场景二：写文章前的深度调研

这是我最高频的需求。以前写稿前搞清一个话题，得开一堆浏览器标签一篇篇读；现在Claude Code用豆包搜索一次查回来十几篇正文摘要，直接读，几分钟理出框架。差别最直观的是搜索轮次：以前agent拿到一堆链接，点进去读、发现不够又回头补搜，来回五六轮是常事；现在正文一次给全，一两轮就把框架搭起来了。省下的主要是agent反复调用的次数。

场景三：多信源交叉核查

这是我后来给MCP加的功能。做调研写内容最怕单一信源不靠谱，我加了个交叉核查模式（cross_check）：agent就同一个问题从多个角度并行搜索，把不同来源的说法摆在一起比对，输出一份共识和分歧的报告。

就拿Doubao-Seed-Evolving来说，我让它核查这个模型的上下文到底多长。搜回来的信源打架，有的说256K，有的说1M。agent要是随手信了第一条，就写错了。交叉核查把矛盾直接摆出来，还顺着时间戳给了解释：6月刚发布时是256K，7月升级后扩到1M，两边都没说谎，只是隔了一次升级。有了这一步，agent不会逮着第一条搜索结果就往报告里写了。

比对和信息整理这一步，我用的也是豆包自己的模型，而且可以指定。我默认搭载的是最新的Doubao-Seed-Evolving：这个模型还挺有特点的，他们的逻辑大概是现在模型持续的更新进化太快了，所以干脆就不固定版本号，始终用同一个模型名就能调到最新版，1M上下文，主打Coding和Agent这类长程任务，拿来给一堆信源做细致比对绰绰有余了。

五、一些延伸思考

Agent搜索和人搜索，是两种产品。给人的搜索是一列蓝色链接，默认你会自己判断、点击、翻页。agent倒不是不能干，但并不擅长这些，工具调用又耗时又废token得。它要的是能直接读的正文、明确的时间戳，还有每条内容占多少token。再往深一层想，给人的搜索甚至有动力只用最少的字勾你点进去，因为平台要的是你的停留；给agent的搜索得反过来，一次把该给的给全，让它不用再点。豆包搜索的返回结构，处处透着后一种思路。

上下文长度很关键。模型每次能读进去的token有限，塞进去的每条信息都在占预算，同一个事实用300个token和3000个token讲清楚，成本差十倍。女娲一次蒸馏要6个subagent各自搜一堆资料回来，用的搜索要是只会往回倒垃圾，上下文不撑爆才怪。我后来给MCP加了个token预算器，按上下文预算自动筛选压缩，每条只留来源、时间、链接和关键句，把搜回来的东西控制在agent够用的且尽量省token得范围内。这个设计能成立，前提是豆包搜索先把每条的token数摊给了我。

以及，最难的信源问题。网上的信息什么货色都有：权威媒体的、营销号洗稿的、AI批量生成的、甚至专门写来骗agent的。人来搜自己会分辨；agent默认搜到什么信什么，你喂它一篇AI编的假新闻，它就当真事写进报告。这也是此前315打击GEO的逻辑。前面那个交叉核查能成立，是搜索这一侧先把信源理顺了，agent才有的可比。至于按权威度给信源分级、把低质营销内容往后压、把注入内容挡在前面，这些活儿用户看不见，却最费功夫、也最能拉开差距。这层我没法拆开验证，但用到现在没被塞过一篇明显的洗稿文，这是我愿意接着用的原因。我做的小工具说到底只是个转接头，核心依赖还是在豆包搜索那边。

豆包搜索现在正式面向企业和开发者开放了。每月500次免费额度，超出支持按量付费和订阅月卡，入口在火山引擎控制台，月卡跟Agent Plan这类火山的开发者套餐可以绑定使用。

如果你也卡在agent联网这一步，或者，你想要一个更好用的更native的agent搜索工具。现在有两个不错的选项：要么直接装我的huashu-doubao-search，一条命令的事；要么拿豆包搜索的API，照自己的业务场景定制一个自己的工具，我这个仓库就当参考实现。反正底层能力是同一个。

我的MCP仓库：https://github.com/alchaincyf/huashu-doubao-search

豆包搜索的体验地址在这里：https://console.volcengine.com/search-infinity/web-search-exp