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

鲨叔
0 阅读10分钟

摘要

我最近读到 @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["第一层：路由文件<br/>始终加载，指引方向"] --> L2["第二层：模块指令<br/>按需加载模块说明"]
    L2 --> L3["第三层：实际数据<br/>任务需要时才加载"]
  • 第一层是轻量级路由文件（SKILL.md），始终加载，告诉 AI"这是内容任务，加载品牌模块"或"这是社交任务，加载联系人"
  • 第二层是模块级指令文件（如 CONTENT.md、OPERATIONS.md），每个 40-100 行，包含文件清单、工作流程和行为规则
  • 第三层是实际数据文件（JSONL 日志、YAML 配置、研究文档），仅在任务需要时加载

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

Agent 指令层级

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

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

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

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

记忆模块（Memory Module）

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

flowchart LR
    E["experiences.jsonl<br/>经历日志"] --- D["decisions.jsonl<br/>决策日志"]
    D --- F["failures.jsonl<br/>失败日志"]
  • 经历日志：记录什么事情重要、我会怎么做不同的选择
  • 决策日志：记录我对权衡取舍的思考方式
  • 失败日志：作者认为这是最有价值的——它编码了用真实代价换来的模式识别能力

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

语音编码与内容框架

语音编码（Voice Encoding）

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

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

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

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

质量关卡（Quality Checkpoints）

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

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

内容模板

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

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

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

日常实际使用

内容流水线

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

flowchart LR
    I["创意<br/>评分 ≥15 通过"] --> R["研究<br/>输出到知识模块"]
    R --> O["大纲"]
    O --> D["草稿<br/>四轮编辑"]
    D --> P["发布<br/>记录到 posts.jsonl"]
    P --> PR["推广<br/>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<br/>更新数据指标"] --> S["stale_contacts.py<br/>标记待维护关系"]
    S --> W["weekly_review.py<br/>生成周报摘要"]
    W --> N["更新下周 todos<br/>调整目标进度"]

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

踩过的坑与反思

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

  1. Schema 过度设计：初版 JSONL schema 每条记录有 15 个以上字段，但大多为空。Agent 面对稀疏数据会试图填充空字段或评论字段缺失，反而影响行为。精简到 8-10 个核心字段后，Agent 表现明显改善

  2. 语音指南过长：初版 tone-of-voice.md 长达 1,200 行。Agent 在第四段左右就开始偏离，因为语音规则落入了"中间遗忘区"。重构后将最有辨识度的规则（标志性用语、禁用词、开头模式）前置到前 100 行，效果显著提升

  3. 模块边界划分不当：最初将身份和品牌放在一个模块里，导致 Agent 加载禁用词列表时会连带加载整个个人简介。拆分为两个模块后，纯语音任务的 token 消耗减少了 40%。每个模块边界都是一个加载决策，划错了就会加载过多或过少

  4. 追加写入不可妥协：因为 Agent 重写而非追加 posts.jsonl，丢失了三个月的帖子互动数据。这让作者彻底确信：JSONL 的追加模式不是约定，而是安全底线

核心原则

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

flowchart LR
    PE["提示词工程<br/>如何更好地措辞问题"] -.- CE["上下文工程<br/>AI 需要什么信息<br/>如何组织这些信息"]
  • 提示词工程问的是："我怎么把这个问题问得更好？"
  • 上下文工程问的是："AI 做出正确决策需要什么信息，以及如何组织这些信息让模型真正使用它？"

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

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

关键术语对照

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

参考资料

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