我开源了 OpenReach：给 AI Agent 补上一层免费的 Web 访问基础设施

长路 ㅤ

233人浏览 · 2026-08-16 11:47:26

长路 ㅤ · 2026-08-16 11:47:26 发布

我开源了 OpenReach：给 AI Agent 补上一层免费的 Web 访问基础设施

如果一个 Agent 连最新网页都拿不到，模型再强，也只能在旧知识里打转。
更现实的问题是：“能搜索”不等于“拥有一套稳定、可控、可替换、可自部署的 Web 能力”。

OpenReach Logo

过去一段时间，我一直在做 Agent 相关的工程。

真正开始把 Agent 往业务里放之后，我越来越明显地感受到一个问题：

模型能力在快速提升，但 Agent 访问真实互联网这件事，依然很碎。

搜索网页是一套接口，搜图片又是另一套接口；找到 URL 之后，还得再解决正文读取；换一个搜索厂商，上层 Tool 协议可能又得跟着改；某个免费搜索源失效，整条 Agent 链路就可能直接断掉。

而现在，Web Search 已经越来越像 Agent 的“基础能力”，而不是一个可有可无的插件。

OpenAI 在 ChatGPT Search 的官方介绍里就提到，过去为了得到一个真正有用的网络答案，往往需要多次搜索、不断点开链接、筛选信息源；现在 Web Search 被直接整合进模型的回答流程。OpenAI 的 API 也已经把 search、open_page、find_in_page 这类动作放进 Web Search Tool 中。Anthropic 同样提供了 Web Search 和 Web Fetch 工具。

这说明一个趋势已经很明确：

未来的 Agent，不只是“会思考”，还必须具备稳定获取外部世界信息的能力。

但对很多需要自托管、国内部署、企业内部 Agent 或希望降低厂商绑定的场景来说，我更希望这层能力能够掌握在自己手里。

于是有了 OpenReach。

GitHub：

https://github.com/changluya/openreach

真正想解决的，不是“再做一个搜索引擎”

OpenReach 的定位其实很简单：

面向 AI Agent 的开源 Web 访问基础设施。

它并不打算重新做一个 Google，也不是要和 Serper、Tavily 这些商业搜索服务竞争。

它想解决的是更靠近 Agent 工程的一层问题：

让 Agent 依赖稳定的能力接口，而不是直接绑定某一家搜索厂商。

我把 Agent 最常用的 Web 能力先收敛成了三个最基础的原语：

search(query)        -> 搜索网页 / 发现信息源
image-search(query)  -> 文搜图 / 发现图片及来源页
read(url)            -> 读取网页 / 提取正文与元数据

对上层 Agent 来说，它只需要知道这三个能力。

至于底层到底使用 Bing、百度、搜狗、360、DuckDuckGo，还是未来换成 SearXNG、Serper、Exa，都不应该让业务侧重新改一遍 Tool。

这也是 OpenReach 最核心的设计。

一个 Agent 联网，为什么需要单独做一层基础设施？

表面上看，搜索 API 很多，直接选一家接入就行。

但实际做下来，至少会遇到三个问题。

第一，搜索能力很容易和厂商绑死

目前主流模型厂商已经把 Web Search 做成托管工具，这种方式体验很好，但本质上还是跟平台绑定。

截至 2026 年 8 月 15 日，OpenAI 官方 API 定价中，Web Search 为 10 美元 / 1000 次调用，另外还会产生相应的搜索内容 Token 费用；Anthropic 官方 Web Search 同样是 10 美元 / 1000 次搜索，再叠加 Token 成本。

对于直接使用大模型官方能力的应用来说，这非常合理。

但如果你正在做的是：

企业内部 Agent
私有化部署
大量检索型任务
Research / Deep Research
希望自由切换搜索 Provider 的 Agent 平台

那么你可能会希望把“Web 能力层”从“模型能力层”里拆出来。

OpenReach 项目本身开源免费，内置的免费 Provider 不要求额外购买 Search API Key。

当然，这不代表运行成本为零：服务器、网络以及未来接入商业 Provider 仍然会产生自己的基础设施成本。

第二，Search、Image Search、Read 往往是三套东西

一个真正能工作的 Agent 搜索流程通常不是：

用户问题 -> 搜一下 -> 完成

而更接近：

用户问题
   ↓
Search
   ↓
发现候选来源
   ↓
Read
   ↓
读取正文
   ↓
判断证据是否足够
   ↓
继续 Search / Read
   ↓
多源验证
   ↓
生成答案与引用

如果是内容生产，还会多一个 image-search。

所以我没有只做一个 /search 接口，而是直接把 Search / Image Search / Read 三个能力放在一起。

第三，免费搜索源最大的问题不是“不能用”，而是“不够稳定”

免费 Provider 经常会遇到页面 DOM 调整、限流、网络出口差异等问题。

所以 OpenReach 没有把稳定性押在一个 Provider 上，而是做了 Provider SPI 和自动降级。

当前 Web Search 默认链路是：

Bing 中国
  ↓
百度
  ↓
搜狗
  ↓
360 搜索
  ↓
DuckDuckGo

Image Search 则是：

Bing Images
  ↓
百度图片
  ↓
搜狗图片
  ↓
Openverse

上游出现超时、解析失败或空结果时，可以继续尝试下一路。

这不等于商业级 SLA，但对于免费、自托管和早期 Agent 场景来说，至少不会把整条链路完全押在一个网页结构上。

现在的 OpenReach，具体能做什么？

当前版本已经把最基础的一套闭环跑通了。

能力	接口	用途
Web Search	`POST /api/web/search`	搜索网页、官网、新闻、博客、技术资料
Image Search	`POST /api/web/image-search`	文搜图、发现图片与来源页
Web Read	`POST /api/web/read`	读取网页标题、正文、元数据和链接
Health Check	`GET /api/web/health`	部署及 Skill 初始化连通性检查
Provider Fallback	内部能力	Provider 失败后自动切换
SSRF Protection	Read 内部能力	降低危险 URL 访问风险
OpenReach Skill	Python CLI	让 Agent 直接调用三种 Web 能力

search 和 image-search 都支持 region 参数。

不填写时默认为：

region = auto
provider = auto

也可以显式传入 CN、JP、US 等区域，让具体 Provider 做 best-effort 映射。

官网、新闻、技术文档，甚至公众号公开文章，都可以进入同一条 Agent 链路

OpenReach 并不限定搜索内容的类型。

现在比较适合的场景包括：

官网 / 产品资料

Agent 可以先搜索公司官网、产品页、解决方案、价格页、更新日志，再继续读取正文。

技术文档 / GitHub / 博客

适合 Coding Agent、研发助手或技术调研场景：先发现信息源，再把页面正文交给模型分析。

新闻 / 行业资讯

先搜索事件相关来源，再读取多篇原文进行汇总和交叉判断。

Research / Deep Research

把 Search 和 Read 组合成循环，让 Agent 不断发现来源、补证据，而不是只依赖一次搜索结果。

微信公众号公开文章

对于公开可访问、并且已经被搜索引擎收录的公众号文章，可以尝试通过 Search 发现链接，也可以直接把公开文章 URL 交给 Read。

这里需要特别说明：微信页面受收录、访问策略和反爬影响比较明显，所以当前属于 best-effort，并不承诺所有公众号文章都能稳定搜索和读取。

这也是我希望项目一直保持的一点：

支持什么就明确写什么，做不到的地方也明确写出来。

我希望“部署一个 Agent 搜索服务”只需要一条命令

为了让这个东西真正容易用，我不希望使用者先配一堆环境。

当前最简单的启动方式就是一条 Docker 命令：

docker run -d \
  --name openreach \
  --restart unless-stopped \
  -p 8080:8080 \
  codercl/openreach:latest

启动完成后，访问：

http://localhost:8080/

就能直接看到 OpenReach 自带的官网。

文档也直接内置在 Spring Boot 服务里：

快速启动    http://localhost:8080/docs/
接口文档    http://localhost:8080/docs/api.html

不需要再部署一套单独的前端或文档服务。

对于一个基础设施型开源项目，我更希望它的体验是：

拉起来，马上能看；复制接口，马上能测。

除了 HTTP API，我还给它做了一个可以直接交给 Agent 的 Skill

我后来又做了一件自己觉得比较有意思的事情：

把 OpenReach 自己封装成了 OpenReach Skill。

服务部署好后，可以直接下载 Skill，然后只提供一次服务器 IP：

python3 scripts/openreach.py init 192.168.1.20

初始化过程会先请求：

GET /api/web/health

确认服务连通之后，再把服务器地址写入 Skill 自己的 config.json。

之后就不需要每次输入服务地址了：

python3 scripts/openreach.py doctor

python3 scripts/openreach.py search "AI Agent" \
  --region auto \
  --provider auto \
  --limit 5

python3 scripts/openreach.py image-search "杭州西湖" \
  --region auto \
  --provider auto \
  --limit 8

python3 scripts/openreach.py read \
  "https://spring.io/projects/spring-boot/"

Skill 本身只使用 Python 标准库，不额外依赖第三方 Python 包。

真正想复刻的，不是 ChatGPT 的“搜索框”，而是它背后的搜索思路

OpenAI 在介绍 ChatGPT Search 时提到，一个真正有用的网络答案，过去经常需要多次查询、不断查看不同来源，再把信息组合起来。

这也是我在设计 OpenReach Skill 时重点参考的地方。

我没有把 SOP 写成“调用一次 search 然后总结”，而是抽象成了：

Query Planning
    ↓
Search
    ↓
Source Selection
    ↓
Read
    ↓
Evidence Check
    ↓
必要时继续 Search / Read
    ↓
Cross-source Verification
    ↓
Citation

换句话说：

Search 只负责发现信息，Read 才开始理解信息，多源验证之后才应该进入最终回答。

这套流程更适合 Research Agent、资讯分析、事实核查和需要引用来源的场景。

OpenAI 当前的 Web Search API 本身也已经暴露了 search、open_page、find_in_page 等不同动作，并且将引用信息作为搜索结果的一部分返回。

所以我越来越觉得，未来 Agent 的 Web 能力不会只是“给模型塞一个搜索 API”。

它更像是一条完整的信息获取流水线。

我也不想把 OpenReach 包装成一个“万能搜索”

当前 OpenReach 还是一个很早期的版本。

有几条边界我认为必须讲清楚。

第一，目前的 read 主要针对普通 HTML / SSR 页面，强 JavaScript 动态渲染页面并不是它当前最擅长的场景，后续计划通过 Playwright / Browser Reader 扩展。

第二，目前没有做跨 Provider 的统一 Pagination、Freshness 和商业级精准 Geo。

第三，Bing、百度、搜狗、360、DuckDuckGo 这些免费 Provider 主要是对公开搜索结果页进行 best-effort 解析，并不是对应厂商提供的商业 Search API。

第四，OpenReach 不准备去建设验证码绕过、住宅代理池、账号池这一类重反爬体系。

如果一个业务真的需要稳定 Google SERP、Shopping、Places、高 QPS 或商业 SLA，我更倾向于通过 Provider SPI 接入 Serper 等商业服务，而不是自己重新造一套反爬基础设施。

这其实也是 OpenReach 的设计原则：

把接口统一，把 Provider 留成可替换的。

最后：我更想把它做成 Agent 与互联网之间的一层“公共接口”

OpenReach 现在还很小。

但我想做的方向其实比较明确：

不是再做一个搜索产品，而是把 Agent 访问互联网时最常见的能力抽出来，形成一层足够轻、足够开放、可以自己部署的基础设施。

今天是：

Search
Image Search
Read

接下来可以继续往里加入：

Playwright Dynamic Read
SearXNG Provider
Commercial Provider
News Search
Places / Maps Search
Rerank
Source Quality
Citation Pipeline

当上层 Agent 只认一套稳定协议之后，底层能力就可以不断替换和增强。

这可能才是我觉得 OpenReach 最有价值的地方。

项目目前已经开源，如果你也在做 Agent、Research、联网搜索、内容生产或者企业内部 AI 应用，欢迎拿去试。

GitHub：

https://github.com/changluya/openreach

有 Bad Case、Provider 接入需求或者新的使用场景，也欢迎一起交流。

参考资料

OpenReach GitHub
https://github.com/changluya/openreach
OpenAI：Introducing ChatGPT Search
https://openai.com/index/introducing-chatgpt-search/
OpenAI API：Web Search Tool
https://developers.openai.com/api/docs/guides/tools-web-search
OpenAI API Pricing（Web Search 价格，以 2026-08-15 页面为准）
https://developers.openai.com/api/docs/pricing
Anthropic：Web Search Tool
https://docs.anthropic.com/en/docs/build-with-claude/tool-use/web-search-tool
Anthropic Pricing（Web Search 价格，以 2026-08-15 页面为准）
https://docs.anthropic.com/en/docs/about-claude/pricing

AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

2026企业微信AI Agent实测：7款技术方案对比

会话审计、敏感词管理、聊天质检、敏感行为识别、舆情、属性、词频及竞品分析覆盖服务风险；线索公海、客户、产品、商机、订单、回款、发票和业绩目标则连接销售全过程。快创助手负责快速建运营任务，策略生成把目标拆成方案，智能客服回答系统使用咨询，数据报表处理自然语言查数，AI洞察联合标签、订单和会话分析客户。我们设计了客户筛选、订单关联、销售交接、会话质检和异常恢复任务，配合技术访谈与行业公开资料复核。准备