随着AI编程助手日益普及，我们积累的技能、脚本和上下文信息也越来越多。当研究新领域，例如大模型推理优化时，开发者通常会阅读大量论文、做笔记、保存PDF。AI Agent会帮忙总结、发现关联、提出问题，这些又会引出更多笔记。几周后，你可能会发现自己面对着一堆散乱的Markdown文件、下载文件夹里半消化的论文，以及一个模糊的记忆：“KV缓存量化好像在哪儿提到过。”当你试图搜索时，会得到几个关于同一主题但内容不完整的文件，却找不到真正需要的答案。
这并非存储问题，信息都在那里，但这是一个结构性问题——而akm的多wiki支持正是为解决此问题而生。
Karpathy的LLM Wiki模式
在GitHub Gist中，Andrej Karpathy描述了一种维护Markdown知识库的模式，由人类和LLM共同构建和维护。其核心思想“看似简单”：一个结构化的Markdown页面目录，由Agent负责将新信息随时间整合到这些页面中。
其洞察在于：Agent在某些人类觉得繁琐的任务上表现出色。例如，将一篇40页的论文总结成两段式的页面条目；发现新论文与知识库中已有内容之间的联系；记录添加了什么以及原因；当新信息与现有内容矛盾或扩展时，更新现有页面。
然而，Agent不擅长维护不变性。Agent无法可靠地强制执行slug唯一性，不会一致地重新生成索引，有时会覆盖你希望保持不变的源文件，并且在会话结束时会忘记已摄取的内容。
因此，我们需要分工协作：Agent负责合成信息，而工具则负责强制执行不变性。这正是akm的wiki支持所填补的空白。
知识积累与遗失的困境
大多数开发者会以两种方式遭遇此问题：
第一种方式：将文件作为知识资产导入（如akm import ./paper.md），然后Agent直接读取。这对于一两个文档来说尚可。但当文档数量达到十个时，Agent在每个相关会话中都会加载全文。当文档达到三十个时，你会在不必要的上下文中消耗大量token，Agent则试图在每个会话中“心智”合成三十个独立文件之间的关系。结果是：信息之间没有关联，也没有索引。
第二种方式：要求Agent将“笔记”记录到一个notes.md文件中。这个文件会不断增长，最终变成一堵没有任何结构的“文本墙”。搜索它只能靠grep。更新它意味着Agent必须在写入任何内容之前完整阅读整个文件。