让博客对 Agent 友好

最近对这个博客做了一次改造，目标是让它对 AI agent 友好。改造本身不大，半天就做完了，但背后的思考值得记录。

为什么要改造

过去一年，我花大量时间研究和构建 AI agent。从最基础的模型调用，到工具链设计，到多步骤推理系统，踩了很多坑，也积累了不少判断。这个过程让我形成一个越来越清晰的认识：agent 正在成为互联网的新用户。

传统的 Web 是为人设计的。人打开浏览器，从上往下阅读，点链接跳转，用眼睛扫描页面找到想要的信息。HTML、CSS、JavaScript、视觉布局，整个技术栈都围绕「人看屏幕」这个假设。

但 agent 不是这样消费信息的。它不看布局，不点链接，不「浏览」。它解析结构、提取语义、执行程序化操作。当一个 agent 访问你的网站，它需要的是：这里有什么内容、每篇讲什么、怎么找到和用户问题最相关的部分。它需要的是索引和语义，不是视觉设计。

当前大多数网站对 agent 来说基本是黑箱。这个博客之前也是。HTML 页面里混杂着 CSS 样式、JavaScript 脚本、导航栏、面包屑、页脚，agent 要从这些噪音里提取正文，就像从一杯咖啡里挑出糖粒。能做，但低效。

更深层的问题是：Web 的信息发现机制是为搜索引擎设计的。sitemap.xml 告诉爬虫「这里有这些 URL」，robots.txt 告诉爬虫「哪些能访问」。但 agent 需要的不是 URL 列表，而是内容的语义地图。这里有什么主题，每篇文章的核心观点是什么，哪些内容之间有关联。

这次改造就是为了解决这个问题。

做了什么

改造分三层，从简单到深入。

llms.txt：给 agent 一张地图

llms.txt 是 fast.ai 创始人 Jeremy Howard 在 2024 年提出的标准，目前已被 Anthropic、Cloudflare 等公司采纳。它的思路很简单：在网站根路径放一个纯 Markdown 文件，用人类和 LLM 都能理解的格式，描述站点的结构和关键内容。

这个文件的作用类似 robots.txt，但面向的是 agent 而不是爬虫。robots.txt 说「哪些能访问」，llms.txt 说「这里有什么值得关注的」。

我的 llms.txt 里放了什么：站点描述、所有文章的链接和一句话说明、结构化数据 API 的入口、RSS 和 Sitemap 的链接。Agent 访问 fanshikun.com/llms.txt 就能快速建立对整个站点的认知，决定要深入看哪些页面。

这个文件在构建时自动生成，内容来自每篇文章的 frontmatter。每发布一篇新文章，llms.txt 就会自动更新。

Markdown 端点：去掉噪音

第二层是为每篇文章生成 Markdown 版本。访问 /model-first-then-agent/index.md 会拿到干净的 Markdown 文件，没有 HTML 标签、没有 CSS、没有导航栏。

实现方式是在构建时为每篇文章生成一个 index.md 文件，放到对应的 dist 目录里。文件顶部包含标题、日期、摘要、关键词等元数据，正文来自构建过程中已处理的数据，模板变量已替换，相关文章已解析为链接。生成的是静态文件，不需要额外的 server 路由。

Agent 拿到的是干净的、结构化的内容。标题是标题，段落是段落，引用是引用，链接是链接。没有需要过滤的噪音。

结构化内容 API：程序化的入口

第三层是在构建时生成一个 JSON 索引文件 /api/posts.json。它包含站点元数据和所有文章的结构化信息：标题、发布日期、摘要、标签、URL、关联文章。

Agent 可以通过一次请求拿到全站内容的完整索引，然后根据用户的问题，决定要获取哪篇文章的完整内容。这比从 HTML 首页解析文章列表高效得多，也准确得多。JSON 是程序化消费的最佳格式，没有歧义。

改造背后的思考

做完这些技术改动后，我重新想了一下：这到底在解决什么问题？

答案是：Web 的消费模式正在从「人类阅读」扩展到「agent 程序化访问」。这不是取代，是新增一层。人类仍然用浏览器看页面，但 agent 需要自己的消费接口。

这个趋势正在加速。微软在 2025 年推出了 NLWeb 项目，核心理念是「每个网站都应该是可对话的」。Agent 可以用自然语言向网站提问，网站返回结构化答案。NLWeb 的每个实例同时也是一个 MCP 服务器，全称 Model Context Protocol。Agent 可以通过标准协议直接调用网站的能力，不需要爬取 HTML。

MCP 正在成为 agent 互联的事实标准。Anthropic 在 2024 年提出，OpenAI、Google、Microsoft 相继采纳。它定义了 agent 和外部工具之间的通信协议。Agent 不需要知道你的网站长什么样，只需要知道你暴露了哪些工具、每个工具接受什么参数、返回什么结果。

这些标准还处于早期。llms.txt 没有被主要 LLM 厂商的爬虫正式采纳，MCP 的生态还在建设中。但方向是明确的：Web 正在从「文档网络」演进为「agent 可编程网络」。现在做准备，比等到标准成熟后再追赶要好。

对 Agent 的理解

我想多聊几句我对 agent 的理解。这不只是技术选型，这是我看待这个领域的方式。

Agent 不是聊天机器人的升级版。聊天机器人回答问题，agent 完成任务。这个区别看起来微小，实际上是根本性的。回答问题只需要理解能力，完成任务需要理解、规划、执行、反馈、纠错的完整循环。

构建 agent 最难的部分不是调用模型，不是写工具链，不是设计记忆系统。这些都有现成的框架。最难的是在具体场景里做判断。哪些步骤应该让 agent 自主决策，哪些必须有人类检查点。模型能力的边界在哪里，什么时候该回退到更简单的方案。工具的粒度怎么定，太粗 agent 用不好，太细会增加出错概率。

这些判断没有通用答案，只能在一个个具体项目中积累。我在这个博客上记录的模型优先原则、渐进式架构、可观测性，都是从实际构建中提炼的经验。

我最近的一个体会是：agent 的价值不在于它能做什么花哨的事，而在于它能把重复的、确定性的工作自动化到什么程度。一个能稳定完成「每天检查三个数据源、生成摘要、发送通知」的 agent，比一个偶尔能写出惊艳代码但经常出错的 agent 有用得多。可靠性是 agent 的第一优先级。

接下来

这次改造是第一步。llms.txt、Markdown 端点、结构化 API 这三件事让博客在当前标准下对 agent 可消费了。

下一步可以考虑的是把博客变成 MCP 服务器，让 agent 通过标准协议直接调用搜索和查询能力。不过这个要看 MCP 生态的实际发展速度，不急。

如果你想构建自己的 agent，或者想让已有的系统对 agent 更友好，可以联系我。这是我最想做的事。

参考来源

相关文章