Deep Agents v0.7 将每轮 Token 减少 65%

Deep Agents v0.7 将每轮基础输入 Token 减少了 65%。 这意味着每次调用携带的固定提示词开销更少、API 支出更低，也能为真正重要的任务内容留出更多上下文空间。

如果要概括此次更新，重点如下：

• 默认基础系统提示词已被移除
• 内置工具说明更简短
• 待办事项不再默认附加
• 中间件按需选择，而不是捆绑加入
• 节省来自执行框架，而不是模型

简单来说：如果一个智能体发起 10 次调用，以前同一个固定包装内容会被发送 10 次。在 v0.7 中，这个默认包装小了很多。因此，每一轮请求都更精简，对读取或写入文件这类简单任务尤其如此。

有几个重点十分突出：

• 成本遵循 llm_calls × input_tokens_per_call 扩展
• 旧配置即使面对不需要的任务，也会发送规划、文件系统和子智能体相关文本
• 新配置把控制权交给开发者，让我可以为任务选择提示词、工具和中间件
• 最大幅度的削减来自移除基础提示词并缩短工具文本
• 长时间、多智能体工作流获益最多，因为固定开销会在每一步重复出现

下面是简单的前后对比：

我的结论： v0.7 的重点不是模型变化，而是提示词纪律。 如果执行框架保持精简，就能保留完整的 65% 收益；如果重新堆入中间件和工具，就会放弃其中一部分收益。

这就是本次更新的核心，也为文章后续内容奠定了基础。

可配置执行框架发生了哪些变化

65% 的 Token 降幅来自改变执行框架在每一轮注入的内容，而不是使用更智能的模型。简单来说，v0.7 去掉了过去随每次请求一同传递的大量默认文本。

移除基础系统提示词并精简工具说明

在 v0.7 之前，即使任务根本不需要，执行框架也会在每次请求中装入默认系统提示词、冗长的工具说明、规划中间件和子智能体逻辑。v0.7 通过让执行框架可配置来改变这一设置，由开发者决定每一轮要注入哪些内容。

最大的开销来源是默认基础系统提示词和冗长的内置工具说明。基础提示词包含规划工具、文件系统工具和子智能体的说明，而且每一轮都会发送。在 v0.7 中，该提示词已被移除。开发者现在可以提供与任务相匹配的提示词文本。

ls、read_file 和 write_file 等实用工具的内置说明也被缩短了。工具的行为没有变化，只是每次请求周围的固定文本更少。这两项变化都不会影响底层模型，只是减少了过去每一轮都要携带的 Token 负载。

待办事项改为按需启用，中间件可以明确选择

在 v0.7 之前，todoListMiddleware 默认附加，因此每一轮都会发送规划文本。在 v0.7 中，待办事项改为按需启用。这意味着只有当多步规划确实能改善任务时，才需要添加它们。

同样的转变也适用于中间件堆栈的其他部分。FilesystemMiddleware 和 SubAgentMiddleware 不再默认捆绑。开发者现在可以只组合自己需要的中间件。文件读取任务可以跳过子智能体逻辑，验证工作流则可以只在有帮助时加入清单中间件。

编排如何变得更加明确

实际变化很简单：设置方式从隐式默认转向显式配置。执行框架不再自行决定哪些工具可见、运行哪些中间件以及系统提示词包含什么内容，而是由开发者做出这些选择。他们现在可以按任务控制提示词组装、工具可见性和中间件。

这些变化体现在下面的默认智能体堆栈中。^[2]

Token 用量前后对比

这些执行框架变化会立即反映在每一轮发送的载荷中。节省来自精简固定请求外壳，而不是改变用户提示词或模型。

v0.7 之前的默认智能体轮次

在 v0.7 之前，即使完全没有用到，每一轮也会包含规划、文件系统和子智能体的脚手架。待办文本与中间件提示词同样默认包含。这意味着一个很大的固定载荷会在每一轮重复发送。

v0.7 之后的默认智能体轮次

在 v0.7 之后，简单的文件读取任务只会发送它需要的工具和中间件，因此额外开销不会再跨轮次重复。基础系统提示词被移除，工具说明更简短，文件读取任务也不再携带未使用的规划或子智能体文本。

正如 Aaron Jewitt 所指出的，智能体成本遵循 llm_calls × input_tokens_per_call 扩展。^[1]

Token 节省来自哪里

下面展示了 65% 降幅的来源。

最大的节省来自移除基础提示词和缩短工具说明。因此，选择性使用中间件并减少工具可见性，会在日常工作流中带来如此明显的差异。

下一节将说明开发者如何只选择任务需要的执行框架组件，从而保留这些收益。

面向开发者的执行框架配置模式

确定 Token 节省后，下一步是为每项任务选择精简的执行框架配置。这些收益来自更短的提示词和更紧凑的框架默认设置。在 Deep Agents v0.7 中，每轮 Token 开销主要由执行框架而不是模型造成。这意味着优化 Deep Agents v0.7 时，模型选择并非重点，如何组装执行框架才是关键。

只选择任务需要的中间件

只有当任务需要门控、规划或状态管理时才使用中间件。对于短任务，这些额外层只会增加开销。

规则很简单：从任务所需的最小中间件堆栈开始。 工具也是如此，只公开当前任务真正需要的工具。

限制工具可见性并缩短说明

每一轮都展示所有工具，是造成每轮输入膨胀最快的方式之一。缩小工具可见范围有助于保持提示词精简。

更短的工具说明可以进一步缩小提示词。紧凑而准确的说明不仅减少提示词大小，也让模型更容易在没有大量额外上下文的情况下选择正确工具。

使用按需启用的待办事项和基于配置档的默认值

待办管理适合需要智能体跨越许多步骤跟踪进度的长期任务。对于短小的单步工作，待办事项只会增加开销，却没有任何回报。

让长期任务按需启用待办事项，并按智能体类别设置精简或丰富的默认值。精简的智能体类别默认值可以让简单智能体保留 65% 的收益，而更丰富的配置档则留给重度规划工作流。

这些选择决定了 65% 的降幅能否在日常使用中转化为更低成本和更快迭代。

v0.7 更新对成本、速度与规模意味着什么

更低的推理成本和更快的迭代循环

在长工作流中，每一轮更小的请求外壳会不断累积收益。Token 成本会在多轮运行中叠加，因此精简执行框架不只会在第一轮省钱，也会让之后每一轮的起点保持更小；随着对话增长，差距还会继续扩大。

以下是这一降幅在实际中的体现：

更小的载荷同样可以加快迭代循环。如果你正在测试提示词变化或尝试新的工具设置，更轻量的请求会更快返回，从而减少日常开发工作中的大量阻力。

长时间运行和多智能体工作流拥有更好的扩展能力

当多个智能体共享同一份工作流预算时，同样的 Token 节省会更加重要。固定开销是多智能体系统中不易察觉的预算消耗。如果每个智能体都携带臃肿的执行框架，这种开销会在每一个协同轮次中成倍增加。

更精简的执行框架包可以让每个智能体占用更少空间。这能提升吞吐量，并降低工作流进行到一半时触及上下文上限或速率限制的可能性。

随着上下文窗口逐渐填满，性能可能下降。精简执行框架能为每个智能体留下更多可用于实际任务数据的上下文空间。简单来说，长时间运行的工作流可以更久地保持准确，而无需让压缩或摘要逻辑过早介入。

在轮次很多、智能体很多或两者兼具的工作流中，较低的每次调用开销价值最大。65% 的 Token 降幅降低了每次调用成本，但 v0.7 在规模方面更大的收益来自显式编排模型。通过明确停止条件而不是开放式循环，智能体完成任务所需的总调用次数会更少。

Deep Agents v0.7 发布的关键要点

Deep Agents v0.7 通过让执行框架可配置来改善成本和质量。中间件选择、工具可见性和基于配置档的默认值，如今决定了工作流能否保留全部收益，还是会因为额外开销而放弃其中大部分。

配置是主要优化杠杆。 它在轮次很多、智能体很多或两者兼具的工作流中最为重要。

常见问题

如何在实际工作流中保留完整的 65% Token 节省？

把执行框架配置视为一个持续演进的系统，而不是一项设置一次就不再理会的任务。首先测量 Token 用量和 LLM 调用次数，然后使用执行框架锁定严格的行为规则。

使用 PreCompletionChecklistMiddleware 阻止重复的推理循环。使用 LocalContextMiddleware 只传入模型需要的上下文和工具。再加入提示词缓存，让系统指令在多次运行中保持稳定。

当 Token 用量激增时，检查是否发生漂移，并收紧执行框架规则。

哪些任务仍应使用待办事项或额外中间件？

当智能体处理复杂的多部分问题时，使用 todoListMiddleware。它可以帮助智能体随着工作推进，跟踪已经完成的内容和仍需处理的事项。

当你在提示词中要求使用 write_todos 工具时，智能体可以随着新细节出现更新进度。这让漫长而困难的工作流更容易跟踪，也能帮助智能体保持方向。

更小的执行框架会影响智能体质量或可靠性吗？

默认情况下不会。经过调优的更小执行框架，可以通过更好的上下文处理、工具卸载和结构化提示词封装来减少每轮 Token，同时保持甚至提升可靠性。

当这些节省与确定性护栏配合时，质量可以保持稳定，例如验证循环和完成前清单。这能帮助智能体始终聚焦于重要的任务数据，并在回答前复核自己的工作。