为什么“让 agent 读书”不能只做 summary。
最近花了一些时间做 book-reader skills。
最开始的想法很朴素：我想让 agent 帮我读书。
很快发现，“读一本书”很容易被理解成：
给我一份 summary。
除了“这本书讲了什么”，我更想知道：
- 作者想解决什么问题？
- 这本书的核心概念是怎么搭起来的？
- 章节顺序背后有没有设计？
- 哪些例子是关键支撑，哪些只是辅助说明？
- 哪些判断来自原文，哪些是读者推断？
- 如果以后我要继续深读，应该从哪里开始？
换句话说，我想要的是一个可以继续工作的知识框架。
为什么还要读书
这里其实有一个更底层的问题：
现在 LLM 已经很强了，为什么还要让它参考书？
直接问模型会漏掉什么？
把文本丢进去，或者简单做个 RAG，又会漏掉什么？
我后来觉得，book-reader 的初衷主要有两个。
第一，知识索引。
我的目标超过把一本书塞进上下文临时读取，也超过让 RAG 在需要时找几个相关片段。
这些方法当然有用，主要还是在“调用文本”。我想把一本书整理成 agent 后续可以反复使用的理解结构。
比如：
- 概念系统
- 论证路径
- 关键证据
- 作者的问题意识
- 章节功能
- 读者路径
- 风格线索
- 未解决问题
如果是小说, 可能还包括:
- 人物性格
- 成长经历
- 弧光塑造
- 社会关系
等等。
这比普通 summary 更重，也比简单检索更结构化，可以让一本书变成可索引、可追溯、可审查、可继续推进的知识工作区。
第二，反庸俗。
LLM 的默认输出很容易滑向高概率文本。
它会很流畅，很稳妥，也很通用。
很多时候，它也会变得平均、圆滑、没风格。
一本好书往往带着明显的非平均特征。
它有自己的问题意识、结构选择和表达习惯。
从统计学的角度看，参考书是给模型一个更强、更具体、更不平均的外部先验。LLM 的训练文本会让输出概率偏向平庸，实际使用时，我们期待更风格化、更具体、更有判断力的结果。
我希望 agent 读书之后，能借用这本书的结构、节奏、风格和判断方式。
这也是 book-reader 需要超过 summary 的原因。
summary 很容易把独特文本压平成普通套话。我想尽量保留书的结构和锋利度。
书籍像前端页面
换个计算机视角：书籍有点像前端页面。
读者直接看到的是：
- 目录
- 标题
- 段落
- 例子
- 图表
- 注释
- 前言和后记
这些都是表层结构。
一本书真正有意思的部分，往往藏在更深的地方：
- 作者的问题意识
- 概念之间的依赖关系
- 论证推进的顺序
- 作者对读者的预设
- 章节之间的功能分工
- 修订、回顾、自我反驳留下的痕迹
读者看到的是“前端页面”，我们也许可以尽量逆向出它的“后端结构”。
它无法百分百还原作者脑子里真实的想法，仍然可以基于原文证据，构造一个可审查、可修订的模型。
这个目标和 summary 很不一样。
summary 会把书压缩。我想把书重新展开。
第一版的问题
一开始我没意识到上面说的问题，最早的 book-reader 更像一个工具流：
extract -> split chapters -> create notes -> validate看起来很合理，实际跑起来问题很快出现。
有些 EPUB 的标题结构很乱，source heading 不等于真实章节。
有些书有前言、回顾、附录、参考文献，不能全部当成同级章节。
技术书的重点可能是符号、公式、例子和依赖关系。
小说的重点可能是人物弧线、场景功能、关系变化和伏笔。
更麻烦的是，agent 很容易生成一堆看起来完整的文件。
notes/
model/
indexes/
guide/
review/文件都在，目录也漂亮。
打开内容后，可能只是薄薄的摘要、一篇流畅的小作文，或者一堆没有证据的概念词表。
这时我意识到一个问题：
文件存在，不代表真的读了。
结构完整，也不代表理解成立。
所以问题涉及 parser 和模板，也涉及一套读书纪律，一种读书的方法论。
Skills 不是魔法
做这个项目之前，我对 skills 有一点过高期待。
好像只要把 skill 写好，用户说一句：
用 book-reader 读这本书agent 就能自动读得很好。
现在我觉得这个期待不太现实。一本书太复杂，不同书型差异很大，输入质量也不稳定，agent 本身还会偷懒。
所以 skills 更像是一种默认行为先验。
它能减少随机性，结果仍不会完美。
缺少 skill 时，agent 可能会直接摘要、按章节复述，或者写读后感。skill 至少可以把它拉回一个比较稳定的方向：
source evidence
-> note items
-> reconstruction model
-> review
-> revision这就是 book-reader 后来的定位：
一次读透一本书并不现实，读书过程至少要有证据、有结构、有审查、有修订路径。
这个目标比“自动完美读书”现实很多。
从 summary 到 reconstruction
所以, 我后来把 book-reader 的核心目标写成：
Book surface text
-> evidence-linked reconstruction workspace也就是从书的表层文本出发，构造有证据链的阅读工作区。
大概是这样：
flowchart LR A[Book Surface Text] --> B[Source Evidence] B --> C[Note Items] C --> D[Reconstruction Model] D --> E[Review / Revision] E --> F[Reusable Reading Workspace]
这里面有几个关键变化：保留原文证据，区分笔记层次，让模型可以被审查，并把结果当成可以继续修改的 workspace。
这比 summary 麻烦很多，也更接近我真正想要的读书结果。
Note 不是章节摘要
一个很典型的问题是：agent 容易把 note 写成章节摘要。
比如读《人月神话》，它可能写：
本章讨论了 Brooks 法则，指出向延期项目增加人手会导致进一步延期。这句话没错，信息密度很低。
更有用的笔记应该继续追问：
- 这是原文观察，还是我对原文的转述？
- 这个判断支撑了后面哪个概念？
- 它和其他章节有什么关系？
- 有没有不同解释？
- 如果要继续深读，应该回到哪里？
所以在 book-reader 里，note 更像是中间工作材料，最终读书笔记不是它的定位。
它服务于后面的模型重建。
Model 不是读后感
另一个问题是，agent 很会写分析性正文。
比如：
作者通过 OS/360 的经验，重新定义了软件项目的组织复杂性，并强调概念完整性在大型系统中的核心作用。这句话可能很有道理。缺少证据时，它就只是一个漂亮判断。
所以 book-reader 里的 model 需要避免小作文式写法。
它至少要回答：
- 这个判断来自哪里？
- 哪条 note 支持它？
- 置信度是多少？
- 有没有替代解释？
- 什么证据会让我们修正它？
这样做会牺牲一点流畅性，换来可审查性。
对于 agent 读书来说，我现在更看重后者。
接受现实
做到后面，我对 skills 的期待降低了。我现在把期待从“一句话完美读懂一本书”，调整成更现实的几件事：
- 不直接退化成 summary
- 不把独特文本压平成普通套话
- 保留 evidence
- 让推断有来源
- 让不确定性留在文档里
- 让 reviewer 能指出问题
- 让后续 agent 能继续修订
也就是说，book-reader 负责启动一个比较可靠的读书过程。skills 最重要的价值，是把一套工作方法固化下来，让 agent 默认更有纪律。把长 prompt 藏起来只是表层作用。
小结
快速知道一本书大概讲什么，summary 就够了。
把一本书变成可继续使用的知识框架，则需要更严肃一点的方法：
证据
笔记
模型
审查
修订book-reader 就是在这个方向上的一次尝试：让书从临时上下文变成可索引、可追溯、可继续推进的知识结构，也让 agent 借助书的结构和风格，生成更具体、更有锋利度的理解。
这就是我说的：读书不是总结。