Agent 为什么需要 Interpreter：从工具调用到程序化执行

前面几篇文章介绍了 Deep Agents 的 Tools、Filesystem、Backend以及 Shell、Execute 和 Sandbox。通过这些机制Agent 已经能够调用工具、管理文件和执行代码。在实际开发中还会遇到一类问题Agent 需要重复调用多个工具处理返回的数据再根据结果继续操作。例如查询 100 个地区的订单筛选异常记录并统计金额。传统 Tool Calling 可以完成但大量中间结果需要返回模型增加了上下文消耗和执行延迟。Deep Agents 提供的 Interpreter解释器 允许 Agent 将多个操作组织成程序在解释器中完成工具调用、条件判断和数据处理最后只返回必要结果。这就是 Programmatic Tool CallingPTC程序化工具调用的核心思路。一、工具调用的成本传统 Tool Calling 通常由模型决定调用工具等待执行结果再判断下一步操作。模型决定调用工具 ↓执行工具 ↓结果返回模型 ↓模型继续判断 ↓执行下一步模型也可以一次发起多个工具调用但当后续操作依赖前一步的结果时通常仍需要新的模型轮次。对于少量调用这种方式没有问题。但如果查询 100 个地区每个地区返回 200 条订单最终只有几十条异常记录值得关注将全部数据交给模型就没有必要。更合适的方式是让模型生成执行逻辑由程序完成重复操作。模型生成执行代码 ↓Interpreter 执行 ├─ 批量调用工具 ├─ 条件判断与循环 └─ 数据筛选和统计 ↓返回精简结果 ↓模型继续分析PTC 减少的是模型参与中间步骤的次数而不是实际的业务工具调用数量。二、解释器的运行机制由于我们使用 Deep Agents Python SDKAgent 的创建、工具定义和运行流程都基于 Python。需说明的是Deep Agents 的 Interpreter 并不直接执行 Python 代码而是使用 JavaScript 作为内部执行语言。那么为什么基于 Python 的 Agent要使用 JavaScript 来执行程序这是因为两者处于不同的执行层次。Deep Agents 通过CodeInterpreterMiddleware集成 Interpreter底层使用 QuickJS 执行 JavaScript。Deep AgentsPython │ │ 模型调用 eval ▼InterpreterQuickJS │ ├─ 循环、条件判断 ├─ 数据处理 └─ tools.getOrders() │ │ PTC 桥接 ▼ Python 业务工具 │ ▼ 返回执行结果开发者使用 Python 定义业务工具例如get_orders()。模型需要批量处理任务时可以生成 JavaScript通过eval执行。代码中如果需要调用业务工具则通过 PTC 桥接到 Python。因此JavaScript 只是 Interpreter 内部的执行语言Agent 应用仍然由 Python 开发。Interpreter 与 Sandbox上一篇介绍的 Sandbox 同样能够执行代码但两者的职责不同。InterpreterSandbox执行入口evalexecute执行环境QuickJS具体 Backend主要用途工具编排、数据处理脚本、测试、系统命令文件访问默认不可直接访问由 Backend 决定Interpreter 适合在 Agent 内部组织工具调用。如果需要运行 Python 脚本、安装依赖或执行测试仍应使用具备相应能力的 Sandbox Backend。三、解释器的实践下面通过一个订单分析 Agent了解 Interpreter 的具体用法。任务是查询三个地区的订单筛选逾期三天及以上的记录并统计数量和总金额。1. 安装依赖pip install -U deepagents[quickjs] langchain-openai2. 定义业务工具先准备模拟订单数据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_asciiFalse)这里使用 LangChain 的tool定义工具与普通 Deep Agents 开发没有区别。实际项目中可以将模拟数据替换为数据库查询或 HTTP API。3. 配置 Interpreteragent create_deep_agent( modelopenai:gpt-5.5, tools[get_orders], system_prompt( 涉及批量查询与统计时优先使用 eval 执行程序化工具调用并在程序中完成 数据筛选和汇总只返回必要结果。 ), middleware[ CodeInterpreterMiddleware( ptc[get_orders], modeturn, timeout10.0, max_ptc_calls10, max_result_chars2000, ) ],)其中ptc是最关键的参数。tools[get_orders]表示 Agent 可以直接调用这个工具。ptc[get_orders]则允许 Interpreter 内部的 JavaScript 调用它。PTC 默认不开放业务工具需要显式配置白名单。4. 运行 Agentasync def main(): result await agent.ainvoke({ messages: [{ role: user, content: ( 查询 east、west、south 的订单 筛选逾期至少三天的记录 统计数量和总金额。 ), }] }) print(result[messages][-1].content)asyncio.run(main())PTC 使用异步桥接因此这里采用ainvoke()。执行过程中模型可以通过eval运行类似下面的 JavaScriptconst 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控制状态模式状态范围适用场景call单次eval独立计算turn当前 Agent 轮次批量查询、临时分析thread同一会话的多个轮次连续数据分析默认使用thread。例如第一次eval保存的变量可以在相同解释器状态中继续使用不必重新查询数据。thread支持跨轮次状态快照但只适合恢复可序列化的数据。需要跨进程持久化时还应结合 LangGraph Checkpointer。对于普通的单轮分析任务建议优先使用modeturn减少不必要的状态积累。资源限制Interpreter 还提供几个重要参数参数默认值作用timeout5 秒单次执行超时memory_limit64 MB解释器内存限制max_ptc_calls256单次执行的 PTC 调用上限max_result_chars4000返回模型的文本长度上限这些限制可以降低异常代码带来的资源消耗。不过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 更适合执行流程由模型动态决定的任务。任务类型推荐方式单次 API 或数据库查询Tool Calling固定规则的数据处理Python 业务工具动态批量查询与工具编排Interpreter PTC脚本、测试和系统命令Sandbox Execute多个独立复杂任务Subagent例如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%免费】