> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 基于文件系统的AI代理上下文工程
- URL: https://www.hubwiz.com/blog/file-system-based-context-engineering-for-ai-agents/
- Published: 2025-11-27T23:22:36.000Z
- Updated: 2025-11-27T23:22:36.000Z
- Description: AI代理可以将检索结果写入文件系统，而不是使用对话历史记录来保存所有工具调用结果和笔记，并在必要时选择性地查找相关的信息。
- Author: admin
- Tags: APPLICATION, AGENT, #Import 2026-10-14 14:41

[深度代理](https://blog.langchain.com/deep-agents/?ref=hubwiz.com)的一个关键特性是它们对一组文件系统工具的访问。深度代理可以使用这些工具来读取、写入、编辑、列出和搜索其文件系统中的文件。

在本文中，我们将探讨我们认为文件系统对代理重要的原因。为了理解文件系统如何有帮助，我们应该从思考代理今天可能不足的地方开始。它们失败的原因要么是（a）模型不够好，要么是（b）没有访问正确的上下文。上下文工程是[“将上下文窗口填满与下一步相关的正确信息的微妙艺术和科学”](https://x.com/karpathy/status/1937902205765607626?ref=blog.langchain.com)。理解上下文工程——以及它如何失败——对于构建可靠的代理至关重要。

## 1、上下文工程的观点

一种看待现代代理工程师工作的角度是通过[上下文工程](https://blog.langchain.com/the-rise-of-context-engineering/?ref=hubwiz.com)的视角。代理通常**拥有**大量的上下文（所有支持文档、所有代码文件等）。为了回答一个即将到来的问题，代理**需要**一些重要的上下文（包含回答问题所需的信息）。在试图回答这个问题时，代理**检索**一些上下文体（将其拉入它的上下文窗口）。

![](https://www.hubwiz.com/blog/content/images/2025/11/image-139.png)

从这个角度来看，代理的上下文工程可能会以许多方式“失败”：

- 如果代理所需的上下文不在总上下文中，代理就无法成功。例如：客服代理需要访问某个文档页面来回答一个问题，但该页面尚未被索引。
- 如果代理检索到的上下文不能涵盖代理所需的上下文，那么代理将无法正确回答。例如：客服代理需要访问某个文档页面来回答一个问题，该页面存在且已被索引，但未被代理检索到。
- 如果代理检索到的上下文比代理所需的上下文大得多，那么代理就会浪费时间或令牌（或两者）。例如：客服代理只需要一个特定的页面，而代理却检索了100个页面。

作为代理工程师，我们的工作是**让红色匹配绿色（确保代理检索到的上下文尽可能小地包含所需信息）**

当寻求隔离适当上下文时会出现一些具体的挑战

1. **太多令牌**（检索到的上下文 >> 必要的上下文）  
一些工具，如网络搜索，可以返回大量令牌。几次网络搜索很快就能在你的对话历史中累积成千上万的令牌。你最终可能会遇到一个烦人的400错误请求，但在那之前，你的LLM账单会迅速膨胀，性能也会下降。
2. **需要大量上下文**（必要上下文 > 支持的上下文窗口）  
有时代理可能确实需要很多信息才能回答一个问题。这种信息通常无法在一个搜索查询中返回，这就是为什么许多人转向了“代理搜索”的想法——让代理反复调用搜索工具。问题是，上下文的数量很快增长到无法全部放入其上下文窗口的程度。
3. **寻找特定信息**（检索到的上下文 ≠ 必要的上下文）  
代理可能需要引用数百或数千个文件中埋藏的特定信息来处理输入。代理如何可靠地找到这些信息？如果无法做到，那么检索到的上下文就不会是回答问题所需要的。有没有替代方法（或补充方法）来代替语义搜索？
4. **随时间学习**（总上下文 ≠ 必要的上下文）  
有时代理可能只是没有访问回答问题所需上下文的权限（无论是在它拥有的工具还是指令中）。终端用户可能经常在与代理的互动中提供暗示性或明确的线索，表明该上下文可能是什么。有没有办法让代理将这些信息添加到其上下文中以供以后迭代使用？

这些都是常见的障碍，我们大多数人都以前经历过不同类型的这些问题！

## 2、文件系统如何使代理更好？

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

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

### 2.1 太多令牌（检索到的上下文 >> 必要的上下文）

代理可以将这些结果写入文件系统，而不是使用对话历史记录来保存所有工具调用结果和笔记，并在必要时选择性地查找***相关的信息***。Manus是最早公开讨论这种方法的人之一[他们的博客文章](https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus?ref=blog.langchain.com)中提到了这一点。下面的图表来自他们的博客文章。

![](https://www.hubwiz.com/blog/content/images/2025/11/image-140.png)

让我们以网络搜索工具的第一个例子为例。我运行了一个网络搜索，得到10k个令牌的原始内容。其中大部分内容可能并不总是必要的。如果我把这些内容放在我的消息历史中，整个对话过程中都会保留这10k个令牌，导致我的Anthropic账单上涨。但如果我把这个大的工具结果转移到文件系统，代理就可以智能地grep搜索某些关键词，然后只将必要的上下文读入我的对话中。

在这个例子中，代理实际上将文件系统用作一个**大型上下文的临时纸巾**。

### 2.2 需要大量上下文（必要上下文 < 支持的上下文窗口）

有时代理需要大量上下文来回答问题。文件系统为LLM提供了一个很好的抽象，允许它们按需动态存储和提取更多信息。这些包括：

- 对于长期答案，代理需要制定计划并遵循它。通过将计划写入文件系统，代理可以在以后将此信息重新拉入上下文窗口，提醒代理它应该做什么（例如 [“通过重述操纵注意力”](https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus?ref=blog.langchain.com)）
- 为了浏览所有这些上下文，代理可能会启动子代理。当这些子代理工作并学习东西时，它们不仅向主代理回复它们的学习成果，还可以将知识写入文件系统（例如 [“最小化电话游戏”](https://www.anthropic.com/engineering/multi-agent-research-system?ref=blog.langchain.com)）
- 一些代理需要很多关于如何做事情的说明。与其将所有这些说明都放入系统提示中（从而增加上下文），你可以将它们存储为文件，并让代理按需动态读取它们（例如 [Anthropic技能](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills?ref=blog.langchain.com)）。

### 2.3 寻找特定信息（检索到的上下文 ≠ 必要的上下文）

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

文件系统提供了一种替代方法，允许代理使用ls、glob和grep工具智能地搜索上下文。如果你最近使用过Claude Code，你会知道它严重依赖glob和grep搜索来找到它需要的正确上下文。这种技术成功的几个关键点如下。

- 当前的模型专门训练[理解遍历文件系统](https://platform.claude.com/docs/en/agents-and-tools/tool-use/bash-tool?ref=blog.langchain.com)
- 信息通常已经逻辑结构化（目录）
- glob和grep允许代理不仅隔离特定文件，还可以隔离特定行和特定字符
- [read\_file](https://platform.claude.com/docs/en/agents-and-tools/tool-use/text-editor-tool?ref=blog.langchain.com) 工具允许代理指定从文件中读取哪些行

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

请注意，语义搜索仍然有用！并且可以与文件系统搜索一起使用。Cursor最近[写了一篇博客](https://cursor.com/blog/semsearch?ref=blog.langchain.com)，强调同时使用两者的优点。

### 2.4 随着时间学习（总上下文 ≠ 必要的上下文）

代理出错的一个主要原因是缺少相关上下文。提高代理的一个好方法通常是确保它们能够访问正确的上下文。有时这可能看起来像添加更多的数据源或更新系统提示。

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

1. 看到一个代理缺乏适当指令的例子
2. 从主题专家那里获取相关指令
3. 用这些指令更新提示

通常，最终用户实际上是最佳的主题专家。通过与代理的对话，他们可能会提供有关正确相关指令的重要线索（隐含或显式）。因此，考虑到这一点——有没有办法自动化第三步（用这些指令更新提示）？

我们认为代理的指令（或技能）与其他它们可能想要处理的上下文没有区别。文件系统可以作为代理存储和更新自己指令的地方！

在用户反馈之后，代理可以立即写入自己的文件并记住一个重要信息。这对于快速的一次性事实非常有用，特别是那些可能因用户而异的东西，比如他们的名字、电子邮件或其他偏好。

这还没有完全解决，仍然是一个新兴模式，但它是一个令人兴奋的新方式，让LLM可以随着时间的推移增长自己的技能集和指令，确保未来的迭代中能够访问必要的上下文。

## 3、看看深度代理如何利用其文件系统

我们有一个开源仓库叫做Deep Agents ([Python](https://github.com/langchain-ai/deepagents?ref=blog.langchain.com), [TypeScript](https://github.com/langchain-ai/deepagentsjs?ref=blog.langchain.com))，它让你可以快速构建一个具有文件系统访问权限的代理。许多使用文件系统的上下文工程技巧已经内置！肯定还有更多模式会出现——试试Deep Agents并告诉我们你的想法吧！

---

原文链接：[How agents can use filesystems for context engineering](https://blog.langchain.com/how-agents-can-use-filesystems-for-context-engineering/?ref=hubwiz.com)

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