I built it twice. Didn't place twice. Then Google and Vercel shipped it.
I built it twice. Didn’t place twice. Then Google and Vercel shipped it.
我做了两次,两次都没获奖。然后 Google 和 Vercel 发布了它。
A you.com rep said it at a hackathon kickoff in March. The web has a second audience now. The first one is people. The second is machines. When you ask ChatGPT or Perplexity something, the retrieval crawler behind it fetches your page and reads the markup that comes back. Not the site as a browser would draw it. The markup. That second audience idea really stuck with me. Then it fired me up. So I went and built a thing about it. I knew I could improve on it, so I built the thing again, better. Both times I submitted to a hackathon. Neither one placed. 一位 you.com 的代表在三月份的黑客马拉松启动仪式上说过:现在的网络有了第二个受众。第一个是人类,第二个是机器。当你问 ChatGPT 或 Perplexity 问题时,其背后的检索爬虫会抓取你的页面并读取返回的标记语言(markup),而不是浏览器渲染后的样子。就是那些标记语言。这个“第二个受众”的想法深深触动了我,并让我热血沸腾。于是我动手做了一个相关的东西。我知道我还能做得更好,所以我又做了一次,效果更好。两次我都提交给了黑客马拉松,但都没能获奖。
On May 7, Google shipped an Agentic Browsing category in Lighthouse. On August 21, Vercel and Ora launched is-agentic.com. That makes four tools now, counting my two, all pointed at the same question: can an agent use this site? Same question, three answers, and we do not agree on what counts as an agent seeing your page. 5 月 7 日,Google 在 Lighthouse 中发布了“代理浏览”(Agentic Browsing)类别。8 月 21 日,Vercel 和 Ora 推出了 is-agentic.com。算上我做的两个,现在总共有四个工具,它们都指向同一个问题:代理(Agent)能使用这个网站吗?同一个问题,三个答案,而且我们对于“代理如何看待你的页面”并没有达成共识。
Hermes was a CLI wearing an agent costume
Hermes 是披着代理外衣的命令行工具
My first build, Hermes Clew, was for the GitLab Duo Agent Platform Challenge. A Python engine that walked the HTML, JSX, and TSX files in a repo, scored six categories out of 100, and let Duo Chat reason over the findings. It worked. I still like the bones of it. It also missed the assignment in two ways I did not see at the time. It read files, not pages. A repo is not what an agent meets. An agent meets a URL. And it told you how to fix things. Ranked fixes, effort estimates, code samples. I wrote that in because it felt more helpful. I did not place, and by the time I understood why the fixes bothered me, I was already rebuilding. 我的第一个作品 Hermes Clew 是为 GitLab Duo Agent 平台挑战赛准备的。它是一个 Python 引擎,可以遍历仓库中的 HTML、JSX 和 TSX 文件,对六个类别进行百分制评分,并让 Duo Chat 对结果进行推理。它成功了,我至今仍喜欢它的架构。但它在当时有两个我没意识到的失误:它读取的是文件而非页面。代理面对的不是仓库,而是 URL。此外,它还告诉用户如何修复问题——包括修复建议排名、工作量预估和代码示例。我加入这些功能是因为觉得这样更有帮助。我没能获奖,而当我意识到为什么这些修复建议让我感到困扰时,我已经开始重构了。
Findings are the first floor, not the whole building
发现问题只是第一层,而非整栋建筑
My second attempt, Agentis Lux, runs on the Perseus Clew engine and takes a live URL instead of a repo. Six deterministic checks, raw HTML, no JavaScript executed, because that is what a retrieval crawler gets. I wrote about the build in My website has two audiences now and the shipped version in Can retrieval agents read your website. Hermes Clew told you how to fix things. Agentis Lux does not. That is the change I care about most, and it is the one that reads like a missing feature. 我的第二次尝试 Agentis Lux 运行在 Perseus Clew 引擎上,它接收的是实时 URL 而非仓库。它包含六项确定性检查,读取原始 HTML,不执行 JavaScript,因为这就是检索爬虫所获取的内容。我曾在《现在的网站有两个受众》中写过这个构建过程,并在《检索代理能读取你的网站吗》中介绍了发布版本。Hermes Clew 会告诉你如何修复,但 Agentis Lux 不会。这是我最在意的改变,尽管它看起来像是一个缺失的功能。
I think findings sit at the bottom of a pyramid. A finding is a fact about what an agent could not do. A fix is a decision about someone’s codebase, made by someone who has never seen it, with no idea what the constraints were or who is on call for the regression. Shipping the first fix a model produces seems reckless to me. Maybe I am too cautious. I am also aware enough to know I am not the expert on your code. I run my own sites through it. It tells me a heading is unreadable to a crawler, and then it stops, and part of me wants the paragraph that says what to type instead. I shipped it without that anyway. I got the same lesson from the opposite direction when Kiro and Claude delivered exactly what I asked for and it wasn’t what I wanted. Confident output is not the same as correct output as I keep learning over and over! 我认为“发现问题”处于金字塔的最底层。发现问题只是关于“代理无法做什么”的事实。而修复建议则是对他人代码库的决策,由一个从未见过该代码库、不知道约束条件、也不知道谁负责处理回归问题的人做出。直接发布模型给出的第一个修复方案在我看来是鲁莽的。也许我太谨慎了,但我也有自知之明,知道我不是你代码的专家。我用自己的网站测试它,它告诉我某个标题爬虫无法读取,然后就停止了。我内心深处确实想要它直接给出修改建议,但我最终还是没加这个功能就发布了。当 Kiro 和 Claude 完全按照我的要求交付,却给出了我并不想要的结果时,我从反方向学到了同样的教训:自信的输出并不等于正确的输出,这一点我一直在反复学习!
Google decided not to give you a number
Google 决定不给你打分
Lighthouse 13.3 shipped on May 7, 2026 with a category called Agentic Browsing. Four checks: an llms.txt file, which is a proposed text file that tells AI agents what your site is about; WebMCP, which lets a page advertise tools an agent can call; the agent-relevant slice of the accessibility tree; and cumulative layout shift. The interesting part is the scoring, or the refusal of it. The category does not produce a weighted average from 0 to 100. Because the standards for the agentic web are still emerging, the stated focus is gathering data and providing actionable signals rather than a definitive ranking. You get a pass ratio. Google marked the whole category experimental and under development. That is a restrained choice from the company that made everyone care about a 0 to 100 performance score, and I respect it.
Lighthouse 13.3 于 2026 年 5 月 7 日发布,新增了“代理浏览”类别。包含四项检查:llms.txt 文件(一种提议的文本文件,用于告诉 AI 代理你的网站是关于什么的)、WebMCP(允许页面声明代理可以调用的工具)、可访问性树中与代理相关的部分,以及累积布局偏移(CLS)。有趣的是评分机制,或者说他们拒绝评分。该类别不会产生 0 到 100 的加权平均分。由于代理网络的标准仍在形成中,其重点在于收集数据和提供可操作的信号,而非给出最终排名。你得到的是一个通过率。Google 将整个类别标记为实验性和开发中。对于一家让全世界都关注 0 到 100 性能评分的公司来说,这是一个克制的选择,我对此表示敬意。
The measurement model underneath is a different animal from mine. Lighthouse calls the Chrome DevTools Protocol WebMCP domain to watch tool registration, verifying both declarative tools defined in HTML and imperative ones defined in JS, and it filters a subset of accessibility audits that matter for machine interaction, because agents rely on the accessibility tree as their primary data model. That is a requirements list. It needs Chrome. It needs JavaScript to run. It needs the page to register tools at runtime. That is an agent driving a browser. A retrieval crawler does a fetch and parses what comes back. No Chrome, no hydration, no registered tools. So Lighthouse and Agentis Lux can look at the same URL and produce two defensible readings, because we are not looking at the same artifact. Lighthouse reads the rendered page. I read the response body. 其底层的测量模型与我的完全不同。Lighthouse 调用 Chrome DevTools Protocol 的 WebMCP 域来监视工具注册,验证 HTML 中定义的声明式工具和 JS 中定义的命令式工具,并筛选出对机器交互至关重要的可访问性审计子集,因为代理依赖可访问性树作为其主要数据模型。这是一个需求列表:它需要 Chrome,需要运行 JavaScript,需要页面在运行时注册工具。这相当于一个代理在驱动浏览器。而检索爬虫只是进行抓取并解析返回的内容——没有 Chrome,没有水合(hydration),没有注册工具。因此,Lighthouse 和 Agentis Lux 可以查看同一个 URL 并得出两个都站得住脚的结论,因为我们观察的对象不同。Lighthouse 读取的是渲染后的页面,而我读取的是响应体。
There is a second split hiding in those four checks. llms.txt and WebMCP are things you add. A file you publish, a tool you register. They measure whether you opted into a proposal. Semantic HTML and the accessibility tree are things your site already is or is not. Two of the four checks reward adoption. Two reward construction. DebugBear says llms.txt is not currently widely adopted by AI services and calls the practical benefit of adding one doubtful. The evidence underneath that is an Ahrefs study of 137,210 domains: 28% published a valid llms.txt, and 97% of those files got zero requests in May 2026. No AI bot went looking for one that did not exist. I build for the second kind. Not because adoption is wrong, but because I can only measure what is there. That is also why the Agentis Lux engine, Perseus Clew, does not run JavaScript. Two reasons, and I wrote them into the architecture doc under a NEVER list before I wrote the scanner. The product reason is that a retrieval crawler does not run it either, so rendering the page would mean scoring an artifact my reader never sees. The engineering reason is plainer: a headless browser in a Lambda means cold starts and memory I did not want to pay for on a free public scan. What I did do was leave the door open. The score is not a bare field in the…
在这四项检查中还隐藏着第二个分歧。llms.txt 和 WebMCP 是你需要主动添加的东西——一个你发布的文件,一个你注册的工具。它们衡量的是你是否选择了加入某项提议。而语义化 HTML 和可访问性树则是你网站本身具备或不具备的属性。四项检查中有两项奖励“采用”,两项奖励“构建”。DebugBear 表示 llms.txt 目前并未被 AI 服务广泛采用,并质疑其添加后的实际收益。其背后的证据是一项针对 137,210 个域名的 Ahrefs 研究:28% 的域名发布了有效的 llms.txt,而其中 97% 的文件在 2026 年 5 月收到的请求数为零。没有 AI 机器人会去寻找一个不存在的文件。我为第二种情况而构建,不是因为采用新技术是错的,而是因为我只能测量已存在的东西。这也是 Agentis Lux 引擎 Perseus Clew 不运行 JavaScript 的原因。有两个原因,我在编写扫描器之前就将它们写进了架构文档的“禁止事项”列表中。产品层面的原因是检索爬虫也不运行 JS,所以渲染页面意味着在评分一个我的读者根本看不到的产物。工程层面的原因更简单:在 Lambda 中运行无头浏览器意味着冷启动和内存开销,我不想在免费的公共扫描服务中支付这些费用。但我确实留下了扩展空间。评分并不是一个空字段……