过去三年，"工具调用"被讨论得最多的维度是可靠性、成本、延迟、并行与安全。这些维度默认了一个前提：工具的Schema是工程师提前手写好的、静态的、封闭集合里的。但2026年真正改变生产形态的不是模型调得更准，而是这个前提本身正在崩塌——工具不再被"预先定义"，而是被Agent在运行时发现、合成、热加载。本文围绕"动态工具发现 + 运行时Schema合成"这条主线，拆解MCP动态发现协议、OpenAPI/函数/自然语言三种Schema合成路径、Description Engineering对准确率的杠杆、跨厂商Schema可移植性陷阱，以及用τ-bench验证合成Schema的实战账本。
传统Function Calling的工作流是：工程师为每个API写一份JSON Schema（参数名、类型、描述、是否必填、枚举），硬编码进Agent配置。当工具只有十几个时这没问题；但当一家企业内部有数百个微服务、上千个MCP服务器、再加上外部SaaS的开放API时，手写Schema的维护成本会以平方级增长——每一次API版本升级、每一次字段重命名，都需要人工同步Schema，否则Agent要么调不通，要么传错参数。
更深层的问题是认知负载。研究表明，工具数量超过50个后，模型在选择阶段就开始出现明显衰减；超过500个时，单靠"全量塞进上下文"已经不可行，必须靠检索路由（这一块此前已覆盖）。但检索路由解决的是"从已有的静态池里选"，它没有解决"工具池本身从哪里来"。2026年的答案是：工具池由Agent自己在运行时构建。这就是动态发现的本质——把工具从"编译期常量"变成"运行时变量"。
这条路上最具标志性的事件是2026年6月2日微软对Microsoft 365 Copilot的更新：为基于MCP的声明式Agent和联合连接器引入动态工具发现，允许工具在不重新发布Agent的前提下于运行时更新，预计7月完成全球推送。这意味着企业IT再也不必为"新增一个连接器就要重新打包上线"而头疼，工具能力变成了一个可以热插拔的能力层。
动态发现的前提是协议层支持自描述。Model Context Protocol（MCP）的核心设计之一就是把工具元数据（名称、描述、输入Schema）从"调用方配置"迁移到"提供方暴露"，客户端通过tools/list原语在运行时拉取当前可用工具集合，而不是在启动时读死配置。
# 伪代码：运行时发现 + 按需Schema加载
async def discover_and_call(mcp_client, user_intent):
# 第一步：只拉取工具的轻量元数据（名称+一句话描述）
catalog = await mcp_client.list_tools() # 返回 {name, summary}
# 第二步：用意图做检索路由，只对候选工具拉取完整Schema
candidates = await embed_router.select(catalog, user_intent, top_k=8)
full_schemas = await mcp_client.describe_tools([c.id for c in candidates])
# 第三步：把完整Schema注入上下文，交给模型决策
tool_call = await model.decide(user_intent, tools=full_schemas)
return await mcp_client.invoke(tool_call)
这套两段式（先目录、后详情）设计的动机是上下文经济性：把上千工具的完整Schema一次性塞进窗口会吃掉数万token，而模型在每一步实际只会用到个位数工具。微软365 Copilot的动态发现实现的就是这个模式——目录常驻、详情按需，且目录可以在运行时变更（增删连接器），客户端下次tools/list自动感知。
这套机制的真正价值在多租户/多团队场景。一个企业的财务团队和法务团队共享同一个Agent壳，但暴露完全不同的工具集；IT管理员可以在后台审计每个连接器的可见范围。工具的"权限边界"从代码里挪到了治理平面，这是2026年企业级Agent落地的关键变化。
动态发现解决了"工具从哪来"，但暴露出来的元数据质量参差不齐。现实中的工具来源主要有三类，对应三条Schema合成路径：
| 合成路径 | 源头 | 合成方式 | 主要风险 |
|---|---|---|---|
| OpenAPI转换栈 | Swagger/OpenAPI YAML | 规则解析 + 字段裁剪 | 过度暴露（把上百endpoint全转成工具） |
| 函数反射栈 | Python函数/Pydantic模型 | 类型注解反射 | 描述缺失（函数没docstring） |
| 自然语言合成栈 | 一段API文档/README | LLM生成JSON Schema | 幻觉（捏造不存在的参数） |
第一栈最成熟。Gorilla LLM项目最早证明了可以从OpenAPI规约微调出会调API的模型；今天LangChain的create_schema_from_function、AutoGen和Semantic Kernel都内置了OpenAPI→工具的转换器。但生产中最常见的坑是爆炸式暴露：一个REST API有200个endpoint，直接全转换就会得到200个工具，远超模型可处理上限。正确做法是先做能力聚合（capability grouping），把CRUD合并成"管理X资源"这一类语义工具，再做路由。
第二栈是Python生态的主流。LangChain的做法是用Pydantic的validate_arguments先生成一个中间模型，再转成JSON Schema：
from langchain_core.tools import StructuredTool
from pydantic import BaseModel, Field
class SearchInput(BaseModel):
query: str = Field(description="用户原始查询，不要改写")
top_k: int = Field(default=5, ge=1, le=20)
# 函数注解 + Pydantic模型 = 自动合成Schema
search_tool = StructuredTool.from_function(
func=my_search,
name="knowledge_search",
description="在企业知识库检索，当且仅当需要事实性证据时使用",
args_schema=SearchInput,
)
这里的关键不是API，而是Field里的description——这直接决定模型会不会调、怎么调（见下一节）。
第三栈最危险也最前沿。给它一段API文档，让LLM直接产出JSON Schema，省去了人工写OpenAPI的成本。问题是模型会幻觉出不存在的参数，或把可选参数标成必填。任何走这条路的生产系统都必须在合成后跑一次Schema校验 + 干跑（dry-run）回归，最好对照真实接口的样例请求做结构匹配。
业界把"Description Engineering"（描述工程）定义为：通过改写工具的name和description字段来系统性提升调用准确率的工程实践。appscale.blog在2026年的生产模式总结里把它列为"单个ROI最高的改动"——理由是模型选不选一个工具、参数填得对不对，70%以上的信息量来自description文本，而不是参数的JSON Schema结构。
一个反直觉的结论是：很多团队的准确率瓶颈不在模型，而在description写得像给人看的说明书，而不是给模型看的决策契约。给模型看的description应该包含三类信息：(1) 触发条件——什么情况下用、什么情况下不要用；(2) 副作用与成本——这个工具会不会改数据、贵不贵；(3) 参数语义——尤其要写清楚"传原始用户输入还是改写后的"。
# 差的description（像给人看）
"搜索知识库"
# 好的description（像给模型看的决策契约）
"在企业知识库中检索内部文档。当用户询问公司政策、产品规格、历史决策等
事实性问题时使用。不要用于实时数据（库存/价格）。优先于网络搜索使用，
因为内部数据更权威。query字段传入用户原始问题，不要改写或翻译。"
后者在τ-bench这类工具-用户交互基准上的提升是结构性的。Description Engineering之所以在2026年成为一个独立工种，是因为它与"动态发现"形成对偶：当工具是运行时合成的、description是LLM生成的时候，谁来保证description质量就成了核心问题。前沿做法是引入一个"描述优化器"——用一个评估模型对合成出的description做红队测试（生成对抗性query，看模型会不会误调），再迭代改写。
工具定义一旦要跨模型、跨框架复用，就会撞上可移植性的三套方言：OpenAI/Anthropic/Google的Function Calling接口底层都用JSON Schema，但各自支持的子集不同；Python生态用Pydantic，TypeScript生态用zod；MCP用的是自己的Schema格式。
三者的转换看似机械，实则有三类隐蔽陷阱：
constrained int（ge=1, le=20），但转成JSON Schema后，部分厂商的API会忽略minimum/maximum约束，导致模型生成超界值而不被服务端拒绝。required是数组语义，Pydantic的Optional是字段语义，跨转换时容易出现"本来可选变成必填"，模型被迫硬编一个默认值。Field(description=...)在序列化路径上如果走错了（比如用了.dict()而非.model_dump()），description会无声丢失，模型失去决策依据。这背后是一个产业级趋势：Schema正在变成可移植制品。一个工具的权威定义应该存在一个与模型无关的地方（OpenAPI或MCP元数据），再由适配层编译成各厂商的方言。这就是为什么LiteLLM、Portkey、OpenRouter这类多模型路由器在2026年成为Function Calling的默认中间层——它们在路由的同时承担了Schema方言的编译职责。
工具能力合不合用，不能靠手感，得靠基准。Sierra在2024年发布的τ-bench（tau-bench）到2026年已经成为工具型Agent的事实标准评测，多个实验室在模型卡里把它和SWE-Bench并列报告。
τ-bench的精髓在于它不是测"单步工具调用对不对"，而是测工具-Agent-用户三方在带状态环境里的多轮协作：模型要和一个被另一个LLM模拟的用户对话，调用一组带数据库后端的API工具（零售域、航空域），完成需要多步骤、可能需要回溯的任务。这恰好是动态发现 + 合成Schema最难的地方——工具集是动态的、状态会变、用户会改主意。
τ-bench给合成Schema的启示有三点：(1) 单步Schema质量高不等于任务级成功率高，必须测端到端；(2) 它的评分是按任务最终状态判定的（数据库是否变成正确状态），这逼着工具定义把"副作用语义"写进description；(3) 它揭示了模型间的工具能力鸿沟是真实存在的——不同模型在同样的工具集上通过率差异巨大，这意味着"换模型不改工具"这个口号在实践中需要严格的回归测试。
任何宣称自己Schema合成方案可靠的产品，都应该公开在τ-bench上的retail/airline分数；只报自建内部基准的，可信度要打折扣。
动态发现带来的最后一个工程问题是版本治理。当工具Schema可以运行时变更，就必然要回答：变更如何灰度？出问题如何回滚？谁有权限改？
生产级做法是把工具Schema当作带版本的数据制品而非代码：
flowchart LR
A[作者提交Schema v1.3] --> B[CI: 合成校验+τ-bench回归]
B -->|通过| C[注册中心: 灰度10%]
C --> D{运行时发现拉取}
D --> E[Agent调用新版]
E --> F[可观测: 错误率监控]
F -->|超阈值| G[自动回滚至v1.2]
F -->|稳定| H[全量发布v1.3]
G --> C
这张图里最关键的两个环节是τ-bench回归（在CI里用基准保证Schema改动不退化）和自动回滚（基于运行时错误率熔断）。没有这两环，动态发现就只是"更快地引入bug"。
微软365 Copilot的设计也体现了这点——动态发现虽然让工具能在运行时更新，但管理员侧保留了审计和可见范围控制，本质上是把"代码发布"的严谨性搬到了"工具发布"。
| 方案 | 上手难度 | 动态发现 | Schema合成 | τ-bench友好度 | 变现潜力 |
|---|---|---|---|---|---|
| 纯静态手写Schema | 低 | ❌ | ❌ | 中 | 低（已被淘汰） |
| MCP动态发现 + 手写Schema | 中 | ✅ | ❌ | 中高 | 中高 |
| OpenAPI自动转换 + 路由 | 中高 | ✅ | ✅（规则式） | 高 | 高 |
| 函数反射（Pydantic/zod） | 低 | 半 | ✅（注解式） | 中 | 中 |
| 自然语言合成 + 校验回环 | 高 | ✅ | ✅（生成式） | 取决于校验强度 | 极高（蓝海） |
针对不同场景的推荐：
2026年工具调用的战场已经从"调得更准"转移到"工具从哪来、怎么合成、怎么治理"。动态发现让工具成为运行时变量，Schema合成让定义可以自动化生产，Description Engineering成为新的高杠杆工程，τ-bench成为不可绕过的验收标尺。能在这四点上建立工程化能力的团队，才是真正解决"千工具时代"的工具调用问题；停留在"手写JSON Schema塞进上下文"的团队，会被运行时能力层的崛起悄悄绕过。
作者：爱卫生（微信：gprshome201101）｜公众号：51学通信
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。