文件系统即数据库：用文件为 AI Agent 构建个人操作系统

摘要

我最近读到 @koylanai 的一篇长文，他是 Sully.ai 的上下文工程师（Context Engineer），在文中系统分享了自己如何用纯文件系统（Markdown + YAML + JSONL）构建了一套个人 AI 操作系统------Personal Brain OS。这套系统不依赖数据库、不需要 API 密钥、没有构建步骤，仅靠 Git 仓库中的 80 多个文件，就让 AI 助手能持久记住他的写作风格、工作目标、人脉关系和内容流水线。文章从架构设计、文件格式选型、语音编码到实际日常使用流程都有详细拆解，对于想让 AI 工具真正"懂自己"的人来说，非常有实操参考价值。以下是我的整理。

正文

核心问题：上下文，而非提示词

作者开篇就指出了一个普遍痛点：每次与 AI 对话都要重复交代"我是谁、我在做什么、我的风格是什么"，四十分钟后模型就会遗忘你的语气，开始像写新闻稿一样输出。

多数人认为 AI 助手的瓶颈在于提示词工程（Prompt Engineering），但作者认为这只在单次交互中成立。当你需要 AI 在数周甚至数月内像你一样处理几十种任务时，真正的瓶颈是上下文工程（Context Engineering）。

注意力预算（Attention Budget）

语言模型的上下文窗口是有限的，而且并非所有位置的记忆效果相同。把所有信息塞进系统提示词不仅浪费 token，还会主动降低性能------每增加一个 token 都在与模型的注意力竞争。语言模型存在与人类类似的 U 形注意力曲线：开头和结尾记得最清楚，中间部分容易模糊。

基于这一认知，作者没有编写一个巨大的系统提示词，而是将 Personal OS 拆分为 11 个独立模块。写博客时加载语音和品牌文件，准备会议时加载联系人和交互历史，彼此互不干扰。

渐进式披露（Progressive Disclosure）

这是整个系统的核心架构模式。系统不会一次性加载全部 80 多个文件，而是分三层按需加载：

flowchart TD L1["第一层：路由文件
始终加载，指引方向"] --> L2["第二层：模块指令
按需加载模块说明"] L2 --> L3["第三层：实际数据
任务需要时才加载"]

第一层 是轻量级路由文件（SKILL.md），始终加载，告诉 AI"这是内容任务，加载品牌模块"或"这是社交任务，加载联系人"
第二层 是模块级指令文件（如 CONTENT.md、OPERATIONS.md），每个 40-100 行，包含文件清单、工作流程和行为规则
第三层是实际数据文件（JSONL 日志、YAML 配置、研究文档），仅在任务需要时加载

这模仿了专家的工作方式：先定位方向，再聚焦领域，最后调取具体数据。任何信息最多两跳即可到达。

Agent 指令层级

作者构建了三层指令体系来约束 AI 在不同层级的行为：

flowchart TD R["仓库级：CLAUDE.md
全局地图与入门"] --> B["Brain 级：AGENT.md
核心规则与决策表"] B --> M["模块级：各目录指令
领域专属行为约束"]

仓库级 ：CLAUDE.md 作为入门文档，任何 AI 工具首先读取，获得项目全貌
Brain 级 ：AGENT.md 包含 7 条核心规则和一张决策表，将常见请求映射到精确的操作序列
模块级：每个目录有自己的指令文件，定义领域专属的行为约束

这解决了"指令冲突"问题。当所有规则挤在一个系统提示词中，内容创作指令可能与社交指令互相矛盾。通过将规则限定在各自领域，冲突被消除，且更新某个模块不会影响其他模块的行为。

文件系统即记忆

作者做了一个反直觉的决定：不用数据库，不用向量存储，不用检索系统，只用磁盘上的文件加 Git 版本控制。

格式与功能的映射

每种文件格式都经过针对性选择：

格式	用途	选择原因
JSONL	日志数据	天然追加写入、流式读取、每行独立有效
YAML	配置数据	层次结构清晰、支持注释、人机可读
Markdown	叙述内容	LLM 原生可读、Git diff 友好、全平台可渲染

JSONL 的追加写入（Append-only）特性尤其关键------它从机制上防止了 AI 误覆盖历史数据。作者早期就因为 Agent 重写了整个 posts.jsonl 文件而丢失了三个月的互动数据。追加写入不是约定，而是安全机制：Agent 只能增加数据，不能销毁数据。删除操作通过标记 "status": "archived" 来实现，保留完整历史供模式分析。

每个 JSONL 文件都以 schema 行开头：

json 复制代码

{"_schema": "contact", "_version": "1.0", "_description": "..."}

Agent 在读取数据前就已了解文件结构。

记忆模块（Memory Module）

多数"第二大脑"系统只存储事实，而这套系统同时存储判断（Judgment）。memory/ 模块包含三个追加写入日志：

flowchart LR E["experiences.jsonl
经历日志"] --- D["decisions.jsonl
决策日志"] D --- F["failures.jsonl
失败日志"]

经历日志：记录什么事情重要、我会怎么做不同的选择
决策日志：记录我对权衡取舍的思考方式
失败日志：作者认为这是最有价值的------它编码了用真实代价换来的模式识别能力

拥有文件的 AI 和拥有判断力的 AI 是完全不同的。当 Agent 遇到类似决策时，可以参考过去的推理记录，而不是生成泛泛的建议。

语音编码与内容框架

语音编码（Voice Encoding）

作者将个人写作风格编码为结构化数据，而非模糊的形容词。语音档案用 1-10 的刻度评估五个维度：

维度	得分	含义
正式/随意	6	偏正式
严肃/活泼	4	偏严肃
技术/通俗	7	偏技术
克制/表达	6	略偏表达
谦逊/自信	7	偏自信

此外还有一份反模式文件（Anti-patterns），包含 50 多个分三级的禁用词、禁用开头、结构陷阱（如强行凑"三点式"、过度使用系动词、过多对冲用语），以及硬性规定每段最多使用一个破折号。

作者的经验是：用"不是什么"来定义语音比用"是什么"更有效。Agent 会对照反模式清单检查每一篇草稿，命中的部分会被重写。

质量关卡（Quality Checkpoints）

每个内容模板每 500 字嵌入一次语音检查点，提示 Agent 自问："我是否以洞察开头？是否给出了具体数据？这篇我真的会发吗？"博客模板内置四轮编辑流程：

flowchart LR P1["结构编辑
开头能抓住人吗"] --> P2["语音编辑
禁用词扫描"] P2 --> P3["证据编辑
论点有来源吗"] P3 --> P4["朗读测试
读出来顺不顺"]

内容模板

系统定义了五种内容模板，每种都有明确的结构约束：

长文博客模板：7 个章节（Hook → 核心概念 → 框架 → 实践应用 → 失败模式 → 上手指南 → 结尾），总字数目标 2,000-3,500 词
推文串模板：11 条推文结构，含 Hook、深度分析、结果展示和行动召唤
研究模板：4 个阶段（全景扫描 → 技术深入 → 证据收集 → 缺口分析），输出带可靠度分级（HIGH/MEDIUM/LOW）的结构化研究文档

模板的价值在于约束混乱而非约束创意。研究模板的产出会直接输入博客模板的大纲阶段------上一个技能的输出成为下一个技能的输入，流水线自我叠加。

日常实际使用

内容流水线

七个阶段：创意 → 研究 → 大纲 → 草稿 → 编辑 → 发布 → 推广。

flowchart LR I["创意
评分 ≥15 通过"] --> R["研究
输出到知识模块"] R --> O["大纲"] O --> D["草稿
四轮编辑"] D --> P["发布
记录到 posts.jsonl"] P --> PR["推广
X + LinkedIn 适配"]

创意通过评分系统筛选，从定位匹配度、独特洞察、受众需求、时效性、投入产出比五个维度各评 1-5 分，总分达到 15 分才进入下一步。作者每周日批量创作 3-4 小时，目标产出 3-4 篇草稿。

个人 CRM

联系人按关系密度分四圈，维护频率各不相同：

圈层	维护频率	说明
核心圈	每周	最亲密的联系人
活跃圈	双周	经常互动的联系人
网络圈	每月	一般社交网络
休眠圈	每季度	需要重新激活的关系

每条联系人记录包含 can_help_with（对方能帮什么）和 you_can_help_with（你能帮对方什么）字段，用于匹配互惠引荐。互动记录带有情感追踪（积极/中性/需关注），让关系健康度一目了然。stale_contacts 脚本交叉引用联系人、互动记录和圈层信息，自动浮现需要维护的关系。

自动化链

五个脚本处理日常工作流，可以串联执行。例如周日复盘流程：

flowchart LR M["metrics_snapshot.py
更新数据指标"] --> S["stale_contacts.py
标记待维护关系"] S --> W["weekly_review.py
生成周报摘要"] W --> N["更新下周 todos
调整目标进度"]

脚本输出 Agent 可读的格式，周报不只是回顾------它引用目标文件，识别哪些关键成果在轨道上、哪些落后、下周该优先什么。复盘自动形成反馈闭环：目标驱动内容，内容驱动数据，数据驱动复盘，复盘驱动目标。

踩过的坑与反思

作者坦诚分享了四个教训：

Schema 过度设计：初版 JSONL schema 每条记录有 15 个以上字段，但大多为空。Agent 面对稀疏数据会试图填充空字段或评论字段缺失，反而影响行为。精简到 8-10 个核心字段后，Agent 表现明显改善
语音指南过长 ：初版 tone-of-voice.md 长达 1,200 行。Agent 在第四段左右就开始偏离，因为语音规则落入了"中间遗忘区"。重构后将最有辨识度的规则（标志性用语、禁用词、开头模式）前置到前 100 行，效果显著提升
模块边界划分不当：最初将身份和品牌放在一个模块里，导致 Agent 加载禁用词列表时会连带加载整个个人简介。拆分为两个模块后，纯语音任务的 token 消耗减少了 40%。每个模块边界都是一个加载决策，划错了就会加载过多或过少
追加写入不可妥协 ：因为 Agent 重写而非追加 posts.jsonl，丢失了三个月的帖子互动数据。这让作者彻底确信：JSONL 的追加模式不是约定，而是安全底线

核心原则

作者最后总结：整个系统背后的原则是上下文工程，而非提示词工程。

flowchart LR PE["提示词工程
如何更好地措辞问题"] -.- CE["上下文工程
AI 需要什么信息
如何组织这些信息"]

提示词工程问的是："我怎么把这个问题问得更好？"
上下文工程问的是："AI 做出正确决策需要什么信息，以及如何组织这些信息让模型真正使用它？"

这是从优化单次交互到设计信息架构的转变。前者像写一封好邮件，帮你一次；后者像建一套好的归档系统，每次都帮你。

整个系统装在一个 Git 仓库里。克隆到任意机器，指向任意 AI 工具，操作系统就跑起来了。零依赖，完全可移植，且因为是 Git，每一次变更都有版本记录，每一个决策都可追溯。

关键术语对照

英文术语	中文翻译	说明
Context Engineering	上下文工程	设计和组织 AI 所需信息架构的系统方法，区别于单次提示词优化
Prompt Engineering	提示词工程	通过优化提示词措辞来改善 AI 输出的方法
Progressive Disclosure	渐进式披露	按需分层加载信息的架构模式，避免一次性加载全部上下文
Attention Budget	注意力预算	语言模型有限的上下文窗口中，token 对注意力的竞争
Append-only	追加写入	只允许新增数据、不允许覆盖的写入模式，防止数据丢失
JSONL	JSONL	JSON Lines 格式，每行一条独立 JSON 记录
Voice Encoding	语音编码	将个人写作风格量化为结构化数据的方法
Anti-patterns	反模式	需要避免的写作模式，如禁用词、禁用结构等
Personal Brain OS	个人大脑操作系统	作者构建的基于文件系统的 AI Agent 个人知识管理系统
Agent Skills	Agent 技能	以 Markdown 形式编码的结构化知识，指导 Agent 如何执行特定领域任务

参考资料

来源	摘要	链接
@koylanai	Agent Skills for Context Engineering 开源仓库，提供平台无关的上下文工程技能标准，已获 8,000+ GitHub 星标	github.com/muratcankoy...