> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Anthropic工具调用2.0 - URL: https://www.hubwiz.com/blog/anthropic-tool-calling-2-0/ - Published: 2026-03-20T11:43:05.000Z - Updated: 2026-03-20T11:43:05.000Z - Description: 如果你构建处理长时间运行、多步骤工作流的代理，Anthropic刚刚发布了自两年前原始函数调用规范以来最大的工具调用架构飞跃…… - Author: admin - Tags: AGENT, #Import 2026-10-14 14:41 如果你构建处理长时间运行、多步骤工作流的代理，Anthropic刚刚发布了自两年前原始函数调用规范以来最大的工具调用架构飞跃。社区称之为**工具调用2.0**。这些更改解决了当代理需要链接超过少数几个工具时浪费token、破坏确定性并炸开上下文窗口的痛点。 ## **1\. 传统工具调用（1.0）的局限性** 过去两年，工具调用一直是AI代理的基础，允许大语言模型（LLM）输出JSON来触发外部操作。然而，这种"乒乓"交互模型——LLM调用工具，等待响应，然后决定下一步——存在几个系统性低效问题： - **冗余数据处理：** 代理经常需要在多个轮次中重新生成相同的参数（如ID）来完成单个任务。 - **Token膨胀：** 工具响应，特别是来自搜索或邮件API的响应，通常包含大量不相关的元数据，消耗上下文窗口。 - **无效的上下文利用：** 虽然现代模型声称有高达100万token的上下文窗口，但其有效的高精度窗口通常限制在128k到200k token之间。 - **高延迟和成本：** 复杂任务，如抓取多个网页并进行总结，需要在服务器和LLM之间进行大量来回往返，导致高token成本和缓慢执行。 对于简单查询，使用传统函数调用感觉很神奇。对于任何复杂的事情，它就成了噩梦： - **Gmail示例：** search\_emails(query="from:Bob")返回15个带有完整元数据的邮件对象。你只需要ID来调用get\_email(id)。整个重负载保留在上下文中。 - **博客写作示例：** web\_search → 10个URL → 10次web\_fetch（每次返回50KB原始HTML）→ 一个write\_blog工具。模型必须手动重新序列化每个抓取结果。Token浪费巨大。 - 即使1M-token上下文窗口也救不了你——在系统提示和历史记录之后，有效的可用上下文仍然只有约128k-200k。 **根本问题：** 模型被迫充当低效的协调器，在每个往返中通过上下文窗口来回复制数据。 ## **2\. 工具调用2.0的核心支柱** 优化四元组：工具调用2.0 ### **2.1 编程式工具调用** LLM不再充当手动在各个JSON调用之间传递数据的"胶水"，而是被提供一个环境，它可以输出可执行代码（如TypeScript）来同时编排多个工具。 - **逻辑和控制流：** 模型可以使用`for`循环、条件语句和变量来处理复杂序列。例如，它可以检索ID列表，然后在单个执行块中循环调用"read"函数处理每个ID。 - **减少往返：** 通过编写脚本来处理序列，模型最小化了完成任务所需的轮次数。 - **Token效率：** 上下文窗口使用显著减少，因为中间"混乱"数据保留在执行环境中，而不是反映回LLM的对话历史。实验显示**token消耗减少30%到50%**。 - **实现：** 开发者可以通过在LLM响应中包含`code_execution`函数并使用`allowed_callers`参数授权特定工具与代码环境交互来激活此功能。 ### **2.2 Webfetch动态过滤** 编程式调用的一个子功能，动态过滤解决了"混乱"网页数据的具体问题。 - **机制：** 当使用`web_fetch`工具（版本20260209）时，系统添加一个中间层，运行代码在原始HTML进入上下文窗口之前进行过滤。 - **影响：** 此过程仅提取相关内容和键，导致平均**token消耗减少24%**，并通过去除噪音提高模型准确性。 ### **2.3 可扩展工具搜索（动态检索）** 传统的代理配置要求在开始时将所有可用工具定义加载到上下文窗口中。当代理可以访问数百个工具或模型上下文协议（MCP）服务器时，这种方法不可扩展。 - **"工具搜索工具"：** 不是加载每个工具，而是给代理一个单独的"工具搜索工具"（约500 token）。 - **延迟加载：** 工具可以配置`lazy_load`参数。当设置为`true`时，工具在模型的初始视图中保持隐藏。LLM然后使用搜索工具动态检索它需要的特定模式。 - **优化：** 此方法可以实现高达**80%的上下文窗口优化**，使代理能够管理大量工具库而不压倒模型的处理能力。 ### **2.4 工具使用示例（输入示例）** 具有嵌套结构或模糊字段的复杂工具通常导致"幻觉"或格式错误的参数。 - **上下文指导：** 开发者现在可以在工具定义中提供`input_examples`数组。这些示例向模型展示如何正确格式化特定字段（例如，基于优先级的日期格式或SLA级别）。 - **准确性提升：** 在Anthropic的测试中，提供这些示例将生成复杂参数的准确性从**72%提高到90%**。这对于具有许多可选参数的工具特别有用，否则模型可能会遗漏这些参数。 ## 3\. 这对现实世界代理为什么重要 - 在数据密集型循环中，token成本急剧下降。 - 更少的往返 = 更低的延迟。 - 确定性控制流（循环、过滤）代替"希望模型选择正确的下一个工具"。 - 易于增量采用——你不必重写整个代理运行时。 ### **性能指标总结** 下表总结了工具调用2.0框架引入的定量改进： | 指标 | 传统工具调用（1.0） | 工具调用2.0 | 改进 | | --------- | ----------- | -------- | -------- | | Token消耗 | 高（冗余数据处理） | 低（编程式调用） | 减少30-50% | | 网页数据token | 高（完整HTML） | 低（动态过滤） | 减少24% | | 上下文窗口使用 | 高（所有工具定义） | 低（延迟加载） | 优化80% | | 复杂参数准确性 | 72% | 90% | 提升18% | | 往返次数 | 多 | 少（脚本化） | 显著减少 | ## **4\. 结束语** 向工具调用2.0的过渡代表了代理设计的根本演变。通过使模型能够编写代码、动态过滤数据和按需搜索工具，Anthropic解决了延迟、成本和上下文限制的主要瓶颈。这些更新允许创建更复杂、更可靠的代理，能够以前所未有的效率处理高密度数据和长时间任务。 --- 原文链接: [Anthropic Tool Calling 2.0: The Game-Changer That Finally Fixes AI Agent](https://medium.com/@lmpo/anthropic-tool-calling-2-0-the-game-changer-that-finally-fixes-ai-agent-fccd2f034568?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处