最近在用 Agent 写代码的时候想到一个问题：我天天让 Agent 替我读文档、翻资料，那我的博客被谁读？
答案是：越来越少的人类，和越来越多的 Agent。人类读者说「帮我看看他怎么看 X」，然后 Agent 替他来。这个变化会从头改变博客该有的样子，而这个博客本身，就是这个系列的实验品。
一个核心判断
博客的本质会从「发布页面的地方」变成「可被调用的个人服务」：
- 访客构成变了：大部分”访客”是 Agent，代表人类来访
- 用户角色变了：从读者变成委托人，浅层消费全部委托出去，亲自阅读只留给深度内容
- 内容单位变了：从文章变成可引用的观点原子（claim），文章只是容器
- 交互界面变了：时间轴退居二线，查询和对话成为第一入口
- 作者角色变了：从写作者变成知识库的策划人
Agent 要什么，人类要什么
Agent 不是一个模拟人类点击的爬虫，它的诉求完全不同：
| Agent 访客 | 人类访客 | |
|---|---|---|
| 想要 | 查询、引用、验证 | 深读、沉浸、和作者连接 |
| 痛点 | 拿不到精确锚点、无法验证可信度和时效 | 信息流噪音、被推荐算法淹没 |
| 需要的设计 | 结构化接口、引用粒度、观点演变史 | 慢阅读排版、无侧边栏、长文优先 |
有意思的地方在于：这两套需求不冲突，反而互补。Agent 拿走所有浅层访问之后，人类亲自阅读反而变得更纯粹——就像电视普及后纸质杂志活成了另一种东西。
这个系列的玩法
每篇文章做两件事：一个判断 + 一次改造。判断可能错，改造一定真实落地在这个站上。文章里讨论的每个想法，读者都能在同一个 URL 上看到它被实现（或被证伪）。
初步路线图，顺序可能调整：
- 元数据与可引用性 — JSON-LD、llms.txt，让 Agent 拿到干净的结构化内容
- 观点时效与演变史 — 显式更新时间、修改记录，观点的 git 化
- 引用粒度 — claim 级锚点，让 AI 引用精确到段落
- Agent 入口 — 查询/问答接口，把 Pagefind 从人类搜索变成 Agent 问答
- 反向优化人类阅读 — 信息架构从时间轴走向知识地图，慢阅读模式
调研了社区实践之后（见系列第二篇），路线图修正为 4 步：核心变化是先建统一内容索引，再长出口——llms.txt、.md 端点、JSON-LD、未来的 MCP server 全部从同一份构建时索引生成，避免四次拼接。“引用粒度”并入元数据层，“Agent 入口”提前到慢阅读之前（成本比预想低，社区已有成熟模式）。
关于实验品本身
你正在看的这个「栏目」页面，就是系列的第一个改造产物——在这之前，这个站只有按时间倒序的文章流和标签，没有任何”系列”的概念。栏目机制加了 series frontmatter 字段、/series 路由和导航入口，一共几十行代码。
这大概就是整个系列想验证的事：改造一个传统博客，从”给 Agent 加适配层”开始，最终长成一个和现在完全不同的东西。走到哪一步算哪一步，每一步都有记录。
系列目录在 /series/agent-era-blog。