第25章：超越对话

定位：MemPalace 的当前验证集中在对话记忆上，但它的架构——Wing/Hall/Room/Closet/Drawer 的层级结构、AAAK 压缩方言、时态知识图谱——并不依赖于"对话"这个特定的数据类型。本章分析这个架构在其他领域的适配可能性，以及 AAAK 进入 Closet 层的技术路线。

一个比对话更大的结构

MemPalace 的 README 中有一句容易被忽略的话：

"It has been tested on conversations -- but it can be adapted for different types of datastores."

这不是一句随意的展望。它是对架构本质的陈述。

回顾 MemPalace 的核心结构：Wing 是一个领域边界，Room 是一个概念节点，Hall 是一个分类维度，Closet 是压缩摘要的概念层，Drawer 是原始内容。这五层结构中，没有任何一层在定义上依赖于"对话"这个数据形态。Wing 不关心它里面装的是对话记录还是代码文件——它只关心"这些东西属于同一个领域"。Room 不关心它代表的是一次讨论的主题还是一个代码模块——它只关心"这是一个独立的概念单元"。

但要补一句实现口径上的实话：在当前公开源码里，显式落地最完整的是 drawer 存储、wing/room 元数据、searcher 查询和外围的 graph/kg/diary 能力；Closet 更多还是 README 与 benchmark 叙事中的中间层概念，而不是产品运行时里的独立 collection。

这意味着 MemPalace 的空间结构是数据类型无关的。宫殿的检索效力来自结构本身——语义分区降低搜索空间、层级过滤提升命中精度——而不是来自被存储内容的特定格式。第四章分析过的那个 34% 检索精度提升，来自 Wing 和 Room 的结构化过滤，与被过滤内容是对话还是代码无关。

当然，"理论上可以"和"工程上可行"之间有距离。让我们具体分析几个方向。

代码库：Wing 是项目，Room 是模块

一个中型软件团队管理着五个微服务、两个前端应用和一个共享库。六个月后，没有人记得为什么 payment-service 的重试逻辑用的是指数退避而不是固定间隔，也没有人记得 shared-lib 中那个看起来多余的抽象层是为了解决什么具体问题。

代码注释和 commit message 理论上应该记录这些信息。实际上，大多数 commit message 是 "fix bug" 或 "refactor auth module"，而代码注释要么不存在、要么过时。真正的设计推理散落在 AI 对话、Slack 讨论和已经关闭的 PR 评论中。

将 MemPalace 适配到代码库场景中，映射关系是自然的：

Wing = 项目（payment-service, user-frontend, shared-lib）
Room = 模块或关注点（retry-logic, auth-middleware, database-schema）
Hall = 知识类型（hall_facts: 设计决策, hall_events: 重构历史, 
       hall_discoveries: 性能发现, hall_advice: 最佳实践）
Closet = 模块的压缩摘要（设计意图、关键约束、已知限制）
Drawer = 原始内容（相关的对话记录、PR 描述、设计文档片段）

这个映射中最有价值的部分是 Tunnel——跨 Wing 的概念连接。当 payment-service 和 user-frontend 都有一个名为 auth-middleware 的 Room 时，Tunnel 自动将它们关联起来。这意味着当你搜索认证相关的设计决策时，你能同时看到后端和前端的视角——即使它们是在不同时间、不同对话中讨论的。

MemPalace 已有的三种挖掘模式中，projects 模式（mempalace mine <dir>）已经支持对代码和文档文件的摄入。更准确地说，当前实现里的 wing 来自 mempalace.yaml 或 --wing 覆盖，room 路由则优先看路径命中，其次看文件名，最后再用内容关键词做启发式判断。它已经足以支持"把项目文件摄入同一个宫殿并按 room 检索"这一级能力，但还不是一句"按目录结构映射到 Wing 和 Room"就能概括的机制。在此基础上，更深度的适配——比如根据代码的 import 关系自动生成 Room 之间的 Hall 连接，或者从 Git 历史中提取时间维度的变更信息——是可工程化实现的扩展。

文档库：Wing 是知识域，Room 是主题

企业级文档管理面临的核心问题不是存储——存储从来不是问题。问题是检索。当一个组织有数千页的产品文档、技术规范、会议纪要和研究报告时，"找到那份关于 GDPR 合规的数据保留策略的文档"变成了一个非平凡的检索任务。

现有的文档管理系统——Confluence、Notion、SharePoint——用文件夹层级和标签来组织文档。这些组织方式的局限在第四章中已经分析过：它们是管理员视角的分类，不是检索者视角的导航结构。

MemPalace 的宫殿结构提供了一个不同的组织方式：

Wing = 知识域（compliance, product-design, engineering-standards）
Room = 具体主题（gdpr-data-retention, oauth-implementation, api-versioning）
Hall = 文档类型（hall_facts: 规范和标准, hall_events: 会议决议, 
       hall_advice: 实施指南）

这个结构的关键优势在于：搜索时，你不需要知道文档的标题或标签——你只需要描述你要找的信息，系统可以通过 Wing 和 Room 的语义过滤缩小搜索空间。对文档场景的适配如果做深，"我们的数据保留策略对欧盟用户有什么特殊要求"这样的自然语言查询，就可以先被组织到类似 wing_compliance / gdpr-data-retention 的局部搜索空间，再在其中进行语义检索。需要和当前实现区分的是：公开源码里的 searcher.py 目前只支持显式的 wing / room 过滤，还没有把自然语言 query 自动分类到 hall_facts 或某个 room 的运行时链路。

邮件与通信：Wing 是联系人，Room 是项目

另一个自然的适配方向是邮件和通信记录。当前的 MemPalace 已经支持 Slack 导出的摄入。将这个能力扩展到邮件，映射关系是清晰的：

Wing = 联系人或团队（wing_client_acme, wing_vendor_stripe, wing_team_infra）
Room = 项目或话题（contract-renewal, api-integration, incident-2026-03）

Tunnel 在这个场景中尤其有价值。当客户 Acme 的合同续签讨论（wing_client_acme / contract-renewal）与内部基础设施团队的容量规划讨论（wing_team_infra / capacity-planning）涉及同一个主题时——比如"明年的 SLA 承诺需要增加多少计算资源"——Tunnel 自动建立连接。你在回顾客户谈判历史时，能自动发现内部团队的相关讨论，反之亦然。

笔记系统：Wing 是领域，Room 是概念

个人知识管理工具——Obsidian、Logseq、Roam Research——的核心理念是双向链接：笔记之间的关联和笔记本身一样重要。MemPalace 的 Tunnel 机制在本质上就是双向链接——同一个 Room 名称出现在不同 Wing 中时，自动创建连接。

Wing = 知识领域（distributed-systems, machine-learning, product-management）
Room = 概念（consensus-algorithms, gradient-descent, user-retention）

一个有趣的可能性是：MemPalace 的宫殿结构可以作为现有笔记工具的检索加速层。你继续在 Obsidian 中写笔记，但 MemPalace 在后台将笔记内容摄入宫殿结构，提供跨笔记的语义检索和自动关联发现。笔记工具擅长的是创作和浏览；MemPalace 擅长的是检索和关联。两者的结合可能比单独使用任何一个都更强。

AAAK 进入 Closet 层

以上所有扩展方向都可以在 MemPalace 的当前架构上实现——它们本质上是改变摄入管道和映射规则，核心的存储和检索机制不需要改变。但有一个更深层的技术演进方向，它将显著改变系统的性能特征：AAAK 方言进入 Closet 层。

要理解这个演进的含义，需要先把"概念层"和"当前运行时"区分开。

更准确地说，当前公开源码里还没有一个显式的 Closet 存储层。mempalace mine 目前直接把切分后的原文块写入 mempalace_drawers；元数据主要是 wing、room、source_file 等字段。searcher.py 的默认路径也是直接查询这个 drawers collection，再把原文返回给调用方。换句话说，当前运行时里真正落地的是 Drawer；Closet 更多是 README 和部分 benchmark 叙事里那种"用于快速导航的中间表示"。

因此，README 所说的 "add AAAK directly to the closets" 并不是在描述一个已经存在、只差换编码的现成子系统，而是在描述下一阶段：把这个中间层从概念/实验表达，推进为显式的压缩导航层。

MemPalace 的 README 中明确提到了这个演进方向：

"In our next update, we'll add AAAK directly to the closets, which will be a real game changer -- the amount of info in the closets will be much bigger, but it will take up far less space and far less reading time for your agent."

让我们从 dialect.py 的当前能力来分析这个方向的可行性。

Dialect 类的 compress() 方法接受纯文本输入，输出 AAAK 格式。它做了以下几件事：

第一，实体检测和编码。_detect_entities_in_text() 扫描文本中的已知实体（通过预配置的实体映射）和疑似实体（通过大写词启发式规则），将 "Kai recommended Clerk" 中的 "Kai" 编码为 "KAI"。

第二，主题提取。_extract_topics() 通过词频分析和启发式加权（大写词、含连字符/下划线的技术术语加分）提取关键主题词，将长段描述压缩为 auth_migration_clerk 这样的主题标签。

第三，关键语句提取。_extract_key_sentence() 对每个句子评分——包含决策词（"decided"、"because"、"instead"）的句子得分更高，较短的句子优先——提取出最具信息量的片段。

第四，情感和标志检测。_detect_emotions() 和 _detect_flags() 通过关键词匹配检测文本的情感倾向和重要性标记（DECISION、ORIGIN、TECHNICAL 等）。

一段 500 词的对话摘要，经过 compress() 处理后，可能被压缩为两到三行 AAAK 格式：

wing_kai|auth-migration|2026-01|session_042
0:KAI+PRI|auth_migration_clerk|"Chose Clerk over Auth0 pricing+dx"|determ+convict|DECISION+TECHNICAL

大约 30 个 token。原始摘要可能是 300 个 token。压缩比约 10 倍。

当这个压缩应用到未来的显式 Closet 层时，效果是双重的。

效果一：同样的存储空间可以容纳更多信息。 如果一个 Closet 之前能存储 10 条摘要（3000 token），AAAK 化后可以存储 100 条（同样 3000 token）。这意味着 AI 在读取一个 Closet 时能获得十倍于之前的上下文覆盖。

效果二：AI 的读取速度更快。 AAAK 被设计为 AI 可即时理解的格式——它在 mempalace_status 的响应中教会 AI AAAK 语法，AI 在之后的交互中直接解析 AAAK。读取 30 个 token 的 AAAK 摘要比读取 300 个 token 的英文摘要快得多，而信息量是等价的。在需要扫描大量 Closet 来定位信息的场景中，这个速度差异是决定性的。

从 dialect.py 的当前实现来看，这个演进在技术上是可行的。compress() 方法已经能够处理任意纯文本输入，不依赖于特定的数据结构。一旦摄入管道开始生成显式的 closet 文本，把这一步接上 dialect.compress() 进行 AAAK 编码，仍然属于增量工程变更，不需要重构核心架构。

需要注意的一个技术考量是：AAAK 压缩后的文本在语义嵌入空间中的行为可能与原始英文不同。ChromaDB 使用的嵌入模型（如 all-MiniLM-L6-v2）是在英文文本上训练的，AAAK 格式的文本——如 KAI+PRI|auth_migration_clerk——可能产生与英文等价描述不同的嵌入向量。这意味着 Closet 层 AAAK 化后，搜索查询（通常是英文自然语言）与 Closet 内容（AAAK 格式）之间的语义匹配可能需要调整。

一种可能的解决方案是双存储：Closet 同时保留 AAAK 版本（用于 AI 读取）和原始英文版本（用于嵌入检索）。这会增加一些存储开销，但保持了检索精度。另一种方案是在搜索时将查询也转换为 AAAK 格式，使查询和内容在同一个表示空间中匹配——但这需要验证嵌入模型在 AAAK 文本上的行为。

无论采用哪种方案，AAAK 进入 Closet 层的方向是明确的，可行性是有基础的。更准确的说法是：它不是从零发明一种全新的能力，而是把已有的 AAAK 编码能力应用到一个尚未在产品运行时中显式物化的中间层。

开源社区的探索空间

MemPalace 以 MIT 协议开源，这意味着上述所有扩展方向都不需要等待官方团队来实现。社区中任何有兴趣的开发者都可以 fork 项目，实现自己的摄入管道适配。

几个具体的探索空间值得指出：

摄入管道的多样化。 当前的 convo_miner.py 处理五种对话格式的标准化。同样的管道模式可以扩展到更多数据类型：Git commit 和 PR 评论的摄入、Obsidian vault 的摄入、浏览器书签和高亮标注的摄入。每种数据类型需要一个 normalizer（将原始格式转为标准结构），其余的宫殿逻辑可以复用。

Wing/Room 的自动发现。 当前的 mempalace init 更接近"本地扫描 + 交互式确认"：先从目录、文件名和内容里检测候选 room，再让用户接受、编辑或补充。对于大型数据集，进一步的自动发现可能更实际——通过聚类分析自动识别数据中的领域边界（Wing）和概念节点（Room）。这在文档库和邮件库等数据量大的场景中尤为有价值。

知识图谱的跨源融合。 当不同类型的数据被摄入同一个宫殿后，知识图谱（knowledge_graph.py）提供了一个本地的三元组存储层，用来承载跨源实体关系。你在邮件中提到的客户名称、在代码注释中出现的同一名称、在会议纪要中讨论的同一客户，理论上都可以被抽成时态三元组并写入同一个图中。需要补清楚的是：当前公开源码已经实现的是 add_triple / query_entity 这一层能力，而不是一个会自动从多种数据源中抽取并融合事实的现成管道。

Specialist Agent 的领域扩展。 README 曾用 reviewer、architect、ops 举过软件开发场景的 specialist 例子，但当前公开源码真正实现的是更底层的通用机制：任意 agent_name 都可以拥有自己的 wing_<agent>/diary。正因为底座足够简单，同样的存储结构也可以扩展到其他领域：sales agent 追踪客户关系演变，research agent 追踪论文阅读和研究方向，legal agent 追踪合规要求的变化。

不做路线图承诺

本章有意识地使用了"可能"、"可以"、"方向"这样的措辞，而不是"将会"、"计划"、"预计"。原因很简单：MemPalace 是一个活跃发展中的开源项目，它的未来方向取决于社区的需求、贡献者的兴趣和实际的工程验证。画一条漂亮的产品路线图很容易，兑现它很难。

更诚实的做法是说：MemPalace 的架构——Wing/Hall/Room 的空间结构、AAAK 的压缩能力、时态知识图谱——在设计上是通用的。它们被验证的领域是对话记忆，验证结果是 96.6%（零 API）和 100%（Haiku 重排序）。它们能否在代码库、文档、邮件、笔记等领域达到同样的效果，需要实际的工程尝试和基准测试验证。

这也是开源的价值所在。一个闭源产品说"我们将支持代码库记忆"，你只能等。一个开源项目说"架构支持代码库记忆"，你可以自己验证。fork 代码、写一个代码摄入管道、跑一个基准测试——整个验证过程对任何人开放。

宫殿的边界

MemPalace 的核心洞见是：结构比算法更重要。 在检索这个问题上，一个好的空间组织结构带来的精度提升（34%），超过了大多数纯算法优化能达到的增益。

这个洞见不限于对话。它适用于任何需要在大量信息中快速定位特定知识的场景。代码库中的设计决策检索、文档库中的策略查找、邮件中的历史讨论回溯、笔记中的概念关联发现——所有这些场景都面临同一个核心问题：搜索空间太大，纯语义匹配的区分度不够。

MemPalace 的宫殿结构——通过引入领域边界（Wing）、分类维度（Hall）和概念节点（Room）——为这个问题提供了一个与数据类型无关的解决方案。它不依赖于更大的模型、更好的嵌入、更多的计算——它依赖于更好的组织。

这是一个简单但深刻的工程判断：与其让 AI 在 22,000 条无结构的记录中搜索，不如先给记录建一个宫殿，让 AI 知道该去哪个房间找。

对话只是 MemPalace 验证这个判断的第一个领域。不会是最后一个。