被 You.com 选中的 MCP 搜索服务器：一次意外的市场验证
You.com 扫描了 93 个 AI Agent 项目推广搜索 API，agent-search-mcp 在 MCP 搜索品类中胜出。一次推广 bot PR 如何变成了意外的架构认可和市场定位报告。
被 You.com 选中的 MCP 搜索服务器：一次意外的市场验证
一个推广 bot 的 PR，教给我的 AI 搜索引擎的定位和分发策略
一、来了一个奇怪的 PR
7 月 23 日，agent-search-mcp 收到了一个外部 PR——「feat: add optional You.com search engine」。代码质量不错：67 行 engine adapter，4 个测试，遵循项目规范。看起来是一个标准的社区贡献。
但几个细节让我觉得不对劲：
- 作者
mouse-value-add：2026 年 2 月创建，64 个 public repo，0 followers，bio 写着 "friendly, small" - PR 描述是一套模板化结构（Problem → Solution → Setup → Validation）
- 底部挂了一个 tracking issue 链接：
youdotcom-oss/integration-tracking/issues/116
点进去一看，发现了整件事的全貌。
二、You.com 的规模化 OSS 推广
You.com 是谁
You.com 是一个 AI 搜索引擎，有自己的搜索 API。和 Tavily、Exa、Brave 一样，它想让 AI Agent 用它的 API 来搜索互联网。
93 个 issues，一套标准化战术
我翻看了 youdotcom-oss/integration-tracking 仓库——93 个 open issues，全部是同一件事：跟踪向 OSS 项目提 PR 推广 You.com API 的状态。
每个 issue 的结构完全一致：
[Integration] 项目名 - 集成方案
### 候选评估
- 项目A: SELECTED — best fit
- 项目B: 太耦合
- 项目C: 太庞大
### 集成方案
- 可选 engine adapter
- 默认关闭
- 通过 --engines 选择
### 当前状态
PR opened, awaiting review
这不是随机撒网的推广——这是有方法论、有优先级、有候选评估的规模化增长引擎。
目标分层：从 S 到 C 的四级漏斗
他们追踪的 93 个项目并非随机选的。按生态影响力，可以清楚分为四层：
| Tier | 定位 | 代表 |
|---|---|---|
| S | 框架/平台级 — 集成后自动触达所有下游 | microsoft/semantic-kernel、deepset-ai/haystack、Alibaba-DeepResearch |
| A | 知名 OSS 项目 — 独立用户群大 | Hermes Agent、meilisearch、Perplexica |
| B | 垂直品类领头 — 在细分赛道占据分发节点 | agent-search-mcp、mcp-omnisearch、swarmclaw |
| C | 个人/小项目 — stars < 50 | 大量个人 repo |
截至调查时：
- C 层：10+ 个项目已 merge（小项目维护者看到就合）
- B 层：大部分 PR 还在 open（维护者在审查）
- S 层：还没提 PR（也许在评估，也许不敢提）
没有一个 S 或 A 层项目被 merge。 大项目对 bot-PR 的审慎程度远高于小项目。
三、为什么我们被选中
在搜索 MCP 垂直品类里，You.com 对比了 3 个项目做了候选评估：
| 项目 | Stars | 结果 | 理由 |
|---|---|---|---|
| agent-search-mcp | 9 | ✅ SELECTED | "clean engine registry, tool-level engine selection, test coverage — best overall fit" |
| n24q02m/wet-mcp | 15 | ❌ | 搜索栈更强但耦合 SearXNG/本地爬虫，加 engine 要动架构 |
| tobocop2/lilbee | 38 | ❌ | 仓库太大、偏平台化，PR 改动不可控 |
9 stars 的项目打败了 38 stars 的竞品。 赢的不是名气，是架构：
- Clean engine registry — 引擎注册在 3 个地方加条目即可，改动量极小
- Tool-level engine selection —
--engines/ MCP 参数天然支持可选引擎 - Test coverage — 引擎解析、策略过滤、搜索路径都有测试，改动风险可控
这恰好是我们从 Day 1 就坚持的设计原则——可插拔引擎架构。当时只是觉得应该和 Tavily 的 "we lock you into our API" 反着来，没想到它成了第三方集成时的最大卖点。
四、搜索 MCP 品类格局
这次调查意外获得了一份「Agent 搜索入口」的竞争地图。B 层几个项目的对比如下：
| 项目 | Stars | 差异化 |
|---|---|---|
| mcp-omnisearch | 334 | 多引擎聚合，Tavily/Brave/Kagi/Exa |
| agent-search-mcp | 9 | 瀑布搜索、置信度评分、渐进披露、中文优化 |
| swarmclaw | 624 | Agent 运行时，搜索只是功能之一 |
mcp-omnisearch 的 You.com PR 已被 merge——它也是同类项目，334 stars。但它的差异化在引擎数量（多集成几个 API），我们的差异化在搜索质量优化（瀑布搜索省 50-75% 调用、渐进披露省 36-58% token、语义去重/重排）。
引擎数量可以追，搜索质量的结构化优化才是壁垒。
五、对 OSS 项目的启示
这次经历给了我几个关于开源项目定位的教训：
1. 架构优势是沉默的营销
没有人主动宣传 "我的引擎架构可插拔"——但第三方在选择集成目标时，这成了决定性因素。好架构自带推销能力。
2. 被 bot-PR 盯上是品类识别信号
You.com 不会随便给一个项目提 PR。他们选择你，说明在他们的市场地图里，你已经是一个品类入口。被推广盯上 ≈ 被市场识别。
3. Stars 不等于分发价值
我们有 9 stars，竞品有 334 stars。但 You.com 选了 9 stars 的。因为对他们来说，「让用户看到 You.com 的可能性」取决于集成深度，而不是项目名气。
4. 把竞争变成宣传素材
如果我只是把 PR #15 merge 掉，这件事就只是一个 commit。但我把它写成了这篇文章——一次推广行为，变成了对我们架构设计的第三方认可。
六、我们接下来做什么
这件事验证了两个方向：
继续强化架构优势：
- 保持引擎可插拔设计（不因功能膨胀破坏注册机制）
- 让每个新功能的 API 变更 ≤ 3 个文件
- 测试覆盖保持 480+ 的密度
补上分发短板：
- Stars 差距（9 vs 334）说明可见度不够
- 加 mcp.so、Smithery 等 MCP 目录
- 掘金/V2EX 文章（国内搜索 MCP 内容空白）
- README 用「被 You.com 选中」做 trust signal
这篇文章本身就是策略的实践——把一次意外发现变成品牌故事。