各位好，我是果叔。
前段时间我写过一篇 WebMCP，讲的是 Google 正在推的这个新规范，会不会改变 WebApp、PLG 和 SEO 的营销逻辑。那篇文章更多是在回答一个基础问题：WebMCP 到底是什么。
但这两天我又把这个东西重新想了一遍，尤其是把它和最近 Google 对 AI Search、AEO、GEO 的表态放在一起看，我觉得真正值得聊的地方，已经超过了“网页能不能给 AI 暴露一个工具接口”这个技术问题。真正有意思的问题是：如果未来 AI 读取网页、总结网页、引用网页之后，还开始直接调用网页里的能力，那 SEO 的下一层竞争会变成什么？
说人话一点。过去我们关心的是，用户搜一个问题，你的网站能不能被看到。后来 AI 搜索来了，我们开始关心，ChatGPT、Gemini、Perplexity 这些东西回答问题的时候，会不会提到你、引用你、把你当成事实来源。但如果 agent 继续往前走，下一步可能会出现一个更现实的问题：AI 能不能直接在你的网站上完成一个动作？
比如帮用户筛选产品，生成报价，预约服务，配置方案，提交表单，导出报告，创建项目，发起购买，或者把某个复杂工作流推进到等待用户确认的那一步。这时候网站的竞争逻辑就不只是“被找到”和“被引用”了。它会多出第三层：被调用。
这也是我今天想聊的核心判断。
SEO 的下一层，可能是动作优化
我先把结论放前面。WebMCP 现在还不是一个必须马上上线的 SEO 标准。它目前仍然处在比较早期的阶段，官方规范还是 Draft Community Group Report，Chrome 侧也把相关能力称作 early preview。也就是说，今天你还不需要立刻拉着前端团队开会，说我们明天就要支持 WebMCP，不然公司完蛋。
别这么焦虑。但 WebMCP 提前暴露了一个很重要的方向：网页未来除了作为内容容器，也会越来越像一个可被 AI 调用的能力容器。这个变化很大。
传统 SEO 的核心问题是：搜索引擎能不能发现你、理解你、排序你。GEO 或 AEO 的核心问题是：AI 回答问题的时候，能不能吸收你、引用你、稳定地表达你。如果 agent 这条线继续往前走，下一层问题会变成：AI 能不能在一个安全、可控、低歧义的环境里调用你。
这听起来像开发者问题，但我觉得它迟早会变成增长问题。因为用户的入口在变。以前用户进入你的网站，是自己点进来，自己看页面，自己找按钮，自己填表单。后来 AI 搜索出现，用户可能先问 AI，再从答案里点到你。下一步，如果 agent 能帮用户做事，路径可能会变成：用户只说目标，agent 帮他找合适的网站，理解网站能力，然后直接调用某些动作，最后让用户确认。
这个时候，页面浏览量可能还在，但它不再是唯一的价值入口。
你的网站有没有被调用，你的能力有没有被正确触发，你的任务流程有没有被 AI 顺利推进，都会变成新的增长变量。
这就是“动作优化”。它不替代内容优化，只是在内容优化之上再加一层产品能力的优化。
先别把 WebMCP 神秘化
每次行业里冒出一个新词，大家最容易做的事情就是把它神秘化。GEO 是这样，AEO 是这样，MCP 也是这样。一神秘化，就开始出现各种焦虑套餐：你不做就落后，你不接就错过时代，你不马上布局就会被 AI 搜索淘汰。
我对这种话一直比较警惕。
WebMCP 当然值得关注，但它现在还远远没有到“全站必接”的程度。更准确的说法是，它在尝试给网页和 AI agent 之间建立一条更结构化的通路。
官方规范里的核心思路并不复杂：Web application 可以通过 JavaScript-based tools，把网页里的某些能力暴露给 AI agent。Chrome 早期预览文章里也提到，这种 structured tools 的目标，是让 agent 在网站上执行动作时更快、更可靠、更准确。
这句话真正该看的是 structured。也就是 AI 不再只是看着页面、猜按钮、模拟点击，而是可以通过网页自己声明出来的工具能力，知道这里能做什么、需要哪些输入、执行后会得到什么结果。
过去很多网页自动化，本质上是 agent 在“看图猜题”。它看见一个按钮，猜这个按钮是什么意思；看见一个表单，猜这里该填什么；看见一个页面状态，猜任务是不是完成了。
这条路能跑，但很脆。
按钮文案稍微改一下，布局稍微换一下，弹窗多一个，流程多一步，agent 就可能开始犯傻。
WebMCP 想解决的，正是这种“瞎摸 DOM”的问题。它希望页面自己把高层动作声明出来，让 agent 不用完全靠视觉和 DOM 猜测。
这背后的思想，其实很像我们过去做 SEO 时讲的语义化。只不过以前的语义化更多服务于内容理解。标题是什么，正文是什么，作者是谁，产品价格是多少，FAQ 在哪里。
现在如果进入 agent 时代，语义化会继续往动作层推进。这个按钮到底触发什么任务，这个表单需要哪些参数，这个流程成功的条件是什么，失败之后能不能撤回，哪些步骤必须用户确认。这些东西过去更多是 UX、前端、产品经理关心的细节。以后它可能也会变成 SEO 和增长团队必须理解的东西。
从“可见度”到“可引用度”，再到“可调用度”
我更愿意把这件事放在一个连续变化里看。
第一层是可见度，这是传统 SEO 的主战场。你的网站有没有被抓取，页面有没有被索引，关键词能不能排名，标题和描述能不能带来点击，内容能不能满足搜索意图。这一层当然还重要。别听到 AI Search 就把传统 SEO 全扔了，那是非常危险的懒人想法。Google 最近对 AEO/GEO 的表态其实已经说得很清楚，从 Google Search 的角度看，针对生成式 AI 功能做优化，说到底仍然属于搜索体验优化。基础 SEO 没有消失，只是它被放进了更复杂的界面里。
第二层是可引用度。AI 搜索起来之后，很多人开始关心一个新问题：AI 回答问题的时候，会不会用我的内容？会不会引用我的页面？会不会把我的品牌放进推荐列表？这个问题也是真的。尤其对内容站、SaaS、工具站、垂直服务商来说，被 AI 引用不一定立刻带来大量点击，但它会影响品牌出现的概率，也会影响用户在购买前形成的认知。
不过这层也很容易被玩坏。有些人把 GEO 理解成“写一点 AI 喜欢的句子”，或者到处制造一些虚假的品牌提及，幻想模型会因此更愿意推荐自己。这个思路我一直不太认同。AI 引用你，最终还是要回到内容是否可信、信息是否有独特性、页面是否能被稳定理解、品牌是否有足够外部证据。
第三层，就是可调用度。这也是 WebMCP 真正提示我们的东西。如果 AI agent 未来不只回答“哪家工具适合我”，还要帮用户直接进入某个工具完成任务，那么竞争单位就会变。以前你优化一篇页面，是为了让它被排名。后来你优化一段定义，是为了让它被 AI 引用。下一步，你可能要优化一个任务入口，让它能被 agent 正确调用。
这就是我说的，SEO 的下一层可能会从内容优化走向动作优化。当然，这不是说每个页面都要变成工具。纯内容页的核心仍然是解释、证明、引用、建立信任。它不一定需要暴露什么复杂动作。
但对 WebApp、SaaS、工具站、电商、预订平台、设计工具、数据 dashboard、客服系统、项目管理产品来说，页面背后本来就有大量可执行动作。它们未来面对 AI agent 的时候，最重要的问题可能不再停留在“你有没有一篇介绍页”，而会变成“你的关键能力能不能被机器稳定理解并调用”。
真正会先受影响的，不是所有网站
这里要收住一点。不是所有网站都会同时被 WebMCP 这类东西影响。如果你是一个纯资讯站，短期最该关心的还是内容可信度、主题权威性、被引用资格、AI 流量测量。你现在去纠结“我的文章页面要不要暴露工具”，大概率有点跑偏。
但如果你做的是 WebApp，就不一样了，尤其是那些 PLG 驱动的产品。
PLG 的核心逻辑是什么？让用户通过产品自己理解价值、体验价值、完成激活、形成传播。过去我们优化 PLG，主要看首屏、注册流程、模板、demo、onboarding、激活路径、付费墙、产品内引导。
但如果用户未来越来越多地通过 AI agent 接触你的产品，那么 PLG 会多出一层新问题：agent 能不能理解你的产品能力，并帮助用户走完第一段价值路径？
这件事听起来很抽象，我换几个场景。
一个 SEO 工具站，用户不一定想点进来慢慢研究你每个功能。他可能会对 AI 说：帮我分析这个页面为什么没有排名，并给我一个修复计划。
一个设计工具，用户不一定想从空白画布开始。他可能会说：帮我把这个产品介绍改成一张适合 LinkedIn 的图。
一个电商站，用户不一定想自己翻几十个 SKU。他可能会说：帮我找一个适合 8 岁女孩生日的礼物，预算 40 美元以内，最好今天能发货。
一个 B2B SaaS，用户不一定想读完整个 pricing 页面。他可能会说：帮我比较这几个方案，看哪个适合一个 12 人团队。
这些任务如果都由 agent 介入，网页就不能只是给人看的展示页。它还需要把自己的能力边界、输入条件、状态反馈、确认点、失败处理讲清楚。这就是 agent-ready 的产品设计。
我不太喜欢把它叫成“AI 友好型页面”，这个词太轻了，听起来像改几句文案就行。更准确一点，它应该叫“可协作的产品界面”。网页不只是给人看，也开始给人和 agent 一起用。
内容资产之外，会多出一种能力资产
过去我们做 SEO，很喜欢讲内容资产。一篇文章，一个 landing page，一个 glossary，一个 comparison 页面，一个 use case 页面，都可以算内容资产。它们的价值来自长期搜索流量、品牌解释、用户教育和转化辅助。
后来进入 AI 搜索阶段，我们开始多讲证据资产。你有没有可信的定义，有没有清晰的数据，有没有第三方引用，有没有真实案例，有没有可以被 AI 吸收的结构化事实。因为 AI 在回答问题时，需要的不只是“你自己说你很好”，还需要外部证据和稳定语义。
如果 agent 继续发展，我觉得会出现第三类资产：能力资产。能力资产不是一篇文章，而是一个可以被理解、调用、确认的动作。
比如：
帮用户生成一份报告。
帮用户筛选一个方案。
帮用户检查一个页面。
帮用户创建一个项目。
帮用户预约一个时间。
帮用户把一组素材转换成另一种格式。
这些动作本来就是产品价值的一部分。只是过去它们主要藏在 UI 里，由用户自己一步步点击完成。agent 时代的问题是，这些动作能不能被表达成清晰的工具能力。
一个成熟的能力资产，至少要回答几个问题。它叫什么。它解决什么任务。它需要什么输入。它会改变什么状态。它执行前要不要用户授权。它执行后如何让用户确认。它失败了怎么反馈。它能不能撤回。
你看，这已经不是传统 SEO 文案能单独解决的东西。它需要产品、前端、后端、增长、SEO 一起参与。
所以我才说，WebMCP 对 SEO 最大的影响，不在于多了一个技术清单，而在于它把 SEO 的边界继续往产品层推。
以前 SEO 从业者懂内容、懂关键词、懂链接、懂技术抓取，已经算比较全面。
以后真正稀缺的人，可能要继续往前走一步。他要能看懂一个产品的任务结构，知道哪些页面只是信息页，哪些页面其实是能力入口，哪些动作值得被 agent 调用，哪些动作必须严格限制。
这听起来有点麻烦。但说实话，增长这件事本来就越来越麻烦。简单流量红利越来越少，靠一堆模板页吃排名的时代，本来就在变难。
不要急着做 demo，先盘你的任务地图
如果你现在是一个 WebApp、SaaS 或工具站团队，我不建议你今天就为了 WebMCP 写一堆半成品 demo。这很容易变成技术兴奋。demo 做出来很漂亮，发条推特很酷，过两周没人维护，最后变成仓库里一个“我们也拥抱 agent 时代”的标本。
更现实的第一步，是盘任务地图。你的网站里到底有哪些任务？哪些任务是用户高频做的？哪些任务标准化程度高？哪些任务适合 agent 先做草稿，再让用户确认？哪些任务一旦做错，成本很高，必须由用户亲自执行？哪些任务需要登录、权限、支付、隐私数据，不能随便开放？
这张图比 WebMCP 语法本身重要。因为协议会变，平台会变，浏览器实现会变，但你的产品任务结构不会完全凭空变出来。
如果你今天能把产品里的任务拆清楚，未来无论是接 WebMCP、接传统 MCP server、接 OpenAPI、接某个平台私有 agent，都会顺很多。反过来，如果你的产品内部动作本来就是一团乱麻，按钮文案含糊，状态反馈不清楚，成功条件全靠用户自己猜，权限边界写得很随缘，那你就算接了再新的协议，也只是把混乱包装成了一个新接口。
AI 不会自动让一个混乱的产品变清楚。很多时候，它只是把混乱放大。
对 SEO 团队来说，要开始学会看“动作语义”
我觉得 SEO 团队接下来要补一个新视角：动作语义。以前我们看一个页面，主要看标题、结构、关键词、内链、schema、内容覆盖、搜索意图、页面速度、可索引性。这些还是要看。
但如果一个页面本身承载任务，你还要继续看它的动作语义是不是清楚。用户来到这个页面，到底能做什么？页面有没有把这个动作讲清楚？输入条件是不是明确？结果是不是可验证？状态变化是不是能被确认？失败之后有没有明确反馈？有没有必须由人确认的关键节点？
这些问题过去更像产品体验检查。以后它们可能会变成 agent 可用性检查。
举个很简单的例子。
一个页面上写着“开始优化”，人类用户大概能结合上下文猜出来是什么意思。但 agent 未必知道这个动作背后到底会发生什么。它是生成建议，还是直接修改内容？是只保存草稿，还是发布到线上？是免费操作，还是会消耗额度？
对用户来说，这些差异很大。对 agent 来说，这些差异更大。所以未来的好页面，可能不只是给人一个漂亮按钮，还要把动作边界讲清楚。这不是让页面变啰嗦，而是让产品语义更稳定。
SEO 团队如果能提前参与这件事，会很有价值。因为 SEO 本来就擅长把复杂产品翻译成用户能理解的语言。只是以前翻译给搜索引擎和用户看，未来还要翻译给 agent 看。
这件事最容易写假的地方
我也说一下这个题最容易被写假的地方。
第一，是把 WebMCP 写成已经落地的大趋势。这不准确。它现在还早。规范还在草案阶段，浏览器实现也在早期预览。未来会怎么演进，哪些浏览器支持，哪些 AI 平台真正采用，站点愿不愿意配合，都还有不确定性。所以这篇文章不能写成“WebMCP 马上颠覆 SEO”。那是标题党。
第二，是把“可调用度”写成某个单一协议决定的事。这也不准确。就算没有 WebMCP，agent 也会通过浏览器自动化、传统 API、后端 MCP、插件、私有集成等方式调用网站和服务。WebMCP 的意义在于，它尝试把网页前端能力这件事标准化、结构化、Web 平台化。它是一个信号，不是唯一答案。
第三，是把 SEO 写成马上要变成工程岗位。没必要这么吓人。SEO 不会因为 agent 出现就消失，也不会所有 SEO 都要去写 JavaScript tool。更现实的变化是，SEO 和增长团队要更懂产品任务，更早参与信息架构和能力表达，而不是只在页面上线后改标题、补文案、塞 FAQ。
第四，是把所有网站都塞进同一个框架。内容站、工具站、电商站、SaaS、社区、媒体、B2B 服务站，它们被 agent 调用的路径完全不同。一个资讯站更重要的是可引用，一个工具站更重要的是可调用，一个交易站还要考虑权限、库存、支付和责任边界。把这些差异抹平，文章就会变成漂亮废话。
普通创业者现在该做什么
如果你是一个普通创业者，或者手里有一个小型 WebApp，我觉得你现在不用焦虑，但可以提前做几件很实在的事。
先把你的页面分成两类：内容页和任务页。内容页负责解释、教育、证明、获得引用。任务页负责让用户完成动作。然后再看任务页：你的核心任务是不是足够清楚？用户第一次来，能不能知道这里能做什么？按钮背后的动作有没有歧义？表单输入有没有清晰说明？执行结果有没有明确反馈？用户能不能撤回或修改？
这些事情听起来不酷，但非常基本。再往前一步，你可以列一个“未来适合 agent 执行”的任务清单。不是所有任务都适合。
适合的通常有几个特点：步骤相对标准，输入可以结构化，结果可以预览，失败成本可控，最后可以交给用户确认。
比如生成草稿、筛选候选项、生成报告、检查问题、推荐配置、整理数据，这些都比较适合。
不适合的任务也要标出来。比如直接扣费、删除关键数据、发布不可逆内容、提交法律责任很重的文件，这些都不应该随便交给 agent 自动执行。
你看，这已经不是单纯 SEO 了。但它会影响未来的获客。因为当 AI 入口越来越强，用户不是只问“哪家产品好”，还会问“帮我直接把这件事做掉”。谁的产品能更自然地进入这个执行链路，谁就多了一层机会。
这才是我觉得 WebMCP 值得盯的原因
所以回到最开始的问题。WebMCP 和 AI Agent，会不会成为下一层 SEO？
我的判断是：WebMCP 自己未必会单独成为“下一层 SEO”，但它代表的方向，很可能会成为下一层 SEO 的重要组成部分。这个方向就是：网页从被阅读的对象，变成可以协作的工具。更具体一点，是从可见度，到可引用度，再到可调用度。
今天大家还在争 GEO 到底是不是新东西，AEO 是不是 SEO，llms.txt 有没有用，schema 会不会提高 AI 引用率。
这些问题都可以讨论。但我觉得更值得提前想的是：如果 AI 未来真的开始替用户执行任务，你的网站准备好被它调用了吗？
这里不该让它随便点按钮、猜页面、绕过用户控制。更合理的方向是在用户授权和确认的前提下，让它更稳定地理解你能做什么，怎么做，做到哪一步必须停下来问人。
这件事如果走实，SEO 的边界会继续扩大。它会从内容生产，走向证据建设，再走向产品能力表达。
这对很多只会追热点词的人来说，可能不是好消息。因为以后想吃到 AI 搜索和 agent 入口的红利，光会改标题、写 FAQ、堆长文，可能不够了。
但对真正做产品的人来说，这是一个好消息。因为你的网站不再只是一个等待被点击的页面。它可能变成一个能被 AI 带着用户一起使用的工作台。
这也是我为什么觉得，这个话题值得继续盯。
别只盯着 AI 会不会引用你。下一步，它可能要直接调用你。
当然，前提是你真的有值得被调用的东西。这句话不好听，但很重要。AI 时代不会凭空奖励一个空心网站。它只会把真正清楚、有用、可信、可执行的东西，放到新的入口里重新分发一遍。
至于你的网站在那一刻是内容资产、证据资产，还是能力资产，就看你今天怎么搭了。
参考资料
- WebMCP Draft Community Group Report：https://webmachinelearning.github.io/webmcp/
- Chrome for Developers: An early preview of WebMCP：https://developer.chrome.com/blog/webmcp-epp
