🧵 讨论帖：用纯 Markdown 文件构建代理操作系统，真的比数据库更可行吗？

在 AI Agent 开发圈，我们似乎陷入了一种“军备竞赛”：更大的模型、更复杂的 RAG 架构、更重的数据库中间件。

但最近一个来自 Google 资深产品经理 Shubham Saboo 的实验，可能会颠覆你的认知。

他用 40 天证明：让 Agent 变聪明的，不是架构复杂度，而是持续的上下文积累。

而他的“操作系统”，竟然只是一堆 纯 Markdown 文件。

1️⃣ 实验背景：40 天的“文件流”革命

Shubham 没有使用向量数据库，没有消息队列，也没有复杂的编排框架。

他只做了最简单的一件事：每天和代理聊天、给反馈，看着它们把反馈“写下来”。

40 天后的结果令人震惊：

• 内容代理 Kelly：完美模仿了他的写作风格（去掉了以前滥用的表情和标签）。
• 研究代理 Dwight：每天早上输出 7 条高质量、可直接行动的 AI 趋势故事（以前全是噪音）。
• 运维成本：整个团队 8 个代理 24/7 运行，他只需打开 Telegram 审稿、喝咖啡。

关键点： 使用的模型从头到尾没变。变化的只有一套 纯 Markdown 文件构成的“操作系统”。

2️⃣ 核心逻辑：文件系统即集成层

为什么大家默认 Agent 需要数据库？为了持久化记忆，对吧？

但 Shubham 的方案表明：文件读写本身就能实现持久化，且更透明。

• 文件不是静态的：它们会随着反馈不断进化。
• 无会话记忆：代理之间没有隐藏的会话状态，一切靠文件读写。
• 共享上下文：一次修正能传播到所有代理，极大减少重复劳动。

这不仅仅是存储，这是 积累的个性化上下文，是别人用同样模型也复制不了的 护城河。

3️⃣ 架构拆解：三层 Markdown 栈

这套“Markdown OS"分为清晰的三层，每一层都是可读可写的 .md 文件：

🟢 Layer 1：Identity（身份层）

• 定义：代理是谁？注入人格和用户上下文。
• 核心文件：SOUL.md
• 技巧：用电视剧角色命名（如 Dwight），利用模型预训练知识瞬间注入性格。
• 示例：

  # Identity
  你是 Dwight Schrute，彻底、激烈、对工作极其认真。
  # Role
  扫描新兴 AI 工具，找出开发者今天就能用的东西。
  # Principles
  - 彻底：验证来源
  - 激烈：优先可行动洞见

🔵 Layer 2：Operations（操作层）

• 定义：代理怎么工作？
• 功能：定义工作流、触发条件和输出格式。

🟠 Layer 3：Knowledge（知识层）

• 定义：代理学到了什么？
• 功能：存储累积的反馈、历史决策和领域知识。

4️⃣ 为什么这可能比数据库更“可行”？

对于个人开发者或小团队，这种方案有几个降维打击的优势：

1. 可调试性极强：你可以直接用文本编辑器打开“记忆”，查看 Agent 到底记住了什么。数据库里的向量你是看不懂的。
2. 版本控制友好：Markdown 文件可以直接进 Git。你可以回滚代理的“性格”，查看知识演进历史。
3. 低成本启动：不需要维护 Postgres、Milvus 或 Redis。只要有文件系统的地方就能跑。
4. 上下文即代码：修改代理行为不需要改代码，只需要改 Markdown 里的指令。

5️⃣ 潜在挑战与讨论

当然，这种方案并非银弹。当数据量达到百万级，或者需要复杂查询时，文件系统可能会遇到瓶颈。

但在 Agent 的早期阶段，我们是否过度工程化了？

Shubham 的经验是：你唯一需要做的就是每天和代理对话。 这种人机协作的进化速度，可能远超优化数据库查询带来的收益。

🎙️ 互动话题

我想听听大家的看法：

1. 可行性：在你的项目中，是否尝试过用文件代替数据库存储 Agent 状态？体验如何？
2. 扩展性：你认为这套"Markdown OS"架构的边界在哪里？多少代理/多少数据量后会失效？
3. 护城河：你同意“积累的个性化上下文才是真正的护城河”这一观点吗？

👇 请在评论区留下你的观点，我们一起探讨 Agent 架构的极简主义之路！