前面几篇文章介绍了 Deep Agents 的 Tools、Filesystem、Backend，以及 Shell、Execute 和 Sandbox。通过这些机制，Agent 已经能够调用工具、管理文件和执行代码。

在实际开发中，还会遇到一类问题：Agent 需要重复调用多个工具，处理返回的数据，再根据结果继续操作。

例如，查询 100 个地区的订单，筛选异常记录并统计金额。传统 Tool Calling 可以完成，但大量中间结果需要返回模型，增加了上下文消耗和执行延迟。

Deep Agents 提供的 Interpreter（解释器） 允许 Agent 将多个操作组织成程序，在解释器中完成工具调用、条件判断和数据处理，最后只返回必要结果。

这就是 Programmatic Tool Calling（PTC，程序化工具调用）的核心思路。

一、工具调用的成本

传统 Tool Calling 通常由模型决定调用工具，等待执行结果，再判断下一步操作。

模型决定调用工具 ↓执行工具 ↓结果返回模型 ↓模型继续判断 ↓执行下一步

模型也可以一次发起多个工具调用，但当后续操作依赖前一步的结果时，通常仍需要新的模型轮次。

对于少量调用，这种方式没有问题。但如果查询 100 个地区，每个地区返回 200 条订单，最终只有几十条异常记录值得关注，将全部数据交给模型就没有必要。

更合适的方式是让模型生成执行逻辑，由程序完成重复操作。

模型生成执行代码 ↓Interpreter 执行 ├─ 批量调用工具 ├─ 条件判断与循环 └─ 数据筛选和统计 ↓返回精简结果 ↓模型继续分析

PTC 减少的是模型参与中间步骤的次数，而不是实际的业务工具调用数量。

二、解释器的运行机制

由于我们使用 Deep Agents Python SDK，Agent 的创建、工具定义和运行流程都基于 Python。

需说明的是，Deep Agents 的 Interpreter 并不直接执行 Python 代码，而是使用 JavaScript 作为内部执行语言。

那么，为什么基于 Python 的 Agent，要使用 JavaScript 来执行程序？

这是因为两者处于不同的执行层次。

Deep Agents 通过CodeInterpreterMiddleware集成 Interpreter，底层使用 QuickJS 执行 JavaScript。

Deep Agents（Python） │ │ 模型调用 eval ▼Interpreter（QuickJS） │ ├─ 循环、条件判断 ├─ 数据处理 └─ tools.getOrders() │ │ PTC 桥接 ▼ Python 业务工具 │ ▼ 返回执行结果

开发者使用 Python 定义业务工具，例如get_orders()。

模型需要批量处理任务时，可以生成 JavaScript，通过eval执行。代码中如果需要调用业务工具，则通过 PTC 桥接到 Python。

因此，JavaScript 只是 Interpreter 内部的执行语言，Agent 应用仍然由 Python 开发。

Interpreter 与 Sandbox

上一篇介绍的 Sandbox 同样能够执行代码，但两者的职责不同。

Interpreter 适合在 Agent 内部组织工具调用。如果需要运行 Python 脚本、安装依赖或执行测试，仍应使用具备相应能力的 Sandbox Backend。

三、解释器的实践

下面通过一个订单分析 Agent，了解 Interpreter 的具体用法。

任务是查询三个地区的订单，筛选逾期三天及以上的记录，并统计数量和总金额。

1. 安装依赖

pip install -U "deepagents[quickjs]" langchain-openai

2. 定义业务工具

先准备模拟订单数据：

import asyncioimport jsonfrom deepagents import create_deep_agentfrom langchain_core.tools import toolfrom langchain_quickjs import CodeInterpreterMiddlewareDATA = { "east": [ {"id": "E01", "amount": 1200, "late_days": 5}, {"id": "E02", "amount": 500, "late_days": 1}, ], "west": [ {"id": "W01", "amount": 750, "late_days": 4}, ], "south": [ {"id": "S01", "amount": 680, "late_days": 2}, {"id": "S02", "amount": 320, "late_days": 3}, ],}@tooldef get_orders(region: str) -> str: """查询地区订单。region 为 east、west 或 south。""" return json.dumps(DATA[region], ensure_ascii=False)

这里使用 LangChain 的@tool定义工具，与普通 Deep Agents 开发没有区别。

实际项目中，可以将模拟数据替换为数据库查询或 HTTP API。

3. 配置 Interpreter

agent = create_deep_agent( model="openai:gpt-5.5", tools=[get_orders], system_prompt=( "涉及批量查询与统计时，优先使用 eval " "执行程序化工具调用，并在程序中完成" "数据筛选和汇总，只返回必要结果。" ), middleware=[ CodeInterpreterMiddleware( ptc=["get_orders"], mode="turn", timeout=10.0, max_ptc_calls=10, max_result_chars=2000, ) ],)

其中，ptc是最关键的参数。

tools=[get_orders]表示 Agent 可以直接调用这个工具。

ptc=["get_orders"]则允许 Interpreter 内部的 JavaScript 调用它。

PTC 默认不开放业务工具，需要显式配置白名单。

4. 运行 Agent

async def main(): result = await agent.ainvoke({ "messages": [{ "role": "user", "content": ( "查询 east、west、south 的订单，" "筛选逾期至少三天的记录，" "统计数量和总金额。" ), }] }) print(result["messages"][-1].content)asyncio.run(main())

PTC 使用异步桥接，因此这里采用ainvoke()。

执行过程中，模型可以通过eval运行类似下面的 JavaScript：

const regions = ["east", "west", "south"]; const results = await Promise.all( regions.map(region => tools.getOrders({ region })));const orders = results.flatMap((text, index) => JSON.parse(text).map(order => ({ ...order, region: regions[index] })));const overdue = orders.filter( order => order.late_days >= 3);({ count: overdue.length, total: overdue.reduce( (sum, order) => sum + order.amount, 0 ), orders: overdue});

这里的tools.getOrders()实际调用的是 Python 定义的get_orders()，PTC 会将工具名称转换为驼峰格式。

Promise.all()并发查询三个地区，后续代码完成筛选与统计。

根据模拟数据，预期结果为：

{ "count": 3, "total": 2270, "orders": [ {"id": "E01", "amount": 1200, "late_days": 5, "region": "east"}, {"id": "W01", "amount": 750, "late_days": 4, "region": "west"}, {"id": "S02", "amount": 320, "late_days": 3, "region": "south"} ]}

模型获得的是处理后的结果，而不需要逐次接收各地区的原始订单。

需要注意，是否调用eval以及具体生成什么代码，仍由模型决定。

四、状态与资源管理

Interpreter 不仅可以执行代码，还能在一定范围内保存中间状态。

状态生命周期

CodeInterpreterMiddleware通过mode控制状态：

默认使用thread。

例如，第一次eval保存的变量，可以在相同解释器状态中继续使用，不必重新查询数据。

thread支持跨轮次状态快照，但只适合恢复可序列化的数据。需要跨进程持久化时，还应结合 LangGraph Checkpointer。

对于普通的单轮分析任务，建议优先使用mode="turn"，减少不必要的状态积累。

资源限制

Interpreter 还提供几个重要参数：

这些限制可以降低异常代码带来的资源消耗。

不过，max_ptc_calls只能限制调用总量，不能控制并发数。

当需要批量请求几百个 API 时，应该分批执行，并在 Python 工具层实现并发控制、超时和重试。

对于允许部分失败的任务，可以使用Promise.allSettled()，避免单个接口异常导致整个批次失败。

五、工程边界与适用场景

Interpreter 提升了执行灵活性，但也意味着模型生成的代码能够参与业务操作，因此需要控制权限。

工具安全

Interpreter 默认不能直接访问宿主文件系统、网络或 Shell，但通过 PTC 开放的工具可能具备这些能力。

例如，订单分析 Agent 只需要开放查询工具：

CodeInterpreterMiddleware( ptc=["search_orders", "get_order_detail"])

没有必要同时开放删除订单、修改价格等敏感操作。

还需要注意，PTC 内部工具调用不会逐次经过普通 Tool Calling 的interrupt_on审批流程。

因此，涉及业务写入时，必须在工具内部实现权限校验、参数验证和审计，必要时通过独立的审批入口执行。

对于重要任务，还应该记录eval执行耗时、PTC 调用次数、失败原因以及数据处理数量，以便追踪和排查问题。

什么时候使用 Interpreter

不是所有 Agent 都应该启用 Interpreter。

如果订单分析逻辑完全固定，直接编写一个 Pythonanalyze_orders()工具，通常更简单，也更容易测试。

Interpreter 更适合执行流程由模型动态决定的任务。

例如，Research Agent 根据用户问题动态选择关键词，批量检索、过滤重复资料，再交给模型分析，就比较适合使用 Interpreter。

模型负责选择检索方向，Interpreter 负责批量执行和整理数据。

对于更复杂的场景，Interpreter 还可以通过task()调度 Subagent，相关机制将在下一篇介绍。

总结

Interpreter 为 Deep Agents 增加了一层程序化执行能力。

在 Python SDK 中，开发者使用 Python 定义 Agent 和业务工具，Interpreter 则通过 QuickJS 执行模型生成的 JavaScript，并通过 PTC 调用授权的 Python Tools。

它的主要价值是减少模型对重复执行步骤的参与，降低上下文消耗与执行延迟。

但对于固定业务逻辑，普通 Python 工具往往更加合适。只有当执行流程需要动态编排，并涉及大量循环、分支和批量处理时，Interpreter 的优势才会更加明显。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】