传送锚点
深度代理的一个关键特性是它们能够访问一组文件系统工具。深度代理可以使用这些工具来读取、写入、编辑、列出并搜索文件系统中的文件。
在这篇文章中，我们将讲解为什么我们认为文件系统对代理来说很重要。为了理解文件系统为何有帮助，我们应先思考代理今天可能存在的不足之处。它们要么失败，要么是因为（a）模型不够好，要么（b）他们无法获得正确的背景。上下文工程是"用恰到好处的信息填充上下文窗口的精致艺术与科学"。理解上下文工程及其失败机制对于构建可靠的代理至关重要。
1.上下文工程的一个视角
看待现代代理工程师工作的一种方式是通过上下文工程的视角。客服通常能接触到很多上下文（所有支持文档、所有代码文件等）。为了回答一个来的问题，智能体需要一些重要的上下文（其中包含回答问题所需的上下文）。在试图回答该问题时，代理会获取一些上下文（以拉入其上下文窗口）。
从这个角度看，情境工程对代理来说有许多可能"失败"的方式：
如果主体所需的上下文不在整体上下文中，主体就无法成功。举例：客服代表需要访问某个文档页面来回答一个问题，但该页面尚未被索引。
如果代理检索的上下文无法封装其所需的上下文，那么代理将无法正确回答。举例：客服客服需要访问某个文档页面来回答一个问题，该页面存在并被索引，但客服无法检索。
如果代理获取的上下文远大于其所需的上下文，那么代理就是在浪费时间、标记或两者兼有。示例：客服客服需要单个特定页面，而该客服会检索100页。
作为代理工程师，我们的工作是将红色映射到绿色（确保代理检索的上下文尽可能是所需信息的超集）
在试图分离合适的背景时，会出现一些具体的挑战
标记过多（检索上下文>>必要上下文）有些工具，比如网页搜索，可能会返回大量标记。几次网络搜索很快就能在你的聊天记录中积累数万个代币。你可能最终会遇到烦人的400个错误请求错误，但早在那之前，你的LLM账单就会膨胀，性能下降。
需要大量上下文（必要的上下文>支持的上下文窗口）有时代理可能需要大量信息来回答问题。这些信息通常无法通过单一搜索查询返回，这也是许多人采用"代理搜索"这一概念的原因------让代理反复调用搜索工具。问题在于上下文的数量很快就会增加到无法全部放进上下文窗口的程度。
寻找生态位信息（检索上下文≠必要上下文）代理可能需要引用埋藏在数百甚至数千个文件中的生态位信息以处理输入。代理如何可靠地找到这些信息？如果不能，那么检索到的上下文就不是回答问题所需的。语义搜索有没有替代方案（或补充）？
随着时间的学习（完整的上下文≠必要的上下文）有时代理可能无法访问回答问题所需的上下文（无论是工具还是指令）。终端用户通常会在与代理的互动中（隐含或显性）提供该上下文的线索。代理有没有办法把它添加到它的上下文中，以便未来迭代？
这些都是常见的障碍，我们大多数人都经历过各种不同的挑战！
文件系统如何让代理变得更好？
简单来说：文件系统提供了一个单一接口，代理可以通过它灵活地存储、检索和更新无限数量的上下文。
让我们看看这在上述每种情境中如何帮助。
2.拆上下文时的四大具体挑战
标记过多 （检索上下文>>必要上下文）代理无需使用对话历史记录来保存所有工具调用结果和笔记，而是可以将这些内容写入文件系统，并在必要时选择性地查找相关信息。Manus是最早公开谈论这种方法的人之一------下图摘自他们的博客文章。
我们来看看第一个例子，使用网络搜索工具。我做了一次网络搜索，从工具里回来了1万个原始内容代币。大部分内容可能并非一直都需要。如果我把这点放进消息记录，所有1万代币都会在整个对话中一直待着，导致我的Anthropic账单不断上涨。但如果我把这个大工具结果卸载到文件系统，代理就可以智能地用grep搜索某些关键词，然后只在我的对话中读取必要的上下文。
在这个例子中，代理实际上是将文件系统作为大型上下文的临时笔记本。
需要大量上下文（必要的上下文<支持上下文窗口）
有时候，代理需要大量背景信息来回答这个问题。文件系统为大型语言模型提供了很好的抽象，可以动态存储和获取更多信息。例如：
对于长期目标，经纪人需要制定计划并执行。通过将该计划写入文件系统，代理随后可以将这些信息拉回上下文窗口，提醒代理它应该做什么（例如**"通过背诵控注意力"**)
为了梳理所有这些上下文，代理可能会启动子代理。随着这些子代理工作和学习，他们不仅仅向主代理反馈所学，还能将知识写入文件系统（例如减少传话游戏）)
有些经纪人要求很多作指令。与其把所有指令塞进系统提示符（和冗余上下文），不如把它们存成文件，让代理根据需要动态读取（比如人类技能）。
寻找小众信息（检索上下文≠必要上下文）
语义搜索是LLM浪潮早期最流行的上下文检索方法之一。它在某些用例中可能有效，但根据文档类型（例如技术API参考、代码文件），由于文本中缺乏语义信息，语义的放置可能非常糟糕。
3.文件系统如何让代理变得更好
文件系统提供了一种替代方案，使代理能够智能地使用 ls、glob 和 grep 工具搜索上下文。如果你最近用过Claude Code，你会知道它很大程度上依赖glob和grep搜索来找到所需的上下文。这种方法之所以成功，有几个关键。
如今的模型专门训练 以理解遍历文件系统信息通常已经有逻辑结构（目录）GLOB和GREP不仅允许代理分离特定文件，还能隔离特定行和特定字符**read_file**工具允许代理指定从文件中读取哪些行
基于这些原因，在某些情况下，使用文件系统（以及通过文件系统获得的搜索功能）可以创造更好的结果。
4.结论与展望
请注意，语义搜索依然有用！并且可以与文件系统搜索结合使用。Cursor 最近写了一篇博客，强调了两者一起使用的好处。
随着时间的学习（完整的上下文≠必要的上下文）
经纪人犯错的一个重要原因是他们缺少相关的背景。提升经纪人的好方法通常是确保他们能够接触到正确的情境。有时这可能表现为添加更多数据源或更新系统提示。
更新系统提示的常见做法是：
请看一个代理缺乏适当指令的例子
从主题中获取相关指导
用这些说明更新提示
很多时候，用户才是最专业的领域专家。通过与代理的对话，他们可能（隐含或明示）提供关于正确相关指令的重要线索。考虑到这一点------有没有办法自动化上面第三步（更新提示并输入这些说明）？
我们认为经纪人的指示（或技能）与他们可能想处理的其他情境没有区别。文件系统可以作为代理存储和更新自己指令的地方！
用户反馈一到，代理就可以写入自己的文件并记住重要信息。这非常适合快速获取一次性的事实，尤其是用户可能自定义的名称、电子邮件或其他偏好。
这个问题尚未完全解决，仍是一个新兴的趋势，但这是大型语言模型随着时间增长自身技能和指令的一种令人兴奋的新方式，确保未来迭代能够访问必要的上下文。