深度代理中的解释器：工具调用与沙盒之间的代码

深度代理（Deep Agents）现在加入了解释器特性：一种小型嵌入式运行时，代理可以在其中编写和执行代码。这为代理提供了介于逐个工具调用和完整沙盒之间的中间地带，使其能够表达多步骤工作，将中间状态保留在模型上下文之外，并以更可预测的方式执行代码和操作。

什么是解释器？ 解释器是一个小型嵌入式运行时，代理在工作时可以针对其编写代码。从功能上讲，这类似于给代理提供一个Python或Node REPL：它可以定义变量、检查值、编写辅助函数，并在多次调用中重用状态。

目前，许多代理已经通过向主机或沙盒环境发出命令来执行代码。当任务是环境级工作（如运行命令、安装依赖或操作文件系统）时，这非常有用。解释器则针对不同的层次：代理编写的代码在代理循环内运行，用于协调委派、组合工具调用、转换结构化数据，以及决定哪些信息应返回给模型。

解释器的定位 当你考虑代理时，通常会想到附加工具。最简单的代理形式是模型在循环中使用工具：模型调用一个工具，观察结果，然后决定下一步。这种一步接一步的风格易于调试和评估，许多工作流程确实需要即时观察结果。沙盒在此基础上通过提供一个bash工具来运行命令、安装依赖和处理文件。但两种方式都有缺点：沙盒可以处理局部过程，但可能难以扩展；纯串行工具循环在中间步骤主要服务于下一步时显得笨拙。

解释器正好填补了这两者之间的空白。它为代理提供了对受限能力的代码级组合，而无需给予整个环境。模型可以编写一个小程序来表达对现有能力的控制流，同时由控制台决定哪些能力可用。

有意限制的设计 我们称其为解释器而非简单的代码运行时，因为它是故意受限的。默认情况下，它不具备正常编程环境中的API：没有文件系统、网络、shell、包安装，也没有实时访问。代理从基本的控制流和对象操作开始：对象、数组、映射、JSON等小型语言运行时。

这些能力通过明确的主机运行时桥接暴露。如果代理需要调用工具、读取限定的文件系统API、获取URL或委派给子代理，控制台必须有意地暴露这些能力。例如，只有当我们显式地将fetch、read_file和task工具桥接到解释器时，以下脚本才能工作。

主机运行时（与控制台相同）包含代理使用解释器可以执行的所有操作，并明确决定哪些操作可以被解释器代码调用。解释器是代理在该边界上的可编程侧。

解释器的优势 解释器状态作为一种上下文表面：代理控制台已在多个表面上组织上下文。消息历史是模型立即可用的上下文，但代价高昂且受注意力限制。文件系统为代理提供存储持久工件、笔记、中间文件和长期工作记忆的地方，但强制代理将工作状态序列化为文件后再重建。解释器状态为代理提供了另一个选项：值可以保留在运行时中，作为数组、对象、映射、计数器、队列和辅助函数。模型无需将每个中间值视为提示文本，但仍可要求解释器检查或重用这些值。

程序化工具调用：Anthropic的程序化工具调用（PTC）是此模式的另一个版本：工具调用从代理编写的代码内部发生，而不是作为模型中介的一系列操作。在深度代理中，PTC作为中间件实现，而非模型提供者行为。开发者传入允许列表，允许列表中的工具出现在全局tools命名空间下，每个工具作为异步函数暴露，解释器可以使用await调用。这意味着你可以为任何模型启用PTC，包括开源模型。在早期测试中，这种调用风格在某些任务上使用的令牌减少了多达35%。

处理大型数据集：对于文档密集型任务，解释器版本看起来不同。模型可以编写代码，在运行时中保持文档和搜索状态，通过编程方式迭代批次，评分或过滤候选，仅在选定切片上调用子代理。解释器返回一个紧凑的证据集，而不是将每个中间结果返回给模型。

递归编排：另一个相关概念是递归语言模型（RLMs），它将长提示视为外部REPL环境的一部分。

总结：解释器为深度代理提供了新的能力层次，使其在工具调用和沙盒之间灵活表达复杂工作流程，同时保持控制和安全。