企业数据的文件系统抽象

2025年4月，我们的日志中不断出现一种现象。我们的AI代理正在发明自己的搜索内容语法——file:front/src/some-file-name.tsx, path:/notion/engineering/weekly-updates。代理试图通过猜测名称或文件路径来引用资源，而不是为语义搜索制定查询。起初看起来像是一个错误或代理指令中的缺陷，但后来发现这是代理本能行为的一个微妙提示。

基于几个月前推出的内容节点架构，我们开始构建代理所暗示的工具：通过列出文件夹中的文件、按名称搜索内容或打开特定文件来导航数据层次结构的工具。

1、识别缺失的基本元素

使用代码库的代理一直在尝试“破解”语义搜索，以通过路径或文件名查找特定文件。

我们已经构建了语义搜索来帮助代理根据含义找到信息。但是当您需要“上周团队会议笔记中的TeamOS部分”时，您不是在搜索含义，而是在导航结构。您知道有一个会议数据库，知道有每周条目，知道在哪里查找。我们的代理也需要这种能力。

我们意识到我们不仅仅是在构建导航工具。我们在创建合成文件系统——在没有任何文件系统的数据源上强加一致且可导航的结构。

2、打造可导航的结构

Notion没有文件夹，只有页面和数据库。Slack有频道和线程。Google Drive有自己的方式。但我们的代理需要一种一致的方式来导航所有内容。

一位工程师这样说道：“我们可以将合成结构映射到实际可浏览和可搜索的结构，没有任何东西阻止我们重新设计那些本身没有结构的连接器的内容节点层次结构（例如Slack），从而使搜索更强大。”

我们不受平台内部数据组织方式的限制。我们可以创建对AI导航有意义的抽象：

• Slack频道变成包含线程文件的目录。
• Notion工作区变成根文件夹，数据库变成特殊目录（既是目录又是表格）。
• GitHub仓库保持其自然结构。
• Google和Microsoft电子表格变成表格文件夹。

Notion数据库“Design Docs数据库”被转换成一个文件夹，以匹配文件夹作为文件容器的概念。

幸运的是，所有这些工作已经在所谓的内容节点架构迁移背景下完成。只是当时我们不知道这个层次结构除了允许用户在Agent Builder中选择知识库的子集之外还有其他用途。

3、实现

我们实现了五个受Unix启发的命令：

• list - 显示文件夹内容（类似于 ls）
• find - 在层次结构中按名称搜索文件
• cat - 以分页方式读取文件内容
• search - 在特定子树内进行语义搜索
• locate_in_tree - 显示通往文件的完整路径

每个命令都在我们的合成文件系统上运行，将Notion页面、Slack消息和Google Drive文档视为Unix系统中的文件或文件夹。（Unix是1970年代的计算机操作系统，成为许多现代系统如macOS和Linux的基础。）

事实上，每个人在寻找计算机上的文件时都依赖相同的原始功能。像Mac上的Finder这样的文件浏览器只是这些命令的界面；ls被替换为打开文件夹后关于你找到的内容的视觉反馈，我们习惯于按名称搜索文件，并且经常查看文件内容以猜测它是什么。

4、上下文窗口问题

一个有趣的挑战来自cat。在Unix中，它会输出整个文件。但AI代理有上下文窗口，这是它们可以处理的文本量的硬性限制。一个简单的实现会让代理尝试读取大文件并立即失败。

我们添加了limit和offset参数：代理可以选择从某个行号开始查看一定数量的行。

cat: {
  nodeId: string,
  offset?: number,  // 开始位置
  limit?: number,   // 最大字符数
  grep?: string     // 过滤行
}

这使得代理可以分块读取文档，跳转到特定部分，并过滤内容，而不会超出它们的上下文窗口。这使代理能够处理任意大的文档。

想象一下，这就像一台存储空间巨大但工作内存（RAM）非常有限的计算机。这样的计算机在一次读取大文件时会遇到困难，并需要想出一种方法来窥探文件以猜测其内容，而无需完全拉取它们。在这方面，LLM就像你电脑上的程序，必须智能地采样文件的部分内容以了解它们的内容，同时在严格的内存限制下工作。

5、既是文件又是文件夹的文件

传统的文件系统是二进制的：某物要么是文件，要么是文件夹。Notion打破了这一假设——文档可以包含其他文档，递归地。

我们必须与Unix隐喻协调。一个Notion页面可能是一个你可以cat（显示其内容）的文件，但也可能是你可以ls（列出其子项）的目录。我们通过告诉模型给定文件是否包含嵌套项或独立存在来解决这个问题，使此信息成为可列表的主要标准。这种双重性质让代理自然地导航复杂的文档结构——他们可以读取页面内容，然后深入其子页面，全部使用熟悉的文件系统命令。幸运的是，在LLM训练集中看到的Unix命令中，命令本身并没有提到每个参数是文件还是文件夹；主要是运行某个命令的文件或文件夹的事实决定了这一点。因此，对文件的子项进行列表在模型语法上是合法的。

6、两种方法，一个系统

当我们部署时发生了以下情况。用户问：“上周团队周报的Notion文档中的TeamOS部分有什么内容？”

代理：

• 使用find定位团队周报数据库
• 调用list查看最近的条目
• 识别最新的文档
• 使用cat和grep查找TeamOS部分

这种结构不存在于Notion的API中。我们创建了它以符合人类思考数据的方式。

有趣的是，代理如何结合这些文件系统工具与语义搜索。文件系统工具不会取代语义搜索；它们会补充它。导航帮助代理理解结构并系统地探索。语义搜索在该结构内查找特定信息。两者结合，让代理缩小范围，然后精确搜索。

考虑另一种工作流程。一个调查功能为何损坏的代理可能会：

• 从整个代码库中进行语义search，查找错误信息或堆栈跟踪
• 对结果使用locate_in_tree，以了解相关文件在架构中的位置
• 导航到父目录并使用list发现相关的模块和配置文件
• 在这些特定子树中应用聚焦的语义搜索，以了解更广泛的背景
• 最后使用cat查看特定文件以检查实现细节

每个命令都很简单。但它们一起让代理能够像Unix专家导航文件系统一样流畅地导航组织知识。

我们将这两种方法统一到一个工具包中。正如我们的产品团队所描述的：“它一次性完成了搜索、包含和提取，而无需进行配置！”这不仅仅是方便的问题——而是认识到代理需要这两种能力协同工作。

这种组合反映了人类实际上如何处理信息。我们不只是搜索——我们浏览、探索相邻内容、构建关于事物所在位置的心理地图。通过赋予代理这两种工具，我们使它们能够发展类似的上下文理解。

代理已经尝试这样做。他们会尝试带有路径类似查询的语义搜索：“在 /engineering/runbooks 中搜索部署过程。”现在他们可以真正执行这个意图：导航到runbooks文件夹，然后在其内部搜索。合成文件系统成为了使语义搜索更高效的支撑结构，而语义搜索仍然能够快速深入并找到分散在知识库中的有趣内容，这些内容随后可以作为代理探索的种子。

7、结束语

未来的工作不仅仅由AI模型变得多聪明来定义，而是由让它们理解和导航组织复杂性的基础设施来定义。就像Unix提供了塑造数十年计算的通用原语一样，这些导航工具代表了AI如何与公司知识互动的基础模式。

这些导航工具为AI代理提供了一个不存在于任何磁盘上的文件系统，它存在于不同数据源之间的逻辑空间中。一个合成文件系统，使组织数据的混乱如同Unix目录树一样可导航。

这种转变之所以重要，是因为它改变了代理能做的事情。当代理能够像搜索含义一样流畅地导航结构时，它们从复杂的搜索引擎转变为真正的知识工作者。它们发展上下文理解，发现信息之间的关系，并处理需要广泛探索和深入调查的复杂多步骤任务。我们的代理本能地寻求这些文件系统模式，揭示了更广泛的现象：随着AI能力的扩展，它们需要更丰富的途径来理解其操作的信息环境。合成文件系统为此奠定了基础，使AI系统不仅处理信息，而且真正理解组织如何构建和使用其知识。

原文链接：How We Taught AI Agents to Navigate Company Data Like a Filesystem

汇智网翻译整理，转载请标明出处