← 返回首页

AnySearch for AI Agents：结构化搜索，减少令牌浪费，提供更优实时上下文

搜索已成为AI代理可用的最重要外部能力之一。强大的模型能够出色推理，但无法恢复从未检索到的事实、无法在没有证据的情况下区分当前信息与过时报道，也无法可靠推断缺失的公司记录。AnySearch将这一问题视为代理的基础设施，而非面向人类的搜索页面。它不局限于返回链接、标题和简短摘要，而是致力于将查询路由至相关网页。

发布于 2026年7月15日•general•GEO 评分: 0

选择语言

العربيةDeutschEnglishEspañolFrançaisItaliano日本語한국어PortuguêsРусский中文
图片背景为深色，带有蓝色网络线条元素，营造科技感。图片中央大字“AnySearch”上方有三条竖线图标，下方“for AI Agents”中“AI Agents”以蓝色突出显示。下方是一个蓝色边框的搜索框，框内有一个放大镜图标。该图片与文档中“SEO Cover Brief”部分相关，用于展示AnySearch for AI Agents的封面设计概念，体现其面向AI代理的搜索功能。

AnySearch for AI Agents：结构化搜索，减少令牌浪费，提供更优实时上下文

引言

搜索已成为AI智能体可用的最重要外部能力之一。强大的模型能够进行良好推理，但对于从未检索到的事实无法恢复，无法凭证据区分当前信息与陈旧报道，也无法可靠推断缺失的公司记录。

AnySearch将此问题视为面向智能体的基础设施，而非面向用户的搜索页面。它不单返回链接、标题和简短摘录，而是将查询路由至相关网络或垂直来源，去除重复和低价值内容，提取有用信息，并交付可直接进入模型推理上下文的结构化响应。

该产品在2026年7月6日当天及当周均位列Product Hunt榜首。其发布介绍强调通过API、MCP服务器或可安装的智能体技能，提供实时、过滤、去重、结构化的信息。

图片展示了Product Hunt网站上上周Top产品的排名情况。其中，AnySearch以126条评论、882次分享位列第一，其描述为"由代理和开发人员信任的实时结构化搜索"。该图片与文档中介绍AnySearch的内容相关，直观呈现了其在Product Hunt上的受欢迎程度，强调了其作为代理导向搜索工作流程的特点。

本文阐述这种面向智能体的搜索工作流与传统搜索API的区别，详细解析原始报告中展示的示例，并提供实用的安装与评估指南。

基准测试说明： 下文准确率和延迟数据均来自源文章复现的AnySearch对比结果。本版本审阅的公开资料未包含完整评估代码、原始输出、评判提示或统计分析。请将这些数据视为供应商报告的结果，而非独立复现的基准测试。

为何普通搜索结果对智能体而言成本高昂

人类能够浏览结果页面、忽略广告、识别重复文章，并判断哪些链接值得关注。

而智能体往往将每个结果都作为输入接收，这会产生多重成本：

  • 重复文章占用上下文空间。
  • 长页面包含导航、广告和无关文本。
  • 弱结果可能触发额外搜索轮次。
  • 过时信息可能被误认为当前事实。
  • 搜索摘要可能遗漏可靠结论所需的证据。
  • 模型在推理前必须花费Token进行清理。

问题不仅在于检索准确率，还在于返回信息的形态与密度。

因此，一个实用的智能体搜索系统在将信息传递给模型前，应回答三个问题：

  1. 哪种来源类型最适用于此查询？
  2. 哪些结果提供了独特且可信的证据？
  3. 如何在不带网页噪音的情况下交付结果？

AnySearch正是围绕这些步骤设计的。

Product Hunt发布与公开基准测试结果

AnySearch在2026年7月6日获得Product Hunt当日及当周第一。Product Hunt将其描述为

受代理和开发者信赖的实时结构化搜索，能够从并行搜索的来源中获取经过过滤和去重处理的信息。

该源文章还介绍了一项由三个基准组构建的300题评估体系：

  • FRAMES
  • FreshQA
  • WebWalkerQA

文中指出，AnySearch、Brave Search和Parallel均使用了相同的语言模型，因此搜索层（而非模型选择）是主要变量。

报告准确率

搜索系统 总体准确率 FreshQA WebWalkerQA
AnySearch 76.4% 80.0% 65.2%
Brave Search 64.0% 74.0% 46.8%
Parallel 72.2% 78.0% 61.0%

图片是一张柱状图，展示了AnySearch、Brave Search和Parallel三种搜索系统在综合准确率、FreshQA和WebWalkerQA三个方面的表现。图中黑色柱代表综合准确率，灰色柱代表FreshQA，深灰色柱代表WebWalkerQA。数据显示，AnySearch的综合准确率为76.4%，FreshQA为80%，WebWalkerQA为65.2%；Brave Search的综合准确率为64%，FreshQA为74%，WebWalkerQA为46.8%；Parallel的综合准确率为72.2%，FreshQA为78%，WebWalkerQA为61%。该图与上下文紧密相关，直观呈现了三种搜索系统在不同方面的准确率情况。

FreshQA评估的是依赖当前或变化信息的问题。WebWalkerQA则侧重于跨多个页面浏览网站和定位证据。两者结合，对于不仅需要浅层链接列表的代理而言具有很强的相关性。

FRAMES被纳入了源文章的综合评估中，但文章展示的按基准划分的图表除了综合得分外，仅显示了FreshQA和WebWalkerQA。

报告延迟

延迟图表显示，在平均对比和WebWalkerQA子集两个维度中，AnySearch的数值均更低。

搜索系统 平均延迟值 WebWalkerQA延迟值
AnySearch 48.0 76.5
Brave Search 68.9 133.0
Parallel 77.4 145.6

这张图是展示两款搜索系统在平均延迟、WebwalkerQA两个指标下的延迟对比饼图，和文档中的对比表格内容相互对应。左侧饼图标注“平均延迟”，其中代表AnySearch的蓝色区块数值为48，Brave Search的灰色区块数值为68.9，Parallel的深灰色区块数值为77.4；右侧饼图标注“WebwalkerQA”，对应区块数值分别为76.5、133、145.6，两款图的图例均为蓝色代表AnySearch、浅灰色代表Brave Search、深灰色代表Parallel。

源图片未明确标注单位，因此表格有意保留了报告中的数值，未将其转换为秒或毫秒。

将AnySearch连接到代理

AnySearch目前支持三种主要集成方式：

  • API
  • MCP
  • 代理技能（Agent Skill）

官方GitHub项目提供了一个采用Apache-2.0许可证的技能和MCP服务器。两者均支持通用网页搜索、垂直领域搜索、并行批量搜索以及整页URL提取。

图片展示了AnySearch的相关信息。上方有齿轮图标，旁边文字为“anysearch”，右侧有垃圾桶图标和蓝色开关。下方文字介绍其为实时搜索引擎，支持网页搜索、垂直领域搜索、并行批量搜索和URL内容...等。该图片与文档中介绍AnySearch的内容相关，是对AnySearch功能和特点的直观呈现，帮助读者更清晰地了解其支持的搜索类型等信息。

安装AnySearch技能

官方仓库建议下载固定版本（pinned release），而非直接从主分支获取未发布的更改。

分支。

# 下载指定版本的 AnySearch Skill 发行版。
# 查看发行版页面，当有更新的稳定版本时替换 v2.1.0。
curl -L -o anysearch-skill.zip \
  https://github.com/anysearch-ai/anysearch-skill/archive/refs/tags/v2.1.0.zip

# 解压发行版。
unzip anysearch-skill.zip

将解压后的目录移动到您的代理使用的相应位置：

# Claude Code
mv anysearch-skill-2.1.0 ~/.claude/skills/anysearch

# OpenCode
mv anysearch-skill-2.1.0 ~/.config/opencode/skills/anysearch

# Cursor 或 Windsurf 项目
mv anysearch-skill-2.1.0 <project>/.skills/anysearch

# 共享代理位置
mv anysearch-skill-2.1.0 ~/.agents/skills/anysearch

确切目录取决于代理平台及其当前的技能发现规则。

API 密钥与匿名访问

官方技能和 MCP 文档指出，匿名访问的速率限制较低。API 密钥为可选，但建议使用以获得更稳定或更高的使用量。

请勿将 API 密钥提交到公共仓库。请将其存储在环境变量、密钥管理器或被忽略的本地配置文件中。

测试一：寻找生产级 Go 代码

源文章中的第一个测试要求代理找到真实、面向生产的 Go API 速率限制器实现，而非入门教程。

提示内容为：

我正在构建一个项目，需要用 Go 实现 API 速率限制器。我不需要教程。请从真实开源项目中找到生产级代码。

在没有专用搜索工作流的情况下，据报告该代理返回了常见的链接和孤立的代码片段。这种结果虽然可能解释了概念，但当开发者需要完整的实现上下文时，帮助有限。

借助 AnySearch 辅助的运行返回了更加结构化的、面向代码的结果，包含更清晰的调用链以及来自实际代码库的材料。

这一区别至关重要，因为生产代码不仅仅是算法。有用的搜索结果应帮助代理检查：

  • 包结构
  • 初始化
  • 配置
  • 存储或分布式状态依赖
  • 中间件集成
  • 错误处理
  • 测试
  • 许可证
  • 项目活跃度
  • 代码与仓库其他部分的关系

一个提取了美观函数但忽略了其上下文假设的代码搜索可能会误导实现代理。

更优的生产代码搜索请求

无论使用哪个搜索提供商，更明确的查询可以改善结果：

寻找维护中的、在生产代码中实现了 API 速率限制的开源 Go 项目。

要求：
- 返回仓库和精确的文件路径。
- 优先选择在真实服务器或网关中使用的代码。
- 包含初始化和请求流上下文。
- 指明算法、后端存储、测试和许可证。
- 排除教程代码库和复制的代码片段。
- 注明最近相关提交的日期。

搜索系统应提供证据。编码代理在改编代码前，仍应检查仓库、许可证、测试、安全假设以及当前的维护状态。

测试二：公司尽职调查

第二个测试

在同一公司调研需求上对比了AnySearch和Exa。

两份报告在基本公开公司信息方面都表现得不错。差异主要体现在风险部分。

据报道，AnySearch找到了本地发布的合规记录和平台公告，而这些内容在Exa生成的报告中是缺失的。消息来源将此差异归因于对中国垂直数据源的访问，而非语言模型本身。

图片展示了AnySearch和Exa在公司基本信息方面的对比。左侧为AnySearch，右侧为Exa，均包含公司全称、英文名称、成立日期、上市时间、上市地点、股票代码、注册地址、所属行业、控股股东、实际控制人、创始人、当前董事长/总经理、董事会秘书等项目。两者的公司全称、英文名称、成立日期等信息一致，但Exa在股票代码、所属行业、控股股东、实际控制人、创始人、当前董事长/总经理等方面有不同，如Exa的股票代码为“002002.SZ”，而AnySearch未显示。该图与上下文提到的两报告在公司基本信息上表现相似，但风险部分有差异相呼应。

图片展示了AnySearch和Exa对某公司风险分析的对比。左侧AnySearch部分，风险事件为2026年，影响、进展、应对措施等信息详列；右侧Exa部分，风险因素包括AI颠覆风险、需求萎缩风险等。该图与上下文紧密相关，上下文提到两报告在风险分析部分存在差异，此图直观呈现了两者的具体内容对比，突出AnySearch在风险事件方面有更多详细信息，而Exa侧重于风险因素分类。

这个例子凸显了公司调研中的一个普遍局限：全球网络索引或许能很好地覆盖组织的官方网站、国际报道和英文数据库，却可能遗漏本地的监管、法院、投诉或平台记录。

一个尽职调查智能体应明确搜索多个类别：

  1. 公司注册与受益所有权
  2. 融资与股东变动
  3. 诉讼与执法记录
  4. 监管公告
  5. 产品投诉与平台处罚
  6. 专利与商标
  7. 网络安全与数据事件
  8. 管理层变动
  9. 财务与运营预警信号
  10. 公司本土市场的最新新闻

重要提示： 搜索辅助的尽职调查不能替代专业的法律、财务或合规审查。记录可能不完整，名称可能产生混淆，自动摘要也可能错误解读证据。

测试三：一份实时全球能源报告

第三项测试要求AnySearch生成一份全球能源市场报告，内容涵盖：

  • 美国天然气库存变化
  • 欧洲各国日前电价
  • 澳大利亚电网碳强度

消息来源显示的输出结果包含了区域库存细节、欧洲电价对比以及排放数据。该报告引用了近期信息，包括美国能源信息署7月9日发布的数据以及欧洲7月12日的日前电价。

这张图片是AI工具AnySearch的操作界面对应的功能演示，顶部明确标注用户需求为“生成一份全球能源市场报告：美国天然气库存变化、欧洲各国日前电价走势、澳洲电网碳排放数据”，界面中显示了工具生成该报告过程中调用的不同工具及对应操作记录，包含不同工具名称、具体指令行内容，底部可见与DeepSeek V6 Pro的交互入口，直观呈现了该工具针对多领域全球能源查询任务的执行过程，呼应了文档中关于AnySearch能处理多独立数据路径查询的相关说明。

图片展示了欧洲各国日前电价走势，标题为“最新日前电价 7月12日”。表格中列出了德国、法国、西班牙等11个国家/竞价区的电价（€/MWh）及日环比情况。如德国电价为75.23 €/MWh，日环比下降20%；法国电价为75.21 €/MWh，日环比下降18%；荷兰电价为73.41 €/MWh，日环比下降22%等。

该图与文档中测试三的内容相关，呈现了欧洲多国日前电价数据，是AnySearch生成的全球能源市场报告的一部分。](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/3f5432f8-0641-4e6e-b8aa-62b6a50e7d18-f18fcac7-52c7-4efa-a066-9c9722c9cea9.jpeg)

这是一个多领域查询的典型示例，要求系统识别出一次请求中包含多个独立数据路径，而非单一常规网页搜索。

可靠的实现应做到：

  1. 将请求拆分为子查询。
  2. 将每个子查询路由至合适的数据源。
  3. 记录发布和观测日期。
  4. 保留单位及地域定义。
  5. 区分预测值与实测值。
  6. 返回来源网址或标识符。
  7. 在最终输出时归一化处理，且不掩盖数据间的矛盾。

当前数据必须始终包含时间戳。若报告未说明底层测量的发布时间及其覆盖周期，则“最新”一词毫无意义。

AnySearch如何路由查询

核心设计主张是：AnySearch围绕智能体行为重构检索管道。

源代码所示的流程包含五个阶段：

  1. 查询接收
  2. 意图理解
  3. 路由编排
  4. 并行检索
  5. 结果聚合与智能体交付

这张图呈现了AnySearch面向AI Agents的检索流程，共分为五个核心步骤，依次为查询进入、查询理解、路由编排、并行检索、结果融合，最终完成Agent交付。其中每个步骤都标注了对应核心动作：查询理解的核心是意图建模与领域判定，路由编排为信息筛选与路径规划，并行检索是多源召回，结果融合则包含归一化、重排序与结构化。该流程对应文档中提及的AnySearch重建检索管道的五个阶段，清晰展现了系统围绕智能代理行为设计的结构化检索逻辑。

1. 意图理解

系统首先识别查询需要何种类型的证据。

企业背景查询可能需要注册记录、专利、法律数据库及投诉平台。代码相关问题应路由至代码仓库和文档。能源市场查询则可能需要官方库存和电力市场数据。

这与将所有请求都通过一个通用索引处理的方式截然不同。

2. 领域与源路由

AnySearch表示，除通用搜索外，其还支持20余个垂直类别，涵盖以下领域：

  • 代码
  • 金融
  • 学术研究
  • 安全
  • 法律信息
  • 公司及商业数据
  • 通用网页内容

这张图片是关于AnySearch的“全光谱覆盖”能力展示，左侧的文字说明其覆盖范围从专业深度到日常广度，能满足代理的各类需求，右侧以地球图案搭配四个核心能力模块，分别为多领域覆盖、可扩展网络、日常需求、个人兴趣，这正好对应文档中提到的AnySearch支持通用搜索及20余种垂直领域，可覆盖代码、金融、学术研究等不同类型场景的内容，直观呈现其覆盖代理多元需求的设计特点。

公共MCP接口包含一个领域目录方法。智能体应请求有效领域和参数模式，而非自行创建不支持的过滤器。

3. 并行检索

一个跨越多个领域的问题可发起多个独立搜索。MCP服务器支持批量执行1至5个查询对象，且某个分支的失败不会阻塞其他分支的执行。

并行检索可减少总等待时间，但前提是聚合层能防止快速出现的低质量结果挤占速度较慢的权威结果。

证据。

4. 模型之前的排序

原文提出了三种排序思路：

  • 同源衰减：降低来自同一站点的重复结果的权重。
  • 信息密度仲裁：优先选择能提供更多独特且有用证据的结果。
  • 混合排序：将语义相关性与时效性结合。

其预期目标是在内容进入语言模型之前进行更多过滤。

这与那种返回大量结果集并让模型自行去重的流水线不同。预过滤可以节省令牌，但引入了另一项责任：排序系统不得静默移除少数来源或关键的矛盾记录。

5. 结构化交付

排序后，AnySearch会提取主要内容、去除页面噪音，并将结果转换为Markdown格式。

官方MCP服务器还提供了一个URL提取操作，能将页面内容以Markdown格式返回，并有明确的截断限制为50,000个字符。

图片展示了AnySearch的Agent-Native Design，强调其为AI代理设计，具有结构化输出，显著减少token浪费，支持内置API、MCP和Skill。左侧为AI代理，右侧有三个框，分别标注MCP / Skill / API、Structured Markdown、Quality Scoring。该图与上下文紧密相关，上下文介绍了AnySearch在AI代理中的应用，包括排名、结构化交付等环节，此图直观呈现了其设计特点及与AI代理的交互方式。

结构化输出可以减少模型所需的工作量，尤其在结果包含以下内容时：

  • 清晰的标题
  • 来源元数据
  • 日期
  • 不同的证据块
  • 表格
  • 带文件路径的代码
  • 标准化的单位
  • 用于验证的URL

为何去重能减少令牌浪费

假设一个代理收到关于同一事件的十条结果。如果其中七条是对同一份原始报告的改写，那么上下文包含的是重复的论断，而非七份独立的确认信息。

这会导致三个问题：

  1. 重复材料消耗上下文空间。
  2. 模型可能错误地将重复视为独立佐证。
  3. 不那么流行但更具权威性的证据可能被挤出。

基于来源的去重旨在保留独特的证据，而非简单保留排名最高的页面。

一个实用的代理搜索响应应使来源信息可见。开发者需要知道五条结果是代表五个原始来源、五个同一来源的联合发布，还是主要与次要证据的混合。

令牌节省是流水线结果，而非固定百分比

原文将较低的令牌消耗描述为AnySearch的一项优势，但并未公布一个通用的令牌减少百分比。

这很合理，因为节省量取决于：

  • 原始结果数量
  • 页面长度
  • 重复率
  • 提取质量
  • 模型分词器
  • 最大上下文大小
  • 代理是否还会再次搜索
  • 所需引用深度
  • 保留的结构化元数据量

公平的评估应衡量整个任务，而不仅仅是首次搜索响应。

有用的指标包括：

指标 衡量内容
搜索输入令牌 检索材料消耗的上下文
代理总令牌 搜索、推理、后续操作、

│ 最终生成 │
│ 每轮搜索调用次数 │ 弱检索是否导致重复搜索 │
│ 不同来源数量 │ 去重后的证据多样性 │
│ 引用精确度 │ 引用的来源是否支持相关说法 │
│ 回答完整性 │ 回复是否覆盖所需维度 │
│ 端到端延迟 │ 任务可用所需时间 │
│ 任务成功率 │ 智能体是否完成预期目标 │

省略关键证据的简短回答并非优化策略。只有在保持回答质量和可追溯性的前提下，Token数量减少才具有价值。

面向智能体的原生工程特性

实际生产环境中使用的搜索组件必须处理那些在产品演示中极少出现的故障问题。

资源来源突出以下特性：

  • 超时处理
  • 自动回退
  • 多来源路由
  • API访问
  • MCP支持
  • 技能支持
  • 结构化Markdown输出

公共MCP文档还支持以下功能：

  • 通用网络搜索
  • 垂直搜索
  • 并行批量搜索
  • 整页提取
  • 匿名访问
  • 可选API密钥认证

这张图介绍了面向智能体与开发者的可靠实时结构化搜索工具AnySearch。该工具可对接OpenClaw、Cursor等各类现存智能体，还可接入安全告警、论文、证券数据、网页内容、法律文本、文档等多元来源，并依托自有策略进行最优信息的筛选。该工具能够为智能体提供受信任的实时结构化搜索能力，适配开发者现有智能体的使用需求，也能整合多类来源的信息以支撑智能体的运行。

生产团队仍应添加自己的控制措施：

  • 每个来源的超时预算
  • 带退避的重试机制
  • 请求和成本追踪
  • 来源白名单和黑名单
  • 提示注入扫描
  • 个人身份信息与秘密过滤
  • 结果大小限制
  • 缓存策略
  • 审计日志
  • 高风险决策的人工审核

搜索输出是未经信任的外部输入。即使经过清理的Markdown文本，仍可能包含恶意指令、虚假陈述或受损内容。

搜索正在成为智能体基础设施

传统搜索帮助用户定位页面。智能体搜索则有不同目标：提供机器可用的证据，以供推理和执行。

这改变了设计优先级。

面向人类的搜索 面向智能体的搜索
针对快速浏览优化 针对机器摄取优化
链接与摘要 结构化证据
用户自行去重 系统应减少重复内容
用户留意过期日期 日期应明确标注
用户决定信任谁 需要来源与质量信号
浏览可以是探索性的 重复搜索会消耗时间和Token
视觉布局重要 稳定架构与Markdown重要

模型决定了智能体利用证据进行推理的能力。而搜索层则决定了最初哪些证据可供使用。

随着模型能力提升，检索质量的重要性只增不减。强大的模型即使基于薄弱上下文，也能生成极具说服力的回答。这使得来源选择、时效性和可追溯性成为智能体安全与可靠性系统的一部分。

如何在自身工作流中评估AnySearch

开发者不应仅凭一项公开基准测试或某个令人印象深刻的安全套就不选择搜索提供商。

而应基于实际场景构建评估集。

您的智能体所执行的任务。

第一步：定义代表性查询

涵盖简单和困难的情况：

  • 当前新闻
  • 仓库代码
  • 本地企业记录
  • 学术论文
  • 监管信息
  • 多国数据
  • 存在冲突来源的问题
  • 需要多个子领域的查询

第二步：保持模型不变

为每个提供商使用相同的模型、提示、工具策略和输出模式。

第三步：捕获原始证据

在模型进行总结之前存储返回的来源。否则，您无法判断错误是来自检索过程还是推理过程。

第四步：评估更多维度，而不仅仅是准确率

衡量延迟、总 token 数、重复搜索调用次数、覆盖范围、引用支持、时效性和失败率。

第五步：人工审核高风险结果

金融、法律、安全、医疗和合规任务需要专家审核。搜索 API 可以改进证据收集，但不能承担专业责任。

第六步：测试故障行为

禁用某个来源、减慢某个路由、返回格式错误的内容、注入重复结果。生产环境的可靠性取决于系统在检索不完善时的表现。

常见问题

什么是 AnySearch？

AnySearch 是一种专为 AI 智能体和开发者设计的实时搜索基础设施服务。它提供网络搜索、垂直领域搜索、批量搜索和带有结构化输出的全文提取功能。

AnySearch 是面向消费者的搜索引擎吗？

它有一个网站可供用户尝试搜索，但其主要定位是智能体基础设施。核心集成方式包括 API、MCP 和可安装的 Skill。

AnySearch 无需 API 密钥也能工作吗？

官方 Skill 和 MCP 文档指出，匿名访问的速率限制和配额较低。API 密钥是可选的，但建议更常规地使用。

AnySearch 支持哪些垂直领域？

公开文档提到金融、学术研究、安全、法律信息、代码及其他类别。智能体在使用特定领域参数前应查询支持的领域目录。

AnySearch 如何减少 token 使用量？

它尝试在检索前路由查询、减少重复来源、优先处理高信息密度的结果、去除页面噪音，并返回结构化 Markdown 格式。实际的 token 节省效果取决于查询内容和更广泛的智能体工作流程。

76.4% 的基准测试是否经过独立验证？

该分数由 AnySearch 报告，并在原始文章中复现。验证过程中未找到完整的公开评估包，因此该结果应被视为供应商报告的对比数据。

AnySearch 能替代专业的尽职调查吗？

不能。它可以帮助收集公司、法律、财务和公共风险信息，但专业人士必须核实身份、来源权威性、完整性、司法管辖权和解读。

AnySearch 是开源的吗？

AnySearch Skill 和 MCP 服务器的代码库以 Apache-2.0 许可证公开。托管的 API 后端是独立服务，不包含在这些代码库的许可证范围内。

相关工具

面向 AI 智能体的搜索基础设施。

  • AnySearch Skill：一种可安装的智能体技能，支持网页、垂直搜索、批量搜索和 URL 内容搜索。
  • AnySearch MCP 服务器：一种 MCP 集成方案，可将 AnySearch 工具暴露给兼容智能体。
  • Exa：专为 AI 应用构建的搜索、内容抓取、爬取和研究 API。
  • Tavily：面向智能体和 RAG 工作流的实时搜索与提取 API。
  • Brave Search API：为应用程序和 AI 系统提供的独立网页搜索 API。
  • Model Context Protocol：一种用于将 AI 应用连接到外部工具和数据的开放协议。

相关链接

总结

AnySearch 将搜索视为智能体的输入层，而非供人浏览的页面列表。它跨通用和垂直来源路由查询，搜索多条路径，对证据进行排序和去重，去除页面噪声，并通过 API、MCP 或 Skill 集成返回结构化内容。

源码中的示例展示了为何这种设计对生产代码发现、本地公司尽职调查以及当前多市场数据至关重要。在每种情况下，智能体都需要完整、及时且可追溯的证据——而不仅仅是相关链接。

其 Product Hunt 排名和供应商报告的基准测试结果使 AnySearch 值得测试，但团队在更换生产检索栈之前，应使用自己的查询、模型、令牌核算和质量标准来重现对比结果。

在智能体工作流中，模型决定如何处理证据；而搜索层决定正确的证据能否到达模型手中。