分层设计：从入口到主题演化HERMES & AGENT ENGINEERING · 课时 03

3.1 交互层负责入口

胶囊系统不能限定单一入口。单一入口不符合 AI 时代的使用方式。

这里先规划三个基本入口。

1. Hermes 终端。就像你平时和 Hermes 对话一样，把资料发给 Hermes 即可。

2. Hermes 的各类接入频道，比如飞书、微信、QQ、Slack 等。

3. 任何你后续扩展出来的入口，比如浏览器插件、移动应用等。只要能连接到 Hermes，就可以进入胶囊系统。

所以这里要特别强调：Hermes 才是胶囊系统的交互层网关。任何能发给 Hermes 的资料，最终都可以进入胶囊系统的主流程。

飞书不是唯一入口。飞书只是多个入口中的一个。

比如用户可以从任何渠道向 Hermes 发送这句话：

胶囊系统 抓取 https://www.logamee.com/blog/karpathy-vibecoding-agentic-engineering

Hermes 会自动抓取这个 URL 下面的内容，并开始执行“制胶囊”的过程。

在进入主流程前，Hermes 可以先做一次入口去重。这个去重只处理非常确定的重复，比如同一个 URL、同一个文件、同一条消息。能在入口挡掉的重复，就不要让它继续进入后面的抽取、证据和理解流程。

但入口去重不负责判断内容是不是“讲过了”。一篇文章改了标题，或者一篇洗稿文章换了说法，入口层通常看不出来。这种重复要等 Hermes 理解正文以后，在主题演化阶段判断。

这个设计很重要。胶囊系统要处理的，不是一种固定格式的资料，而是用户在各种场景里临时遇到的资料。可能是一篇网页，也可能是一张截图、一段语音、一份 PDF，甚至只是聊天里的一句话。入口越自然，系统越有机会长期使用。

3.2 证据层负责固定资料

资料进入系统以后，第一步不是总结，而是固定证据。

这里的证据不是法律意义上的原始证据，而是后面可以核对、可以引用、可以被 Hermes 继续处理的信息。音频可以先转写成文字，PDF 可以抽取正文，网页可以清理成 Markdown。只要转换后的信息足够完整，后面还能回到来源核对，它就可以承担证据层的职责。

所以证据层要做的事情不是“保存附件”，而是把资料变成一个可检查的文本底稿。这个文本底稿应该进入飞书知识库或飞书云文档，成为后续理解、索引和主题演化的主要依据。

+------------
|  原始资料      URL、PDF、音频、图片、文字
+------------
       |
       v
+------------
|  主证据        飞书知识库/云文档里的 Markdown
+------------

证据层的主存储应该放在飞书，而不是本地。

而来源类型、原始链接、入库时间、证据页 URL 或飞书路径、目标主题页和处理状态，都应该由索引层管理。后面需要回到证据时，直接从索引记录找到对应的飞书文档。这样每个层的边界责任最干净：证据层保存内容，索引层管理位置和状态。

而本地工作目录承担一些辅助作用：保存临时转换结果、处理日志，以及不适合上传到飞书的原始附件。

这几个位置的职责可以拆开看：

飞书证据页    保存标准化后的正文
索引层        保存来源、状态、证据页 URL、目标主题页
本地工作目录  保存临时转换结果、日志、少量不适合上传的附件

这样做有两个好处。第一，用户可以直接在飞书里审查和修改证据文本。第二，Hermes 后面理解错了，也可以回到飞书证据页重新核对。至于这份证据从哪里来、当前状态是什么、要不要参与演化，统一到索引层查看。

3.3 索引层负责管理入库资料

证据层解决的是“信息能不能核对”。但只留下证据还不够。资料一多，系统必须知道每一份资料处在什么状态。

这就是索引层的作用。

索引层管理的对象，不是整个 Wiki，也不是所有页面，而是一条条进入胶囊系统的资料单元。

一条资料进入系统以后，证据层会生成可核对的主证据。索引层要记录这条资料从哪里来、证据页在哪里、当前处理到什么状态、属于哪个主题，最后被送往哪个主题页。

也就是说，索引层首先是证据层的管理索引，同时也是证据层和演化层之间的连接表。它不负责维护主题页本身，也不负责给整个 Wiki 做目录。主题页、概念页、综合页的目录，应该属于演化层。

可以把索引层理解成胶囊系统的资料账本。

+------------
|  一条资料
|  标题：Embedding 为什么能表示语义
|  主题：Embedding 向量
|  状态：已入库
|  证据页：飞书云文档链接
|  目标主题页：Embedding 向量主题页
|  参与演化：是
+------------

这一层适合放在飞书多维表格里（你可以把飞书多维表格理解成一个更灵活的 MySQL 数据库）。多维表格可以筛选、查询、更新字段，也方便 Hermes 通过 CLI 读取。

第一版字段不要太少，但也不要一开始就过度设计。可以先保留这些字段：

标题
来源类型
原始链接
证据页 URL / 飞书路径
入库时间
处理状态
主题
标签
参与演化
目标主题页
备注

所以索引层看起来像表格，实际承担的是资料入库后的控制台。没有这一层，资料会保存下来，但系统无法管理这些资料的状态，也不知道哪些资料应该暂缓、忽略或重新处理。

3.4 理解层负责判断资料关系

理解层由 Hermes 承担。

飞书能保存文档，也能搜索文档，但它不会自动判断一篇文章和哪些主题有关，也不知道这些资料和旧内容之间是什么关系。这类判断需要 Hermes 来做，这本身就是 LLM 存在的意义——理解语义。

比如一篇文章讲的是“词向量如何表示语义”，另一篇文章讲的是“为什么相似句子的向量距离更近”。它们表面上不是同一个标题，但都可能属于“Embedding 向量”这个主题。如果只靠关键词，系统很容易把它们分开；如果 Hermes 读懂了内容，就能把它们放到同一条知识线上。

理解层大概做四件事：

+------------
|  读资料        提取正文、识别标题和来源
+------------
       |
       v
+------------
|  抓观点        摘要、关键观点、涉及实体
+------------
       |
       v
+------------
|  判主题        属于哪个主题，是否需要新主题
+------------
       |
       v
+------------
|  判断关系      与旧主题/旧资料的重复、补充、冲突
+------------

如果要说技术难点，理解层可能是最难的一层。难点不只在于抓观点（这对 LLM 很小儿科），而在于判断这份资料和现有知识之间的关系：它关联哪些主题，和旧资料有没有重复，是否补充了新的例子，是否和旧判断发生冲突。

第一版可以让 Hermes 输出一份结构化理解结果。它不一定要很复杂，但至少要包含主题判断、关键观点、重复关系、冲突线索和可引用场景。

这份理解结果可以先保持成一个很朴素的结构：

这里需要明确一下理解层与演化层的边界：

判断资料关联哪些主题，以及判断它和旧主题、旧资料之间的关系，都是理解层的事情。而根据这些判断去改写主题页、概念页或综合页，才是演化层的事情。

理解层回答“它和谁有关、是什么关系”，演化层回答“知识体系要因此怎么变化”。

3.5 演化层负责维护主题页

如果胶囊系统只做摘要，这显然不够。

摘要通常只能回答“这篇文章讲了什么”。但这远远不够。如果只是摘要，那就和传统的收藏夹没有区别。这个系统依然会越来越臃肿，依然会重复记录相同的内容，也无法将知识结构化。我们需要的是一份像维基百科一样的知识体系。

演化层承担什么职责

理解层先判断这篇资料关联哪些主题，以及它和旧资料之间是重复、补充还是冲突。演化层接着处理另一组问题：是扩展主题的边界，还是修正旧的内容？

这也是胶囊系统里最接近“内化”的一层。它不是让用户反复回答问题，也不是要求用户额外复习，而是让 Wiki 自己不断吸收新资料。用户每次回到同一个主题时，看到的都不是一堆新增记录，而是一篇已经重新融合过的知识文章。

演化层主要做四件事：

融合不是追加

人需要内化知识，这份 Wiki 也需要内化掉新增内容。对于用户来说，他是看不到新增内容的，他看到的永远都是一份融合后、不突兀的知识文章。

比如原来的“Embedding 向量”主题页里，只写了“把词变成向量”这层意思。后来用户又存入一篇资料，里面讲到向量空间、语义相似度和检索召回。胶囊系统不应该在主题页末尾简单追加一段“新增资料：某某文章”，也不应该把新内容硬插到某个小节后面。LLM 应该重新理解整篇主题页，把新资料融合进原来的论述结构里。

比如，主题页不再只是说“Embedding 是向量”，而是进一步说明：向量为什么可以表示语义，语义相近为什么会表现为距离更近，Embedding 又为什么会成为检索、推荐和 RAG 的基础。用户再次打开这篇主题页时，看到的仍然是一篇完整的“Embedding 向量”文章，而不是一堆按入库时间排列的资料摘录。

这里说的主题演化，不是把新资料追加到主题页后面，也不是给主题页记录一段更新日志。更准确地说，它是在维护一篇持续演化的 Wiki 页面。

每一份新资料进入以后，Hermes 都要根据理解层的判断，决定它应该怎样改变现有主题。它可能让某一段论述变得更完整，也可能扩展主题的边界；它可能印证旧判断，也可能暴露旧判断里的缺陷。真正重要的不是“这篇资料被收进来了”，而是主题页本身有没有因此变得更准确、更完整。

内容去重只看知识是否被采纳

这里还要进一步去重。这个去重不是判断两个文件是否完全相同，而是判断这份资料对主题页有没有新增价值。互联网资料里，严格相同的正文反而不常见，更常见的是改写、洗稿、转载和重复讲同一件事。对于这类资料，保留来源是有意义的，但主题页不应该把同一段知识再写一遍。

这里可以把它叫做内容去重。

内容去重和入口去重不一样。入口去重处理的是非常确定的重复，比如同一个 URL、同一个文件、同一条消息。内容去重处理的是另一类问题：这份资料虽然不是同一个文件，但它有没有被本次主题演化使用？

这里不要分得太细。只要一份资料里有一点内容被融合进主题页，它就算被使用。哪怕只是修正了一个边界，补进了一个例子，或者让原来某段论述更准确，都算被使用。只有当它对当前主题没有任何帮助时，才叫完全不被采纳。

如果 Hermes 判断这份资料完全不被采纳，不应该直接让 Agent 删除所有证据。这个判断毕竟带有理解成分，可能会有误判。所以这份资料可以停止进入主题演化，但需要在索引层留下轻量记录。

轻量索引记录不需要保留完整证据正文，但至少要保留来源链接、标题、入库时间、对应主题、采纳状态和判断理由。这样做不是为了收藏重复资料，而是为了让系统知道这份资料已经处理过。以后同一篇资料再次进入时，Hermes 可以直接识别它的状态，不必重新走完整流程。

真正的删除应该更谨慎一些。第一版可以让 Agent 自动决定“是否参与主题演化”，但不要让它默认拥有“彻底删除证据”的权力。删除动作最好先变成一个状态：建议删除。用户确认以后，再清理对应的证据页和临时文件。

演化层生成哪些页面

所以主题页主要有两种变化：

延伸    主题覆盖的案例、概念、工具、使用场景越来越丰富
校正    旧页面里不够准确的判断被修正，原来模糊的边界被重新写清楚

演化层的产物主要是主题页、概念页和综合页。

+------------
|  主题页        某个主题沉淀后的判断和材料关系
+------------
       |
       v
+------------
|  概念页        某个概念的定义、例子、边界
+------------
       |
       v
+------------
|  综合页        围绕一个问题整理出的回答
+------------

这里先不用展开每一种页面的写法。读者只要先理解它们的关系：主题页负责维护一条知识线，概念页负责解释基础概念，综合页负责回答具体问题。

这一层需要 Hermes 和飞书配合。Hermes 负责理解、融合和校正，飞书负责保存这些持续演化的页面。至于主题页、概念页和综合页应该怎么设计，后面单独展开。

3.6 内化层负责让知识进入人的判断

演化层让 Wiki 自己变得更完整，但这还不等于用户已经形成了自己的知识结构。

所以还需要单独看内化层。不过这里的内化层，不是让系统不断向用户提问，也不是把胶囊系统做成复习软件。它要的思路是：把演化层产生的知识页，整理成用户愿意反复打开、反复引用、反复修正的知识结构。

内化层可以先理解成三件事：

这几个动作不要求用户额外打卡，也不要求用户每次回答问题。它们只是让 Wiki 的结构变得更容易被人吸收。详细设计放到后面单独展开。

3.7 ■ 学点英语