以前做好 SEO,就能把网站推上 Google 首页。可到了 2026 年,如果客户不再亲自搜索,而是直接让 AI 智能体(Agent)帮忙"找出最合适的邮件工具"呢?这时候,智能体不会去 Google 翻答案,而是从自己能访问到的工具列表里挑一个。 YC 把这种变化称为"智能体经济(Agent Economy)",下面就来整理一下 SaaS 开发者现在该做哪些准备。
这是什么?
一直以来,SaaS 的发现(discovery)都是为人设计的。SEO、文案、口碑、广告——全部围绕"让人的眼睛看见"在做文章。可随着 AI 智能体变成有自主行为的经济参与者,局面正在改变。
智能体挑选工具时,大致是这么运作的:
- 扫描可用工具清单(MCP 服务器、API 目录等)
- 读取每个工具的 description(描述)、schema(结构)、示例
- 挑出最适合当前任务的那一个
- 执行 → 评估结果 → 必要时换另一个工具
关键在于,智能体看到的不是 UI,而是描述和 schema。哪怕你的落地页做得再漂亮,工具描述一旦模糊,智能体就会去选别家的。
有什么不同?
a16z 的 Yoko Li 在一篇 MCP 深度解析中点出了核心——"开发者导向公司的竞争力,将从'最优秀的 API 设计'进化为'为智能体准备的最佳工具集合'"。
这不只是一次技术潮流,而是 SaaS 商业模式本身的转折:
| 维度 | 过去(面向人) | 智能体时代 |
|---|---|---|
| 发现方式 | Google SEO、广告、口碑 | MCP 注册中心、工具描述、llms.txt |
| 选择标准 | UI/UX、品牌、价格 | 描述的清晰度、schema 一致性、响应速度 |
| 集成方式 | 人手动配置 | 智能体自动接入(MCP) |
| 定价模式 | 按座席 / 订阅 | 按 API 调用计费,智能体比较性价比 |
| 文档角色 | 供人阅读的参考资料 | 供智能体理解的执行指引 |
Vercel 已经在行动。他们搭建了 AEO(AI Engine Optimization,AI 引擎优化)追踪系统,用来监测编码智能体发现和推荐 Vercel 的频率。早期数据显示,约 20% 的编码智能体会执行网络搜索,并基于搜索结果来推荐工具。
The New Stack 的分析把 MCP 的采用比作"智能体 SEO 的淘金热"。就像 2000 年代初企业争相做 SEO 一样,如今为了被智能体发现而展开的竞争已经打响。
上手指南
- 优化工具描述(Tool Description)
智能体选工具时,最先读的就是 description。与其写"这是一个邮件发送工具",不如写成"用于按 HTML 模板撰写营销邮件,按设定时间向收件人列表定时发送,支持打开率追踪和 A/B 测试",把颗粒度做到能让智能体判断'何时、为何该用这个工具'的程度。 - 把 API 设计得对智能体友好
API 和 tool 并不是一一对应的关系。比起单独的 send_email(),像 draft_email_and_send() 这种智能体一次调用就能完成任务的高层动作更有效。因为智能体希望用尽量少的调用拿到结果。JSON schema 也要清晰——必填字段、可选字段、示例都不能少。 - 制作 llms.txt 文件
llms.txt 可以理解为 robots.txt 的 AI 版本。把它放在站点根目录,LLM 和智能体就能更准确地理解你的服务。用机器易读的格式,把服务说明、核心功能、API 端点摘要整理进去。 - 提供 MCP 服务器
MCP(Model Context Protocol,模型上下文协议)是 AI 模型调用外部工具的标准协议。只要为你的服务搭一个 MCP 服务器,Cursor、Claude Desktop 这类 MCP 客户端就能直接接入。把它注册到 Smithery、mcpt 等 MCP 市场,被发现的机率还会更高。 - 开始做 AEO 追踪
监测智能体发现并使用你工具的频率。可以像 Vercel 那样搭一套专属系统,也可以从更简单的做法起步——比如过滤 API 日志里 User-Agent 为智能体的请求。你还能对不同的描述做 A/B 测试,看哪种写法更能促成选择。
"智能体 SEO"的核心原则
HN 讨论中浮出的一条关键洞见——不同模型对同一个工具描述的反应可能不一样。Claude、GPT、Gemini 各自有不同的评估标准。与其想用一段描述取悦所有模型,不如把核心功能写得清晰具体,这样反而在各模型间都更通用有效。
MCP 仍处于早期阶段
认证、权限管理、多租户等核心能力尚未标准化。把 MCP 服务器部署到生产环境前,必须做安全审查。另外,目前大多数 MCP 服务器是本地优先(local-first)的,若要做远程部署,还需额外的基础设施设计。
