一句话答案：多工具编排不是把几十个 API 一次性塞给模型，而是让应用先根据用户身份、任务阶段和风险范围筛出小而相关的候选工具，再由模型或确定性路由器选择，运行时负责依赖、并发、超时、审批、幂等、补偿和审计。工具越多，名称相似、参数混淆、权限扩大和上下文膨胀的问题越明显；真正的生产能力来自受控工具目录与可恢复执行，而不是“模型可以调用一切”。
本文讨论的是“一个任务需要多个工具时，系统怎样组织它们”，不是渠道销售中的代理，也不是单次函数调用语法。内容依据 Model Context Protocol、OpenAI Agents SDK、Google Agent Development Kit、LangGraph、OWASP 与 NIST 的公开资料整理，资料复核日期为 2026 年 7 月 18 日。框架接口会变化，实施时仍应核对对应版本文档。
多工具编排和 Function Calling、工作流、Multi-Agent 有什么区别？
| 概念 | 主要解决什么 | 不自动解决什么 |
|---|---|---|
| Function Calling / Tool Use | 描述一次工具选择、参数生成与结果回传 | 跨步骤依赖、恢复、全局权限和长期状态 |
| 多工具编排 | 管理工具发现、筛选、路由、顺序、并发、状态与失败 | 业务授权、数据正确性和责任归属 |
| 确定性工作流 | 用固定节点和条件表达可预期流程 | 开放问题中的动态规划与工具选择 |
| Multi-Agent | 让不同角色分工、移交或由管理者调用专家 | 天然更准确、更便宜或更安全 |
如果只需要解释工具 schema、权限、幂等与一次调用闭环，先看站内的Tool Use 与 Function Calling 指南；需要理解智能体整体循环，可看AI Agent 定义与上线治理。涉及知识检索时，站内的RAG 检索增强生成指南可帮助区分“检索资料”与“执行动作”。本页关注这些能力之上的运行时编排层。
生产系统需要哪六层？
- 工具注册表：保存稳定 ID、版本、用途、输入输出契约、所有者、风险级别、费用、超时、数据域和退役状态。
- 候选集筛选：按用户身份、租户、任务意图、当前步骤、地域与数据敏感度，动态生成本轮可见工具。
- 路由与规划：用规则、语义检索、分类器或模型选择工具；复杂任务再形成带依赖关系的步骤图。
- 受控执行器：完成 schema 校验、授权、审批、幂等、并发上限、超时、重试与结果净化。
- 状态与恢复：记录每一步输入摘要、状态、结果引用和副作用；失败后从检查点恢复或执行补偿。
- 观测与评测：追踪候选工具、选择理由、调用参数、延迟、费用、错误、人工介入与最终任务结果。
MCP 架构文档区分 host、client、server、tools 与 resources；协议让能力发现和调用更一致，但不会替应用判断服务器是否可信。OpenAI Agents SDK 工具文档也区分托管工具、本地运行工具、函数工具和 agents-as-tools。无论接入方式如何，目录元数据和业务授权都应由应用掌握。
工具注册表至少要记录哪些字段？
| 字段 | 作用 | 缺失后的风险 |
|---|---|---|
| 稳定 ID、版本、所有者 | 定位契约、变更和责任人 | 同名工具混淆，升级不可追踪 |
| 用途与负面条件 | 说明何时用、何时不能用 | 描述重叠导致误路由 |
| 输入输出 schema | 约束结构、枚举、范围和错误 | 参数猜测、结果无法组合 |
| 风险与副作用 | 区分只读、预览、可逆写入和高影响动作 | 模型把查询和付款视为同级动作 |
| 身份、租户、数据域 | 决定谁可见、可操作哪些对象 | 工具面过宽与跨租户访问 |
| 超时、费用、配额 | 支持预算、限流和降级 | 长尾延迟、费用失控 |
| 幂等与补偿策略 | 安全重试并处理部分成功 | 重复写入或半成品状态 |
工具描述应写“可验证的能力边界”，不要写“万能搜索”“智能处理一切”。读与写、预览与提交应拆成不同工具。用户 ID、租户 ID、角色和授权范围应由服务端会话注入，不应让模型自由填写。工具返回只包含下一步所需字段，避免把令牌、内部提示、堆栈或整份业务对象送回模型上下文。
工具很多时，怎样减少选错？
| 策略 | 适合 | 优点 | 主要限制 |
|---|---|---|---|
| 规则路由 | 意图少、边界明确、高风险动作 | 可解释、稳定、易审计 | 规则增长后维护成本高 |
| 语义检索工具 | 目录大、描述差异明显 | 先取 Top-K，减少上下文 | 相似描述可能召回错误 |
| 模型直接选择 | 候选集小、低风险、语言表达开放 | 灵活，能利用上下文 | 非确定性，需离线评测 |
| 确定性工作流 | 审批、财务、发布、合规流程 | 依赖和恢复路径清楚 | 不适合完全开放目标 |
| 混合路由 | 多数生产系统 | 规则先裁剪，检索/模型再选择 | 需要统一观测与回放 |
可执行做法是“两阶段路由”：第一阶段由确定性代码根据身份、租户、风险和任务阶段过滤；第二阶段才在小候选集中做语义检索或模型选择。对于相似工具，用对照样例测试边界，例如“查订单”不能选“修改订单”，“生成退款预览”不能直接选“提交退款”。若目录超过模型可稳定区分的规模，应使用工具搜索或分域注册表，而不是持续加长提示词。
步骤依赖、并发与状态怎样组织？
先把任务表示成有向依赖图：节点是工具调用或人工确认，边表示前置结果。只有彼此独立、只读或已证明可并行安全的节点才并发；修改同一对象、依赖前一步输出或存在额度竞争的动作应串行。OpenAI Agents SDK 的运行配置文档明确区分“模型能否发出并行调用”和“运行时实际并发上限”；这两个控制不能混为一谈。
| 场景 | 编排选择 | 保护措施 |
|---|---|---|
| 并行查多个只读来源 | 并行 + 汇总 | 总超时、来源标识、部分结果策略 |
| 先查库存再下单 | 串行依赖 | 执行时重新校验库存和价格 |
| 同时改同一客户记录 | 串行或乐观锁 | 版本号、条件更新、冲突返回 |
| 跨系统创建资源 | Saga / 补偿流程 | 逐步记账、幂等键、人工接管 |
| 长时间人工审批 | 持久化检查点 | 暂停、恢复、审批过期与重授权 |
LangGraph 官方概览把持久化执行、流式处理和 human-in-the-loop 作为编排运行时能力。无论采用哪个框架，都不要只把状态留在模型上下文：应将任务 ID、步骤状态、工具调用 ID、输入摘要、结果引用、审批人和副作用写入持久化存储。
失败恢复：重试、降级、补偿和人工接管
| 失败 | 是否重试 | 处理 |
|---|---|---|
| 参数或业务规则错误 | 不盲目重试 | 返回字段错误，澄清或终止 |
| 限流或短暂网络故障 | 有界重试 | 指数退避、抖动、总时限和并发限制 |
| 写入结果不确定 | 先查询状态 | 使用同一幂等键确认原请求 |
| 部分步骤成功 | 按步骤判断 | 补偿、保留检查点或转人工 |
| 权限、审批或预算不足 | 不自动绕过 | 暂停，重新授权或终止 |
| 工具退役或契约变化 | 切换需验证 | 版本固定、兼容测试、显式降级 |
“换另一个相似工具试试”不是通用恢复策略，因为它可能改变数据来源、费用、权限或副作用。每个工具都应声明可重试错误、幂等范围与补偿动作。工作流要设置总步数、总时长、总费用和同一工具连续失败上限，防止代理循环。涉及发布、付款、删除、改权限或外发数据时，失败后默认暂停比自主探索更安全。
工具生命周期：新增、升级和退役不能直接改描述
工具目录本质上是生产依赖清单。名称、参数、默认值、返回字段、权限范围或错误语义发生变化，都可能让历史提示、路由规则和恢复逻辑失效。不要在原工具 ID 下静默替换不兼容契约；应发布新版本，让旧版和新版短期并存，在影子流量或小比例会话中比较选择准确率、参数通过率、延迟、费用与任务结果，再逐步迁移。
| 生命周期阶段 | 必须动作 | 验收证据 |
|---|---|---|
| 准入 | 确认所有者、数据流、权限、风险、费用、超时和支持渠道 | 安全审查、契约测试、最小权限清单 |
| 发布新版本 | 固定 schema 与错误语义；保留变更说明和回滚版本 | 兼容测试、影子调用、回归样本 |
| 扩大流量 | 按风险等级逐步放量，监控误选与副作用 | 分层评测、告警阈值、人工接管记录 |
| 降级 | 明确只读替代、缓存结果、转人工或停止服务 | 故障演练、用户提示和数据一致性检查 |
| 退役 | 先从候选集隐藏，再停止新调用，最后移除连接 | 零新增调用、依赖清单归零、审计归档 |
工具描述也是路由数据，修改后应重新运行候选召回和近义工具对照测试。远程 MCP 服务器或第三方 API 的行为可能在客户端不变更代码时发生变化，因此还要监控能力列表、schema 指纹、证书、域名和返回数据形态。发现未授权的新工具、权限扩大或契约漂移时，默认隔离该服务，而不是让模型自行适应。
依赖外部供应商时，应准备明确的降级路径：信息查询可以返回“当前来源不可用”并转向已批准的备用来源；写入动作不能因为主工具故障就自动切到权限和幂等规则不同的替代工具。备用工具必须单独完成准入、评测与授权，且在追踪中标记实际执行版本，保证事故后能还原当时的选择。
提示注入与工具污染怎样控制？
网页、邮件、文档、MCP 服务器描述与工具结果都属于不可信输入。外部内容不能扩大当前工具集合，不能修改系统授权，也不能证明用户已经同意。OWASP GenAI 风险清单持续关注提示注入、敏感信息泄露与过度代理问题；多工具系统因为连接面更大，更要执行最小权限、数据隔离和结果净化。
- 工具服务器加入目录前进行来源、所有者、权限、数据流和更新机制审查。
- 工具描述和 schema 变更需要代码审查、版本号和回归测试。
- 高风险动作展示目标、关键参数与影响范围，要求逐次确认。
- 工具结果回传模型前过滤令牌、个人信息、内部提示和无关字段。
- 审批在执行瞬间重新校验身份、会话和资源状态，不复用过期同意。
上线前如何评测，而不是只看演示成功？
| 层级 | 关键指标 | 必须包含的反例 |
|---|---|---|
| 候选召回 | 正确工具是否进入 Top-K；无权工具是否被排除 | 跨租户、相似名称、已退役工具 |
| 工具选择 | 选择准确率、拒绝调用率、澄清率 | 缺参数、无工具可用、多个近义工具 |
| 参数契约 | schema 通过率、业务校验通过率 | 越界值、错误 ID、时区和单位歧义 |
| 运行与恢复 | 成功率、P95 延迟、费用、重复副作用 | 超时、限流、部分成功、恢复后重放 |
| 最终任务 | 用户目标达成、事实正确、人工接管质量 | 提示注入、越权请求、不可逆动作 |
OpenAI Agents SDK tracing 文档列出模型生成、工具调用、handoff 与 guardrail 等追踪事件。生产日志还应避免默认记录敏感输入输出，并建立脱敏、保留期与访问控制。风险治理可结合NIST 生成式 AI 风险管理资料，以及站内的AI 安全治理指南和AI 可用性与失败恢复测试指南。
一套可执行的上线顺序
- 先选一个低风险任务，建立 10～30 个边界清晰的工具目录。
- 默认只读；写入先做预览和人工确认，再逐级开放可逆动作。
- 使用两阶段路由，把每轮候选工具压缩到小集合。
- 为每个工具补齐版本、所有者、风险、超时、幂等、费用与退役策略。
- 建立持久化检查点、总预算、循环上限、补偿和人工接管。
- 用真实任务、相似工具、故障注入、越权和提示注入样本做离线评测。
- 先影子运行，再只读小流量，最后按风险等级分批开放写入。
常见问题
接入 MCP 就等于完成多工具编排吗？
不等于。MCP 可以标准化能力发现与调用，但候选筛选、服务器信任、业务授权、审批、幂等、失败恢复、费用和审计仍由宿主应用负责。
工具越多，Agent 能力一定越强吗？
不一定。工具面扩大可能降低选择准确率并增加上下文、延迟和攻击面。更可靠的做法是按任务动态加载小候选集，并用评测数据决定是否增加工具。
什么时候需要 Multi-Agent？
当角色具有不同指令、工具、数据权限或责任边界时，分工可能有价值。若只是固定步骤调用多个 API，一个状态机或工作流通常更简单、更可测。Google ADK 的多智能体系统文档把层级、顺序、并行与循环等组织模式分开描述，也说明 Multi-Agent 是一种编排选择，而不是质量保证。
怎样判断可以开放自动写入？
至少要证明身份与租户隔离、参数和业务校验、幂等与回滚、故障恢复、提示注入测试、审计和人工接管均有效；高影响动作仍应保留强确认或人工审批。
编辑复核与纠错记录：本文由兰塞 AI 编辑流程于 2026 年 7 月 18 日复核。旧稿与 93257 近乎逐字重复，且把多工具系统泛化成“自动选择并串联工具”的宣传描述；本次重写明确了与 Function Calling、工作流和 Multi-Agent 的边界，新增工具注册表、两阶段路由、依赖并发、失败恢复、安全控制、生命周期与分层评测。93257 仅在本页完成远端 A 级验收后才合并。本站的来源、更新与纠错原则见关于本站与编辑规范。
