关于页面 mcp/skills 、插件与 mcp/skills 市场的提议

[crypto-2042]

页面 mcp/skills

当前内置了一些基础的 tools 结合 PageController 来驱动 AI 与页面交互，这里可能还存在几个问题：

1. 站点自带一个 LLM，支持 chat 方式交互，对于站点成本会上升不少。想要拥抱 AI 但奈何实力不允许
2. PageController 来获取页面内容，可能仍存在上下文过多或页面质量不够导致效果不理想

针对这两个问题在 core 侧，有如下建议：

1. 在 core 基础上将 mcp/skills 逻辑抽离出来，使用类似埋点的方式暴露出来，站点可以先把基建做起来
2. 用户安装插件后即可将插件与页面的 mcp/skills 打通，将 AI 成本转嫁给用户

插件与市场

如果仅依赖站点与 page-agent 对 AI 的支持，这将时个漫长的阶段。
有如下建议：

1. 打通只暴露了 mcp/skills 能力的页面
2. 支持从 page-agent 市场安装站点的 mcp/skill
3. 支持在插件端定制自己的站点 mcp/skills
4. 构建针对 page-agent 的 skills-creator 降低站点、社区构建 page-agent mcp/skills 门槛

[gaomeng1900]

感谢提议！

MCP 会是我接下来的重点之一（HTML 清洗优化、MCP、本地模型）。现阶段先给浏览器插件提供 MCP link，让 agent 客户端（例如小龙虾和 claude）能调用浏览器插件。

通过 page-agent 来将站点变成 mcp/skill 是个不错的想法。对站点开发者来说，自己的应用能直接变成独立 skill 接入 agent 客户端，对 page-agent 来说，能成为 WebApp skill 化的标准解决方案。

不过埋点的接入方式我不确定，和 llms.txt 和 accessibility 这些标准有些重复，accessibility 优化本身有类似的效果。

AI 成本目前看来没那么糟糕，方案本身就很节约 token 而且缓存友好，目前 live demo 每天几万次调用 qwen 3.5 flash，成本还不到20快。不知道浏览器内置模型的发展什么时候能达到完全离线使用。

目前作为开源项目运行，做市场这个事情还没思考过，愿闻其详。

[crypto-2042]

埋点的建议是偏体验方面的，让前端在开发时可以便捷的先把为 AI 提供 mcp/skills 的能力做了。具体的我不确定当前的 llms.txt 和 accessibility 是否已经覆盖。

我查询到当前有个 webmcp 的协议在推进，这个项目是否也可以考虑尽早适配，后续不管是插件方案还是浏览器原生，都会用到。

目前整个项目体验下来非常 nice，希望继续做大做强！

[crypto-2042]

👍 我看到开发计划中已经将 mcp 纳入了，继续来补充下 mcp 市场的说明。
针对 web 页面的 mcp，与 anthropic 定义的 mcp 不同，我理解为是继续将 web 页面作为 mcp 资源，而不是再额外架设 mcp server。
页面 mcp 资源是为了让 页面跟 AI 能更轻量、准确的交互。

基于以上设定，mcp 资源目前有两种方式：

1. web 站点自行提供，标准、稳定、理想情况下在这个页面是可靠的
2. 第三方提供（类似油猴脚本的运作方式），使用市场来统一管理

另：我也有在弄一个仅基于 mcp/webmcp 实现的项目，如果有需要可以交流下 page-mcp-plugin

[gaomeng1900]

从外部控制插件的 MCP 已经发布了。

不过我们聊得是 WebMCP，我建议就用 chrome 刚发到 beta 的 WebMCP 概念。

这个概念确实和 page-agent 的定位很搭。Google 看起来是打算把 agent -> chrome -> mcp 的连接层内置了，网站开发者直接在自己网页里对接 chrome 提供的声明式接口。这会增加页面内自动化的需求。

不过他们给的文档好少呀，感觉得参加下他们那个试用活动。