AI Search Hub：把八家大模型的搜索入口收进一个 Skill
One Query. All Search Skill. 聚合 Gemini、Grok、豆包、元宝等平台原生 AI 搜索能力，免费获取科技趋势、行业舆情、热点追踪、旅行规划、日常问题统一接进自己的 Agent 与工作流，指定链接免费爬取
秒懂
- 它是什么？
- 这个 Python 项目不自建爬虫，而是驱动浏览器复用 Gemini、Grok、豆包、元宝等平台的原生搜索与网页理解能力，把结果回收到 Agent。判断它是否适合你，取决于你能否接受浏览器驱动带来的登录与页面变动成本。
- 适合谁用？
- 如果你已经在用 Claude Code、Codex CLI、Cursor 这类带 Skill 机制的编码工具，并且需要中文平台（公众号、抖音、B 站）的内容作为检索补充，这个项目值得拉下来读一遍 README 和 skill 定义文件再决定是否接入。如果你的场景要求无人值守的稳定批量抓取，或者需要明确的数据合规边界，浏览器驱动加上依赖第三方平台账号的架构就是错误的选择，应当退回自建爬虫或官方 API。
- 能商用吗？
- 未经许可不能。GitHub 在这个仓库里没有找到许可证文件；没有许可证，默认即「保留所有权利」：你可以阅读代码，但不能复用。使用前请看看 README，或先征得作者同意。
- 还在维护吗？
- 在维护。仓库最近一次提交在 142 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是爬虫维护成本，不是搜索质量问题
任何做过中文内容采集的人都熟悉这条链路：写爬虫、解析页面、处理反爬、页面改版后重写解析规则。AI Search Hub 的取舍是干脆不碰这条链路。README 的说法是让平台替你搜、替你抓、替你清洗，把最难拿的数据入口交给大厂。
这意味着它把维护成本从「解析规则」转移到了「浏览器自动化与账号状态」。前者是你可以完全掌控的代码，后者取决于第三方平台的登录流程、验证码策略和页面结构。这是一次成本搬家，不是成本消除。项目自己也承认这一点，README 在对比表里把传统方案描述为反复处理风控与验证码，把自身描述为尽量沿用平台已有入口，用词是「尽量」，不是「不再需要」。
目标用户画像因此比较明确：已经在用带 Skill 机制的编码工具、希望快速拿到某个平台视角的检索结果、并且能接受偶尔需要人工处理登录状态的人。它不适合把采集当作生产级数据管道来运营的团队。
浏览器驱动：机制决定了它的能力上限
仓库的徽章里有一个 mode-browser-driven 标记，这是理解整个项目的关键。AI Search Hub 不是调用各家平台的公开 API，而是通过浏览器去驱动这些平台的搜索界面，再把返回内容抽取出来。
这个机制带来一个直接好处：它能触达那些没有开放 API 的入口。README 明确列出 Grok 覆盖 X / Twitter 的实时动态、豆包覆盖抖音内容、元宝覆盖微信公众号信源。这三类数据在公开 API 层面基本拿不到，浏览器驱动绕开了这个限制。
代价同样直接。浏览器驱动意味着执行速度受页面加载和模型生成时间约束，稳定性受页面结构约束，可并发性受账号风控约束。README 里八个平台的状态徽章全部标为 Good，但没有给出任何延迟、成功率或并发数据，也没有 release 记录。这些指标需要你自己在目标平台上验证，不能从仓库材料推断。
一次提问如何分发到八个平台
README 描述的数据流是：输入一个问题，由 Skill 分发给多个平台的原生搜索，各平台返回自己的结果，再由 Skill 统一回收到一个出口交给 Agent 或工作流。另一条路径是输入一个链接，让平台完成正文抓取、去广告、去噪和结构化整理。
当前已接入的平台清单是 Gemini、Grok、豆包、元宝、LongCat、通义千问、MiniMax、Kimi。README 给每个平台标注了擅长方向，例如 Gemini 偏 Google 搜索与网页发现，Grok 偏实时舆情，元宝偏中文补充检索与交叉验证。这份分工表是理解项目设计意图的主要材料，但仓库没有说明分发是并行还是串行，也没有说明多个平台返回冲突结论时如何合并。
从工程角度看，这是一个聚合层而不是检索层。检索质量由各平台决定，AI Search Hub 负责的是调度和结果回收。判断它值不值得用，很大程度上等于判断这八个平台的检索结果对你的场景是否有互补价值。
接入方式：Skill 形态而非独立服务
README 顶部的徽章列出了 Claude Code、OpenAI Codex CLI、Cursor、Kiro、OpenClaw、Google Antigravity、OpenCode。这说明项目的交付形态是 Skill 定义文件，而不是一个可以 pip install 后独立运行的服务。它依附在宿主工具的 Skill 机制上工作。
提供的材料里没有安装命令、没有配置键名、没有环境变量列表，也没有依赖清单。因此无法在这里给出可执行的接入步骤。可以确认的只有两点：主语言是 Python，仓库 topics 里有 python3 和 claude-skills。实际接入需要你打开仓库，阅读 Skill 定义文件，确认它对 Python 版本、浏览器运行时和账号登录状态的要求。
仓库同时推广了一个商业调研产品 notyet.chat，这一点在评估时需要留意：开源部分和商业产品的关系、以及未来功能边界是否会移动，材料里没有说明。
许可证状态与升级成本
这里存在一处矛盾。README 的徽章显示 License-MIT，但仓库元数据返回的许可证字段是 unknown，且没有检索到任何 release。徽章是作者自己贴的，元数据来自平台接口，两者不一致时不能默认以徽章为准。
在许可证未从仓库 LICENSE 文件确认之前，商业使用、二次分发和修改后的闭源都存在不确定性。这不是法律意见，只是提示：接入生产环境前应当先打开仓库根目录确认许可证文件的实际内容。
升级成本方面，由于没有 release 记录，只能按 main 分支跟踪。对于浏览器驱动型项目，这意味着上游平台的页面改动可能随时影响可用性，而项目方没有版本化的兼容承诺。如果你的工作流对稳定性敏感，跟随 main 分支是一个需要提前接受的成本。
什么时候该选别的方案
最直接的替代方案是自己写爬虫配合各平台的官方 API。两者的差别不在功能覆盖，而在控制权归属。自建方案里，解析规则和限流策略都在你手里，你可以做缓存、做重试、做并发，也可以对结果做确定性校验。AI Search Hub 把这些交给了第三方平台的界面和账号体系，换来的是开发速度和那些没有 API 的数据入口。
具体到场景：如果你需要每天定时拉取固定几个信源并写入数据仓库，自建爬虫配合官方 API 更合适，因为浏览器驱动的失败模式（登录过期、页面改版、验证码）对无人值守管道是致命的。如果你只是想在编码过程中快速获得某个平台对某个话题的检索结果，或者需要拿到抖音、公众号这类难以通过 API 触达的内容，AI Search Hub 的路径更短。
另一个需要考虑的替代是直接用单个平台的官方客户端或网页版。多平台聚合的价值在于交叉验证和覆盖互补，如果你只关心一个平台，聚合层带来的额外复杂度没有对应收益。
采用前的判断顺序
先确认许可证。打开仓库根目录看 LICENSE 文件，不要依赖 README 徽章。这一步决定你能不能在商业项目里用它。
再确认 Skill 的运行前提。读 Skill 定义文件，弄清楚它需要哪个浏览器运行时、是否需要你在各平台保持登录状态、以及登录失效时的表现是报错还是静默返回空结果。最后一点尤其重要，静默失败在聚合场景里很难排查。
最后做一次小范围验证。挑两个你真正需要的平台，用同一组问题跑一遍，对比返回内容的质量和稳定性。README 里的平台分工表是作者的判断，不是你的场景的答案。八个平台全部标为 Good，但没有任何量化依据支撑这个评级。
编辑结论
如果你已经在用 Claude Code、Codex CLI、Cursor 这类带 Skill 机制的编码工具，并且需要中文平台（公众号、抖音、B 站）的内容作为检索补充，这个项目值得拉下来读一遍 README 和 skill 定义文件再决定是否接入。如果你的场景要求无人值守的稳定批量抓取，或者需要明确的数据合规边界，浏览器驱动加上依赖第三方平台账号的架构就是错误的选择，应当退回自建爬虫或官方 API。接入前先确认三件事：仓库里到底声明了哪个许可证，Skill 对浏览器和账号登录状态的具体要求，以及当某个平台页面结构变化时，项目是否有对应的适配说明。
社区笔记