本文导读
本文提出了一种面向 Oxygen 智能体的大规模工具编排框架------NaviAgent。该方法采用"LLM规划+图导航"的双层Agent架构，通过动态图建模工具之间的依赖关系，将工具调用从逐步决策转化为图搜索过程，从而在数千API环境下实现稳定、高效的工具编排。
Oxygen 是京东零售产研对外发布的电商创新AI架构体系：以Joy AI大模型为底座，构建系统能力与多元智能体，赋能购物、供应链等电商场景，呈现AI技术在京东零售业务中的整体应用布局。
基于本工作的论文已被 ICML 2026 接收，欢迎阅读交流。 · 链接：arxiv.org/abs/2506.19... 论文：NaviAgent: Graph-Driven Bilevel Planning for Scalable Tool Orchestration
01
摘要
大型语言模型（LLM）越来越多地作为函数调用代理，调用外部工具来处理超出其静态知识范围的任务。然而，它们通常一次只调用一个工具，缺乏对任务结构的全局视图。由于工具之间往往相互依赖，这会导致错误累积和可扩展性差，尤其是在扩展到数百或数千个工具时。为了解决这些局限性，我们提出了NaviAgent，一种显式的双层架构，它通过基于图的工具关系建模将任务规划与工具执行解耦。在规划层，基于 LLM 的代理决定是直接响应、澄清意图，还是检索并执行一个独立于工具间复杂性的工具链。在执行层，工具世界导航模型（TWNM）编码了工具之间的结构和行为关系，引导代理构建可扩展且稳健的调用序列。通过整合来自真实工具交互的反馈，NaviAgent 实现了规划和执行之间的闭环协调，从而能够在大规模工具生态系统中实现自适应导航。在 API-Bank 和 ToolBench 上的评估表明，任务成功率 (TSR) 持续提升，其中TWNM在复杂任务上的平均提升幅度为13.1。对涵盖7个领域的50个真实API进行的进一步测试表明，TSR 持续提升4.3至12.0分，同时减少了步骤数和延迟，展现了其在真实世界动态环境下的稳健泛化能力。
02
动机
从单工具调用走向多工具协作
早期的工具增强语言模型主要关注单个工具的使用，即模型根据用户需求选择一个合适的工具，并生成对应参数完成调用。这类任务通常只涉及一步工具调用，因此核心问题是工具选择和参数生成。
然而，当Agent开始处理更加复杂的真实任务，越来越多的问题需要多个工具协同完成。例如，查询某个用户最近的订单状态，可能需要先查询用户信息，再获取订单编号，最后调用订单状态接口。前一个工具的输出会作为后一个工具的输入，因此多个工具之间形成了明确的数据依赖关系。
随着工具数量进一步增加，同一种能力可能对应多个功能相似但参数定义不同的API。模型不仅需要找到功能正确的API，还需要判断其输入是否已经满足、输出能否被后续工具使用，以及整条调用链是否能够顺利执行。
因此，工具调用问题已经从"选择一个工具"逐渐演变为"规划一条可执行的工具链"，Agent需要具备全局规划能力，而不仅仅是局部决策能力。
传统逐步调用缺乏全局视角
目前主流的工具调用框架大多采用ReAct模式，即模型在"推理---调用工具---观察结果"之间不断循环，每一步根据当前状态决定下一步操作。这种方式具有较好的灵活性，但每一步决策都建立在当前局部信息之上，缺乏对整个工具链的全局规划。
例如，模型当前选择了一个能够查询订单的API，但该接口输出的是order_code，而后续订单状态接口要求输入order_id。由于模型没有提前检查整条调用链的参数依赖，通常只有真正执行到下一步时才会发现两者无法衔接，不得不重新规划后续步骤。
此外，工具选择错误、参数解析错误或中间结果缺失都会沿调用链不断累积。调用链越长，错误传播带来的影响越明显，最终导致整个任务执行失败。
这类问题的根本原因在于，ReAct更擅长完成一步一步的局部决策，却难以从全局角度规划整条工具链。
现有方法的局限性
现有方法虽然已经取得一定进展，但其局限性大致可以概括为"结构化但静态"和"自适应但缺少结构"两类。
一类方法将工具知识写入模型参数中。这种方式可以减少推理时需要输入的工具文档，但当API发生新增、修改或失效时，通常需要重新训练模型，维护成本较高。
另一类方法基于历史调用轨迹建立工具图。图结构能够显式表示工具之间的依赖关系，但如果历史多跳调用数据较少，就难以覆盖完整的工具调用路径。单纯依赖历史共现关系，也难以准确描述参数在不同API之间的传递过程。即使部分方法能够根据执行反馈动态调整调用策略，由于缺少统一的全局工具结构，模型仍然主要依赖局部试错完成规划。
基于上述分析，本文的目标并不是简单引入一个工具检索模块，而是构建一个同时具备以下能力的工具调用系统：
• 显式建模API及参数之间的结构关系；
• 利用历史执行数据学习真实调用规律；
• 在API新增、失效或恢复时动态更新工具关系；
• 将高层决策与复杂工具链搜索分离。
03
方法
NaviAgent采用双层规划架构，由LLM负责交互决策，由工具图负责工具链搜索与执行。与传统Planner-Executor不同，Planner不会提前生成完整工具链，而是在每一步决定当前应采取的交互策略。真正的工具规划则交由工具图动态完成。这种设计将任务规划与工具搜索解耦，使LLM无需直接面对数千API的搜索问题。
交互动作决策
在规划层，LLM并不会直接选择具体API，而是首先判断当前应采取哪一种交互动作。
整个决策空间划分为四类动作：
• Direct Response：模型认为已有信息足够，直接生成回答；
• Intent Clarification：用户需求仍存在歧义，需要进一步澄清；
• ToolChain Retrieval：需要检索工具图，规划后续工具链；
• Tool Execution：执行已经确定的工具调用。
整个决策过程可以表示为：
其中，
表示历史交互信息，
表示当前观察，
表示结合上一轮执行反馈更新后的工具图状态，最终输出当前应该执行的动作。
图驱动工具导航
具体工具规划由 Tool World Navigation Model（TWNM）完成。整个过程包括图构建、图表示学习、图搜索和图进化四个部分。
图构建：TWNM首先将整个工具生态建模为异构图G=(V,E,W)，其中包含API节点和参数节点两类节点。API节点表示具体接口，参数节点表示API的输入输出参数，不同API通过参数依赖建立连接。相比仅根据工具名称或调用共现关系建图，这种方式能够显式表示工具之间的数据流，使一条多步工具链可以自然地表示为图中的一条路径。除了API文档中定义的静态依赖关系，TWNM还利用历史调用记录建立行为边，并根据实际调用结果初始化边权：
其中，
表示工具
成功调用工具
的次数，
表示工具
被调用的总次数。该比值反映了从
到
的历史调用成功率，使工具图不仅包含静态结构信息，也能够编码真实执行经验。
图表示学习 ： 采用 Heterogeneous Graph Transformer（HGT）学习不同类型节点及关系的表示。训练阶段以链接预测为目标，使模型判断哪些节点之间应当建立连接，并学习不同工具依赖关系的可靠程度。经过图表示学习后，TWNM能够补充静态规则中未显式描述的潜在连接，为后续工具链搜索提供更完整的图结构。
图搜索 ： 根据当前任务，在工具图中搜索满足输入输出约束的工具链。这里设计了两种搜索方式：Alpha-Beta Pruning通过剪枝快速排除大量低价值路径，具有较高的搜索效率；Hybrid Heuristic Pruning则综合考虑边权、路径长度、参数覆盖率等因素，对候选路径进行迭代优化。后者搜索过程更复杂，但通常能够找到质量更高的工具链。两种搜索策略分别侧重效率和规划质量，可根据不同任务需求进行选择。
图进化 ： 真实API环境会持续变化，新工具可能接入，已有工具也可能失效，因此TWNM并不是一张离线构建后固定不变的图。系统会根据执行反馈持续更新图结构，包括接入新增API、剪枝长期不可用的API，以及动态调整工具之间的边权。
如图所示，在T-1时刻，多条工具路径具有相近的权重；随着执行反馈不断积累，到T时刻，表现更优的路径被逐渐强化，并成为优先选择。当T+1时刻部分API失效后，TWNM能够重新调整边权并切换到新的可用路径，从而适应运行环境的变化。具体而言，通过指数滑动平均持续更新统计边权，并将其作为监督信号定期训练图模型，使模型学习到的边表示和路径偏好随执行环境动态更新。统计边权的计算公式如下：
其中，第一项表示历史边权，用于保留长期积累的工具依赖关系；第二项表示最近
天内工具之间的调用成功率，用于反映当前API的实际可用性。通过融合长期经验和近期反馈，工具图能够在稳定性与适应性之间取得平衡。
动态执行与路径恢复
为提升真实环境中的执行鲁棒性，NaviAgent提出Path Recombination机制（见方法图右下部分），用于处理API失效、参数缺失和工具返回异常等运行时问题。当工具调用失败时，系统利用工具图中的依赖关系对当前路径进行局部修复，而非重新规划完整工具链。
该机制包含三种恢复策略：首先，寻找具有相同输入输出的等价API进行替换；若无法直接替换，则回退至上游节点，重新规划后续路径；若当前工具子图整体不可用，则重新检索新的工具子图以完成剩余任务。
这种局部恢复方式能够减少重复搜索和规划带来的计算开销，使系统更快地从执行失败中恢复，从而提升复杂工具调用场景下的执行效率与稳定性。
04
实验结果
主实验
表1比较了NaviAgent与ReAct、ToolLLM、ToolPlanner等方法在ToolBench上的表现。从整体结果来看，NaviAgent在Qwen2.5-14B、Qwen2.5-32B和DeepSeek-V3三种基础模型上均取得最高的TSR，说明该框架具有较好的模型泛化能力。随着任务难度提升，其优势更加明显，例如在DeepSeek-V3的Hard任务上，TSR达到44.9%，相比ToolNet提升18.2个百分点。此外，NaviAgent在取得更高成功率的同时，平均执行步数仍保持较低，说明性能提升主要来自更准确的规划，而不是更多的试错。
小结： NaviAgent真正解决的是复杂多工具任务中的路径规划问题，因此任务越复杂，图驱动规划带来的收益越明显。
消融实验
表3验证了各个核心模块的贡献。相比ReAct，仅加入工具图便将TSR从34.5%提升到45.7%，说明显式建模工具之间的依赖关系能够有效减少错误调用；仅采用双层规划也带来了明显提升。当双层规划、工具图和搜索策略全部结合后，TSR进一步提升至55.2%，取得最佳结果，说明各模块具有互补作用。
表4进一步分析了不同工具图设计的影响。相比静态工具图（Static+A），引入历史调用信息构建动态图（Dynamic+A）后，多数模型在Hard任务上的表现进一步提升，例如Qwen2.5-32B的Hard任务TSR由26.3%提升至31.4%。最终采用动态图结合启发式搜索（Dynamic+H）后，整体性能达到最佳，说明动态图能够根据历史调用持续优化工具之间的连接关系，而启发式搜索则进一步提高了复杂工具链的规划质量。
小结： 双层规划降低了LLM的决策难度，工具图提供了全局依赖关系，而动态图进一步利用历史执行反馈优化工具链选择，三者共同构成了NaviAgent性能提升的关键来源。
行为分析
图6统计了不同方法在成功任务中的决策行为。相比基线方法，NaviAgent不仅正常执行比例更高，还更频繁地进行Intent Clarification和Re-retrieval。随着任务难度增加，这两类行为占比进一步提高，说明复杂任务往往无法依靠一次规划完成，而需要根据执行结果不断调整工具链。
小结： NaviAgent的优势不仅在于找到正确工具，更在于能够主动澄清需求、重新检索并动态调整规划，从而减少错误路径带来的级联失败。
05
总结
NaviAgent针对大规模工具调用中缺乏全局规划、工具扩展困难等问题，提出了一种"LLM规划+图导航"的双层Agent架构。通过将交互决策与工具搜索解耦，并利用动态图持续建模工具之间的依赖关系，实现了更加稳定、高效的工具编排。
实验结果表明，无论是在公开基准还是真实API环境中，NaviAgent都取得了更高的任务成功率，并减少了执行步骤和推理延迟。随着工具规模和任务复杂度不断增加，图驱动规划带来的优势更加明显，也说明显式建模工具之间的结构关系能够有效提升复杂多工具任务的执行能力。