LlamaIndex 撰文分析文件接口正成为 Agent 读取和交互上下文的核心方式

我们正在看到一个有趣的趋势：智能体读取和交互非结构化上下文的主要方式是通过文件。这篇博客概述了核心接口、它们的使用场景，以及我们未来仍需探索的问题。

我注意到文件主要有 3 种使用方式：

1. 作为智能体存储和搜索长时间运行对话历史的主要方式
2. 作为智能体检索大量外部上下文的主要格式，取代朴素的 RAG 模式
3. 作为一种为智能体配备“技能”并完全绕过 MCP 的方式

这些模式主要通过 Claude Code 和 Cursor 等流行的编码智能体工具被采用。但编码智能体本就等同于通用推理智能体，而且我看到一个普遍趋势：智能体应用正围绕文件和文件系统集中，将其作为上下文管理的核心抽象。

文件接口

对智能体而言，文件与你计算机上的文件相同。文件有各种不同的形态和格式：

1. 纯文本文件：所有代码文件（.py、.tsx……），以及其他纯文本文件，如 .txt、.md、.csv、.json 等。你可以直接将这类文本放入 LLM 上下文窗口。
2. 文档格式：.pdf、.docx、.pptx、.xlsx。这些格式并非原生机器可读，需要解析才能转换为 LLM 可用的格式（稍后详述！）
3. 图像：.png、.jpeg 等
4. 其他任何内容（视频、音频、应用程序二进制文件）——它们目前与智能体无关，至少要到 computer use 真正实现之后。

智能体以多种方式与文件和文件系统交互。默认情况下，它们可以访问 CLI，并能使用 ls 和 grep 等命令来遍历和搜索文件（尤其是纯文本文件）。它们还配备了 Read 等第一方工具，以便从纯文本文件中读取子节。如果你愿意，还可以为编码智能体配备语义搜索能力。

与其让一个智能体拥有数百个工具，我们正朝着这样一个世界演进：智能体实际上只能访问一个文件系统和大约 5-10 个工具：

• 基于文件系统的 CLI
• 代码解释器
• 网页抓取

而这与拥有 100 多个 MCP 工具的智能体一样通用，甚至更为通用。

文件用于存储长上下文和操作

1. 文件是智能体存储和搜索长时间运行对话历史的核心抽象
上下文窗口仍然是在长时间运行的知识工作任务中部署前沿智能体的主要限制之一。这在编码智能体中显而易见。每次看到 Claude Code 上弹出“Context left until auto-compact”通知时，我都会感到一阵恐惧。一旦触发压缩，智能体不可避免地会失忆，无法可靠地完成剩余任务。

无论是人工触发还是智能体自身触发，主要的变通方法之一就是将这些对话存储到文件中。Claude Code 有一个最简单的实现，即 Claude.md 文件，这是一个静态文件，让编码智能体在实例化时能够访问一个通用的上下文池。最近，Cursor 的博客文章展示了他们的方法：在触发上下文压缩时，将过去的聊天历史存储为可搜索的文件；这使智能体在感觉现有上下文窗口不足以解决手头任务时，能够动态地查找之前的对话历史。

用户正在手动定义工作流，以便在其编码代理环境中创建和编辑文件。Dex Horthy 在这里有大量资源。他有一个令人惊叹的三步研究、规划、实施流程，据传闻这能大幅提升编码代理的性能。这会让代理先创建一个 research.md 文件，然后创建一个 plan.md 文件，从而允许压缩现有上下文以供人工审查，然后再将其传递到下游步骤。顺带一提，Kyle Mistele 也写过关于“渐进式披露”的概念，即你引导代理去访问嵌套的 MD 文件。

2. 文件是代理检索大量外部上下文的主要格式，取代了朴素的 RAG 模式

RAG 很糟糕是 2023 年的问题，我做了很多视频详细说明如何改进它。问题在于，所有这些技术都只解决了问题的子集。我们距离实现这样一个代理的承诺仍然很远：它能够从任意大小的代码库中动态读取任意一堆上下文，以回答任意复杂的问题。

拥有简单文件搜索工具的代理让我们离这个目标近得多。代理可以将搜索与 Read() 操作交错进行，类似于人类，它们可以选择跨文件扫描，或在单个文件中向上或向下滚动来完成任务。

最近，在我们自己的实验中，我们发现了两件事：

1. 具备文件系统工具和语义搜索的推理代理，可以让代理动态遍历上下文，以回答任意复杂的问题。
2. 即使仅靠文件搜索，在中小型文档集合上也优于朴素的语义搜索（忽略延迟）。

在实践中，你很可能仍然需要语义索引，但你始终可以将其作为一条命令来实现，以补充现有的文件系统 CLI 命令（参见 semtools）。

文件抽象的好处在于，你也可以将任何预先存在的大量非结构化上下文缩减为一个文件。Cursor 和 Claude Code 都会自动将冗长的 MCP 工具响应转储到文件中，这使代理能够使用前述文件系统工具对这些内容进行后处理，而无需截断。

3. 作为一种为代理配备“技能”并完全绕过 MCP 的方式

Anthropic 在十月首次引入了“技能”的概念。这个概念理解起来非常简单。与 Claude.md 文件类似，Claude Skills 实际上也只是文件，有时是文件的文件夹，你将其交给代理来教它一些东西。代理依靠其文件系统工具来遍历这些文件，并通过遍历这些文件来学习做事。

Simon Willison 最先说过：技能可能会取代 MCP。与其显式地给代理提供 MCP 工具，你可以直接给它一堆文件 + CLI/代码解释器/网络访问权限来做事。从理论上讲，这种方法有几个好处：

1. 它们定义和分享起来要容易得多。只需把一些 API 规范复制/粘贴到一个 .md 文件里。或者输入几条非结构化的要点。然后——agent 就知道该怎么做事了。就我自己的经验而言，编写 MCP 工具相比之下是件相当痛苦的事。
2. 它们不会自动膨胀 agent 的上下文窗口。如果 MCP 服务器定义了一个 search 端点并返回 10 万+ token 的搜索结果，调用 MCP 的 agent 默认会直接吞下全部内容。而文件为 agent 提供了一种自然的接口，让它们去读取和搜索相关的上下文片段。
3. 它们让 agent 能通过代码做任意、更灵活的事情。借助 skills，agent 可以通过代码执行任意与任何服务的 API 交互，即使该服务没有定义 MCP。它们还允许 agent 做诸如上传文件二进制之类的操作，而这在 agent 直接编写工具调用参数的情况下是不可能实现的。

差距 + 前路

我提到过，通用 agent 推理 + 文件系统是计算机使用的一个不错的初始替代方案（参见 Claude Cowork）。话虽如此，仍有一些核心差距需要解决，才能让编程 agent 以更准确、可靠、可扩展的方式解决更多任务。

1. 解析非纯文本文档：编程 agent 并不具备读取 PDF、Word、Powerpoint、Excel 等非纯文本文件格式的固有能力。为了做到这一点，它们必须调用优秀的 OCR 工具，将这些文件读取为 LLM 可解释的表示形式。这正是我们在 LlamaParse 中构建的东西，涵盖我们整套 Parse、Extract、Sheets 及其他能力。我们还构建了像 semtools 这样的开源封装，以便轻松地将其作为命令提供给编程 agent 使用。
2. 可扩展的文件搜索：编程 agent 已经将 CLI 工具作为其文件搜索的主要手段，但我们注意到这种方法无法扩展到海量文档集合（1 千到 100 万+）。Mac OSX 等操作系统中的原生搜索工具并不太好用。如何将语义/关键词索引与文件搜索操作结合起来，实现可扩展但动态的搜索，将会很有意思。
3. 文件编辑与生成：编程 agent 可以轻松地对代码和纯文本文件应用编辑补丁。但它们需要专门的工具来处理更复杂的格式和更复杂的工作负载，比如制作演示文稿、编辑图像或填写表单。目前有一组针对 PPTX、DOCX、XLSX 的初始 Claude skills——但这些使用的是原始的开源工具。这里有很大的机会去创建一组专注的工具，让编程 agent 具备解决更多端到端工作任务的能力。

目前尚不清楚文件作为一种格式是否会继续作为 agent 读取和交互上下文的主要机制，但它正在成为当今最好的模式。这与我们看到的整体趋势非常契合，即编程正通过自然语言而非代码来完成。它也是迈向通用计算机使用的一块垫脚石。

我们不是在构建通用的编码/计算机使用代理，但我们很兴奋能成为这一旅程的核心部分。基于文档的文件需要处理，我们提供一流的技术，帮助你将 PDF、Powerpoint、Excel、Word、HTML 等转换为代理就绪的上下文。来看看我们吧！