从一张 Agent 图谱开始：把学习写成可以生长的博客

我想把这个博客做成一个能慢慢长起来的地方。文章记录某个阶段的想法，短笔记放还没想清楚的问题，图谱把它们之间的关系连起来。

所以这里一开始不会摆满“已经掌握”的概念。我更想留下的是过程：我现在怎么理解一个问题，它和什么有关，后来为什么改了看法，哪些想法真的进了代码。比如我最早把“接了工具”当成 Agent 的标准，后来发现很多接了工具的系统其实是写死顺序的工作流，这个认识上的修改本身就值得记下来。

为什么不只用文章目录

按日期排适合回顾经历，不太适合理解知识。学 Agent 的时候，工具调用、规划、记忆 和 评测 会反复缠在一起。比如“工具调用超时后要不要重试”这个问题，一头连着工具，一头连着规划里的状态记录，还要靠评测去验证重试后有没有建出两张单。放在按日期排的目录里，这三篇可能隔着好几个月，读的人很难看出它们说的是同一件事。

所以我同时留了两条读法：文章顺着叙述往下读，图谱沿着问题和关系往外走。图谱参考了 Obsidian 的双链和反向链接。不过两篇笔记连在一起，只说明我在写的时候提到了对方，并不代表其中的知识已经成立。

本体思想先落在一个小模型上

本体建模 给我的启发是：先说清楚讨论的对象是什么、关系是什么意思，再决定系统怎么处理它们。

这个博客目前只定义了四种节点：概念、设计模式、实践、文章。关系也尽量少：使用、依赖、阐释、实践、检验、相关，再加上普通双链自动产生的“提及”。

关系类型要分开，是因为它们的含义差很远。“这篇文章阐释了本体论”和“研究 Agent 使用了检索”就不是一类关系。再比如，一篇笔记只在正文里用双链提了一句研究 Agent，图上就只多一条“提及”边，意思是“这里说到了它”。评测 那篇不一样，我在它的属性里明确写了 checks: [research-agent]，图上画出来的才是“检验”关系。这个区分很小，后面做工程设计时我还想一直沿用它。

先把笔记做实，再接 Agent

现在的 知识花园 是一个纯静态的知识整理和阅读工具。它没有自动推理，也不会让模型替我写结论再发布出去。

以后要是接入 Agent，我打算让它先读相关节点，指出哪里有缺口，再提出关系和内容的修改建议，最后由我核对。比如它发现“记忆”这篇笔记讲了冲突处理却没有例子，可以提一条“补一个成本中心从 A 改成 B 的例子”的候选，但发不发布由我决定。哪些材料真读过，哪些联系只是猜测，哪些实验还没做，这些边界要一直标清楚。这和 人在回路 以及 证据优先 的设计是一回事。

实践从哪里开始

一个候选方向是 本体驱动的研究 Agent：把研究问题、论文、方法、主张、证据和实验计划都当成明确的对象，看这种建模能不能让来源更好追溯、证据缺失时处理得更稳、方案之间比得更公平。举个具体场景：两篇论文用的数据集不同，一个普通的问答助手可能直接说“A 方法比 B 好 3 个点”；有了显式的“实验条件”对象，系统就能先发现两者条件不可比，再决定要不要下这个结论。

这目前还是设想，项目没做完，也没有可以发布的性能数字。博客会先记设计，再记实现和踩过的坑，最后用同一组任务比较版本之间的变化。

我希望怎样记录成长

• 起步笔记：先写一个工作定义和几个具体疑问。
• 持续完善：补来源、案例、反例和实践记录。
• 阶段整理：写下暂时的结论，同时写清它适用的范围和还没解决的问题。

不用每篇文章都得出一个大结论。今天能把对象和关系说清楚一点，下次能让一条规则真正写进程序，再下次能用评测发现它的局限，这些我都想留下来。

这张地图现在还很粗，我会一直改它。

参考入口

• Obsidian 官方文档：后续学习双向链接与图谱组织。
• W3C OWL 2 Overview：继续厘清本体建模与形式化语义。