# 工具动态发现与运行时Schema合成：2026年Agent能力边界的真正战场 过去三年，"工具调用"被讨论得最多的维度是可靠性、成本、延迟、并行与安全。这些维度默认了一个前提：**工具的Schema是工程师提前手写好的、静态的、封闭集合里的**。但2026年真正改变生产形态的不是模型调得更准，而是这个前提本身正在崩塌——工具不再被"预先定义"，而是被Agent在运行时**发现**、**合成**、**热加载**。本文围绕"动态工具发现 + 运行时Schema合成"这条主线，拆解MCP动态发现协议、OpenAPI/函数/自然语言三种Schema合成路径、Description Engineering对准确率的杠杆、跨厂商Schema可移植性陷阱，以及用τ-bench验证合成Schema的实战账本。 ## 一、为什么"静态手写Schema"在2026年成了负债 传统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再也不必为"新增一个连接器就要重新打包上线"而头疼，工具能力变成了一个可以热插拔的能力层。 ## 二、动态发现协议层：MCP如何让工具"自描述" 动态发现的前提是协议层支持自描述。Model Context Protocol（MCP）的核心设计之一就是把工具元数据（名称、描述、输入Schema）从"调用方配置"迁移到"提供方暴露"，客户端通过`tools/list`原语在运行时拉取当前可用工具集合，而不是在启动时读死配置。 ```python # 伪代码：运行时发现 + 按需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合成三栈：从异构源头生成可调用定义 动态发现解决了"工具从哪来"，但暴露出来的元数据质量参差不齐。现实中的工具来源主要有三类，对应三条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： ```python 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：被严重低估的准确率杠杆 业界把"Description Engineering"（描述工程）定义为：通过改写工具的`name`和`description`字段来系统性提升调用准确率的工程实践。appscale.blog在2026年的生产模式总结里把它列为"单个ROI最高的改动"——理由是模型选不选一个工具、参数填得对不对，70%以上的信息量来自description文本，而不是参数的JSON Schema结构。 一个反直觉的结论是：**很多团队的准确率瓶颈不在模型，而在description写得像给人看的说明书，而不是给模型看的决策契约**。给模型看的description应该包含三类信息：(1) 触发条件——什么情况下用、什么情况下**不要**用；(2) 副作用与成本——这个工具会不会改数据、贵不贵；(3) 参数语义——尤其要写清楚"传原始用户输入还是改写后的"。 ```text # 差的description（像给人看） "搜索知识库" # 好的description（像给模型看的决策契约） "在企业知识库中检索内部文档。当用户询问公司政策、产品规格、历史决策等 事实性问题时使用。不要用于实时数据（库存/价格）。优先于网络搜索使用， 因为内部数据更权威。query字段传入用户原始问题，不要改写或翻译。" ``` 后者在τ-bench这类工具-用户交互基准上的提升是结构性的。Description Engineering之所以在2026年成为一个独立工种，是因为它与"动态发现"形成对偶：当工具是运行时合成的、description是LLM生成的时候，**谁来保证description质量**就成了核心问题。前沿做法是引入一个"描述优化器"——用一个评估模型对合成出的description做红队测试（生成对抗性query，看模型会不会误调），再迭代改写。 ## 五、跨厂商Schema可移植性：JSON Schema / Pydantic / zod的三角债 工具定义一旦要跨模型、跨框架复用，就会撞上可移植性的三套方言：OpenAI/Anthropic/Google的Function Calling接口底层都用JSON Schema，但各自支持的子集不同；Python生态用Pydantic，TypeScript生态用zod；MCP用的是自己的Schema格式。 三者的转换看似机械，实则有三类隐蔽陷阱： 1. **类型表达力不对等**。Pydantic能表达`constrained int`（`ge=1, le=20`），但转成JSON Schema后，部分厂商的API会忽略`minimum/maximum`约束，导致模型生成超界值而不被服务端拒绝。 2. **必填语义不一致**。JSON Schema的`required`是数组语义，Pydantic的Optional是字段语义，跨转换时容易出现"本来可选变成必填"，模型被迫硬编一个默认值。 3. **description丢失**。Pydantic的`Field(description=...)`在序列化路径上如果走错了（比如用了`.dict()`而非`.model_dump()`），description会无声丢失，模型失去决策依据。 这背后是一个产业级趋势：**Schema正在变成可移植制品**。一个工具的权威定义应该存在一个与模型无关的地方（OpenAPI或MCP元数据），再由适配层编译成各厂商的方言。这就是为什么LiteLLM、Portkey、OpenRouter这类**多模型路由器**在2026年成为Function Calling的默认中间层——它们在路由的同时承担了Schema方言的编译职责。 ## 六、τ-bench：用canonical基准给合成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当作**带版本的数据制品**而非代码： ```mermaid 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） | 低 | 半 | ✅（注解式） | 中 | 中 | | 自然语言合成 + 校验回环 | 高 | ✅ | ✅（生成式） | 取决于校验强度 | 极高（蓝海） | **针对不同场景的推荐：** - **企业内部Agent（工具<50，团队稳定）**：用函数反射栈（Pydantic/zod）就够了，description写好，先别上动态发现，维护成本最低。 - **SaaS集成Agent（工具50–500，跨厂商模型）**：MCP动态发现 + OpenAPI规则转换 + 多模型路由器（LiteLLM/Portkey）。这是2026年的主流生产形态，微软365 Copilot已经验证。 - **开放生态Agent（工具>500，来源不可控）**：必须上动态发现 + 检索路由 + 自然语言合成，并强制CI跑τ-bench回归 + 运行时错误率回滚。没有这套治理闭环，规模一大必崩。 - **训练营/产品包装**：Description Engineering是最佳切入点——它门槛低、效果立竿见影、可量化（用τ-bench前后对比），适合做成"工具调用准确率提升"的实战课，比泛泛讲Function Calling有抓手得多。 ## 核心结论 2026年工具调用的战场已经从"调得更准"转移到"工具从哪来、怎么合成、怎么治理"。**动态发现让工具成为运行时变量，Schema合成让定义可以自动化生产，Description Engineering成为新的高杠杆工程，τ-bench成为不可绕过的验收标尺**。能在这四点上建立工程化能力的团队，才是真正解决"千工具时代"的工具调用问题；停留在"手写JSON Schema塞进上下文"的团队，会被运行时能力层的崛起悄悄绕过。 ## 参考来源 1. [Introducing dynamic tool discovery for MCP-based agents and connectors in Microsoft 365 Copilot — M365 Admin](https://m365admin.handsontek.net/introducing-dynamic-tool-discovery-mcp-based-agents-connectors-microsoft-365-copilot/) — 微软365 Copilot动态工具发现机制，运行时不重发布即可更新工具，2026年7月完成推送 2. [Tool-Calling Schema Design for LLM Agents (2026 Production Pattern) — AppScale Blog](https://appscale.blog/zh/blog/ai-service-pattern-tool-calling-schema-design-llm-agents-2026) — 生产级Schema设计模式，含Description Engineering、JSON Schema/Pydantic/zod对比、并行调用安全契约 3. [τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains — Sierra/arXiv](https://arxiv.org/abs/2406.12045) — 工具-Agent-用户三方多轮协作的事实标准基准，retail/airline双域 4. [τ-Bench, methodology, history, and how to verify a published score — Benchlist](https://benchlist.ai/articles/tau-bench) — τ-bench评分方法学、历史与分数核验指南 5. [Function calling and tool orchestration in 2026: Smart routing across providers — CallSphere](https://callsphere.ai/blog/llm-comparison-function-calling-tool-orchestration-hybrid-router-may-2026) — 多模型路由器（LiteLLM/Portkey/OpenRouter）在Function Calling中的方言编译与编排角色 --- *作者：爱卫生（微信：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 等场景全覆盖。