/tags/chrome/ Recent content in chrome on Hugo -- gohugo.io en Thu, 10 Sep 2026 22:30:22 +0800 /posts/hugo-webmcp-agent-tools/ Thu, 10 Sep 2026 22:30:22 +0800 /posts/hugo-webmcp-agent-tools/ 这个博客的 Cmd+K 搜索框背后是一份 /index.json，178 条记录，每条带标题、日期、URL、正文前 500 字、tags 和 keywords。人用得上它，浏览器里的 agent 用不上，因为 agent 不知道这个文件存在。 WebMCP 让页面把这类东西直接声明成 agent 可以调的工具。我这次挂上去 5 个，其中 4 个的数据源就是那份现成的索引，第 5 个读的是当前页的正文。在 meirong.dev 上跑通了，中间有两类问题：一类让 5 个工具一个也注册不上，原因有两个，而且都不报错；另一类是工具注册上了，答出来的数却和读者在站上看到的不一样。 这是个还在 origin trial 里的 API，随时可能变。我写这篇时（2026-09-10），注册页上写的可用范围是 Chrome 149 到 156，结束日期「no later than Nov 17, 2026」。下面所有实测都在 Chrome 152 上做的。 agent 现在只能截图、扒 DOM、模拟点击 先说这套东西冲着什么来的，不然后面的代码看着只是又一个 API。 一个 agent 今天要在网页上做事，手段和人差不多：截图，抓 DOM 和 accessibility tree 的快照，看明白页面长什么样，然后模拟点击和键盘输入。WebMCP 的 explainer 把这类做法归为「已有的网页操作手段」，并且说得挺直白：就算 agent 做成了，简单操作往往也要好几步，慢而且不可靠。原因不难理解，DOM 是给人看的一份渲染结果，不是给程序读的数据模型，页面改版一次，靠视觉位置认出来的「那个按钮」就换了地方。 那为什么不让站点直接提供一个 API 或者 MCP server？explainer 列了三条代价，都是针对交互型 web 应用说的：