Tessl 博客：用 OpenClaw 与 Obsidian 搭建可查询的组织记忆

我演讲背后的挫败感非常普通：“那个文件、那个演示文稿、那个决定、那个客户细节，或者我们之前讨论过的那项研究在哪里？”

在 Leapfrog，我们是一个小团队，为时尚和品牌客户进行高强度的 AI 视觉和制作工作。我们大规模创作数字人、图像、视频及相关内容。因为团队小、产出大，我们不能把时间花在翻找文件夹或重建会议背景上。

这就是为什么我一直在构建我称之为组织“一个大脑”的东西。这不是企业知识管理的推销。这是一个务实的尝试，让公司知识、研究、客户背景、会议和决策通过智能体在我们实际工作的地方可用。

关键理念很简单：如果知识散落在文件、会议记录和其他人的聊天窗口中，组织就无法很好地利用它。我希望尽可能多的知识在我们自己的技术栈中，可以通过自然语言查询，并对应该共享的内容设定边界。

将本次演讲用作智能体上下文

Tessl 已将我的人工智能原生开发者大会演讲转化为你的智能体可以用作上下文的技能。你也可以观看完整录像。

两类知识很重要

我们针对两类知识进行优化。

第一类是公司知识：我们正在学习的关于 AI、智能体、技能、评估、生产流水线以及我们自身系统如何运作的知识。这包括研究、实验、内部决策以及我们希望不断改进的实践。

第二类是创作流水线知识：客户信息、制作偏好、资产细节、交付要求、会议记录，以及客户与我们合作时使用的许多不同格式。有些客户使用 Miro，有些使用 Figma，有些使用 Keynote，有些使用其他工具。很难强迫所有人采用一种工作流程，因此我们解读他们提供的内容并将其带入我们的系统。

这两类知识支持不同的工作。第一类帮助公司学习和改进。第二类帮助我们快速、一致地为客户制作正确的作品。

从小型技术栈开始

第一个版本足够简单，其他人也可以尝试类似的做法。

我从沙盒中的 OpenClaw 开始，一个存放研究和公司数据的 GitHub 仓库，我机器上的 Obsidian 以便本地浏览，以及 Telegram 作为我可以随时与系统对话的界面。

Telegram 很有用，因为它让我可以在散步时、清晨或深夜用自然语言进行交互。我可以请求上下文、发送想法，或者查找原本需要翻找文件才能找到的东西。

Obsidian 很重要，因为它快速且本地。对于这种知识库，我更喜欢它，因为我希望知识感觉触手可及，而不是另一个人们避之不及的缓慢知识库。

重点不是每个人都应该复制那些确切的工具。重点是从你拥有且可以逐步改进的小型技术栈开始。

自然语言搜索改变了工作方式

你获得的第一个回报是一个自然语言的切磋伙伴。

我不再搜索文件，而是搜索想法。我可以问：“那个 Microsoft CI/CD 模型又是什么？”系统可以将模糊的记忆连接到正确的研究。因为它也理解我的上下文，它可以问我指的是演讲材料还是某个特定的内部项目。

这就是文件检索与组织记忆之间的区别。系统不仅仅是在定位一份文档。它是在帮助我找回一个想法周围的上下文。

这在日常工作中很重要。如果我需要知道某个原型是500台还是5,000台，或者哪些资产来自某个客户，我不想等到别人醒来，也不想在多个工具中翻找。我想直接询问组织的记忆。

一个研究代理成了我的报纸

系统的第二部分是主动研究。

我有一个通过OpenClaw运行的定时任务，追踪与代理工程、技能、生产流水线以及其他我们关心的领域相关的账号和关键词。每天早上，它会给我一份精选更新。我不会为了这项工作去读一份普通报纸。这是我观察需要关注的特定世界的镜头。

但并非所有内容都会进入共享库。这个区分很重要。

只有当内容看起来有依据且有用时，我才会将其提升到库中。我不想因为每一个我个人觉得有趣但未经证实的研究线索去打扰团队。提升是一种纪律。代理可以帮助分析一项技能、一篇文章或一个想法是否真的为我们当前的设置增添了价值，但更广泛分享的决定仍然应该是深思熟虑的。

这可以防止公司大脑变成一个杂物抽屉。

库中存放着研究、笔记和连接

在库中，我们有研究文件、笔记、待办事项以及相关材料之间的链接。在演讲时，研究结构大约有1,200个文件，这套设置无需太多额外机制就能处理。

我可以向聊天代理询问我们系统的某个部分如何运作，并基于库得到答案。我可以在会议结束后收到通知，并在转录可用时获取。我可以跟踪自己的研究，同时也能在相关时将研究与团队知识连接起来。

我们还有第二个用于客户信息的库。这就是生产端变得实用的地方。如果有人问哪些文件来自Calvin Klein，或者某位艺术总监倾向于什么偏好，系统可以呈现这些上下文，而无需让人手动检查每个文件和对话。

这就是改变生产工作的那种记忆。它让我们专注于创造，而不是重新发现。

记录更多，但拥有数据

演讲中更具哲学性的部分之一是关于记录的。

如果一段对话没有被数字化，那么对于AI原生工作流来说，它实际上就不存在。这并不意味着所有内容都应该与所有人共享。它意味着未被记录的知识无法被系统使用。

我受到了Bridgewater多年前记录会议这一理念的影响。当时，这听起来可能很奇怪。现在，在代理可以将转录转化为有用上下文的世界里，我看到了它更大的价值。

我们使用Granola等工具进行会议转录，因为它可以将打字笔记与转录结合，生成有用的摘要。我们还订购了Obi，一个开源录音设备，因为我想要在仍然拥有数据并将其发送到我们自己服务器的同时，找到捕捉对话的方式。

目标不是监视。目标是让有用的组织知识可用，同时控制它存放在哪里以及谁可以访问。

边界是系统的一部分

知识共享很快就会变得困难。

你真的要把每场会议都分享给所有人吗？如果一次通话中包含不该泄露的内容呢？如果客户数据需要保持隔离呢？如果领导层的研究不应自动成为全公司范围的指导方针呢？

这些问题正是架构需要边界的原因。我们将个人保险库、领导层知识、已晋升的公司知识、客户信息和代理实例分开。我不希望所有东西都泄露到其他所有东西里。

这个系统一开始很混乱。我们遇到了冲突、加载问题、内容交付与 GitHub 之间的合并冲突、损坏的脚本、失败的 cron 任务以及持续的维护工作。一旦基础设置正常工作，添加新功能仍然可能变成一项繁重的工作。

这还不是一个完善的企业平台。它是一个内部技术栈，之所以能给我们带来杠杆效应，是因为我们愿意维护它。

架构可以逐步成长

现在的架构包括连接到 GitHub 的私有保险库、来自 Gary Tan 的 GBrain、向量搜索、关键词搜索、翻译、直接文件读取，以及针对不同任务的独立代理。Telegram 是一个界面。Obsidian 是另一个。我们还在探索诸如 Neo4j 之类的图层。

对于 OpenClaw 搜索，我们结合了对偏好、决策和过往上下文的记忆搜索；按任务或时间的保险库上下文；通过 GBrain 进行的更广泛研究；以及在需要时直接读取文件。一些工作可以运行在更便宜的模型上以控制开支。

细节不如模式重要：保持技术栈模块化、自主拥有且有边界。只有当更简单的设置不再足够时，才添加检索层。

从小处着手，先让一个人受苦

我的建议是从小处着手。

不要立即向所有人推广。先让一个人熬过设置过程。在本地运行它。检查哪些地方会出问题。了解权限、安全加固，以及你可以对数据做什么。

然后添加能带来明显价值的部分。一个能减少会议准备或后续跟进时间的幕僚长代理，可以为人们腾出改进系统的空间。一个通过你的视角来筛选世界的研究代理，可以帮助团队持续学习。一个晋升工作流可以决定什么成为共享知识。

一个大脑并不是把所有知识都放进一个不加区分的大堆里。它关乎拥有组织记忆，使其可查询，并有意识地决定什么从个人上下文转移到团队上下文，再转移到公司上下文。

这一论点的完整版本已在 AI Native DevCon London 上展示。要深入了解，请观看完整录像。