关于页面 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，希望继续做大做强！