我用 Is Agentic 给博客做了一次体检

发布时间：2026-08-22 15:00:00

🕒 阅读时间：4 分钟📝 字数：1479👀 阅读量：Loading...

AI 辅助声明

本文由作者实际操作与 AI 辅助整理完成，评分、页面内容和命令输出均以本次实测结果为准。

前阵子我刚把博客的 llms.txt、Markdown 输出和几个只读 API 折腾了一遍。代码写完、本地 build 也绿了，但我还是有点不放心：这些入口到底是我自己觉得有用，还是 agent 真能找到？传统 SEO 更像是在问“搜索引擎能不能找到我”，这次我想换个问法——AI agent 能不能找到博客，读懂博客，再把里面的内容讲给别人听？

所以我没有继续凭感觉改 meta 标签，而是先给自己的博客 xingwangzhe.fun 做了一次 agentic 体检。

Is Agentic 是什么

它还提供了一个很方便的 CLI：

1
npx is-agentic [domain]

这和我平时打开 Lighthouse 看性能的感觉不太一样。Lighthouse 主要看浏览器性能、可访问性、最佳实践和 SEO；Is Agentic 关心的是，站点作为一个公开资源，能不能被 agent 发现、访问、理解和使用。它也不是 Google Search Console，更不是“测完就能被 Google 收录”的快捷按钮。

官网给出的框架里，Essential 检查占主要分数，Recommended 检查则会根据站点是否暴露 API、OAuth、GraphQL、MCP 或开发者门户等能力来启用。这个设计我比较喜欢：一个博客没有 OAuth，不应该因为没有 OAuth 就被无条件扣分。具体评分边界可以继续看官方的 Methodology，开发者接口则写在 Developer resources 里。

我给 xingwangzhe.fun 跑了一次

我在终端里实际执行了：

1
npx is-agentic xingwangzhe.fun

终端没有给我一句“你的博客很棒”，而是直接甩出一张有点刺眼的成绩单：

1
▲ / Is Agentic  xingwangzhe.fun
2

3
  ██████████████████████░░░░░░░░░░░░░░    61 / 100
4
                                          Important blockers remain
5
                                          8 failed · 7 partial
6

7
SCORE BREAKDOWN
8
  Essential       45.9 / 80    4 / 9 passed
9
  Recommended     11.6 / 20    7 / 17 passed
10
  Bonus                +3.3    15 positive signals
11

12
REPORT
13
  URL      https://is-agentic.com/scan/xingwangzhe.fun
14
  Scanned  2026-08-22T02:25:37.316Z
15
  Checks   26 eligible

看到 61 的第一反应当然是想继续优化，但我很快把这个冲动按住了。它不是博客质量分，也不是搜索排名；对我来说，更像一张“如果我是一个 agent，我会在哪里卡住”的检查单。报告页面的分项结果是 Essential 45.9 / 80、Recommended 11.6 / 20、Bonus signals +3.3。

如果想在脚本里消费结果，也可以使用 JSON 输出：

1
npx is-agentic xingwangzhe.fun --json

关键字段如下：

1
{
2
  "target": "https://xingwangzhe.fun",
3
  "score": 61,
4
  "scanned_at": "2026-08-22T02:25:37.316Z",
5
  "eligible_checks": 26,
6
  "essential": "45.9 / 80",
7
  "recommended": "11.6 / 20",
8
  "bonus": "+3.3"
9
}

agent 是怎样走过我的博客的

这份报告有一段我觉得特别有意思：agent trajectory。它不是只给一个分数，而是把一次观察到的访问过程画了出来。

报告记录的 8 个步骤里，agent 先访问了首页，然后读取 /index.md、/about.md 和 /rss.xml。evaluator notes 还写道，agent 已经收集到足够信息，可以解释 xingwangzhe.fun 的用途、受众和业务模式；站点发布了结构化 metadata 和干净的 Markdown 文件，这让发现过程比较顺利。

这说明我之前给博客加 Markdown 导出和 AI discovery 入口，并不是完全自嗨。至少在这次公开扫描里，agent 确实找到了这些入口，并用它们完成了任务。对一个写博客的人来说，这比首页上多一个漂亮的渐变按钮更有说服力。

不过这里必须刹一下车。agent 能读懂博客，不等于 Google 已经收录博客；报告里的 observed run 成功，也不代表每一个模型、每一个地区和每一种 bot policy 下都能得到同样结果。它描述的是某个时间点、某一次公开访问看到的证据。

报告指出了哪些问题

报告里的失败项和部分通过项，比单独看分数更值得读：

检测方向	本次报告中的实际表现
Agent-friendly 404	部分通过，真实 404 存在，但缺少更适合 agent 恢复的 Markdown 说明
Content without JavaScript	部分通过，首页有 H1 和可读内容，但标题层级较扁平
OpenAPI	未检测到
JSON error responses	未检测到
Markdown content negotiation	未通过，报告指出 `Accept: text/markdown` 与 `Vary: Accept` 仍存在问题
Developer resource discoverability	未通过，agent 没有找到足够明确的开发者资源
When-to-use guidance	未通过，`llms.txt` 没有被识别为明确的使用指引
Content efficiency	未通过，可读文本约占 HTML 的 `0.43%`，报告记录为 709 个字符对应 161 KB HTML
JSON-LD	部分通过，报告建议补充 `url`、`sameAs` 或 `jobTitle`

有几项看上去和我之前刚发布的 Stalux 1.25.1、1.25.2 改动矛盾：我已经在源码里加过 /openapi.json、developer resources、when-to-use 说明和 Markdown 响应头，但这个报告的扫描时间是 2026-08-22T02:25:37.316Z，它不一定已经看到后续部署的内容。

这正好提醒了我：优化源码、发布 npm、更新 myblog、推送 GitHub 和线上站点实际生效，是五件不同的事。不能因为本地 build 成功，就把线上扫描结果当成已经更新。

我也不会为了让分数好看，给一个个人博客硬塞不存在的 OAuth、MCP 或商业 API。报告给的建议要结合站点真实能力来处理；如果博客本来就是静态文章站，优先修复公开内容、错误页、Markdown、结构化数据和资源发现，比虚构一套 API 更靠谱。

它为什么适合做 GEO 和 AI 索引优化

我不太喜欢把 GEO 说成一套神秘的“让 AI 推荐你”的玄学。落到工程上，它还是一些可以检查的事情：页面有没有真正的文字内容，agent 能不能通过稳定 URL 找到文章，有没有明确的 Markdown 或 JSON 入口，404 能不能告诉它下一步去哪，JSON-LD 是否足够完整，页面是不是塞了太多 agent 不需要处理的 markup。

所以我觉得它比较适合下面几类人：

读者	适用原因
独立博客作者	检查 AI 是否能直接读懂博客用途、关于页和文章入口
做 GEO 的开发者	从 agent 可访问性、机器可读接口和结构化内容角度定位问题
有 API 或 MCP 的项目维护者	验证 OpenAPI、工具说明和 function-calling 相关入口
使用 Astro、Next.js 或静态站点的人	检查 SSR、HTML 文本密度、Markdown 和错误页行为

Is Agentic 给我的感觉是，它把这些问题整理成了一份外部体检报告。它的报告比我自己凭感觉扫一眼页面更有结构，尤其是 agent trajectory 和每个 finding 的 evidence，让“我觉得 AI 应该能看懂”变成了可以继续验证的假设。

这也是我愿意推荐大家试试它的原因。它背后显示的是 Vercel 和 Ora，官网的报告、方法说明和开发者页面也都公开；从产品可信度和信息完整度看，我认为它值得作为 GEO 优化的一个起点。它的报告比我自己凭感觉扫一眼页面更有结构，也比“我在首页加了几个 AI 关键词，应该有用吧”可靠。

但“值得作为起点”不等于“它就是行业标准”，更不等于它能代替搜索引擎站长工具、性能测试、无障碍测试和安全审计。

使用时要注意什么

报告页面会显示扫描时间，Is Agentic 的官方说明也提醒，报告是某个公开 URL 在某个时间点的快照。站点部署状态、CDN、bot defenses、地理位置和检测方法改变后，分数都可能变化。我这次就遇到了一个很具体的坑：源码里已经加入 OpenAPI、developer resources 和 Vary: Accept 等改动，但报告的扫描时间早于这些线上变化，CLI 读到的仍然是旧快照。已经修复问题时，需要从首页重新扫描同一个 URL；CLI 在有旧报告时可能直接读取已有报告，不一定会强制启动新扫描。

我建议把报告当成一个排序工具。先看 Essential，再看和自己真实业务有关的 Recommended；对于一个普通博客，OpenAPI、OAuth、MCP 这些项目不应该为了凑分数而伪造。修复之后还要单独检查线上 headers、HTML、Markdown endpoint、sitemap 和 canonical，最后再看新报告有没有真正拿到新的扫描快照。

还有一个容易混淆的点：Is Agentic 检测的是 agent readiness，不是 Google indexing。它可以告诉我 AI agent 访问博客时遇到了什么问题，但不能保证文章会出现在 Google、Bing 或任何特定模型的回答里。

结尾：先测一次，再决定怎么改

我原本只是想知道自己的博客是不是“对 AI 友好”，跑完之后得到的不是一句泛泛的“还不错”，而是一张具体的改进清单：哪些入口已经被 agent 找到，哪些响应还不够机器友好，哪些优化已经写进源码但线上还没有被看到。更重要的是，我终于知道下一次 build 之后应该检查什么，而不是继续盲目堆功能。

如果你也在做个人博客、文档站、API 服务或 GEO 优化，可以从 Is Agentic 首页开始，提交自己的域名；也可以先看看我这次的 xingwangzhe.fun 检测报告。官方的 Methodology 解释评分边界，Developer resources 则介绍报告 API、Markdown content negotiation 和 MCP 入口。

对我来说，这次体检最有价值的地方不是 61 这个数字，而是它让我把“AI 能不能理解我的博客”拆成了一组可以实际动手检查的问题。先测一次，再决定怎么改；至少比凭感觉堆几个关键词踏实。

我用 Is Agentic 给博客做了一次体检

作者：xingwangzhe

本文链接：https://xingwangzhe.fun/posts/is-agentic-blog-check/

本文采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。