用文件系统重构AI记忆：个人操作系统设计实践

全文概览

你是否有过这样的经历：与AI助手对话时，每次都需要重新介绍自己、粘贴风格指南、说明工作目标？40分钟后，模型便“忘记”你的偏好，开始写出千篇一律的内容。这不仅是提示工程的困境，更是AI记忆架构的根本性挑战。

传统方案要么依赖昂贵的向量数据库，要么将所有信息塞入有限的上下文窗口，导致注意力分散、性能下降。本文作者Muratcan Koylan提出了一个反直觉的解决方案——用文件系统替代数据库，构建一个基于Git代码库的“个人大脑操作系统”。80多个Markdown、YAML和JSONL文件，让AI能够渐进式加载上下文，像专家一样按需获取信息。

这一方案能否为AI记忆问题提供新思路？又能从中获得哪些启发？

阅读收获

• 存储架构新视角：理解为何JSONL的仅追加模式能防止数据丢失，YAML的层级结构如何服务于AI的信息检索，Markdown的通用渲染为何适合人机协同
• 上下文工程方法论：掌握“渐进式披露”三层加载机制——路由层→模块层→数据层，这是解决AI长周期任务记忆的核心设计模式
• 技能系统设计原则：学习如何通过结构化指令和自动加载机制，让AI在不同任务中一致地遵循用户的优先级和工作流程
• 实践避坑经验：作者踩过的模式过度设计、语音提示过长、模块边界划分错误等坑，为类似项目提供了宝贵的参考

2026年春节 openclaw 开启的代理式应用，给这个春节以足够多想象，笔者也是在假期末尾尝试构建，后被其强大执行力所惊讶，在给伴侣普及这块能力时，曾激动的手心冒汗，连着几宿测试其在核心工作流中的表现能力，本文从可操作层面介绍了如何构建Agent 操作系统，在技术快速演进的今天，值得复刻以接受代理式AI的效率变革。

👉 划线高亮 观点批注

作者：Muratcan Koylan

每次与人工智能的对话都以同样的方式开始。你先介绍自己，说明你在做什么，粘贴你的风格指南，再次描述你的目标，提供和昨天、前天、大前天一样的背景信息。然后，40分钟后，模型就忘了你的意思，开始像写新闻稿一样撰写内容。

我厌倦了这种情况，所以我开发了一套系统来解决这个问题。

我称之为“个人大脑操作系统”。它是一个基于文件的个人操作系统，运行在 Git 代码库中。克隆它，用 Cursor 或 Claude Code 打开，AI 助手就能获取一切：我的声音、我的品牌、我的目标、我的联系人、我的内容创作流程、我的研究、我的失败。无需数据库、无需 API 密钥、无需构建步骤。只有 80 多个 Markdown、YAML 和 JSONL 文件，人类和语言模型都能直接读取。

基于md构建人机交互的个人操作系统，是代理式AI应用早期的记忆范式。

我分享完整的架构、设计决策和错误，以便您可以构建自己的版本。不是复制我的版本，而是您自己的版本。具体的模块、文件模式和技能定义会因您的工作而异，但模式是通用的。构建人工智能代理信息结构的原则是通用的。取其精华，去其糟粕，最终交付真正有用的人工智能，而不是泛泛而谈的辅助工具。

以下是我构建它的过程，为什么架构决策很重要，以及我从惨痛经历中学到的东西。

1）核心问题：语境，而非提示

大多数人认为人工智能助手的瓶颈在于提示。编写更好的提示，就能得到更好的答案。这对于单次交互和生产环境中的助手提示来说确实如此。但当你想让人工智能在数周甚至数月的时间里，像你一样完成数十项任务时，这种方法就行不通了。

注意力预算：语言模型的上下文窗口是有限的，而且并非所有信息都同等重要。这意味着把所有已知信息都一股脑地倾倒到系统提示符中不仅浪费资源，还会降低性能。你添加的每个词元都会争夺模型的注意力。现阶段大模型1M的上下文，在相对完善的提示词交互环境中，大概能维持一周时间，想要维持更长的周期，就得更高效的设计交互系统。

我们的大脑运作方式也类似。如果有人在会议前15分钟向你简要介绍情况，你会记住他们说的第一句话和最后一句话，中间的内容则会变得模糊。语言模型也具有类似的U型注意力曲线，只不过它们的注意力曲线是可以用数学方法测量的。词元位置会影响回忆概率。虽然新模型在这方面有所改进，但你仍然会分散模型的注意力，使其无法专注于最重要的信息。了解这一点会改变你为人工智能系统设计信息架构的方式。

我没有编写一个庞大的系统提示符，而是将个人操作系统拆分成 11 个独立的模块。当我让 AI 撰写博客文章时，它会加载我的语音指南和品牌文件。当我让它准备会议时，它会加载我的联系人数据库和互动记录。在内容创作任务中，模型不会接触到任何网络数据；在会议准备任务中，模型也不会接触到任何内容模板。

渐进式披露：这是整个系统运行的基础架构模式。系统并非一次性加载 80 多个文件，而是采用三层加载方式。第一层是一个轻量级的路由文件，始终加载，用于告知 AI 哪个模块是相关的。第二层是模块特定的指令，仅在需要时加载。第三层是实际数据，包括JSONL 日志、YAML 配置和研究文档，仅在任务需要时加载。

这与专家的工作方式如出一辙。这三个层级构成了一个漏斗：首先是宏观路径，然后是模块上下文，最后是具体数据。在每个步骤中，模型都只拥有它需要的，不多也不少。

我的路由文件是 [技能.md] 告诉代理“这是一个内容任务，加载品牌模块”或“这是一个网络任务，加载联系人”。模块指令文件（[内容.md]，[操作.md]，[网络.md]) 每个文件包含 40-100 行，包含文件清单、工作流程序列以及一个包含该领域行为规则的 <instructions> 块。数据文件最后加载，仅在需要时加载。AI 逐行读取 JSONL 中的联系人信息，而不是解析整个文件。信息流分为三层，最多需要两跳才能获取任何信息。

智能体指令层级：我构建了三层指令，分别控制人工智能在不同层级的行为方式。在存储库层级， [CLAUDE.md])这是入职文档——每个人工智能工具都会首先读取它，并获取项目的完整地图。在大脑层面，[代理.md] 包含七条核心规则和一个决策表，该决策表将常见请求映射到精确的操作序列。在模块级别，每个目录都有自己的指令文件，其中包含特定领域的行为约束。

这解决了困扰大型人工智能项目的“指令冲突”问题。当所有指令都集中在一个系统提示中时，规则之间就会相互矛盾。例如，内容创建指令可能与网络建设指令冲突。通过将规则限定在其各自的领域内，可以消除冲突，并为智能体提供清晰且互不重叠的指导。这种层级结构还意味着，您可以更新一个模块的规则，而不会导致其他模块的行为出现倒退。

我的 [代理.md] 是一个决策表。人工智能读取到“用户说‘向 Z 发送电子邮件’”，并立即看到：

1. 第一步，在 HubSpot 中查找联系人。
2. 第二步，验证电子邮件地址。
3. 第三步，通过 Gmail 发送。

模块级文件，例如[操作.md] 定义优先级级别（P0：今天完成，P1：本周完成，P2：本月完成，P3：待办事项），以便代理能够一致地对任务进行分类。代理遵循我使用的相同优先级系统，因为该系统是明确规定的，而不是隐含的。

2）文件系统即内存

我做出的最反直觉的决定之一：没有数据库，没有向量存储，除了 Cursor 或 Claude Code 的功能之外，没有其他检索系统。只有磁盘上的文件，用 Git 进行版本控制。

格式-功能映射：系统中每种文件格式的选择都基于特定原因，这些原因与人工智能代理处理信息的方式相关。日志使用 JSONL，因为它设计为仅追加式，对流式处理友好（代理逐行读取，无需解析整个文件），并且每一行都是独立的有效 JSON。配置使用 YAML，因为它能清晰地处理层级数据，支持注释，并且对人和机器都易于阅读，避免了 JSON 括号带来的冗余。叙述性内容使用 Markdown，因为 LLM 可以原生读取它，它可以在任何地方渲染，并且在 Git 中生成清晰的差异。

JSONL 的追加特性避免了一类错误，即代理程序意外覆盖历史数据。我曾见过这种情况发生在 JSON 文件上：代理程序写入整个文件，导致三个月的联系人历史记录丢失。而使用 JSONL，代理程序只能添加行。删除操作通过将条目标记为 "status": "archived" 来实现，这样可以保留完整的历史记录以进行模式分析。YAML 的注释支持意味着我可以为目标文件添加代理程序可以读取的上下文注释，而不会污染数据结构。Markdown 的通用渲染功能意味着我的语音指南在 Cursor、GitHub 和任何浏览器中看起来都一样。

我的系统使用 11 个 JSONL 文件（帖子、联系人、互动、书签、想法、指标、体验、决策、失败、参与度、会议）、6 个 YAML 文件（目标、价值观、学习、圈子、节奏、启发式方法）和 50 多个 Markdown 文件（语音指南、研究、模板、草稿、待办事项）。每个 JSONL 文件都以一个 schema 行开头：{"_schema": "联系人", "_version": "1.0", "_description": "..."}。代理在读取数据之前始终知道文件结构。

情景记忆：大多数“第二大脑”系统存储事实。我的系统也存储判断。memory/ 模块包含三个仅追加的日志：experiences.jsonl （关键时刻，带有 1-10 的情感权重评分）、decisions.jsonl （关键决策，包含推理过程、考虑的替代方案和跟踪的结果）和failures.jsonl （出了什么问题、根本原因和预防措施）。

拥有你过往记录的AI和拥有你判断的AI之间是有区别的。事实告诉智能体发生了什么，而情景记忆则告诉智能体什么才是最重要的，我会如何改进，以及我是如何权衡利弊的。当智能体遇到与我记录过的决策类似的情况时，它可以参考我过去的推理过程，而不是生成通用建议。失败日志是最有价值的，它记录了我苦心钻研才获得的模式识别能力。

当我决定是否接受 Antler Canada 的 25 万美元投资或加入[Sully.ai]作为情境工程师，决策日志记录了所有选项、每个选项背后的原因以及最终结果。如果遇到类似的职业选择，系统不会给我千篇一律的职业建议，而是会参考我实际的思考方式：“学习 > 影响力 > 收入 > 增长”是我的优先级顺序，而“我能否接触到所有领域？我能否在自身能力的极限范围内学习？我是否尊重创始人？”则是我选择加入公司的框架。

跨模块引用：该系统采用平面文件关系模型。虽然没有数据库，但结构足够清晰，代理可以跨文件连接数据。interactions.jsonl 中的 contact_id 指向 contacts.jsonl 中的条目。ideas.jsonl 中的 pillar 映射到 identity/brand.md 中定义的内容支柱。书签提供内容创意。帖子指标用于每周评论。各模块在加载时相互独立，但在推理过程中相互关联。

孤立无援的局面就像一堆文件夹。交叉引用让智能体能够在需要时遍历知识图谱。“准备与Sarah的会面”会触发一个查找链：在联系人中查找Sarah，提取她的互动记录，检查与她相关的待办事项，并整理一份简报。智能体无需加载整个系统，即可跨模块跟踪这些引用。

我的会前工作流程包含三个文件：contacts.jsonl（联系人信息）、interactions.jsonl（按 contact_id 筛选以记录互动历史）和 [todos.md]（任何待办事项）。代理会生成一份包含关系背景、上次对话摘要和待办事项的单页简报。无需手动整理。数据结构使工作流程成为可能。

3）技能系统：教人工智能如何完成你的工作

文件存储知识，技能编码流程。我遵循人机交互代理技能标准构建了代理技能，该标准包含结构化的指令，告诉人工智能如何执行特定任务，并内置了质量控制机制。

自动加载与手动调用：两种类型的技能解决两种不同的问题。参考技能（例如 voice-guide、writing-anti-patterns）在其 YAML 前置元数据中设置了 user-invocable: false。当任务涉及写作时，智能体会读取描述字段并自动注入这些技能。我无需手动调用它们，它们每次都会静默激活。任务技能（例如 /write-blog、/topic-research、/content-workflow）设置了 disable-model-invocation: true。智能体无法自行触发这些技能。我需要输入斜杠命令，该技能才会成为智能体执行该任务的完整指令集。

自动加载解决了一致性问题。我无需每次请求草稿时都记住“使用语音”，系统会自动记住。手动调用解决了精确性问题。研究任务和博客文章的质量门槛不同。将它们分开可以防止代理混淆两种不同的工作流程。YAML 前置元数据是实现这一机制的关键，一些元数据字段控制着整个加载行为。

当我输入 /write-blog context engineering for marketing teams 时，五件事会自动发生：加载语音指南（我的写作方式）、加载反模式（我从不写的内容）、加载博客模板（包含七个部分的结构和字数目标）、检查用户画像文件夹中的受众群体信息，以及检查研究文件夹中是否存在已有的主题研究。一个斜杠命令即可触发完整的上下文构建。技能文件本身会显示“读取 brand/tone-of-voice.md”，它引用了源模块，并且从不重复内容。确保单一数据源的真实性。

语音系统：我的声音被编码为结构化数据，并带有一些个人风格。语音档案以 1-10 分制评估五个属性：正式/随意 (6)、严肃/轻松 (4)、技术性/简洁 (7)、内敛/富有表现力 (6)、谦逊/自信 (7)。反模式文件包含 50 多个禁用词，分为三个层级，此外还包括禁用的开头语、结构陷阱（强制三词规则、避免使用系词、过度使用缓和语），以及每段最多只能使用一个破折号的限制。

大多数人会用形容词来描述自己的声音：“专业但平易近人”。这对人工智能来说毫无用处。技术/简洁程度评分为 7 分，就能让模型准确把握声音的定位。禁用词列表的作用更加强大；定义你“不是什么”比定义你“是什么”要容易得多。智能体会将每一份草稿与反模式列表进行比对，并重写任何触发列表的内容。最终生成的内容听起来像我本人，因为这些限制条件防止了它听起来像人工智能生成的。

每个内容模板都包含每500字的语音检查点：“我的开头是否切中要害？我的数据是否具体？我真的会发布这篇文章吗？”博客模板内置了四道编辑工序：结构编辑（开头是否引人入胜？）、语音编辑（检查禁用词汇、句子节奏）、证据编辑（论点是否有来源？）以及朗读测试。这些质量把关是写作技巧的一部分，而不是事后添加的。

模板作为结构化框架：五个内容模板定义了不同内容类型的结构。长篇博客模板包含七个部分（引子、核心概念、框架、实际应用、故障模式、入门指南、结尾），每个部分的字数目标为 2,000-3,500 字。系列文章模板定义了一个包含 11 篇文章的结构，每个文章都包含引子、深度分析、结果和行动号召。研究模板包含四个阶段：现状分析、技术深度分析、证据收集和差距分析。

模板不仅能限制创造力，还能抑制混乱。没有结构，创作者只能写出杂乱无章的文字；有了结构，就能创作出节奏分明、条理清晰、引人入胜的内容。每个模板还包含一份质量检查清单，方便创作者在提交草稿前进行自我评估。

研究模板以结构化格式输出到 knowledge/research/[topic].md 文件，内容包括：执行摘要、概览图、核心概念、证据库（包含统计数据、引文、案例研究和论文，每项均注明来源和日期）、失效模式、内容机会以及可靠性评级为高/中/低的参考文献列表。该研究文档随后会导入博客模板的大纲阶段。一项技能的输出成为下一项技能的输入。整个流程环环相扣。

4）操作系统：我日常是如何实际使用它的

没有执行，建筑设计就毫无意义。 以下是该系统在实际运行中的运作方式。

内容制作流程：七个阶段：构思、研究、大纲、草稿、编辑、发布、推广。

• 所有想法都会被记录到 ideas.jsonl 文件中，并采用评分系统进行评估。每个想法都会根据其与定位的契合度、独特见解、受众需求、时效性以及投入产出比进行 1-5 分的评分。总分达到 15 分或以上即可继续推进。
• 研究成果提交至知识模块。
• 草稿要经过四轮修改。
• 发布的内容会记录到 posts.jsonl 文件中，包括平台、URL 和互动指标。
• 推广活动使用主题模板创建 X 公告和 LinkedIn 版本。

我会在周日集中进行内容创作：3-4小时，目标是完成3-4篇博文的草稿和大纲。内容日历会将每天的内容对应到一个平台和一种内容类型。

个人客户关系管理系统：联系人分为四个层级，维护频率各不相同：核心联系人（每周）、活跃联系人（每两周）、人脉圈联系人（每月）和休眠联系人（每季度重新激活）。每个联系人记录都包含 can_help_with 和 you_can_help_with 字段，用于实现介绍匹配系统。通过交叉引用这些字段，系统会发现对双方都有价值的人脉资源。互动记录会进行情感追踪（正面、中性、需要关注），因此关系健康状况一目了然。

大多数人只是把联系人信息记在脑子里，任由关系因疏于维护而逐渐淡漠。stale_contacts 脚本会交叉比对联系人（他们是谁）、互动记录（上次联系的时间）和社交圈（多久联系一次），从而发现哪些关系需要维系。每周只需 30 秒，我就能知道哪些关系需要关注。

circles.yaml 中的专业群体包括创始人、投资者、人工智能开发者、创作者、导师和学员，每个群体都有明确的关系发展策略。对于人工智能开发者：分享有用的内容、合作开发开源项目、提供工具反馈、推广他们的工作。对于导师：提出具体问题、汇报之前指导的进展情况、寻找回馈价值的方式。这些是当我询问“本周我应该联系谁？”时，系统会遵循的操作指南。

自动化链：五个脚本处理重复性工作流程。它们串联起来执行复合操作。每周日的周回顾会按顺序运行三个脚本：metrics_snapshot.py 更新数据，stale_contacts.py 标记关系，weekly_review.py 生成一份包含已完成与计划对比、指标趋势以及下周优先级的总结文档。内容创意链会读取最近的书签，检查未开发的想法，生成新的建议，并与内容日历交叉引用以查找日程安排上的空档。这些不是定时任务——代理会在我请求回顾时运行它们，或者我可以使用 npm run weekly-review 命令触发它们。

以代理可读格式输出到标准输出的脚本实现了数据与行动之间的闭环。每周回顾脚本不仅告诉我发生了什么，还会参考我的目标，指出哪些关键结果进展顺利，哪些落后，以及下周的优先事项。这些脚本读取的文件与代理在正常运行期间读取的文件相同，因此不存在数据重复或同步问题。

完成每周审查后，代理程序就拥有了更新所需的一切信息。[todos.md]下周，调整 goals.yaml 文件中的进度指标，并针对表现欠佳的关键指标提出相应的内容主题建议。此次评估并非报告，而是下周计划的起点。自动化流程构建了一个反馈循环：目标驱动内容，内容驱动指标，指标驱动评估，评估驱动目标。

5）我的错误之处以及我会如何改进

• 我第一次设计模式时设计得过于复杂。最初的 JSONL 模式每个条目有 15 个以上的字段，其中大部分都是空的。代理程序处理稀疏数据很吃力——它们会尝试填充字段或对缺失的字段进行注释。我把模式精简到 8-10 个必要字段，只有在有实际数据时才添加可选字段。更简洁的模式，代理程序的行为也更好。
• 语音提示一开始太长了。第一版 [语气.md] 原文有1200行。代理人的开头气势如虹，但到了第四段，语音指令就显得冗长乏味，中间部分也显得模糊不清。我重新调整了结构，将最鲜明的模式（标志性短语、禁用词、开场白）放在前100行，并在后面提供更详细的示例。关键规则应该放在开头，而不是中间。
• 模块边界比你想象的更重要。我最初把身份和品牌放在一个模块里。结果，系统加载了我的整个个人简介，而实际上只需要我的禁用词列表。把它们拆分成两个模块后，语音任务的令牌使用量减少了 40%。每个模块边界都代表着一个加载决策。设置错误会导致加载过多或过少。
• 仅追加模式是不可妥协的。我早期丢失了三个月的帖子互动数据，因为一个代理程序重写了 posts.jsonl 文件，而不是追加数据。JSONL 的仅追加模式不仅仅是一种约定，更是一种安全机制。代理程序可以添加数据，但不能删除数据。这是系统中最重要的架构决策。

6）结果及其背后的原理

实际结果比任何指标都简单。我打开 Cursor 或 Claude Code，开始对话，人工智能就已经知道我是谁、我的写作风格、我正在做什么以及我关心什么。它能用我的声音写作，因为我的声音被编码成了结构化数据。它能遵循我的优先级，因为我的目标记录在一个 YAML 文件中，它会在提出工作建议前读取该文件。它能管理我的人际关系，因为我的联系人和互动记录在它可以查询的文件中。

这一切背后的原则是：这是情境工程，而不是提示工程。提示工程问的是“我该如何更好地表述这个问题？”而情境工程问的是“人工智能需要哪些信息才能做出正确的决策，以及我该如何组织这些信息才能让模型真正利用它们？”

这种转变是从优化个体交互转向设计信息架构。这就好比写一封好邮件和构建一个好的文件系统之间的区别。前者只能帮到你一次，后者则每次都能帮到你。

整个系统都装在一个 Git 代码库里。把它克隆到任何机器上，用任何 AI 工具连接，操作系统就能运行。零依赖，完全可移植。而且因为是 Git，每次更改都有版本控制，每个决策都可追溯，数据永远不会真正丢失。

延伸思考

这次分享的内容就到这里了，或许以下几个问题，能够启发你更多的思考，欢迎留言，说说你的想法~

1. 在企业级AI应用场景中，这种基于文件的记忆方案是否具备可扩展性？当数据量达到百万级时，文件系统的检索性能会成为瓶颈吗？
2. 作者强调“文件系统即数据库”的理念，但传统数据库的事务性、一致性保障在AI代理场景中是否真的不重要？如果重要，应该如何补充？
3. 渐进式披露机制本质上是信息架构的优化，这能否推广到更广泛的AI系统设计中？是否存在一种通用的“AI记忆分层模型”？

原文标题：The File System Is the New Database: How I Built a Personal OS for AI Agents[1]

---【本文完】---

👇阅读原文，搜索🔍更多历史文章。

丰子恺-护生画集-舍外早梅/寻香

1. https://x.com/koylanai/article/2025286163641118915 ↩