引言
过去两年，企业对 AI 的关注已经明显从“能不能聊”转向“能不能干活”。
MCP 推出之后，模型第一次可以在统一协议下调用各种工具，接数据库、连业务系统、改文件、跑任务，这一步已经把 AI 从“纯对话”推向“可执行”。
但很多团队很快发现，“能调工具”并不等于“能成为可靠的执行层”。
工具一多，错误率上来；工作流一复杂，成本和不确定性就失控；一旦想规模化接入几十上百个系统，原有的工具调用方式很快遇到天花板。
Anthropic 最新发布的 Tool Search、Programmatic Tool Calling 和 Tool Use Examples，其实是在承认并正面回应这个现实：
现在的问题不再是“AI 会不会调工具”，而是如何把这套能力升级成一个可运营、可治理、可规模化的智能执行基础设施。
从智能系统供应商的视角，这是一条必须看懂的技术路线。这篇文章尝试站在 AGISurge 的位置，拆解这三项能力背后的逻辑，并讨论它们对未来智能系统架构的启发。
一、从“能调用工具”到“可运营的执行层”
MCP 出现时，行业已经完成了第一轮跨越：模型不再只是回答问题，而是可以通过标准化的工具接口做查询、修改、创建和触发业务操作。这让很多“智能助手”从 Demo 走进了轻量级生产场景。
但当场景稍微真实一点，问题就浮现出来：一个典型的企业环境中，工具和系统的数量往往不是十几个，而是数十到上百个；单条流程也不是两三步，而是多系统、多角色、多环节协同。
在这样的环境里，传统的“自然语言逐步调用工具”模式会遇到几类共性难题：
- 工具定义和工具数量急剧膨胀，挤占上下文空间，推高成本；
- 工具名相似、参数复杂，模型选错工具、填错参数的概率持续上升；
- 中间结果全部回流到模型上下文，让推理变慢、变贵，也变得难以控制；
- 工作流一旦跨越多个系统，整个过程缺乏可审计、可复用的执行逻辑。
换句话说，MCP 已经回答了“能不能调”的问题，但企业真正需要的是“能不能长期、稳定、可控地调”，并把这套能力沉淀成基础设施，而不是一次性的项目工程。
这正是 Anthropic 此次高级工具使用三项新能力试图补齐的那一块：把“模型调用工具”升级为“模型驱动的执行层”。
二、Tool Search：让工具库从负担变成资产
在传统模式下，只要你接了 MCP 服务器，对应的工具定义就会源源不断塞进上下文。对于一个连接 GitHub、Slack、监控系统、日志平台、Jira 等多个服务器的企业环境，这是典型的“工具越多，系统越难用”的悖论：工具定义本身成为系统的负担。
Tool Search 改变了这件事的结构：工具定义仍然完整存在，但默认是“延迟加载”的。模型真正看见的，只有一个“搜索工具”本身；当它需要执行某类能力时，先发起一次工具搜索，再按需加载极少量真正相关的工具定义。
从工程的角度来看，这等于把原本“硬塞进上下文的配置”，变成了一层“可查询的工具索引”。
对企业方而言，有几个直接的含义：
- 工具库的规模不再与上下文直接绑定，工具数量可以随着业务扩展持续增长；
- 引入新工具、新系统，不再意味着重新推导整套提示词和上下文结构；
- 工具的命名、描述、标签设计，本身会变成一项需要治理的“资产”。
这意味着：我们在设计智能化解决方案时，不再需要为“工具会不会太多”而刻意做减法，反而要思考如何让工具库的组织方式更适合被搜索、被编排和被演化。
三、Programmatic Tool Calling：把执行逻辑从话术变成代码
传统的工具调用路径是：“模型推理 → 调一个工具 → 拿到结果 → 把结果放回上下文 → 再推理下一步”。
只要流程超过三四步，中间数据就开始堆积在上下文里：日志、明细、行级记录、字段列表……结果是两个字：失控——成本失控、延迟失控、行为也随之失控。
Programmatic Tool Calling 选择了另一条路：模型不再逐条“说”出下一步要调什么，而是一次性写出一段程序，让这段代码去负责循环、分支、并行调用、错误处理和汇总。所有中间结果都在代码执行环境中流转，模型最终只看到少量、必需的结果。
从系统视角看，这带来了几件非常现实的改变：
- 执行逻辑具象化了。之前藏在自然语言推理中的“隐形流程”，现在变成清晰的 Python 代码，可以审查、可以复用、可以监控。
- 中间数据不再反复进出模型。日志、表格、明细记录可以在代码里处理掉，只把统计结果、异常项、关键结论送回模型，大幅降低 token 消耗与隐私暴露风险。
- 复杂流程变得可“产品化”。同一段 orchestrator 代码可以多次复跑、比对结果、接入监控，真正具备了“生产系统”的特征。
对于需要处理大量文档、日志、记录的制药、金融、制造等行业，这意味着：智能体不再是一个“看一眼所有数据再给你一个主观结论”的助手，而是变成可以承载严肃任务的执行节点，可以在质量体系、合规流程中真正站得住脚。
四、Tool Use Examples：用示例把“业务习惯”也编码进去
JSON Schema 可以把结构说清楚，却很难把“如何正确使用”说清楚。
很多企业内部 API 都带有强烈的业务习惯：字段填写的优先顺序、哪些组合意味着某种状态、某些枚举值在什么场景下才会出现、ID 长什么样、日期用哪种格式。Schema 全写得出来，但写完之后，对模型来说仍然是“合法但不一定正确”。
Tool Use Examples 通过在工具定义中直接附带少量真实的调用示例，让模型不仅知道“什么是合法的 JSON”，还知道“在这个组织里，人是怎么用这个工具的”。
从智能系统供应商的角度，这件事带来的变化非常微妙但重要：我们给客户设计工具时，不再只是交付一套“接口定义”，而是在交付一套可学习的“业务风格”。示例本身会成为智能系统的长期资产，随着场景扩展不断丰富与迭代。
在 AGISurge 面向医药、生产型企业的项目里，这个思路非常契合：无论是偏差管理、SOP 执行、文件归档还是审批流，一开始就把“正确的用法”内嵌到工具示例中，将显著降低智能体的冷启动成本，也让后续扩展更可控。
五、竞争正在从模型转向架构
把这三项能力放在一起，其实是在给行业释放一个清晰的信号：
智能系统的下一阶段竞争，不再是“谁接入了哪个模型”，而是谁能把模型能力沉淀成一层真正可运营的智能执行中间层。
这意味着几件需要长期投入的事情：
第一，工具中台的价值会持续上升。 我们需要把工具视作一套可治理、可搜索、可演进的资产，而不是零散的接口集合。围绕工具的标签、分组、命名、示例和权限，本身就是一整块产品与工程工作。
第二，程序化执行会成为复杂场景的默认模式。 单纯“逐步自然语言推理 + 工具调用”很难长期支撑。我们需要从平台层天然支持代码化编排、安全沙盒执行和统一监控。
第三，业务示例将成为“新型文档”。 未来，当我们为某个行业打造智能系统，不仅要交付接口与模型接入，还需要交付一套系统化的 Tool Use Examples，让智能体真正“理解这个行业是怎么做事的”。
站在更长的时间维度看，这些能力其实都在指向同一件事：智能，正在从一个“模型”变成一个“系统能力”。
而能不能提供这层能力，将决定一个智能系统供应商在未来几年里的天花板。
结语
高级工具使用并不是一组“酷炫功能”，而是一次实打实的架构升级信号：从 MCP 时代的“能调用工具”，到今天“可以大规模、可治理地调用工具”，中间隔着一整套关于工具发现、程序化执行和示例驱动的系统设计。
对企业来说，这意味着智能体第一次有机会真正进入关键流程，而不仅仅停留在边缘辅助。 对 解决方案供应商来说，这意味着产品形态必须从“模型包装层”升级为“智能执行基础设施”。这也印证了我们一直坚持的一条路线：用工程化的方法，把先进的模型能力变成可持续运营的系统能力。
未来几年，谁能把这层智能执行中间层搭起来，谁就有机会成为下一代企业基础设施的一部分。
这场竞争，已经不再是“谁的模型更聪明”，而是谁真正懂系统。