数据工程博客
数据工程博客订阅

从 Obsidian 个人仓库到企业知识大脑：让 Agent 写、分支、合并

多年来我一直在使用个人第二大脑。我最初用OneNote，后来因为Obsidian的链接功能而转向了Obsidian。从那以后，我为个人生活建立了完整的知识网络，不仅如此：我还用Obsidian管理我的个人业务，比如我的CRM或所有与公司相关的知识。

但如果你想在更大的公司采用同样的方法，企业规模，内部信息丰富，同时外部也能获取呢？在多位写手、大量用户且始终保持最新的情况下，如何管理知识？

虽然企业知识管理并不新鲜，但Andrej Karpathy在短短中分享了一个自我策划的大型语言模型维基要点它迅速走红，展示了小型个人自动更新知识维基的可能性。

但它在企业级下运行不起作用，而且没有验证流程或版本管理。

本文将从个人大脑转向企业大脑，展示了功能差异、使这些差异成为可能的原因，以及智能体如何帮助我们不仅读取上下文，还帮助我们编写和更新信息。

我们探讨智能体如何在自身分支上写入（有不碰撞的变更，以及人类进行审查和决策的碰撞）。所有内容都配有两个展示，比较两个大脑及其尺度。

起因：企业知识管理

回顾六十年的知识管理历史，我们会发现这并非全新事物，但我们的工作方式——从基础到维基，再到图表，现在是大语言模型增强——都很有趣：

作为个人知识型，我用图表连接个人生活、学校甚至工作的笔记。最初是用Roam，但你也可以用任何关联的笔记应用，比如Obsidian或Logseq。

我建议使用像这样的开放文件格式Markdown 明文文件所以你的知识不绑定在工具上。

如果我们评估单用户连接的图系统是什么样的，就可以比较其局限性以及与企业知识管理的比较。个人系统代表：

  • 一个可以捕获与收集“知识”用于长期保留（一种开放格式，100年后仍然有效）
  • 创意创作，一个我们可以策展与写作知识
  • 理解与学习通过相互关联的笔记（下面构建图表）带来的新内容
  • 知识检索，并从多年书写的联系中获得洞见
  • 用于自动化常见笔记结构的模板，与知识捕捉工具（例如，黑曜石网剪刀)

可能还有更多，但这些是个人系统应当为你提供的本质。

个人知识脑的局限性

个人大脑相比公司和企业大脑存在真实的实际局限和劣势。确实如此无多用户功能或者几乎没有，只有本地Markdown文件（你需要同步它们CRDT或者找其他方法），但最终，文本文件或Markdown文件并不是为此设计的。

图中也没有类型或方法保证数据类型是持久的。它是非结构化的“自由流”文本。链接笔记（主要是Zettellerkasten）提供了音符之间的有限语义及其关系。

这就是谢尔盖·西蒙诺维也这么说指出，这可能导致“处理大量音符时出现摩擦点”。

如果我们不是几千条笔记，而是数百万条笔记，我们需要一个快速检索的索引，可能需要嵌入/聚类，还需要能根据公司规模和各种类型的数据（TXT、CSV、API、JSON 等）扩展。

企业知识管理规模：多用户、并发写入、自动更新

令人惊讶的是，我们对个人大脑的所有要求，对企业也同样需要。我们需要获取上个月/年度销售数据， 我们想了解新的见解从不断变化的商业环境（新法律、新提供的数据）中，我们想与内部和外部利益相关者分享.

但规模要大得多。我们需要与多个用户合作，使用更大、更复杂的数据集。我们不能只是复制粘贴网站。我们需要数据管道，数据仓库。

我们既要自动化，也要治理。从某种意义上说，你可以想象一下更换一些定制软件产品比如需要专用系统和软件的CRM或ERP，尤其是CRM，它们会收集各种上下文，结合客户的输入，比如他们最后一次打电话的时间、客户说了什么、他们现在的温度（热/暖/冷）等。

如果这些能自动从销售记录中收集，或者通过电话的专用日志（如果批准）收集，这些状态就能在公司大脑中管理，这正是我们需要的好例子。

企业型公司大脑的特征

企业公司的大脑需要多个用户同时写入，而我们需要自动化。这时代理就加入了，代理扮演重要角色，但不是唯一的。当多个并发用户写入时能够显示版本状态是关键，否则你需要一个能处理所有请求和卷的存储系统。

代理优先治理，适用于自动更新上下文

经纪人非常擅长信息采集任何格式都行。客服应该让我们能够自主地做到这一点。我们希望他们能够读取定义的位置，并获得对公司大脑有用的信息。

以CRM为例，数据库中的所有客户都应该每天自动更新，通话和文档都应该被接收和更新，交易和合同也应该关联并关联到每个客户，等等。

但他们如何为公司大脑写出新的语境呢？

版本版：与分支

这正是我们需要分支的地方。不仅因为数百个AI智能体同时添加知识会相互碰撞，更因为每一次变化都可能发生冲突登陆前评测.没有这些，由代理人驱动的公司大脑就会陷入噪音。

自动更换错误电话号码或虚假的交易状态，可能在几周内导致不可信状态。

所以我们给每个代理都分配了自己的分支和私有副本。它在那里写入，然后其更改会合并回main分支，就像GitHub上的拉取请求一样。在“正式”版本被批准之前，什么都不会出现。

人类可以审核并拒绝某些合并或者稍后还原，你就能获得完整的历史记录，知道是谁改了什么。

此外，代理和人类可以同时工作而不破坏任何东西。这样可以避免冲突，让多个代理并行工作。分支也非常适合长期任务，因为它们可以并发运行，完成后再合并回来。

所以你得到验证并且实现一次多重并发。

更一般地说，a需要一个有用的公司大脑而是它始终保持最新、正确且丰富（比如总是陈旧、缺失或错误的CRM，所以人类通过询问同事来修补，但客服直接行动）。

分支是让“持续更新”和“依然正确”协同工作的基础。

廉价、人人可及的存储：对象存储

我们需要一个开放空间，可以写入数据，可以给数据进行版本。最好的地方，价格实惠的是对象存储。除了设置简单和易用外，它还允许使用像Apache Parquet或其他[[Data Lake文件格式|开放文件格式]]的开放格式（你也可以使用开放表格格式如果你愿意，可以说在文件之上增加了数据库功能），让任何人只要有合适的权限就能阅读信息，而不是像把数据导入专有数据库格式那样。

也没有数据库服务器可以运行：你的整个图就是一堆文件。

与代理的一致性：类型图

那么，我们如何确保代理能够一致地写入从各种来源获取的信息呢？不像Obsidian Markdown的例子，我们会把它们关联到[ [wikilinks] ]而数据是自由流存储的，我们可以使用带类型化的图表。

也就是说，数据存储在像Obsidian那样链接的图中，但用数据类型进行类型化。所以你使用的系统会确保代理始终为客户的电话号码写入号码，或者日期对齐，等等。

这些类型的作用是数据合同对于代理来说，既是存储，也是如何获取正确信息的。这对代理来说也是避免写坏数据的关键。与其分开的表格，不如用打字图（点和线）存储所有内容。

点是事物（一个人、公司、交易）。线路是他们之间的联系方式（这家公司就是这个创始人）。基本上就是Obsidian 中的“连接”视图或者说，社交网络是如何知道谁和谁做朋友。

“Typed”意味着它有规则.每个点和线都有一个明确的形状，你先写下（一个人必须有名字，而FoundedBy行只连接一个人和公司）。所以没有无关的东西可以偷偷溜进去。

可以把它想象成一个带有必填字段的表格，而不是一个任何人都可以写的空白笔记本。

我们可以储存图作为代码.这里有一个节点的例子Organization:

1
2
3
4
5
6
7
8
9

node Organization {
    slug: String @key
    name: String @index
    brief: String?
    description: String?
    website: String?
    founded_year: I32?
    hq: String?
...

用黑曜石的术语解释：图链是你声明的连接（“A 与 B 连接”），而嵌入是模型推断出的相似性（“A 读起来像 B”）。拥有两者的公司大脑可以检索意义和类型关系，而不仅仅是基于向量相似度。

结合带有版本限制的分支，能够回退或完全拒绝某些更改，构建在S3、R2等开放标准存储层之上，我们可以大幅提升质量和一致性。

这是我们通过主数据管理（MDM）来控制的，我们用Excel来实现管理工作数据需要人力驱动，这一直是瓶颈：领域专家本来就最忙，现在他们又多了一个任务，就是核对数据是否正确并批准。

有了代理，只要我们有高质量的文档和最新的模型文件，就能加快这一过程。

此外，没有绝对的真理，客服也能发现数据中自然发生的矛盾。也许一份文档写着客户最后一次通话是上个月，而日志条目显示的是其他情况。

在这样的系统中，人工总能拦截并更改数据，就像客服人员一样。

这是持续的共同理解这些都是由经纪人和整个公司共同开发的。

我们需要本体论吗？

但有了图表，我们可以更准确、更详细地建模数据。这是一个优势。我们可以将世界知识建模为本体，并与企业数据结合，帮助模型通过正确的“连接”世界+本地和业务知识获得更多领域理解。

该图是本体论Ragnor最广义的版本他说.文本与其他文本线性链接。图包含许多类别。代理需要理解领域（客户是什么，>与数据模型的连接等）。

一个本体论是一个由相互连接的对象组成的世界，以及连接所有这些的图，包含索引、嵌入和开放存储格式。

这些本体论对公司大脑尤其有用，因为它们帮助找到跨部门的共同点。个人黑曜石知识大脑不需要它们，但如果你想增加复杂性，它们仍然很有用。

图可以表示为表格、JSON 等，但表格不能转换回图，所以如果需要，你仍然能用表格格式。A16z论证使用特工迄今为止无效的原因是”缺乏适当的数据背景“，并且”如今的企业数据依然极其分散且杂乱“，这也是数据代理难以回答基本问题的原因。

为什么不使用关系型数据库呢？Andrew重构问题是：Postgres已有40多年历史，是由于当时计算和其他限制而产生的。对于需要大量相互关联、真实世界知识结合数据的代理来说，从根本原理出发的设计本质上是一个图表，而非表格格式。

结合描述世界中实体的本体论，这在上下文方面非常强大。

展示：如何与Obsidian及多代理管理CRM。

让我们来看看个人大脑和企业大脑的区别。

个人大脑与Obsidian合作

以CRM为例比较具有说明性，因为我已经构建并[[Managing My Business with Obsidian|管理我自己的Obsidian中的CRM系统]]。我为每个客户使用一个备注，然后用专用 #hashtag 将他们汇聚到一个表格中。

我使用前置内容（头部中Markdown文件的元数据）用来给每个客户端归属：每个人的活跃度以及我需要联系谁。

有不同的观点，比如销售漏斗或概述， 我就能看到不同的内容。销售漏斗看板视图- 基于上述表格相同的数据：

公司大脑与OmniGraph

如果我们把这个扩展到公司大脑，有代理写作，所有内容都有版本控制，以开放格式存储，以下是示例，满足全能图： 它使用长枪作为对象存储上的开放列存储格式（你的图只是你拥有的桶里的文件，没有数据库服务器），数据融合作为查询引擎，构建带有 git 风格分支的类型图。

我用自己的Obsidian CRM重建成公司大脑公司-大脑-客户关系管理（改编自vc-os食谱示例），我公司SSP Data的一个公司智囊，扩展到一个虚构的50人版本，负责大量数据工程文章和咨询的推广工作。

我Obsidian前页的每个字段都被添加了一个类型：我的Hotness: 5-Cold变为hotness: enum(hot, warm, cold)系统强制执行（代理物理上不能写出“5-Cold-ish”），我的## Log截面变为Interaction节点（通话/邮件/会议/笔记），以及我的#crmssp标签变为Company节点类型本身。

整个CRM系统是你提交到Git的三个文件:schema.pg（4种节点类型——公司、个人、交易、互动——以及7种边类型）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

node Company {
    slug: String @key
    name: String @index
    kind: enum(us, prospect, client, publisher, partner) @index
    // the old Obsidian frontmatter `Hotness: 5-Cold`, now enforced
    hotness: enum(hot, warm, cold)? @index
    segment: String?
    notes: String?
    // ...
}

node Deal {
    // ...
    stage: enum(lead, contacted, proposal, won, lost) @index  // the sales funnel
    value_usd: F64?
}

// the [[wikilinks]], but with meaning
edge WorksAt: Person -> Company { role: String? }
edge Knows: Person -> Person { context: String? }
edge DealWith: Deal -> Company

queries/crm.gq以打字形式写成的重复问题，可列入存储查询：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// The sales funnel — the kanban board as a query.
query sales_funnel() {
    match {
        $d: Deal
        $d dealWith $c
    }
    return { $d.stage, $d.name, $c.name, $d.kind, $d.value_usd }
    order { $d.stage, $d.name }
}

// Warm-intro path: which SSP teammate knows someone at the target company?
query warm_intro($slug: String) {
    match {
        $target: Company { slug: $slug }
        $contact: Person
        $contact worksAt $target
        $teammate: Person
        $teammate knows $contact
        $teammate worksAt $ssp
        $ssp: Company { slug: "com-ssp" }
    }
    return { $teammate.name, $contact.name, $contact.role, $target.name }
}

以及seed.jsonl（数据——每个节点或边一行 JSON 代码）：

1
2
3

{"type": "Company", "data": {"slug": "com-nordbahn", "name": "Nordbahn Logistik", "kind": "prospect", "hotness": "warm", "segment": "logistics", ...}}
{"type": "Person", "data": {"slug": "per-tom-vermeer", "name": "Tom Vermeer", "role": "Account Executive", ...}}
{"edge": "Knows", "from": "per-tom-vermeer", "to": "per-lars-petersen", "data": {"context": "met at Data Council booth"}}

用make init && make seed，你有98节点 / 123边CRM，本地存储在你的磁盘上，不需要数据库。你可以把路径换成s3://…桶，且同样的流程运行在对象存储上。

从那里开始，我在Obsidian里的每个视图，比如销售漏斗看板或后续表，都是你用名称调用的存储查询(sales_funnel,hot_prospects,company_log).本次演示的所有结果均被记录在DEMO.md，例如销售漏斗作为查询结果，和我上面Obsidian看板的数据一样。

该上下文层具有版本化、可变换和可重复性从干净的结账开始，就像你其他基础设施一样。

客服或用户如何获取上下文？

代理人（或同事）实际上是怎么做的去这有什么背景吗？就是通过打电话查询。比如我的Obsidian反向链接在50个人网络中永远无法回答的问题：“谁能在目标公司为我们做热身介绍？”

结果是一次遍历：teammate → knows → contact → works在Target：

1
2
3
4
5

$ omnigraph query warm_intro --params '{"slug":"com-nordbahn"}' ...
teammate.name | contact.name  | contact.role | target.name
--------------+---------------+--------------+------------------
Tom Vermeer   | Lars Petersen | Head of BI   | Nordbahn Logistik
...

回复CRM的

现在是写回部分，大多数上下文层或代理还做不到，但OmniGraph支持。CRM一旦没人更新就会变得陈旧，所以在这个演示中，两个代理保持新鲜感，且都不写入main直接。

你可以尝试仓库里的命令，比如make agents，运行它们：

1
2
3
4
5
6
7

# the inbox agent logs this morning's replies on ITS OWN branch — main untouched
omnigraph load --data agents/inbox-scan.jsonl --mode merge \
  --branch agent/inbox-scan --from main --as agent-inbox --store graphs/crm.omni

# meanwhile the billing agent marks a signed PoC as won — on a second branch
omnigraph load --data agents/billing-sync.jsonl --mode merge \
  --branch agent/billing-sync --from main --as agent-billing --store graphs/crm.omni

自动合并

这两次变更涉及不同的行，所以两次合并都是干净的，无需人工验证即可完成，且自动合并.有三向和行级合并，各有一个原子提交：

1
2

omnigraph branch merge agent/inbox-scan --into main --as agent-inbox --store graphs/crm.omni
# merged agent/inbox-scan into main: fast_forward

冲突处理

有趣的是当作家意见不合时(make conflict在仓库中）：收件箱代理将Nordbahn标记为hot（“CEO今天回复了”）而CRM卫生代理则将同一行降级为cold（“60天内无接触点”）。

第一次合并成功，第二次被阻挡：

1
2

Error: merge conflicts: [MergeConflict { row_id: "com-nordbahn",
       kind: DivergentUpdate, ... }]

没有任何出版，而没有无声的最后写入胜利.相反，由人工（或策略/数据合同）来决定。而且因为每次写入都会记录一个演员（--as agent-inbox),omnigraph commit list给出了审计追踪，“谁把这个客户设为冷档，什么时候？”有实际答案。

你可以找到两个案件的完整录制过程，自动合并以及被阻挡的冲突，在仓库中。

这是一个虚构的演示，几乎没有数据来说明这个概念，但我希望你能大致理解它如何实现完全不同的上下文相关用例，并通过自动合并和代理帮助更新陈旧的文档和上下文，让生活变得更轻松。

[！示例]另一种OmniGraph的第二大脑方法如果你想要另一个个人第二大脑的例子，以及一个将OmniGraph作为个人生活本体的应用，这里展示了一个打字图来回答诸如：
  • 有谁我很久没说过话，我很想和他们聊？
  • 莎拉推荐了哪些我还没读过的书？
  • 我还欠西奥什么？
  • 我对育儿/工作/健康有什么想法？

打造企业型大脑，接下来是什么？

希望你能很好地理解个人维基和全自动LLM维基（后者由代理写回）之间的区别。以及为什么诸如版本分支、开放格式对象存储和类型等功能能帮助形成比纯文本或零散过时文档更能描述丰富上下文的图表，尤其是在代理的帮助下：收集和抓取有用信息，同时更新现有上下文，提高数据中出现矛盾的意识。

这种新方法值得记住，以构建企业大脑。它不仅是按相似度搜索的嵌入，还有输入的、声明知识加上推断相似性的嵌入，像代码一样版本化，这样一百个代理可以写入，而人工则通过审查合并回主分支的部分，防止它漂流成噪声。

最终，这和我把个人大脑转移到普通Markdown时做的赌注是一样的。打开文件比所有工具都活得久它读取这些文件，而作为你自己桶中开放文件存储的公司大脑，将能经受如今使用的CRM或维基。

新情况是，这些文件现在包含类型、历史和合并流程，知识不再依赖于一个谨慎的所有者。我的Obsidian保险库需要我，这个单一用户。

一个企业公司的大脑，为代理设计的图数据库由特工保持新鲜感，由人工审核，主要需要有人点击“合并”。

这种差异会叠加，并可能成为管理不断增长信息的关键，从你维护的维基转向公司实际使用的企业大脑。

如果你想开始，那全集食谱是最快的路径。把其中一个输入给你选择的代理，获取包含真实种子数据（公司大脑、风险投资操作系统、制药和行业情报）的现成图。

为了深入讨论，联合创始人Andrew和Ragnor将与Stanislav Kozlovski进行深入讨论。为什么智能体需要类型化图来协调.

参与讨论