Code Mode 和 Programmatic Tool Calling 都涉及让模型使用代码组织工具调用，Tool Search Tool 则侧重按需发现工具。它们针对工具定义过多、调用链过长和中间结果占用上下文等问题，但实现与运行条件不同，不能简单视为同一种协议。
为什么工具接得越多，代理反而越难用？
工具定义需要描述名称、参数和返回结构。当系统连接多个业务服务，模型可能在真正执行任务前就读入大量无关说明。名称相似、参数复杂的工具还会增加误选与漏传字段的机会。
另一方面，传统多轮调用会把每一步结果交给模型，再由模型选择下一步。假设只需要汇总订单金额，几千行完整订单未必都需要进入模型上下文。系统可以先过滤与计算，再把必要结果交给模型解释。
Code Mode 的核心思路是什么？
Cloudflare 在 2025 年 9 月的工程文章中讨论将 MCP 工具呈现为 TypeScript API，再让模型编写调用这些 API 的代码。代码可以表达循环、条件和数据转换，使多个动作能够组成一个执行过程。
这不等于模型获得了无限制执行环境，也不意味着所有 MCP 服务都能直接照搬。实际落地需要定义运行环境、可用接口、返回结构和错误处理方式。工具是否真正执行成功，仍应由系统记录和验证。
Programmatic Tool Calling 与它有什么关系？
Anthropic 在 2025 年 11 月的功能公告中介绍了在代码执行环境中调用工具的方式，目的是让编排与中间数据处理减少对模型上下文的干扰。它与 Code Mode 在思路上相关，但产品接口、支持条件和执行机制需要分别核对。
企业不能只因为两个方案都用了代码，就假设脚本可以直接互换。选择时应确认当前模型和平台支持哪些调用能力、需要怎样的工具声明，以及结果如何回传。本文章解释工程思路，不提供未经当前文档验证的可复制 API 参数。
Tool Search Tool 又解决什么问题？
Tool Search Tool 侧重按任务发现并加载工具，而不是一开始展示所有工具定义。它和程序化调用可以配合：先找到当前任务需要的工具，再决定使用普通调用还是代码编排。
工具少、定义简短且每次都会用到时，额外搜索未必划算。只有工具库已经形成明显负担，或者代理常常选错工具时，按需发现才更值得验证。搜索名称与描述必须具体，否则把工具藏到搜索后面也不会自动变得容易找到。
用一个业务例子理解三者的分工
假设需要汇总多个门店的昨日订单并标出异常退款。工具搜索先定位订单查询与退款查询接口；代码编排负责按门店读取、过滤日期、关联订单并计算金额；模型最后根据汇总结果解释异常与待核对事项。
这时最重要的是统一门店标识、订单状态、币种和时区。若接口按支付时间筛选，用户却要求按下单时间统计，再高效的调用也会得出错误口径。提效之前要先保证业务对象和数据定义一致。
如何处理失败与部分成功？
把每个子任务的状态分别保存：哪些门店已经读取，哪些超时，哪些返回空数据。空数据与读取失败不能都写成零，否则汇总表看起来完整，却隐藏了缺失来源。
涉及写入时还应避免整段程序盲目重跑。假设批量创建记录执行到一半，重试应先确认已有记录，再补剩余项。代码编排让执行更紧凑，也更需要清晰的状态与可重复执行规则，不能把错误处理全部交给最后一次自然语言总结。
怎样判断值得采用哪一种方式？
使用固定业务任务比较总执行时间、输入上下文大小、结果正确率和单次成功成本。少了一轮模型调用不一定更快，因为代码运行、工具搜索和外部请求也可能增加时间。
先改当前最大的瓶颈：定义太多就研究工具搜索，中间结果太大就增加数据过滤，多次独立请求才考虑代码编排。复用现有接口和日志做一个小试验，通常比同时引入多套新机制更容易判断收益，也便于团队维护。
工具目录怎样写才有利于发现与调用？
工具描述应说明它读取或修改什么对象、适用条件、必需参数和返回结果。比如“查询指定门店在日期范围内的已支付订单”比“获取业务数据”更容易区分；遇到状态为空、分页未完成和接口限流，也应有明确返回说明。
使用示例可以围绕易错参数设计，尤其是时区、币种、状态和分页范围。不要把完整工具目录重复塞进每份技能，而应保持一个权威说明入口，并在接口变化后同步检查相关任务。最后比较代理是否真的更容易选对工具、结果是否完整，以及失败能否被定位。目录更短或执行代码更少，都不能代替这些业务层面的验证。
官方资料与核验范围
本文资料核验日期为 2026 年 10 月 17 日。下列日期指对应公告或工程文章的发布日期，不代表概念首次出现；产品可用范围、版本与接入条件请以官方当前说明为准。文中业务案例为帮助理解而设计的假设示例，不是实测成绩或客户交付承诺。