🛠️ Tool Calling：模型「动手」的完整链路
模型只会「说」，动手靠这条链路：注册→筛选→决策→校验→执行→处理→回传，环环都能优化。
一句话看懂：模型的嘴 + 系统的手
🗣️ 模型只会「说」
大模型住在厂商的推理服务里，摸不到你的数据库、文件、API。它只能输出一句话：「我想调 get_weather("北京")」。
谁真去跑？你的代码 / 框架 / 平台沙箱。
🛠️ 链路 = 一套结构化协议
Tool Calling 把「模型的嘴」和「系统的手」用一套七步链路串起来，每一跳都有得优化。
七步：注册 → 筛选 → 决策 → 校验 → 执行 → 处理 → 回传。
核心思想：让模型知道有什么工具 → 选对的 → 填对参数 → 安全执行 → 结果喂回去继续想。
七步链路逐环拆解
📝 ① 工具注册 Tool Registry
模型一开始不知道有啥工具，得先注册进上下文。
每个工具用 JSON Schema 描述（name + description + parameters），参数要标类型、是否必填、enum、description。
一般挂在 tools 字段随请求发，少数塞进 system prompt。
⚠️ 命门：description
写太抽象（「获取信息」）→ 模型乱调；写太窄（「查北京天气」）→ 泛化差。
这是第一层优化的关键，也决定后面的召回率。
写使用场景，别复制函数名
🔍 ② 候选筛选 Candidate Filtering
工具 >50 个时全量塞进 tools 会吃爆上下文 + 模型挑花眼。
工程上加一层检索：按意图粗筛——用户问「查订单」就只把 order 相关工具放进 tools。
实现：工具 description 做 embedding，用用户 query 召回 top-K（K=5~15）。
🎯 ③ 模型决策 Model Decision
模型看 messages + tools 后决定：调哪个工具 + 参数填什么 + 还是不调。
输出结构化 tool_calls 数组（不是自由文本）。
注意：模型按 description 做语义匹配，不是按 name 精确匹配 → description 质量直接决定召回。
✅ ④ 参数校验 Parameter Validation
模型输出的 arguments 是 JSON 字符串，不能迷信它合法。
三级校验：JSON 语法（缺引号/换行劈裂）→ Schema（类型/required/enum）→ 语义（订单号格式、用户 ID）。
失败：轻度自动修复或让模型重答；重度把报错塞回 tool role 让模型补。
🛡️ ⑤ 执行隔离 Execution Isolation
真正调工具这里是安全边界：
• 超时：单工具设 timeout（HTTP 5s）
• 权限隔离：执行账号 ≠ 模型账号
• 幂等：外部 API 尽量幂等（模型会重试）
• 熔断：连续失败的工具移出候选
📦 ⑥ 结果处理 Result Handling
工具返回不能直接塞回模型，要加工：
• 截断：5000 行 → 摘要
• 结构化：JSON 转模型好懂的格式
• 错误处理：HTTP 500/超时 → 包装成 error 字段，让模型知道「这次没成」
🔁 ⑦ 结果回传 & 循环 Context Injection
把 tool 消息挂回 messages，再把完整对话发回模型——这轮不是结束，是下轮的起点。
结果够了 → 自然语言回复；不够 → 再调别的工具；有错 → 修正参数重调。
这就是 ReAct 循环。
五层优化怎么叠：72% → 96%+
| 优化层 | 做法 | 准确率提升 |
|---|---|---|
| ① 优化 description | 写清楚使用场景，别复制函数名 | 72% → 84% |
| ② 候选工具筛选 | 按意图 embedding 召回 top-K，减噪 | 84% → 90% |
| ③ 参数校验 | JSON + Schema + 语义三层检查 | 90% → 93% |
| ④ 重试 + 降级 | 轻度修复/重答，重度报错回传 | 93% → 96% |
| ⑤ 设计模式管理 | 路由器 + 子 agent + 工具分组 | 可维护性提升 |
前四层是准确率维度：从「喂给模型的信号质量」（description）做起，再到检索减噪、校验拦错、重试兜底。
第 5 层换成了可维护性维度：工具从 10 个涨到 200 个时，靠 pattern（路由器 + 子 agent + 工具分组）不让链路崩。
这就是从 70 分提到 95+ 分的典型路径。
工程上最容易踩的坑
工具太多不筛选
>30 个时误召率明显爬升。不是模型菜，是 signal-to-noise 塌了。
description 复制函数名
get_data → 「获取数据」模型完全不会调，必须写使用场景。
省略参数校验
生产环境 JSON 解析失败率约 3-8%，深层嵌套参数尤其高。
context 泄露
tool 原始返回可能含内部字段（db 主键、内部状态码），塞回模型前要么脱敏要么摘要。
无限循环
模型调 A→不够→调 B→还不够→再调 A… 要设 max_tool_rounds（一般 5-10）。
Tool Calling 完整链路 = 注册 → 候选筛选 → 模型决策 → 参数校验 → 执行隔离 → 结果处理 → 结果回传，最后连回形成 ReAct 循环。模型永远只出「想调哪个工具 + 参数长啥样」的意图，真正执行的是你的代码；每一跳都能用 description 优化、检索减噪、校验拦错、重试兜底来提升。
我会按七步来说：先是工具注册，把每个工具用 JSON Schema 描述清楚挂到 tools 字段；然后候选筛选，工具多了就按用户意图做 embedding 召回 top-K，避免上下文爆炸和模型挑花眼；接着模型决策，输出结构化的 tool_call；然后是参数校验，模型输出的 JSON 不能迷信，要做语法、Schema、语义三层检查；再是执行隔离，设超时、权限隔离、幂等和熔断；结果要处理一下，截断、结构化、脱敏；最后把 tool 消息回传挂回上下文，形成 ReAct 循环，直到模型输出最终答复。
我从数据上说，五层优化：先优化 description，这是最关键的，写使用场景而不是复制函数名，能让准确率从 72 提到 84；然后做候选工具筛选，按意图 embedding 召回，减噪提到 90；再加参数校验，JSON 语法加 Schema 加语义三层，到 93；然后重试加降级，轻度就修复重答、重度把报错回传让模型补，到 96；最后是设计模式管理，工具多了用路由器、子 agent、工具分组来控复杂度。
不会。模型永远只输出一个结构化意图，就是「我想调 get_weather，参数是北京」，它住在厂商那边物理隔离的推理服务里，摸不到我们的系统。真正执行的是我们的代码、框架，或者平台沙箱。这中间有个安全契约，叫 tool-use contract：模型只负责出意图，我们在执行前要校验 call_id、参数、权限，甚至用户是不是同意，然后再决定执不执行。