Rewrite: improve translation quality, add English terms, add 核心/评价 sections for 7 Anthropic articles

- 信达雅翻译：长句拆短、被动改主动、从句重组为中文节奏
- 英文原词标注：晦涩术语首次出现附英文，如 transcript classifier、reasoning-blind
- 末尾结构：核心思想 → 核心 + 评价两节，用 --- 分隔；评价节做批判性分析

Co-Authored-By: Claude <noreply@anthropic.com>

Author: puppylpg

_ai/2026-06-05-advanced-tool-use.md

@@ -9,90 +9,130 @@ description: "Anthropic 发布三项工具使用增强特性，通过动态工
 1. Table of Contents, ordered
 {:toc}
 
-> 原文：[Advanced Tool Use on the Claude Developer Platform](https://www.anthropic.com/engineering/advanced-tool-use)
+> 原文：[Advanced Tool Use on Claude Developer Platform](https://www.anthropic.com/engineering/advanced-tool-use)
 
-# 问题与动机
+# 问题背景
 
-在构建大规模 AI 代理系统时，工具定义会消耗大量 token。传统的「一次性加载所有工具」模式下，工具定义可能在代理读取实际请求之前就已吃掉 50,000+ token，导致：
+构建规模化 AI（AI）代理系统时，工具定义的 token 消耗是个显著瓶颈。传统「全量加载所有工具」模式下，工具定义可能在代理处理实际请求前就消耗 50,000+ token，导致三个问题：
 
-- 上下文窗口被浪费
-- 推理成本和延迟增加
-- 模型在复杂工具协调任务中表现下降
+- 上下文窗口被浪费，留给响应的空间缩小
+- 推理成本和延迟上升，每轮对话都要费力读取大量工具定义
+- 模型在复杂任务中的表现下降，噪声干扰决策
 
-Anthropic 针对这些瓶颈发布了三项测试版特性。
+Anthropic 发布三项测试版特性，针对性解决这些瓶颈。
 
 # 特性一：工具搜索（Tool Search）
 
-允许 Claude 动态发现工具，而非一次加载全部定义。
+传统模式要在请求中塞入所有工具定义，工具数量增加会线性放大 token 消耗。工具搜索允许 Claude 按需发现工具，定义页面和调用面分离开来。
 
-**工作机制：**
+## 工作机制
 
-在工具定义中标记 `defer_loading: true`，该工具在代理真正需要时才被加载。Claude 可以通过搜索接口查询和发现可用工具。
+在工具定义中标记 `defer_loading: true`，该工具只在代理真正需要时才被加载。Claude 通过搜索接口查询可用工具池，而不是一次性遍历所有定义。
 
-**性能收益：**
+本质是「惰性加载（lazy loading）」模式：定义层只保留索引，具体定义延迟到调用点才展开。
 
-- **Token 消耗减少 ~85%**：在测试场景中从约 77K token 下降到 8.7K token
-- **准确率显著提升**：Opus 4.5 在知识检索任务中从 79.5% 提升到 88.1%
-- **与缓存兼容**：可与提示缓存（prompt caching）配合使用，进一步提升成本效率
+## 性能收益
+
+- **Token 消耗减少 85%**：测试场景从约 77K token 降到 8.7K token
+- **准确率提升**：Claude Opus 4.5 在知识检索任务中从 79.5% 提升到 88.1%
+- **与缓存兼容**：可与提示缓存（prompt caching）叠加使用，成本效率再增一层
+
+关键收益在于「上下文噪声减少」——工具定义不再挤占模型推理空间，更干净的上下文窗口让模型专注于决策本身。
 
 # 特性二：编程工具调用（Programmatic Tool Calling）
 
-传统工具使用需要多轮 API 调用；此特性让 Claude 通过代码执行来编排工具，中间结果不进入 Claude 的上下文窗口。
+传统工具使用是多轮对话模式：模型返回工具调用，服务端执行，结果再塞回模型，如此反复。编程调用让 Claude 通过代码执行编排工具，中间结果留在执行环境，不进入上下文窗口。
+
+## 工作机制
 
-**工作机制：**
+代理在执行环境中直接编排多个工具调用，控制流程和条件分支，类似编写脚本。模型只输出「调用哪个工具、怎么传参」，执行逻辑在代码层完成。
 
-代理在执行环境中直接编排多个工具调用，控制流程和条件分支，类似于编写脚本。
+这把「控制流」从模型推理剥离出去，模型退化成执行器的指挥官，而非行军层面的审批官。
 
-**性能收益：**
+## 性能收益
 
-- **Token 消耗减少 37%**：在复杂研究任务中
-- **消除多轮推理**：对于多步骤工作流至关重要
+- **Token 消耗减少 37%**：复杂研究任务中的实测数据
+- **消除多轮推理**：多步骤工作流变成单次规划+批量执行
 - **准确率改进**：知识检索准确率从 25.6% 提升到 28.5%
-- **支持并行执行**：多个工具可并行调用，而非顺序执行
+- **支持并行执行**：多个工具可并行调用，而不是串行等待
 
-**典型场景：**
+## 典型场景
 
-预算合规性检查需要处理数千条支出行项，传统方法会将所有行项塞入上下文，导致推理变差；编程调用则将逻辑留在执行环境中，模型只关注决策和控制。
+预算合规性检查要处理数千条支出项。传统方法将所有行项塞入上下文，噪声导致推理质量下滑。编程调用把循环逻辑留在执行环境，模型只关注「读哪些字段、按什么规则判断」，执行环境负责批量处理数千条记录。
+
+本质是「能力下沉」——把代码擅长的事（批量循环、条件分支）执行掉，模型只做价值最高的决策和规划。
 
 # 特性三：工具使用示例（Tool Use Examples）
 
-超越 JSON Schema 定义，提供具体的使用样板，帮助模型理解：
+JSON Schema 只能定义数据结构，但无法描述「实际调用模式」。工具使用示例提供具体样板，让模型理解真实世界中的调用方式。
+
+## 解决的问题
 
-- 格式约定
-- 参数关联关系
-- 可选字段的包含方式
-- 实际调用模式
+JSON Schema 在以下场景会引发歧义：
 
-**性能收益：**
+- 格式约定：字段是蛇形命名还是驼峰命名
+- 参数关联：某个字段出现时，另一个字段怎么取值
+- 可选字段包含：在什么场景下包含可选字段
+- 边界情况：参数为空数组、特殊字符时怎么处理
 
-- **准确率从 72% 提升到 90%**：在复杂参数处理的内部测试中
+仅靠 Schema 无法回答这些问题，模型只能「猜测」，猜测成本折算成准确率损失。
 
-这看似简单，但能显著减少模型的「猜测成本」，特别是在字段组合和边界情况处理上。
+## 性能收益
 
-# 分层策略与实施
+- **准确率从 72% 提升到 90%**：复杂参数处理任务的内部测试
 
-三项特性的最佳使用方式是**分层应用**：
+看似简单的示例子，实际能显著减少模型在「字段组合」和「边情况处理」上的猜测成本。对复杂工具尤其重要——字段越多、约束越多，抽象定义和真实使用的差距越大。
 
-1. 先诊断性能瓶颈（是 token 消耗、推理轮数还是格式理解？）
-2. 针对最严重的瓶颈优先应用特性（例如工具众多则先用工具搜索）
-3. 根据需要补充其他特性
+# 使用策略
 
-避免盲目全量启用，应结合具体场景灵活组合。
+三项特性的最佳实践是**分层应用**，而非全量启用：
 
-# 可用性与接入
+1. 诊断性能瓶颈：是 token 消耗、推理轮数，还是格式理解问题？
+2. 针对最严重的瓶颈优先应用：工具众多则用工具搜索，任务复杂则用编程调用，格式复杂则补充使用示例
+3. 按实际效果补充其他特性
+
+避免一刀切组合。不同代理的瓶颈不同，盲目优化错误的维度比不优化还糟。
+
+# 接入方式
 
 - **发布状态**：测试版（Beta）
-- **接入方式**：通过 Claude Developer Platform API，添加请求头 `betas=["advanced-tool-use-2025-11-20"]`
-- **文档**：Developer Platform 官方文档和 GitHub cookbook 提供代码示例
+- **接入接口**：在 Claude Developer Platform API 请求中添加请求头 `betas=["advanced-tool-use-2025-11-20"]`
+- **文档资源**：Developer Platform 官方文档和 GitHub cookbook 提供代码示例
+
+---
 
-# 核心思想
+# 核心
 
-Anthropic 这三项特性的本质是**突破 agent 工具使用的根本瓶颈**：
+三个特性的本质是突破「agent 工具使用的根本瓶颈」：
 
 - **工具搜索**解决「定义爆炸」——用惰性加载替代全量加载，削弱工具数量的诅咒
-- **编程调用**解决「推理碎片化」——把复杂协调从模型推理转移到确定性执行环境，节省推理成本
-- **使用示例**解决「理解歧义」——通过具体样板而非抽象定义消除格式猜测
+- **编程调用**解决「推理碎片化」——把复杂协调从模型推理迁移到确定性执行环境
+- **工具使用示例**解决「理解歧义」——用具体样板替代抽象定义，消除格式猜测
+
+关键洞察是三个瓶颈**相互独立但都很关键**。不是「选一个」，而是「依症状组合」。真实场景中工具多、任务复杂、格式复杂三者往往同时存在，需要三个特性协同发力。
+
+Anthropic 特意强调「分层策略」，反映对工程现实的务实态度：不同 agent 的主要瓶颈不同，诊断优先于优化。这套思路对设计复杂系统有普适价值——先找最痛点，再打针对性补丁，而非全盘重构或全量引入。
+
+# 评价
+
+文章结构清晰，按问题→特性→实施→核心洞察展开，逻辑链条完整。性能数据量化具体（如 85%、37% token 减少），可信度高。
+
+**说得好：**
+
+- 准确定位「工具定义」是规模化瓶颈，而非泛泛而谈「性能问题」
+- 每个特性都给出「工作机制」和「性能收益」双重视角，适合工程师按场景选型
+- 强调「分层策略」而非全量启用，避免一刀切误用
+
+**有待补充：**
+
+- 缺少「适用边界」的讨论：工具搜索在多少数量级以上才有明显收益？编程调用的执行环境如何隔离、如何编写？
+- 示例代码过少：虽然文中提到几个典型场景，但没有具体代码片段，开发者难以直观对比传统调用和编程调用的差异
+- 三特性组合的「优先级矩阵」缺失：什么组合序列是推荐的？什么组合会冲突？这是开发者最关心的问题
+
+**隐含假设：**
 
-关键洞察是这三个瓶颈**相互独立且都很关键**。不是"选一个"而是"依症状组合"。对于工具多、任务复杂、格式复杂的真实 agent 场景，往往需要三个特性同时发力。
+- 假设用户已经熟悉 Claude API 的基础工具使用，未解释 minimun viable setup
+- 假设执行环境由开发者提供，未提及平台的「沙箱能力」「安全性保证」——这对企业部署很关键
+- 性能数据基于内部测试，未公开「测试场景」细节（工具数量、任务复杂度），外部难以复现验证
 
-Anthropic 特意强调「分层策略」而非一刀切，反映了对工程现实的理解：不同 agent 的主要瓶颈不同，盲目优化错误的维度比不优化还糟。这套思路对设计任何复杂系统都有参考价值。
+整体是篇清晰的特性推介文章，但距离「实操指南」还有距离——适合了解特性，但要落地还需要去找 cookbook 或实验代码。