Dash如何利用上下文工程打造更智能的AI
作者：肖恩-迈克尔·刘易斯 • 2025年11月17日
为Dash设计精确的上下文工程
展望未来
当我们最初构建Dash时，它与大多数企业搜索系统类似：一个结合了语义搜索和关键词搜索、基于索引文档的传统RAG（检索增强生成）流程。它在检索信息和生成简洁答案方面效果不错。但随着团队开始将Dash用于不仅仅是查找内容——例如，要求它解释、总结甚至对找到的内容采取行动——我们意识到仅有检索是不够的。从“身份项目的状态是什么”自然地演进到“打开编辑器并撰写一份我所负责项目的执行摘要”，这要求Dash从搜索系统演变为具有代理能力的AI。
这一转变引入了一种新的工程挑战：决定模型实际需要看到哪些信息和工具才能有效地进行推理和行动。这后来被广泛称为上下文工程，即在正确的时间构建、过滤和传递恰如其分的上下文，使模型能够智能规划而不至于不堪重负。我们开始思考这些理念如何在Dash内部应用，包括模型如何规划、推理并对请求采取行动。它不再仅仅是搜索和总结结果，而是规划要做的事情并执行这些步骤。
同时，在Dash工作流中添加工具也对如何管理上下文带来了新的权衡。在任何RAG系统中，输入模型的信息的精确性都至关重要，这一经验同样适用于代理系统。为模型提供最相关的上下文，而不仅仅是更多的上下文，始终能带来更好的结果。下面，我们将介绍我们是如何为Dash构建更好的上下文的。
为Dash设计精确的上下文工程
随着Dash获得新的能力——如上下文搜索和辅助编辑——我们注意到一个意想不到的现象：工具越多，往往意味着决策速度更慢、准确性更低。这里的“工具”指模型可以调用的任何外部功能，例如搜索、查找或摘要。每一项新能力都扩大了模型的决策空间，创造了更多的选择机会和混淆的可能。即使是设计良好的工具，也会让模型花费更多时间在决定如何行动上，而不是真正采取行动。问题不在于工具有缺陷，而在于好工具太多了。用人类的术语来说，Dash正面临着分析瘫痪。
模型上下文协议是一个用于定义和描述服务器所提供工具的开放标准，它通过概述每个工具的功能和所需输入来帮助解决这个问题。但当我们试验MCP服务器时，遇到了限制。我们添加的每个工具都带有自己的描述和参数，所有这些都必须适配到模型的上下文窗口内（即模型用于读取和推理信息的空间）。在实践中，这些定义还会消耗大量令牌（token），而令牌是一种直接影响成本和性能的资源。此外，我们注意到Dash在运行时间较长的任务中整体准确性会下降。工具调用增加了大量的额外上下文。我们看到了与流行的“上下文腐化”模式类似的情况。
这促使我们重新思考上下文。构建有效的、具有代理能力的AI不仅仅是增加功能，更是帮助模型关注最重要的事情。对于Dash而言，这意味着通过以下三项核心策略来管理上下文，使模型能够做出更快、更好的决策：
- 限制上下文中的工具定义数量
- 过滤上下文，只保留相关部分
- 为需要深度推理的任务引入专用代理
我们的原则很简单：更好的上下文带来更好的结果。关键在于，在正确的时间，以正确的形式，为模型提供正确的信息。
限制上下文中的工具定义数量
我们的第一个发现是，为模型提供过多的工具调用选项会导致更差的结果。Dash连接了我们的客户用于完成工作的许多应用程序，每个应用程序都提供自己的检索工具，如搜索、按ID查找或按名称查找。
尽管我们拥有Dash搜索索引——我们基于服务器的搜索索引，用于存储和管理文档及消息，以实现快速可靠的检索——但我们确实尝试过使用其他工具进行检索。例如，为服务一个请求，Dash可能需要查询Confluence获取文档、查询Google Docs获取会议记录、查询Jira获取项目状态。在我们对这些其他检索工具的实验中，我们发现模型通常需要调用所有这些工具，但它的调用并不总是可靠的。
我们通过用一个由Dash通用搜索索引支持的、专门的单一工具来替换所有这些检索选项，从而解决了这个问题。我们不再期望模型理解和在数十个API之间做出选择，而是创建了一个处理所有服务检索的统一接口。关键思想很简单：为模型提供一种一致的检索信息方式，使其推理更清晰、规划更高效、上下文使用更集中。
这些经验也影响了我们设计Dash MCP服务器的方式，该服务器仅通过一个工具，就将Dash的检索能力带给Claude、Cursor和Goose等与MCP兼容的应用程序。它连接到人们已经使用的系统，并在他们的应用程序中安全地搜索。通过保持描述的精简，更多的上下文窗口可以专注于用户的请求。
过滤上下文，只保留相关部分
我们的下一个发现是，从多个API检索到的内容并非都对当前任务真正有用。当我们尝试同时从几个工具拉取数据时，仍然需要一种方法来对结果进行排序和过滤，以便只有最相关的信息才能到达模型。
我们构建的Dash索引将来自多个来源的数据合并到一个统一的索引中，然后在上面叠加了一个知识图谱，以连接这些来源中的人员、活动和内容。（知识图谱映射这些来源之间的关系，使系统能够理解不同信息片段是如何连接的。）这些关系有助于根据每个查询和每个用户最关心的内容对结果进行排序。因此，模型只能看到我们平台已确定为相关的内容，这使得每一个上下文片段都具有意义。预先构建索引和图谱意味着Dash可以在运行时专注于检索，而不是重建上下文，从而使整个过程更快、更高效。
关键的教训是：所有检索到的内容都会影响模型的推理，因此相关性对于有效地引导模型至关重要。仅发送必要的内容既能提高性能，也能提升整个代理流程的质量。
为复杂任务引入专用代理
我们的第三个发现是，有些工具非常复杂，模型需要额外的上下文和示例才能有效地使用它们。随着我们不断扩大Dash搜索工具的功能，我们亲眼目睹了这一点。查询构建本身就被证明是一项艰巨的任务。它涉及理解用户意图、将该意图映射到索引字段、为获得更好的语义匹配而重写查询，以及处理拼写错误、同义词和隐含上下文等边缘情况。
随着搜索工具功能越来越强大，模型需要更多的指令才能正确使用它。这些细节开始占据上下文窗口的很大一部分，从而减少了用于整体任务推理的空间。换句话说，模型将更多的注意力放在了如何搜索上，而不是如何处理结果上。
我们通过将搜索功能转移到其自己的代理中解决了这个问题。主要的规划代理决定何时需要搜索，并将实际的查询构建任务委托给一个拥有自己提示词的专用代理。这种分离使主代理能够专注于规划和执行，而搜索代理则处理检索的具体细节。关键的教训是：当一个工具需要过多解释或上下文才能有效使用时，通常最好将其转变为一个拥有聚焦提示词的专用代理。
展望未来
面向代理AI系统的上下文工程仍然是一个新兴领域。虽然我们概述的策略——检索整合、相关上下文过滤和专用任务代理——在我们的用例中效果良好，但我们仍在不断学习和迭代。随着我们继续为知识工作者构建最佳工具，我们发现Dash索引是管理相关上下文的有力资源，并帮助我们更有效地使用其他工具。
我们在此分享的工作专注于解决一个难题：学习如何在工具选择和检索中，将上下文精简到真正重要的部分。但上下文在许多方面都是昂贵的。它影响成本、速度以及模型对当前任务的关注程度。我们发现，更精简的上下文不仅能节省资源，还能让模型变得更聪明。
接下来，我们将把这些经验教训应用到Dash上下文的其他部分，如用户和公司档案，以及长期和短期记忆。我们认为，通过改进这些领域，尤其是在我们尝试更小、更快的模型时，还有更多的性能潜力可以挖掘。
尽管我们的讨论集中在基于检索的工具上，但面向行动的工具也表现出许多相同的限制。MCP继续作为一个健壮的协议，但有效的扩展取决于减少工具激增、投资于专用代理，以及在适当的时候让LLM生成基于代码的工具——这种方法与我们整合检索工具到Dash检索系统的思路类似。我们在之前的博客文章中介绍了Dash如何使用基于代码的工具，我们看到其他公司也在以类似的心态处理这个问题。
展望未来，我们的重点是让上下文更加高效，以便模型能够将其注意力集中在最重要的地方。
致谢：Rene Schmidt, Josh Clemm, Marta Mendez, Nishchal Arya, Roland Hui, Noorain Noorani, Tony Xu
~ ~ ~
如果构建创新的产品、体验和基础设施让您感到兴奋，欢迎加入我们，一起构建未来！请访问 jobs.dropbox.com 查看我们的空缺职位。