AI 智能体如何利用文件系统进行上下文工程

作者：LangChain 团队

深度智能体（Deep Agents）的一个核心特征，就是它们能够使用一套文件系统工具。通过这些工具，深度智能体可以在其文件系统中进行读取、写入、编辑、列出目录以及搜索文件等操作。

在这篇文章中，我们将探讨为什么文件系统对 AI 智能体（AI Agent）至关重要。为了理解文件系统的价值，我们得先看看当下的智能体在哪些地方容易“掉链子”。它们失败通常有两个原因：(a) 模型本身不够聪明，或者 (b) 它们没能获取到正确的上下文信息。上下文工程（Context Engineering）被 Andrej Karpathy 形象地称为“一门将恰到好处的信息填入上下文窗口，以进行下一步操作的微妙艺术与科学”。理解上下文工程——以及它为何会失效——对于构建可靠的智能体至关重要。

透视上下文工程

我们可以透过上下文工程这个视角，来重新审视现代 AI 工程师的工作。通常来说，智能体拥有海量的上下文（比如所有的支持文档、所有的代码文件等）。为了回答一个突发的问题，智能体实际上需要的是其中一部分关键上下文（即包含答案的那部分信息）。而在试图回答问题的过程中，智能体抓取了一部分上下文（将其拉入自己的上下文窗口中）。

(注：上下文窗口 Context Window 可以理解为 AI 的“短期记忆容量”，它一次能处理的信息量是有限的。)

从这个角度看，上下文工程导致智能体“翻车”的方式有很多种：

• 如果智能体需要的上下文根本不在它能访问的总库里，那它注定失败。例子： 客服智能体需要某篇文档来回答问题，但这篇文档根本没被索引（AI 读不到）。

• 如果智能体抓取的内容里没有包含它真正需要的信息，它也无法正确回答。例子： 客服智能体需要某篇文档，这篇文档虽然存在也被索引了，但智能体就是没把它检索出来。

• 如果智能体抓取的内容远远多于实际需要的，那就是在浪费资源（无论是时间还是 Token）。例子： 客服智能体只需要特定的一页纸，结果它一口气抓了 100 页。

(注：Token 是 AI 计费和处理信息的单位，大致相当于单词或字符。抓取过多不仅费钱，还可能干扰 AI 的判断。)

作为智能体工程师，我们的任务就是让红色区域尽可能贴合绿色区域（即：确保智能体抓取的上下文，刚好覆盖所需信息，而不要多余太多）。

在试图精准分离出这部分“恰当的上下文”时，我们会遇到几个具体的挑战：

1. Token 太多（抓取的上下文 >> 实际需要的上下文） 有些工具（比如网络搜索）会返回大量的 Token。仅仅几次网络搜索，对话历史中就可能堆积成千上万的 Token。你最终可能会遇到令人讨厌的 400 错误（请求过大），但在那之前，你的大语言模型（LLM）账单早就爆炸了，而且性能也会下降。

2. 需要巨量上下文（实际需要的上下文 > 支持的上下文窗口） 有时，智能体确实需要大量信息才能回答问题。这些信息通常无法通过一次搜索查询返回，这就是为什么许多人倾向于“代理式搜索”（Agentic Search）——让智能体反复调用搜索工具。但问题在于，上下文的数量会迅速增长，直到塞不进它的上下文窗口为止。

3. 寻找利基信息/冷门信息（抓取的上下文 ≠ 实际需要的上下文） 智能体可能需要引用埋藏在成百上千个文件中的某个冷门信息来处理输入。智能体如何才能可靠地找到它？如果找不到，那么抓取的上下文就不是回答问题所需的。除了语义搜索，还有替代方案（或补充方案）吗？

4. 随时间学习（总上下文 ≠ 实际需要的上下文） 有时，智能体可能根本无法获取回答问题所需的上下文（无论是在工具中还是指令中）。最终用户往往会在与智能体的互动中（隐式或显式地）提供线索，指出那些上下文可能是什么。有没有办法让智能体将这些新知添加到自己的上下文中，以便在未来的迭代中使用？

这些都是常见的障碍，我们大多数人都曾面临过这些问题的不同变体！

文件系统如何让智能体变得更强？

简单来说：文件系统提供了一个单一的接口，通过它，智能体可以灵活地存储、检索和更新无限量的上下文。

让我们看看这如何帮助解决上述的每一个场景。

Token 太多（抓取的上下文 >> 实际需要的上下文）

智能体不必将所有的工具调用结果和笔记都塞进对话历史记录里，而是可以将它们写入文件系统，然后在必要时有选择地查找相关信息。Manus 是最早公开讨论这种方法的公司之一——下图来自他们的博客文章。

让我们拿网络搜索工具的例子来说。我运行一个网络搜索，工具返回了 1 万个 Token 的原始内容。这些内容大部分时候可能都是没用的。如果我把它们全部塞进我的消息历史记录，这 1 万个 Token 就会一直停留在那里直到对话结束，不断推高我的 Anthropic 账单。但如果我把这个巨大的工具结果“卸载”到文件系统中，智能体就可以智能地使用 grep 搜索特定的关键词，然后只将必要的上下文读入对话中。

(注：grep 是一个强大的命令行工具，用于在文本中搜索匹配的字符串。这里指 AI 像程序员一样去精准查找关键行，而不是全篇通读。)

在这个例子中，智能体有效地将文件系统用作了处理大量上下文的草稿纸。

需要巨量上下文（实际需要的上下文 < 支持的上下文窗口）

有时智能体需要大量上下文才能回答问题。文件系统提供了一个很好的抽象层，让 LLM 可以动态地存储和拉取更多信息。这方面的例子包括：

• 长周期任务： 智能体需要制定计划并遵循执行。通过将计划写入文件系统，智能体可以在稍后将此信息拉回上下文窗口，以提醒自己应该做什么（例如“通过背诵来控制注意力”）。

• 子智能体协作： 为了处理所有这些上下文，主智能体可能会启动多个子智能体。当这些子智能体工作并学到东西时，它们不必只是向主智能体回复它们学到了什么，而是可以将知识写入文件系统（例如最大程度地减少“传声筒游戏”带来的信息失真）。

• 复杂指令： 有些智能体需要大量的操作说明。与其将所有这些说明都塞进系统提示词（System Prompt）中导致上下文臃肿，不如将它们作为文件存储，让智能体在需要时动态读取（例如 Anthropic 的技能库）。

寻找利基信息/冷门信息（抓取的上下文 ≠ 实际需要的上下文）

在 LLM 浪潮的早期，语义搜索（Semantic Search）是最流行的上下文检索方法之一。它在某些用例中很有效，但取决于文档类型（例如技术 API 参考、代码文件），由于文本中缺乏语义信息，语义搜索的效果可能非常差。

(注：语义搜索是基于“含义”来找东西，比如搜“好吃的”，它能找到“披萨”。但在代码或精确的技术参数中，这种模糊匹配往往不如精确的关键词匹配好用。)

文件系统提供了一种替代方案，允许智能体使用 ls（列出文件）、glob（模式匹配）和 grep（文本搜索）等工具智能地搜索上下文。如果你最近使用过 Claude Code，你会知道它严重依赖 glob and grep 搜索来找到所需的正确上下文。这项技术之所以成功，有几个关键原因：

• 今天的模型经过了专门训练，能够理解并遍历文件系统。

• 信息通常已经按逻辑结构化了（通过文件夹目录）。

• glob 和 grep 允许智能体不仅隔离特定的文件，还能定位到特定的行和字符。

• read_file 工具允许智能体指定从文件中读取哪些行。

由于这些原因，在某些情况下，使用文件系统（以及通过使用文件系统获得的搜索能力）可以创造更好的结果。

请注意，语义搜索仍然很有用！而且可以与文件系统搜索结合使用。Cursor 最近写了一篇博客，重点介绍了两者结合使用的好处。

随时间学习（总上下文 ≠ 实际需要的上下文）

智能体搞砸的一个很大原因是它们缺少相关的上下文。改进智能体的一个好方法通常是确保它们能访问正确的上下文。有时这看起来像是添加更多的数据源或更新系统提示词。

更新系统提示词的常见做法是：

1. 发现一个智能体缺乏适当指令的例子。

2. 从主题专家那里获取相关指令。

3. 用这些指令更新提示词。

通常，最终用户实际上就是最好的主题专家。通过与智能体的对话，他们可能会提供重要的线索（隐式或显式），说明什么是正确的相关指令。既然如此——有没有办法自动化上述的第三步（用这些指令更新提示词）？

我们认为智能体的指令（或技能）与它们可能想要处理的任何其他上下文没有什么不同。文件系统可以作为智能体存储和更新自身指令的地方！

在用户给出反馈后，智能体可以立即写入自己的文件并记住一条重要信息。这对于快速记录一次性事实非常棒，尤其是那些可能针对特定用户的内容，比如他们的姓名、电子邮件或其他偏好。

这个问题尚未完全解决，仍然是一种新兴的模式，但这是一种令人兴奋的新方式，让 LLM 能够随着时间的推移增长自己的技能组合和指令，确保在未来的迭代中它们能够获得必要的上下文。

看看深度智能体如何利用其文件系统

我们有一个名为 Deep Agents（深度智能体）的开源仓库（支持 Python 和 TypeScript），它可以让你快速构建一个能够访问文件系统的智能体。许多利用文件系统的上下文工程技巧都已经内置其中！几乎可以肯定会有更多的模式出现——试试 Deep Agents，告诉我们你的想法！

订阅我们的新闻通讯

来自 LangChain 团队和社区的最新动态

来源: https://blog.langchain.com/how-agents-can-use-filesystems-for-context-engineering/