文件系统就是新的数据库：我是如何为 AI Agent 构建个人操作系统的
每一次与 AI 的对话几乎都从相同的方式开始。你先解释你是谁。你解释你在做什么。你贴上你的风格指南。你重新描述你的目标。你给出昨天、前天、大前天都给过的相同上下文。然后聊到第40分钟，模型就忘记了你的语气，开始写得像新闻稿一样。
我受够了。所以我构建了一个系统来解决这个问题。
我称之为 Personal Brain OS（个人大脑操作系统）。它是一个基于文件的个人操作系统，全部存在于一个 Git 仓库中。克隆它，在 Cursor 或 Claude Code 中打开，AI 助手就拥有了一切：我的语气、我的品牌、我的目标、我的联系人、我的内容生产流水线、我的研究、我的失败经历。不需要数据库、不需要 API Key、不需要构建步骤。只需 80+ 个用 Markdown、YAML 和 JSONL 格式写的文件，人类和语言模型都能原生读取。
Context Engineering 技能让我的项目创建速度提升了10倍。
我用 Claude Code 和 Context Plugin 重建了我的数字大脑系统，现在它已经成为一个真正的 Personal OS。
它提供了一个完整的基于文件夹的架构，用于管理：
- 个人品牌 - 语气、定位、价值观
- 内容
我是如何构建一个 AI agent 系统，能够根据我互动的内容自动维护我的数字大脑？
我的个人上下文工程架构，使用 Claude Sonnet 4.5、Groq Compound、Browser Use，全都在 Cursor 里 👇
我把完整的架构、设计决策和踩过的坑都分享出来，让你能构建出你自己的版本。不是抄我的，而是属于你的。具体模块、文件 schema、技能定义都会因你的工作而不同。但模式是可迁移的。为 AI agent 结构化信息的原则是通用的。拿走适合你的，忽略不适合的，然后尽快做出一个真正对你有用的 AI，而不是泛泛地"帮忙"。
下面是我如何构建它、为什么这些架构决策重要，以及我吃过的苦头学到的教训。
1) 核心问题：是上下文，而不是 Prompt
大多数人认为 AI 助手的瓶颈在于 Prompt。写更好的 Prompt，就能得到更好的回答。这在单次交互和生产级 agent Prompt 上是对的。但当你希望 AI 在几十个任务、几周甚至几个月的时间里像"你"一样运作时，这个方法就崩了。
注意力预算：语言模型的上下文窗口是有限的，而且并不是所有 token 都平等重要。把你知道的一切都塞进 system prompt 不只是浪费，它会主动降低性能。每一个你加进去的 token 都在和模型的注意力竞争。
我们的大脑也类似。有人在会议前给你讲15分钟，你记住的是开头第一句和结尾一句，中间模糊。语言模型也有类似的 U 型注意力曲线，只是它们的曲线可以用数学精确测量。token 位置会影响召回概率。新模型在这方面越来越好，但仍然，你在分散模型对最重要事情的关注。知道这一点，会彻底改变你为 AI 系统设计信息架构的方式。
渐进式披露（Progressive Disclosure）：这是让整个系统运转起来的核心架构模式。不是一次性加载全部 80+ 个文件，而是用三级结构：
- Level 1：轻量路由文件（总是加载），告诉 AI 当前任务属于哪个模块。
- Level 2：模块专属指令，只在需要时加载。
- Level 3：实际数据（JSONL 日志、YAML 配置、研究文档），只在任务真正需要时加载。
这模仿了专家的工作方式。三级结构形成一个漏斗：广义路由 → 模块上下文 → 具体数据。每一步模型都只拿到它真正需要的东西，没有多余内容。
我的路由文件是 SKILL.md，它告诉 agent："这是内容任务，加载品牌模块"或"这是网络任务，加载联系人"。模块指令文件（CONTENT.md、OPERATIONS.md、NETWORK.md）每份 40--100 行，包含文件清单、工作流序列和 <instructions> 行为规则。数据文件最后加载，AI 从 JSONL 中逐行读取联系人，而不是一次性解析整个文件。三级结构，到任何信息最多两跳。
Agent 指令层级：我构建了三层指令，在不同粒度约束 AI 行为：
- 仓库级：
CLAUDE.md是 onboarding 文档，每个 AI 工具首先读取它，获得项目全景图。 - 大脑级：
AGENT.md包含七条核心规则 + 决策表，把常见请求映射到精确的行动序列。 - 模块级：每个目录有自己的指令文件，带有领域专属行为约束。
这解决了大型 AI 项目常见的"指令冲突"问题。当所有规则放在一个 system prompt 时，它们互相打架。内容创作指令可能和网络指令冲突。通过把规则限定在领域内，消除了冲突，agent 获得清晰、不重叠的指导。层级结构还允许你更新一个模块的规则，而不影响其他模块的行为。
我的 AGENT.md 是一个决策表。AI 读到"用户说 '给 Z 发邮件'"，立刻看到：
Step 1：在 HubSpot 查找联系人
Step 2：验证邮箱
Step 3：通过 Gmail 发送
模块级文件如 OPERATIONS.md 定义优先级（P0：今天做，P1：本周，P2：本月，P3： backlog），让 agent 按照我本人的方式一致地对任务排序。因为优先级被编码了，而不是隐含的。
2) 文件系统即记忆
我做的最反直觉的决定之一：不用数据库、不用向量库、不用检索系统（除了 Cursor / Claude Code 自带功能）。就只是磁盘上的文件，用 Git 版本控制。
格式-功能映射：系统里每种文件格式都是针对 AI agent 处理信息的方式精心选择的：
- JSONL 用于日志：天生 append-only、流式友好（agent 逐行读，不用解析全文件）、每行都是独立的合法 JSON。
- YAML 用于配置：层级数据清晰、支持注释、人机可读，不像 JSON 那么多括号噪音。
- Markdown 用于叙事：LLM 原生读取、各处渲染好、Git diff 干净。
JSONL 的 append-only 特性避免了一类 bug：agent 误写全文件导致覆盖历史数据。我见过 JSON 文件被 agent 重写，三个月联系人历史没了。用 JSONL，agent 只能加行。删除靠标记 "status": "archived"，保留完整历史供模式分析。YAML 的注释让我能在目标文件里加上下文说明，agent 能读但不污染数据结构。Markdown 的通用渲染让我的语气指南在 Cursor、GitHub、浏览器里看起来都一样。
系统里有 11 个 JSONL 文件（posts、contacts、interactions、bookmarks、ideas、metrics、experiences、decisions、failures、engagement、meetings）、6 个 YAML 文件（goals、values、learning、circles、rhythms、heuristics）、50+ 个 Markdown 文件（语气指南、研究、模板、草稿、todos）。每个 JSONL 文件开头都有 schema 行：{"_schema": "contact", "_version": "1.0", "_description": "..."}，agent 读数据前先知道结构。
情景记忆（Episodic Memory） ：大多数"第二大脑"系统只存事实。我的系统还存判断。memory/ 模块有三个 append-only 日志：
experiences.jsonl：关键时刻 + 情感权重（1-10）decisions.jsonl：关键决策 + 推理、备选方案、结果跟踪failures.jsonl：出错了什么、根因、预防措施
事实告诉 agent 发生了什么，情景记忆告诉 agent 什么重要、我会怎么改、我是如何权衡的。当 agent 遇到类似决策时，它可以引用我过去的真实推理，而不是给泛泛建议。失败日志最有价值，它编码了真正通过痛苦获得的模式识别。
跨模块引用 ：系统用扁平文件关系模型。没有数据库，但结构足够让 agent 跨文件 join 数据。interactions.jsonl 里的 contact_id 指向 contacts.jsonl。ideas.jsonl 里的 pillar 映射到 identity/brand.md 定义的内容支柱。书签喂内容 idea，帖子指标喂周报。模块加载时隔离，但推理时连通。
"为我和 Sarah 的会面做准备"会触发查找链：contacts 找人 → interactions 拉历史 → todos 找待办 → 合成一页简报。agent 按需跨模块遍历知识图谱，不加载全系统。
3) 技能系统：教 AI 如何做你的工作
文件存储知识，技能编码流程。我按照 Anthropic Agent Skills 标准构建了 Agent Skills，结构化指令告诉 AI 如何高质量完成具体任务，内置质量关卡。
自动加载 vs 手动调用：
- 参考类技能（voice-guide、writing-anti-patterns）：
user-invocable: false，agent 根据任务描述自动注入。写东西时自动激活，我从不手动调用。 - 任务类技能（/write-blog、/topic-research）：
disable-model-invocation: true，agent 不能自己触发。我输入 slash 命令，技能就成为该任务的完整指令集。
自动加载解决一致性问题，我不用每次都提醒"用我的语气"。手动调用解决精确性问题。研究任务和写博客的质量关卡完全不同，分开避免混淆。YAML frontmatter 控制加载行为。
输入 /write-blog context engineering for marketing teams 时，自动发生五件事：加载语气指南、反模式、博客模板、检查受众 persona、检查已有研究。一个命令触发完整上下文组装。技能文件只引用源模块（如 "Read brand/tone-of-voice.md"），永不复制内容，单一真相来源。
语气系统：我的语气被结构化 + 少量 vibe 编码。语气 profile 在五个维度打分（1-10）：正式/随意 (6)、严肃/玩闹 (4)、技术/简单 (7)、内敛/表达 (6)、谦逊/自信 (7)。反模式文件有 50+ 个禁词（分三级）、禁开头、结构陷阱（强行三点式、避免系动词、过度 hedge）、每段最多一个 em-dash。定义"你不是什么"比定义"你是什么"更容易。agent 每稿都对照反模式检查并改写，结果就是听起来像我，而不是 AI。
模板作为结构化脚手架 ：五种内容模板定义不同类型结构。长文博客模板有七段（Hook、Core Concept、Framework、Practical Application、Failure Modes、Getting Started、Closing），每段字数目标，总计 2000--3500 字。研究模板有四阶段：景观映射、技术深潜、证据收集、缺口分析。输出结构化到 knowledge/research/[topic].md，包含执行摘要、景观图、核心概念、证据库（统计、引用、案例、论文都带来源和日期）、失败模式、内容机会、来源可靠性分级。研究文档再喂给博客模板的 outline 阶段。一条技能的输出成为下一条的输入，流水线自增强。
4) 操作系统：我日常如何使用它
内容流水线 ：七阶段 Idea → Research → Outline → Draft → Edit → Publish → Promote。
Idea 进 ideas.jsonl，按定位契合度、独特洞见、受众需求、时效性、投入产出比打 1--5 分，总分 ≥15 才推进。
周日批量创作：3--4 小时，目标 3--4 篇草稿 + 大纲。内容日历映射每天的平台和类型。
个人 CRM ：联系人分四层圈子，不同维护频率：核心（每周）、活跃（双周）、网络（每月）、休眠（季度激活）。每人记录 can_help_with 和 you_can_help_with，支持互助介绍匹配。互动记录带情感标签（positive、neutral、needs_attention）。每周 30 秒扫描 stale_contacts 脚本，显示哪些关系需要维护。
自动化链 ：五个脚本处理循环工作流。周报运行三个脚本：metrics_snapshot.py 更新数据、stale_contacts.py 标记关系、weekly_review.py 生成总结（完成 vs 计划、指标趋势、下周优先级）。这些脚本输出 agent 可读格式，闭环数据与行动。
5) 我做错了什么，以后会怎么改
- 第一版 schema 过度设计，15+ 字段，大多为空。agent 会试图填充空字段或评论缺失。后来砍到 8--10 个核心字段 + 按需可选，简单 schema 让 agent 表现更好。
- 语气指南最初太长（1200 行），agent 前强后飘。改成前 100 行放最独特模式（标志短语、禁词、开头规律），关键规则前置。
- 模块边界比想象中重要。最初 identity 和 brand 放一起，导致只需要禁词时也加载整份 bio。拆成两个模块，纯语气任务 token 减少 40%。
- append-only 不可妥协。早期 agent 重写
posts.jsonl丢三个月数据。JSONL 不是习惯，而是安全机制：能加，不能毁。
6) 结果与背后的原则
最真实的结果很简单：打开 Cursor 或 Claude Code 开始对话，AI 已经知道我是谁、怎么写作、在做什么、在意什么。它用我的语气写作，因为语气被结构化编码。它按我的优先级建议，因为目标在 YAML 文件里。它管理我的关系，因为联系人和互动在可查询的文件里。
这一切背后的原则是：这是上下文工程（Context Engineering），而不是 Prompt 工程。
Prompt 工程问："怎么把这个问题问得更好？"
上下文工程问："AI 需要什么信息才能做出正确决定？我该如何结构化这些信息，让模型真正用得上？"
从优化单次交互，转向设计信息架构。就像写一封好邮件 vs 建一个好文件系统。前者帮你一次，后者每次都帮你。
整个系统装在一个 Git 仓库里。克隆到任何机器，指向任何 AI 工具，操作系统就运行了。零依赖、完全可移植。因为是 Git，每次变更都有版本，每项决策可追溯，什么都不会真正丢失。
Muratcan Koylan 是 Sully.ai 的 Context Engineer，设计医疗 AI 的上下文工程系统。他的上下文工程开源工作（GitHub 8,000+ stars）被学术研究引用，与 Anthropic 并列。之前在 99Ravens AI 担任 AI Agent 系统经理，构建处理每周 10,000+ 交互的多 agent 系统。