Obsidian Wiki — 让个人知识同时对人和 Agent 可用
以 raw 原文层、LLM 编译层、MOC 索引和可执行工作流，构建可追溯、可检索、可持续维护的本地知识系统
发布时间：2026/6/20
Obsidian Wiki 是我为自己构建的本地知识系统。它既要适合人在 Obsidian 中阅读和连接，也要让 AI Agent 能够理解内容来源、执行摄入与查询，并把新的结论可靠地写回知识库。
为什么做
知识管理真正困难的地方，不只是文件越来越多。当网页原文、我的加工结论、项目资料和 Agent 的临时状态混在一起时，任何一次搜索都可能得到无法追溯的答案；Agent 也不知道哪些文件可以修改、哪些内容必须保持原样。
所以我没有继续增加更复杂的标签和文件夹，而是先解决知识的生命周期：资料从哪里来，经过什么加工，如何进入索引，使用后又怎样回流。
关键产品决策
raw/是永久原文层 — 外部资料只增不改，保留来源和原始上下文，为后续结论提供可追溯证据wiki/是 LLM 编译层 — Agent 完整阅读原文后创建或复用结构化笔记，不复制整篇内容- 索引与内容分离 — MOC 页面集中放在
wiki/索引/，承担知识导航；内容笔记拍平，避免目录层级替代语义关系 - 短期状态不冒充长期知识 —
tasks/hot-cache.md只记录当前目标、最近决策和开放下一步，不进入 Wiki 总索引 - 规则本身可以执行 — Agent 的目录权限、Frontmatter、Markdown 风格和任务流程都写成明确规范，而不是依赖口头约定
从采集到知识回流
整个知识循环由 Ingest、Query、Retrieve 和 Lint 四类工作流组成。采集时先保留 raw 原文，再生成或更新编译层笔记和索引；查询时先读总索引，再读取少量相关页面，只有需要核实证据时才回到 raw 层。
这条分层路径控制了检索成本，也减少了 Agent 用局部关键词直接猜分类的风险。每次查询还会判断是否需要更新 Wiki，让临时结论有机会回到长期知识，而不是停留在一次对话里。
可维护性设计
所有加工笔记使用统一 Properties，保留来源、作者、日期、描述和标签。标签遵循稳定、简短、以简体中文为主的约束；被纠正后能够跨任务复用的经验进入 tasks/lessons.md，避免 Agent 重复犯同类错误。
这些规则不是为了追求格式整齐，而是为了让每条知识都能回答三个问题：它来自哪里、现在表达什么、未来怎样被找到和更新。
当前状态
知识库在持续增长，共享工作流已经用于日常资料摄入、查询、检索和维护。当前根目录没有全库自动校验脚本，因此文档质量仍以范围明确的检查和实际使用反馈为准。