立正谈到聊天窗口的限制时指出，深度知识工作常要分叉、引用另一条信息、比较不同方案，还要处理图文混排、表格、带格式长文和多文件差异；这些在聊天窗口里组织起来很不自然。他还强调，涉及关键技术资产或知识资产时，改了什么、调用了什么工具应当可见、可控⁠1。这是 AI 对这段判断的归纳：选知识库路径时，先看它能否承载分支、引用、结构化资产和变更可追溯，而不只看录入是否方便。

立正署名文章转述杜磊的说法：多套 SaaS 各管自己的数据库和界面，缝隙靠人复制、粘贴、同步来填，形成“信息组织税”；该删的删，仍必要的搬运可交给 agent⁠2。用于你的中台，这意味着知识库与知识台之间若靠人工反复搬字段、改格式，选哪种存储方式都难解决根本问题；这是 AI 的应用推演，不是原文对 Obsidian 或 grep 的评价。

立正把知识资产拆成三层：文件是 what，即你有哪些信息；skill 是流程和判断，即这件事如何做；resolver 负责遇到任务时决定调用哪些文件和 skill⁠1。他还提到，人类积累的 context 大量散落在聊天、会议和文档里，把这些组织好、沉淀好、管理好是很重要的一环⁠1。因此，对自建中台来说，选 Obsidian 还是 mag/grep 之前，先问你的知识是否已经变成可被调用的文件与流程。

立正指出，聊天窗口是线性的，而深度知识工作需要分叉、引用和比较不同方案；复杂任务还需要表格、长文、文件 diff 和结构化知识资产⁠2。他还强调过程可观测性：涉及关键技术资产或知识资产时，改动应当可见、可控⁠2。这支持把知识库做成有结构、可追溯的资产层，而不是只靠对话记录。

这是 AI 基于上述判断的应用推演，不是立正对具体产品的推荐。你可以先选一小批真实知识资产，分别用 Obsidian 式文件组织和 mag/grep 式检索各跑一遍，观察三件事：能否被 agent 稳定调用、改动是否可追溯、复杂任务是否需要分叉和引用。哪条路径在这三项上反馈更好，再扩大范围。

出处 2 1