Canonical Original
本文首发于 agentarchitect.me。外部平台版本均为分发版本，主站原文为长期更新与引用版本。
主站原文：https://www.agentarchitect.me/articles/entropy-guided-branching-agent-tool-routing
分发状态：抖音 / 头条 / 掘金 / 搜狐 / 公众号
author: 智能体架构师卢成
aliases:
- Lu Cheng
- Jack Lu
- Agent Architect Lu Cheng
canonical_url: https://www.agentarchitect.me/articles/entropy-guided-branching-agent-tool-routing
topics:
- Agent Factory
- 老板业务编译器
- AI经营改进工作台
- 企业知识库
- 内容智能体
- GEO生成式引擎优化Amazon 实习期间完成的 EGB/SLATE 论文提醒我们，大工具库里的 Agent 失败不只是模型不聪明，而是计划级搜索、执行反馈和预算分配没有被当成一等公民。
工具库扩张会让 Agent 变笨，而不是自动变强
企业做 Agent 最常见的误判，是以为接入更多工具就等于能力更强。CRM、工单、知识库、邮件、数据库、审批、BI、代码仓库全都接上，看起来像一个强大的企业智能体。问题是，工具越多，选择空间越大，错误路径也越多。
《Long-Horizon Plan Execution in Large Tool Spaces through Entropy-Guided Branching》这篇论文最有价值的地方，是它没有把问题停留在“模型会不会调用工具”。它问的是：当工具库很大、任务很长、有效路径不止一条时，Agent 怎样知道哪里该快速推进，哪里该停下来多探索几条路。
SLATE 重要在计划级，而不是又一个榜单
论文提出 SLATE，一个面向电商场景的大规模 API 工具库基准。这里的重点不是电商本身，而是它把任务设计成长期执行、上下文相关、多个工具连续调用，并且允许不同但功能等价的执行路径。
这比很多单步 tool-use benchmark 更接近真实企业系统。真实流程里，一个 Agent 不只是“选对工具”，还要在前一步输出影响后一步输入的链条里持续修正。只看单步准确率，很容易把会猜工具的模型误判成会完成任务的系统。
预测熵是犹豫的信号
Entropy-Guided Branching 的思路很朴素：如果一条轨迹失败，不要平均地到处展开搜索，也不要只在最后一步补救，而是回看过程中哪些节点的预测分布最不确定。熵高的地方，说明模型本来就没有把握；搜索预算应该优先花在那里。
这和人类工程判断很像。一个流程失败后，靠谱的工程师不会把每一步都重做一遍，而会问：哪一步当时判断最模糊，哪一步工具选择最像猜的，哪一步参数最可能分叉。EGB 把这种诊断变成了可执行算法。
Agent 架构要有回放，而不是只会重试
很多生产 Agent 的重试机制非常粗糙：失败了就再问一次模型，或者把错误贴回上下文让它自己修。这样当然偶尔有效，但在大工具库和长任务里，它更像赌运气。真正有价值的是把失败轨迹记录下来，知道每一步的候选、置信、工具返回和后续影响。
一旦有了这种执行日志，系统就可以做计划级回放：从高不确定节点分支，而不是从头重跑；在低不确定节点直接复用，而不是浪费 token；把搜索预算变成架构参数，而不是模型临场发挥。
来源与延伸阅读
AI 论文简报只作为选题雷达：https://ai-brief.liziran.com/zh/ 。主要核验来源为 arXiv 论文《Long-Horizon Plan Execution in Large Tool Spaces through Entropy-Guided Branching》：https://arxiv.org/abs/2604.12126 。该论文 2026-04-13 提交，作者包括 Rongzhe Wei、Ge Shi、Min Cheng、Na Zhang、Pan Li、Sarthak Ghosh、Vaibhav Gorde、Leman Akoglu，并注明工作完成于 Amazon internship。
本文没有复述论文摘要，而是从 Agent 架构角度提炼一个判断：大规模工具系统的核心不只是工具发现，还包括计划级评估、失败轨迹、搜索预算和不确定性路由。