面向 AI 智能体的图片搜索基础设施：市场究竟提供了什么

今年发布的每一个智能体框架都能写作、规划、调用工具、开 pull request。可一旦让它去找一张照片，整个系统就退化成耸耸肩：凭记忆编造出的图库 URL、失效的直链，或者干脆生成一张图——因为搜一张真实的照片比编一张出来还难。模型不是薄弱环节，它们下面的图片层才是——而且它缺失的方式非常具体，也可以量化。

这是一篇市场研究，不是宣言。以下所有内容都是在2026 年 8 月 18 日实测或来自一手资料：官方 MCP 注册表的普查、四个大型免费图片 API 的公开条款、本月上线智能体连接器的两个付费老牌服务的访问条件，以及一个无需 API 密钥、一分钟内即可复现的小型基准测试。

先划一条界线，方便不关心这个问题的读者尽早跳过：本文谈的是访问层——检索、可达性、条款、配额。它不是发布流水线。如果你想知道的是如何把一份草稿变成配图、注明来源、带标记的页面——路由提示词、视觉需求、组装、ImageObject 标记——那部分内容单独写在 为 AI 写作的文章配图的流水线里。

当调用方是一台机器时，什么会改变

一个人搜图片时会打两三个词、扫一眼图片网格，一眼就能认出一张好图片。以往每一个图库搜索引擎都是围绕这个循环设计的。而智能体一下子打破了这三个假设：

1. 它写的是句子，不是关键词。一个刚刚写完一段关于房贷文书内容的模型，不会输出 mortgage；它会输出“一位女性在厨房桌前签署房贷文件，一位银行顾问在旁解释条款”。这是语言模型自然的输出方式，而这恰恰是一个基于标记匹配的索引无法处理的内容。
2. 它无法浏览图片网格。工具返回什么，智能体“知道”的就是什么。如果响应只是一串没有描述、没有尺寸、没有版权信息的 URL 列表，智能体就得逐一抓取查看每张图片——或者更常见的情况是，直接猜。
3. 它没有手。它无法把截图上传到审核队列、接受条款、轮换密钥，也无法等待三个工作日的生产环境审批。API 上线流程中每一个需要人类操作的步骤，都是智能体走不过去的一堵墙。

所以“面向 AI 智能体的图片搜索基础设施”不是一句营销用语，而是一份检查清单：自然语言检索、足够丰富到可供推理的机器可读结果，以及一个程序可以独立完成的身份验证和配额模型。

测试：一句话 vs 一个关键词索引

最便宜的验证方式，就是把智能体自己写的话发给一个关键词引擎。下面的测试使用了Openverse——由 WordPress.org 运营的开放授权媒体搜索引擎，因为它的 API 是公开的，不需要密钥，任何读者都能在一分钟内自行复现。四份需求，都是模型在为自己刚写完的内容配图时会写出的那种：

import json, urllib.request, urllib.parse

BRIEFS = [
  "a woman signing a mortgage document at a kitchen table while a bank"
  " adviser explains the terms, warm morning light",
  "An elderly couple enjoying a peaceful retirement together",
  "a child discovering snow for the first time in a suburban garden",
  "a delivery cyclist waiting at a red light in heavy rain",
]

def count(q):
    u = "https://api.openverse.org/v1/images/?" + urllib.parse.urlencode({"q": q})
    r = urllib.request.Request(u, headers={"User-Agent": "benchmark/1.0"})
    return json.load(urllib.request.urlopen(r))["result_count"]

for b in BRIEFS:
    print(count(b), "|", b[:48])
# 0 | a woman signing a mortgage document at a kitchen
# 0 | An elderly couple enjoying a peaceful retirement
# 0 | a child discovering snow for the first time in a
# 0 | a delivery cyclist waiting at a red light in hea

四份需求，四个空结果集。现在把每份需求都精简成人类会打的那两个关键词——signing document、elderly couple、child snow、cyclist rain——每一个都返回了满满一页照片（API 报告的数字是 240，这是它对匿名调用者设置的计数上限）。图库里是有这些照片的，无法解析的是那句话。

左右滑动表格查看所有列 →

Pexafy 那一列，是把同样四句话原封不动地发给托管 MCP 服务器上的 search_photos，延迟数据是服务器自己返回的。这是一次查询形态的对比，而不是图库质量的对比——图库质量明确不是问题所在。Openverse 自己的统计接口在测试当天报告了覆盖 52 个来源的 9.15 亿张图片，它在自己被设计来做的事情——面向人类的关键词搜索——上表现出色。它本身没有任何问题，只是从未被设计成能应对以句子思考的调用方。为什么标签匹配在描述性场景上会失效——以及语义检索用什么来替代它——这一点从读者视角在 用一句话搜索，而不是用关键词一文中已有论述；这里新增的是实测数据，以及当调用方是程序而非人类时它意味着什么。

“一对老年夫妇一起享受平静的退休生活” · 135 ms 内返回 16 条结果 · 展示其中三条

排名 1Pexels Pixabay Unsplash

截至 2026 年 8 月 18 日的市场情况

检索只是问题的一半。另一半是可达性：智能体到底能不能触达图库，条件是什么？自从模型上下文协议（Model Context Protocol）成为助手接入外部系统的方式以来——其当前规范，日期为 2026 年 7 月 28 日，把协议改造成无状态的请求/响应核心，使服务器可以部署在普通的负载均衡器之后1——审视这个市场最诚实的方式，是看实际公开发布了什么，而不是宣布了什么。

付费老牌服务本月才刚上线

Getty Images于本文发布前六天，也就是2026 年 8 月 12 日，上线了自己的 MCP 服务器，把创意、编辑和档案类搜索及下载功能开放给了 AI 工作流。2它面向的是企业团队和平台构建者，其自身的访问页面对准入门槛毫不含糊：你需要一份有效的 Getty Images 协议，比如 Premium Access，外加接受 Web Service 条款。没有免费层级。Shutterstock的内容同样可以通过一个 MCP 服务器访问——涵盖搜索、收藏和授权的 24 个工具——下载功能被限定在需要持有有效订阅的账户之内。3

这两步棋都是理性的，而且都是针对特定买家的。Getty 在 2025 年录得9.813 亿美元的营收4，所处的图库摄影市场 2026 年规模约为54 亿美元5；需要签约才能使用的连接器，保护的是这份营收，而不是把它打开。如果你是一家银行或一家广播公司，这正是你想要的。但如果你是一个搭建side project 的开发者——或者是一个不能停下来、请人签个字的智能体——这就是一扇关闭的门。

免费图库根本还没上线过任何官方服务器

Unsplash、Pexels 和 Pixabay 是大多数构建者最先想到的三个图库，但没有一家发布了官方的 MCP 服务器。取而代之的，是一整排社区包装器。我们完整爬取了官方 MCP 注册表——22,607 个服务器，75,487 个已发布版本——保留了所有名称或描述中涉及照片或图库图片搜索的条目。呈现出的模式是一致的：

左右滑动表格查看所有列 →

import json, urllib.request, urllib.parse

def crawl(term):                      # 注册表用 `nextCursor` 分页
    out, cursor = {}, None
    while True:
        p = {"limit": "100", "search": term} | ({"cursor": cursor} if cursor else {})
        d = json.load(urllib.request.urlopen(
            "https://registry.modelcontextprotocol.io/v0/servers?" + urllib.parse.urlencode(p)))
        for e in d["servers"]: out[e["server"]["name"]] = e["server"]
        cursor = (d.get("metadata") or {}).get("nextCursor")
        if not cursor or not d["servers"]: return out

servers = {}
for t in ["photo", "image", "stock", "picture", "unsplash",
          "pexels", "pixabay", "getty", "shutterstock", "openverse"]:
    servers |= crawl(t)

# 137 个不重复的服务器 · remote 还是 local 由 server["remotes"] 决定
# 所需的第三方密钥列在 packages[].environmentVariables 中

这些包装器每一个都是同样三个关键词 API 的薄客户端，这意味着上面的基准测试适用于它们全部：传输方式变了，检索方式没变。包装器无法让一个标签索引理解一句话。

真正拦住机器的那一条条款，不是配额

免费图库的配额和条款已经用同一套单位并排比较过了，见 免费图库 API 对比——审批队列、强制的下载调用、24 小时缓存义务、署名规则。那篇文章是从一个正在选择服务商的开发者角度来读的。如果换成那个必须遵守这些条款的程序的角度重新读一遍，有一行和数量无关的条款会格外醒目：

同样的解读也适用于上线流程。一个只有在有人审核过你的应用截图之后才能转为生产环境的演示层级，不是一个智能体可以退避重试的速率限制；而是它根本无法执行的一个步骤。Pixabay 明确说明了这一意图——该 API 面向合法的人类使用，禁止大规模自动化下载。这一切都并非不合理：摄影师无偿贡献作品，总得有人为带宽买单。它描述的只是一个默认调用方拥有屏幕和双手的 API。

四项要求，以及谁满足了它们

把这两部分放到一起，一个智能体真正能用的图片层规格，就变得简短而可检验。它刻意不是一份服务商对比——图库规模、定价和授权条款已经在 对比文章里排好了。以下四点只关乎程序到底能不能触达这些图片：

1. 语义检索——一句完整的话返回的是一页排好序的结果，而不是空集。
2. 免费授权，多个来源——不用为单张图片单独授权，也不受某一个图库口味的支配去决定你发布的每一页内容。
3. 带自有登录方式的托管服务器——远程、OAuth，不需要安装本地进程，也不需要把第三方的 API 密钥粘贴进配置文件。
4. 一个机器能自行完成注册的免费层级——不需要截图审核，不需要签合同，有一个月度配额和一个每分钟速率限制，工作进程可以据此自我调节节奏。

左右滑动表格查看所有列 →

Pexafy 是我们做的产品，所以请带着应有的怀疑态度去读最后这一行——然后自己核实：注册表普查可以用一个脚本复现，Getty 和 Shutterstock 的访问条件就在它们自己的页面上，三个图片 API 的限制也都在各自的文档里，全部链接在文末。这个论断范围很窄，也可以被证伪：截至 2026 年 8 月 18 日，我们没有找到第二个能同时满足这四项的服务。如果你知道有这样一个服务，我们会把它加进这张表——把要求写清楚的意义就在于，任何人都可以拿这四条去检验任何产品，包括我们自己的。

一个优秀的图片服务器在 MCP 上应该做什么

连接器不是套了件新外衣的 REST 端点。这一层的两种用法已经在别处写过，这里不再重复——给草稿配图，见 流水线文章；让一整个长篇系列在视觉上保持一致，见 关于规模化的那篇。属于基础设施层的，是二者都依赖、但事后都无法补上的东西：三个服务端决策，一次性做好，供每一个日后接入的智能体使用。

1. 返回智能体可以推理的对象。工具返回什么，就是模型知道的全部——它无法浏览图片网格。下面两种返回形态之间的差异，就是一个能对照片进行推理的助手和一个只会转发链接的助手之间的差异：

# 典型的关键词包装器：智能体要么去抓取查看，要么去猜
[{ "url": "https://…/photo-8795398.jpeg" }, { "url": "https://…/366611.jpg" }]

# 实际返回的一条结果——此处做了删减，未额外添加内容
{
  "rank": 1,                       // 人类使用的编号："再来点像 #1 的"
  "photo_id": "019e14d9-e821-…",   // get_similar_photos 需要的参数
  "width": 6424, "height": 4283, "orientation": "landscape",
  "color_hex": "#918872", "blur_hash": "LPI#Px?aDikCGwW?M{kD-VR*s.fl",
  "source": "Pexels", "license_type": "free",
  "alt_description": "Older couple sits together on wooden bench in a park",
  "attribution": { "plain": "Photo by Anastasia Shuraeva on Pexels", "html": "…" },
  "urls": { "thumb": "…", "small": "…", "regular": "…", "large": "…" }
}

有了第二种形态，智能体就可以说“#3 是竖版的，会破坏你的主图位置”，去掉一个重复的摄影师，输出署名信息，并给你的模板提供一组 width/height数值，从而消除布局偏移——而这一切都无需抓取一张图片。用第一种形态，上面每一个决策都是猜测或需要一次额外的往返请求。

2. 给结果编号，方便人指认。结果按 #1, #2, #3… 排序返回，这也是人们在对话中指代照片的方式——“再来点像 #3 的”——不需要手动复制任何标识符。在支持 MCP Apps 的客户端里，缩略图会内嵌渲染，点开其中一张就能看到工具结果里本就存在的元数据，不需要额外调用。

3. 保持只读，并明确这一点。三个工具，没有写入权限，不会更改账户。其中一个工具在任何关键词 API 里都没有对应物：search_photos_by_image接受一张参考图片——客户已有的主图、粘贴到聊天里的一张截图——外加一句可选的话来调整方向（“像这张，但是在夜里”）。在标签匹配 API 里，根本没有字段能输入这样的请求。而一个无法改动任何东西的智能体，最坏的结果只是一个空结果集，而不是一张客服工单。

两种接入方式，以及你该选哪一个

接入方式正好有两种，选择取决于是否有人在环内，而不是能力上的差异——两种方式背后的工具和图库是完全相同的。

有人在环内时，用连接器。只需一个 URL，https://mcp.pexafy.com/mcp，在助手的连接器设置里添加一次；登录在浏览器窗口中完成，客户端会拿到自己的凭证，因此不需要把密钥粘贴进配置文件，日后也无需轮换。不支持 OAuth 的客户端，可以把 Pexafy API 密钥作为 bearer token 发往同一个端点——这使得连接器也能在构建服务器上的一个 cron 任务里使用，那里没有人会点“允许”。Claude、ChatGPT 以及一份多智能体配置文件的具体接线步骤，写在 流水线文章里，没有变化。

没有人在环内时，用 HTTP API。一个为 800 个主题集群填充图片池的批处理任务，不应该假装自己是一个聊天客户端：同一个账户，同一个密钥，普通 HTTP，每次调用 100 条结果。与之配套的节奏规则——速率限制响应头、为什么每分钟触发的 429值得重试而每月配额触发的 429不值得、一个工作进程在大量调用下的成本——属于 关于大规模配图的文章，那篇文章把这个工作进程完整地写了出来。

这里值得记住的重点更窄一些，也正是这份市场研究所要论证的核心：这两种接入方式，在写下本文这一天，都可以被一个程序直接触达，不需要排队，也不需要签约。

这解决不了什么

一份诚实的清单，因为其中每一条都曾让某个人吃过回滚的苦头。

• 授权条款仍然约束着这张图片。Pexafy API 条款并不要求署名，每一条结果也都自带一段可以直接渲染的署名字符串——但原图库附加的授权条款，仍适用于你对这张照片的使用。自动渲染署名信息；这比事后审计要便宜得多。
• 免费授权图库不是新闻编辑档案库。没有新闻、没有体育赛事，也无法按需获取可识别的品牌或公众人物。如果你的页面需要一张特定事件或特定人物的照片，那正是授权型老牌服务商存在的意义，它们的连接器现在也已经上线。
• 这只是检索，仅此而已。图表、图形和截图应该由代码渲染而不是搜索出来；你各页面之间的去重是数据库里的一个字段，而不是端点上的一个参数；也没有任何照片能让一篇内容单薄的页面获得排名——无论页面是否配了图，Google 的垃圾内容政策对规模化内容滥用一视同仁。6这三个都是流水线问题，也有对应的流水线解法，分别在 流水线文章和 关于规模化的那篇里详细展开。

从哪里开始

1. 重新跑一遍这个基准测试。二十行代码，不需要密钥。不管你现在用的是哪个图片 API，把你自己智能体写的三份需求原样发过去，数一数有多少个空结果集。
2. 给你已经在用的助手接上一个连接器，用一句话向它要一张你这周确实需要的照片。这就是全部的评估过程。
3. 把配图需求交给智能体来写——每个位置写一个场景，从草稿内容出发，绝不从标题出发。
4. 在批量发布任何内容之前，加上 photo_id 这一列。
5. 先在免费层级上跑起来——每月 5,000 次搜索，每分钟 20 次，直到是构建规模而不是账单，逼着你升级。

参考资料与脚注