featured

一、起因：一份漂亮的规范和它的三个陷阱

前几天，一份《Agent OS v1.0 — 完整系统规范》在圈子里流传。它设计了一个七层目录的 Personal AI Operating System：Identity、Knowledge、Working Memory、Episodic Memory、Decisions、Governance、Reflection，配合完整的写入 Pipeline（重要性评分→去重→冲突检测→Schema 验证→写入）和 Token 预算分配。

这份规范非常漂亮——如果对象是企业级 AI 团队。但对于个人使用大模型+Agent 的创作者来说，它踩中了三个经典陷阱。

二、陷阱一：过度架构化

规范设计了 9 层目录：Identity、Knowledge、Working、Episodic、Decision、Scratch、Archive、Reflection、Governance。

每一层都有对应的文件、模板、Pipeline。看起来很完整。但问题在于——Agent 会花越来越多时间管理知识，而不是使用知识。

症状

你创建了一个 reflection/daily/ 目录，写了日反思模板。第一周你认真填了 7 天。第二周填了 3 天。第三周，Agent 开始提醒你「日反思已过期 4 天，是否补填？」你开始回避打开 Agent。

这不是 Agent 的问题，是架构的问题。反思作为一种能力，不应该是一个需要维护的目录，而应该是 Pipeline 中的一个环节。

修正方案：逻辑分层，物理精简

之前（9个物理目录）          之后（5个逻辑层）

identity/                    Identity
knowledge/                   Knowledge
working/                     Workspace（Working + Projects）
episodic/                    History（Episodic + Decisions）
decisions/                   Archive
projects/
scratch/
archive/
reflection/    → Pipeline 能力，不设目录
governance/    → Pipeline 能力，不设目录

Reflection、Validation、Governance 不是存储层，它们是贯穿整个系统的规则。就像你不需要一个叫「质检」的房间——质检是生产线上的一道工序，不是一个仓库。

三、陷阱二：把 Markdown 当数据库

规范中所有知识都存为 Markdown 文件，检索方式是「扫描文件名 + 标签匹配 + 关键词搜索」。这在知识条目 < 100 条时够用，但到 500 条以上就会遇到瓶颈——每次检索都要全量扫描文件系统，O(n) 复杂度，无法做向量语义搜索。

双层架构

更可靠的模式是文本负责保存，数据库负责查询：

Markdown（Source of Truth）         SQLite / LanceDB（Retrieval Index）
─────────────────────────          ────────────────────────────────
长期存储                            Metadata（ID/kind/tags/confidence）
版本控制（Git）                     全文检索（FTS5）
人类可读                            Embedding（语义相似度）
人类可编辑                          关系查询（related/parent/children）
                                   TTL 追踪
                                   过滤排序

写入流程：

Markdown 写入 → Parser 提取 Metadata → 写入 Index

查询流程：

查询条件 → Index 检索 → 返回 ID 列表 → 按需读取 Markdown 正文

这样 Markdown 文件做它擅长的事（存储、版本、可读），数据库做它擅长的事（索引、检索、过滤）。你不需要在 Markdown 上硬扛数据库的功能。

我的实际情况

我自己用的 Hermes Agent 已经有了这个双层基础的雏形：state.db（111MB SQLite，含 FTS5 CJK bigram 全文索引，109 个 session）负责情节记忆检索。但知识层（MEMORY.md）仍然是纯文本全量注入——这意味着每条知识不管有没有用，每轮对话都要塞进上下文。

MEMORY.md 有 2200 字硬上限。这不是检索，这是容量溢出截断。到 99% 时，每加一条就要删一条，像在 1 平米的房间里搬家具。

四、陷阱三：知识图谱过早

规范中设计了 related、parent、children、references 等关系字段，暗示需要维护知识图谱。

很多人做 Agent 容易进入一个误区：「知识图谱一定更智能。」

实际上，对于个人知识库，80% 的收益来自：

  • 高质量 Metadata（kind/source_type/verification/confidence）
  • 稳定 Retrieval（标签 + 全文 + 语义）
  • 良好的 Chunking（语义块 ≠ 文件）
  • 正确的 Ranking（相关度 + 可信度 + 时效性）

而不是复杂图谱。

知识规模达到几千甚至上万条时，再考虑自动生成图谱。一开始就手动维护复杂关系，结果是：你花在维护图谱上的时间比用知识的时间还多——这又回到了陷阱一。

五、五个增量能力：比增加目录更重要

与其继续增加目录，不如增加以下五个能力。

1. 事实与观点分离

很多长期 Agent 最大的问题不是遗忘，而是混淆。

kind:
  fact        — "Rust 发布于 2015"（可验证的客观事实）
  opinion     — "Rust 比 Go 更安全"（观点/判断）
  preference  — "我更喜欢 Rust"（用户偏好）
  assumption  — "假设用户有 Docker 环境"（未验证的假设）
  hypothesis  — "OpenRouter 将成为主流"（探索性推断）

Agent 回答时根据 kind 调整置信度。fact 可以直接引用，hypothesis 必须标注「这是推测」。

2. 来源可信度体系

除了 confidence 数值，再拆一个来源维度：

source_type:
  official    — 官方文档/配置
  personal   — 用户明确声明
  web        — 网络信息
  llm        — AI 推断生成
  inferred   — 从行为推断（未确认）

verification:
  verified   — 已通过实测/用户确认
  pending    — 待验证
  disputed   — 存在矛盾

这样可以避免把 AI 推测和官方文档放在同一层级。source_type=llm 的条目 verification 不能为 verified——哪怕它看起来很有道理。

3. 语义分块（Chunk ≠ 文件）

RAG 最佳实践不是「一个 Markdown = 一个知识」，而是：

一篇 3000 字文章 → 切成：
  ├── 安装（chunk-001）
  ├── 配置（chunk-002）
  ├── API（chunk-003）
  ├── 常见问题（chunk-004）
  └── 性能优化（chunk-005）

每个 Chunk 有独立 Metadata。这样 Top-K 检索更精准——你问「怎么安装」不会拉回「性能优化」的内容。

4. 记忆预算（Memory Budget）

不是所有 Session 都需要读取所有层。

Identity     → 始终加载（300 token）
Workspace    → 按项目加载（500 token）
Knowledge    → Top-K 注入（1500 token）
History      → 最近 N 条（500 token）
Archive      → 默认不加载（0 token）

让 Prompt 大小可预测，而不是随着知识增长不断膨胀。你的上下文预算是固定的，知识条目数是增长的——如果不设预算，迟早撞墙。

5. 可观测性（Observability）

Agent 用久了，你不知道为什么它选了这条知识、忽略了那条。建议记录 Memory Trace：

Query: "怎么部署博客"
  ↓ Retrieved: K04(blog deploy), K02(blog path), K11(blog style)
  ↓ Rank: K04(0.95), K02(0.80), K11(0.60)
  ↓ Injected: K04, K02（Top-2，预算1500 token）
  ↓ Skipped: K11(相关度不足)
  ↓ Reason: "部署相关查询，排除风格偏好"
  ↓ Output: ...

出了问题可以定位，而不是只能猜。这在知识量小的时候看起来多余，但到 50 条以上就会救命。

六、五层抽象：不是六个目录

把整个 Agent OS 重新抽象为五层，不是六个目录：

Interaction Layer     —— User / MCP / API / CLI
       ↓
Reasoning Layer       —— LLM / Planner / Tool Use
       ↓
Memory Layer          —— Identity / Knowledge / Workspace / History
       ↓
Governance Layer      —— Validation / Version / TTL / Conflict / Reflection
       ↓
Storage Layer         —— Markdown + Git + SQLite + Vector Index

最大的区别是：Governance 不是一个目录，而是一套贯穿所有层的规则。

它不存数据，它定义数据的生命周期——写入时验证、存储时标注 TTL、读取时过滤过期、冲突时提示人工、定期时触发反思。Governance 是动词，不是名词。

七、落地实践：我自己的 MEMORY.md Schema 化

说完理论，我自己先把 MEMORY.md 做了 Schema 化改造。

之前（自由文本）

Hugo blog发文路径必须 content/posts/（不是 blogs/），否则首页和 /posts/ 菜单看不到。
§
14 cron reminders (05:30-21:30 Beijing). deliver=origin,telegram...

每条就是一段文字，没有元数据，没有类型，没有过期时间。全量注入每轮上下文。

之后（Schema 化）

[K02|fact|official|verified|∞] Hugo 发文路径必须 content/posts/(不是 blogs/). 日期不超前.
§
[K06|fact|official|verified|180d] 14 cron提醒(05:30-21:30). deliver=origin,telegram双通道. 全含约束行. iLink 30s冷却.

每条头部加 5 个字段：[ID|kind|source_type|verification|ttl]

  • K02 — 唯一 ID
  • fact — 事实（不是观点或假设）
  • official — 来自配置/系统行为
  • verified — 已实测确认
  • ∞ — 永不过期

12 条知识从自由文本变成了结构化条目。虽然仍然是全量注入（因为条目数 < 20，检索不划算），但每个条目都有了类型标签和过期日期。当某天知识量增长到 50 条以上时，可以快速按 kind/source_type/verification/ttl 过滤——而不用重新人工分类。

Schema 规范文件

同时写了一个 MEMORY_SCHEMA.md，定义了字段的取值范围、写入规则和记忆预算分配。这个文件不注入上下文，只在写入新条目时参考。

八、优先级排序：什么决定 Agent 能不能活三年

如果按照长期可维护性排序，真正决定 Agent 能否运行三年以上的优先级是：

  1. Memory 分层 — 不分层，知识就会糊成一锅粥
  2. Metadata 规范 — 没有元数据，检索就是全量扫描
  3. Retrieval Pipeline — 没有检索，上下文就会无限膨胀
  4. Governance（版本、冲突、TTL）— 没有治理，知识就会腐烂
  5. 双存储（Markdown + Index）— 文本存、索引查，各司其职
  6. Reflection — 没有反思，就不知道系统在退化
  7. Knowledge Graph — 锦上添花，不是基础设施

知识图谱是锦上添花。真正让系统长期稳定的，是清晰的数据模型、可验证的写回流程、以及高效的检索与治理。

九、结语：Agent OS 不是架构图，是生命周期

Agent OS v1.0 规范的架构图很漂亮，但它最大的问题是——把一个动态的生命周期问题当成了静态的目录结构问题。

知识不是放在哪个文件夹的问题，知识是「从哪来→什么类型→多可信→什么时候过期→谁验证的→怎么检索→怎么淘汰」的完整链路。

目录结构只需要 5 个：Identity、Knowledge、Workspace、History、Archive。但贯穿这 5 个目录的生命周期管理——Schema、TTL、冲突检测、检索预算、可观测性——才是真正让 Agent OS 运行十年的基础设施。

最好的架构不是最完整的，而是最不会让你花时间维护它的。

延伸阅读