Agent 时代的博客（一）：社区已经在做什么

上一篇文章我说这个博客本身是实验品。动手之前，我先花了些时间看社区里有没有人做过同样的事——结论是：有，而且比想象中多。这一篇把看到的整理出来，顺便修正我原来的改造计划。

按成熟度分四个方向说。

方向一：静态文件协议层（已成事实标准）

这是最成熟的一层。核心是 llms.txt——一个类似 robots.txt 的新标准，2024 年提出，目前已被 84 万+站点采纳，包括 Anthropic 自家文档站。格式极简：一个 H1 标题、一段 blockquote 简介、一组带描述的链接。Perplexity 和 Claude 已确认会主动抓取它。

和我们技术栈相同的参考实现有两个，都值得看：

1. SSHeRun：做一个对 Agent 友好的博客（Astro，中文）。他构建时自动生成一套”六件套”：

   • llms.txt：站点说明书（介绍 + 全部文章的标题/链接/摘要 + 导航）
   • llms-full.txt：全部文章的完整 Markdown 聚合，Agent 一次请求拿走全站
   • 每篇文章的 .md 纯文本端点（如 /blog/hello-world.md）
   • 每篇文章 HTML 里的 Schema.org BlogPosting JSON-LD
   • 常规的 robots / rss / sitemap
   • HTML head 里的 <link rel="help" href="/llms.txt"> 发现入口

   全部由 Astro 内容集合在构建时生成，新发文章自动更新，零维护。他的口号：「不要展示自己，部署自己。」

2. vanzan01 的踩坑记录。他想做得更优雅：同一个 URL 按 Accept 头做 content negotiation，浏览器拿 HTML、Agent 拿 Markdown。结果在 Cloudflare Pages 上跑不通——纯静态站没有 SSR，Functions 不执行。最终接受 .md 后缀约定。这个坑直接适用于我们：静态优先，别碰 content negotiation。

另外一个值得记的细节：Trivedi 对 robots.txt 做了 AI bot 分策略管理——放行搜索类 bot（Claude-SearchBot）和代访类 bot（Claude-User），区别对待训练爬虫。“边界声明”不是一句允许所有，而是可以精细到 bot 类型。

方向二：可查询接口层（最活跃，模式已收敛）

社区现在收敛出了两种模式：

模式一：NLWeb 式双端点。微软的 NLWeb 把”站点可查询”标准化为两个端点：/ask 给人类（对话 UI），/mcp 给 Agent（MCP 协议）。一套内容，两种接口。

模式二：一份索引、多个出口。cubxxw 用一队 Agent 重组了 120 篇文章的博客，这篇文章是我这次调研里信息量最大的一篇：

• 核心架构是一份 content-index.json，同时喂三个出口：站内 AI 问答、首页数字分身、对外 MCP server
• MCP server 是零依赖单文件（scripts/mcp-server.mjs），只暴露 search_blog 和 get_blog_post 两个工具，任何 MCP 客户端（Claude、Cursor、ChatGPT 桌面版）配一行就能检索他的全部文章
• 工作流是”写新文章 → 跑索引脚本 → 三个出口同时更新”。他的原话：「一条管道开三个龙头，而非每个功能各拉一条管道」

轻量实现也很多：blog-mcp 是本地只读 MCP server，同步文章后用本地 embedding 索引；Mofei 的方案用 Cloudflare + AI SDK 暴露三个 tool（搜索、列表、正文），让 Agent 通过 tool calling 消费博客。

cubxxw 的几条教训也值得抄在系列备忘录里：

• AI 的 bug 不红屏——它会安静地输出错误结果且测试全绿，所以每个模块必须回答”出问题我怎么知道”
• 长链条成功率是乘出来的——单步 95% 的把握，20 步连乘只剩 1/3
• 签字权不外放——AI 可以观察、建议、开 PR，merge 永远由人完成

方向三：内容信任层（共识有了，标准还散）

这层有个重要结论：“检测 AI 文本”这条路基本被证伪了。行业共识在转向”过程可验证”——不做事后检测，而是让真实性在创作流程里可验证：签名、manifest、哈希锁定（Why AI detectors cannot prove authorship）。

标准方面，C2PA / Content Credentials 是最成体系的，但主要落地在图像和视频；GEO 圈在推内容溯源 + 数字签名，让生成引擎能验证”谁写的、何时发布、是否被改过”。

关键是：个人博客层面，这层几乎没人认真做。这是四个方向里社区最不充分的——上一篇文章里”观点演变史 / 修改留痕”的想法正好卡在这个空位上。

方向四：GEO 写作方法论（内容侧，非工程侧）

2026 年的生成式搜索优化已经从玄学变成有 A/B 数据的实践：

• 开头直答（answer capsule）：每节第一句给结论，别让模型挖三段才找到重点
• H2/H3 用问题式标题，AI 可直接引用到小节
• 2000 字以下的文章很少被引用；交叉引用密度影响被引率
• 站外背书比投放有效：非商业来源在 AI 引用里占主导

本质上就是上一篇文章说的”观点密度 > 篇幅”，但现在有了可操作的清单。

修正后的计划

调研之后，原来的五步路线图需要改一处架构决策：

先建统一数据层，再长出口。 cubxxw 验证过的”一份索引多个出口”是对的：llms-full.txt、.md 端点、JSON-LD、未来的 MCP server，不应该各做各的拼接，而是从同一份构建时索引生成。修正后的路线：

1. 统一内容索引 + 静态协议层：构建时生成 content-index.json，从它长出 llms.txt / llms-full.txt / .md 端点 / JSON-LD
2. 观点时效与演变史：modDatetime 真实化 + 修改记录——社区空白，系列的原创主张
3. 可查询接口：基于同一份索引，先做 MCP server（零依赖单文件，成本最低收益最直接），站内问答看情况
4. 信息架构与慢阅读：人类侧的反向优化

引用先行者的文章本身也是 GEO 实践——这篇就是第一个示范。