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

深度智能体 (deep Agents)^[1] 的核心能力之一，便是它们能够自如运用一套文件系统工具。通过这些工具，深度智能体可以在其文件系统中读取、写入、编辑、列出和搜索文件。

在本文中，我们将深入探讨为什么文件系统对智能体至关重要。要理解文件系统的作用，我们首先需要思考当前智能体在哪些方面会表现不佳。它们失败的原因无外乎两点：(a) 模型本身的能力不足，或者 (b) 它们无法获得正确的上下文信息。所谓上下文工程 (Context engineering)，正是 Andrej Karpathy 所描述的“一门为智能体下一步骤，精准填充上下文窗口所需信息的精妙艺术与科学”^[2]。因此，理解上下文工程及其可能的失败之处，是构建可靠智能体的重中之重。

上下文工程的视角

我们可以借由上下文工程^[3]的视角，来审视当代智能体工程师的工作。通常情况下，智能体掌管着（拥有）海量的上下文信息（例如所有支持文档、所有代码文件等）。为了回答一个请求，智能体实际需要（依赖）其中的一部分关键上下文（即回答问题所必需的信息）。而在尝试回答该问题的过程中，智能体会检索一部分它认为相关的信息，并将其载入上下文窗口中。

从这个角度看，智能体的上下文工程可能在多个环节出现问题：*   所需信息不存在：如果智能体解决问题所需的上下文，在其能够访问的全部信息中根本不存在，那么它注定会失败。例如，一个客服智能体需要查阅某个文档页面来回答用户问题，但该页面并未被索引。

• 检索信息不准确：如果智能体检索到的上下文，并未包含其解决问题所必需的关键信息，那么它也无法给出正确答案。例如，客服智能体需要的文档页面虽然存在且已被索引，但智能体未能成功检索到它。
• 检索信息太冗余：如果智能体检索到的上下文远超其实际所需，那么就会造成时间、Token（令牌）或两者的浪费。这种冗余不仅会使对话历史膨胀，还会导致计算成本和费用急剧上升。例如，客服智能体只需要一个特定页面，却检索出了 100 个页面。作为智能体工程师，我们的任务就是让上图中红色区域（检索到的信息）尽可能地贴近绿色区域（所需信息），确保智能体检索到的信息既涵盖了解决问题所必需的内容，又不包含多余的部分。

在试图精准定位所需上下文时，我们通常会遇到以下几个具体挑战：

1. Token 消耗过大 (检索到的上下文 >> 所需上下文) 一些工具（如网页搜索）可能会返回大量 Token。几次网页搜索就可能让你的对话历史累积数万个 Token。最终你可能会遇到恼人的 400 bad request 错误，但在此之前，你的大语言模型（LLM）账单早已飙升，性能也随之下降。
2. 所需上下文过大 (所需上下文 > 支持的上下文窗口) 有时，智能体确实需要大量信息才能回答一个问题。这些信息通常无法通过单次搜索查询返回，因此许多人开始探索“自主性搜索 (agentic search)”——让智能体重复调用搜索工具。但问题在于，这样累积的上下文信息量会迅速增长，直到超出其上下文窗口的容量。
3. 难以发现深层信息 (检索到的上下文 ≠ 所需上下文) 为了处理某个输入，智能体可能需要引用埋藏在成百上千个文件中的某个不起眼的信息。它如何才能可靠地找到这些信息？如果找不到，那么它检索到的上下文就不是解决问题所需的。除了语义搜索，还有没有其他替代或补充方案？ 4.随时间推移进行学习 (可访问的全部上下文 ≠ 所需上下文) 有时，智能体仅仅是因为缺少回答问题所需的上下文（无论是在工具中还是在其指令中）。而终端用户在与智能体的互动中，往往会（有意或无意地）提供线索，暗示缺失的上下文是什么。那么，有没有办法让智能体将这些信息补充到自己的知识库中，以备后用呢？

这些都是常见的障碍，我们大多数人或多或少都遇到过这些问题的不同变体。

文件系统如何赋能智能体？

简单来说：文件系统为智能体提供了一个统一的接口，使其能够灵活地存储、检索和更新无限量的上下文信息。

让我们看看文件系统如何帮助解决上述各种场景中的问题。

应对 Token 消耗过大 (检索到的上下文 >> 所需上下文)

智能体可以将大量的工具调用结果和笔记写入文件系统，而不是一股脑地塞进对话历史里。这样，在需要时，它就可以只选择性地查询和加载***相关信息***。Manus 是最早公开讨论这种方法^[4]的团队之一，下图就来自他们的博客文章。

回到前面网页搜索的例子。例如，进行一次网页搜索后，工具会返回大约 1 万 Token 的原始内容。这些内容大部分可能并非一直都需要。如果我把它放进对话历史，这 1 万 Token 就会在整个对话过程中持续占据空间，让我的 Anthropic 账单节节攀升。但如果我把这个庞大的工具结果转移到文件系统中，智能体就可以在需要时通过 grep 等命令智能地搜索特定关键词，然后只将必要的内容读入对话中。通过这种方式，智能体能够避免将大量数据直接保存在对话历史中，从而降低 Token 消耗和费用风险。

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

应对所需上下文过大 (所需上下文 > 支持的上下文窗口)

有时，智能体需要大量上下文来解决问题。文件系统提供了一个很好的抽象层，让大语言模型可以根据需要动态地存储和调取更多信息。例如：

• 对于需要长远规划的任务，智能体需要先制定计划，然后遵照执行。通过将计划写入文件系统，智能体稍后可以将其重新读入上下文窗口，提醒自己当前的任务是什么（例如，Manus 提到的“通过复述来引导注意力”^[5]）。
• 为了处理海量上下文，主智能体可能会派生出子智能体。当这些子智能体完成工作并获得新知识时，它们可以将这些知识写入文件系统，而不是直接回复给主智能体，从而避免信息在多层传递中失真（就像“传话游戏”一样）^[6]。
• 有些智能体需要大量关于如何行事的指令。与其将所有这些指令都塞进系统提示词（导致上下文臃肿），不如将它们作为文件存储起来，让智能体在需要时动态读取（例如 Anthropic 的技能 (skills) 机制^[7]）。

应对难以发现深层信息 (检索到的上下文 ≠ 所需上下文)

在大语言模型浪潮初期，语义搜索是最流行的上下文检索方法之一。它在某些场景下很有效，但对于某些类型的文档（如技术 API 参考、代码文件），由于文本缺乏足够的语义信息，语义搜索可能力不从心。

文件系统为智能体提供了一种替代方案，让它们可以通过 ls、glob 和 grep 等工具智能地搜索上下文。如果你最近用过 Claude Code，你可能注意到，Claude Code 在查找所需信息时主要依赖于 glob 与 grep 工具。这项技术之所以成功，有几个关键原因：

• 如今的模型经过了专门训练^[8]，能够理解如何遍历文件系统。*   信息本身通常已经有了逻辑化的结构（例如按目录组织）。
• glob 和 grep 不仅能让智能体定位到特定文件，还能精确定位到特定的行和字符。*   `read_file`^[9] 工具允许智能体指定从文件中读取哪些行。

基于这些原因，在某些情况下，利用文件系统及其搜索能力可以取得比语义搜索更好的效果。

当然，这并不意味着语义搜索没有用！它完全可以与文件系统搜索结合使用。Cursor 最近就发表了一篇博客^[10]，强调了将两者结合使用的好处。

实现随时间推移进行学习 (可访问的全部上下文 ≠ 所需上下文)

智能体出错的一个主要原因是它们缺少相关的上下文。因此，改进智能体的一个有效方法就是确保它们能够接触到正确的上下文。这有时可能意味着添加更多数据源或更新系统提示词。

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

1. 发现智能体因缺少恰当指令而表现欠佳；
2. 从领域专家处获取正确指令；3.  将新指令融入系统提示中。

很多时候，终端用户本身就是最好的领域专家。通过与智能体的对话，他们可能会（有意或无意地）提供关于正确指令的重要线索。既然如此，我们是否可以将上述的第三步——用新指令更新提示词——自动化呢？

我们认为，智能体的指令（或技能）与它们处理的其他任何上下文没有本质区别。文件系统完全可以成为智能体存储和更新自身指令的地方！

当收到用户反馈后，智能体可以立即将重要信息写入自己的文件并加以记忆。这对于快速记录一次性的事实非常有用，特别是那些用户专属的信息，比如他们的姓名、邮箱或其他偏好。

这个方向尚未完全成熟，仍是一种新兴的模式，但它为大语言模型提供了一种激动人心的新方式，使其能够随着时间的推移不断扩充自身的技能和指令库，从而确保在未来的迭代中能够访问到必要的上下文。

亲身体验深度智能体如何利用文件系统

我们有一个名为 DeepAgents的开源仓库（Python^[11] | TypeScript^[12]），可以让你快速构建一个能够访问文件系统的智能体。许多利用文件系统进行上下文工程的技巧都已内置其中！未来几乎肯定还会有更多新的模式涌现——不妨试试 DeepAgents，并告诉我们你的想法！

参考资料