Harness Router：为 AI Agent 打造的工具路由决策层

AI 编程助手和 Agent 系统的能力越来越强，但一个长期存在的痛点始终没有得到很好的解决：当工具（Tools）数量膨胀时，LLM 该如何准确地选择正确的工具？一位开发者在 Reddit 上分享了他的开源项目 Harness Router，试图通过引入一个独立的"决策层"来回答这个问题。

问题：LLM 选工具为什么会出错

在典型的 Agent 架构中，模型会从一大堆可用工具中"自由挑选"。当工具集较小时，这套逻辑运作良好；一旦工具数量增加，尤其是出现命名相似、功能重叠的工具时，模型的选择就开始变得不可靠。

作者特别举了一个很有代表性的例子：get_x、fetch_x、read_x 这类语义高度接近的工具。对人类而言它们的差异可能显而易见，但对 LLM 来说，这种模糊性会直接导致错误调用。除此之外，把所有工具的描述都塞进上下文，还会带来两个隐性成本——Token 消耗上升，以及模型在"显而易见的路由决策"上浪费推理算力。

解决思路：在执行前加一层路由

Harness Router 的核心理念并不复杂：不要让 LLM 盲目地从大量工具里做选择，而是在真正执行之前，插入一个决策层。

这个思路本质上是把"工具选择"从模型的自由发挥中剥离出来，交给一个更可控、更可解释的路由组件。它是 framework-agnostic（框架无关）的设计，意味着不绑定特定的 Agent 框架，理论上可以接入多种 Agent harness。

项目最新版本加入了对 Codex hooks 的支持，整套流程被拆解为几个清晰的阶段：

• SessionStart：在会话开始时一次性发现所有可用工具
• PreToolUse：对每一个即将发生的工具调用进行检查

而 PreToolUse 阶段的判断逻辑很值得关注，它体现了作者对"安全兜底"的考量：

• 相同选择 → 直接放行（allow）
• 存在更优替代 → 触发重新规划（re-plan）
• 路由器自身失败 → 采用 fail-open 策略，即不阻断执行

fail-open 的设计很关键——它保证了即便路由层出问题，也不会让整个 Agent 卡死，而是退回到原有的执行路径。这对生产环境的稳定性是一个务实的取舍。

Codex hooks 是 OpenAI Codex 提供的一种生命周期钩子机制，允许开发者在 Agent 执行流程的特定节点注入自定义逻辑，而无需修改核心 Agent 代码。这与 Web 框架中的中间件（middleware）或事件钩子概念类似——你可以在"请求进来之前"或"工具被调用之前"挂载自己的处理逻辑。

Harness Router 利用这一机制实现了对工具调用的透明拦截：开发者不需要改变 Agent 的主体逻辑，路由层以"旁路检查"的方式静默介入。SessionStart 钩子负责在会话初始化时完成工具注册与发现，相当于预热阶段；PreToolUse 钩子则在每次工具调用触发前执行路由判断，决定是放行、替换为更优工具，还是触发更深层的 MCTS 搜索。这种钩子式设计使路由层可以做到对上层 Agent 逻辑几乎透明，降低了接入成本。

进阶能力：用 MCTS 处理复杂路由

对于更难的路由决策，Harness Router 引入了 蒙特卡洛树搜索（Monte Carlo Tree Search, MCTS），可以在本地跑数千次模拟来评估不同的路由路径。

这一点让项目跳出了简单的"规则匹配"层面。MCTS 常见于博弈和决策搜索场景，把它用在工具路由上，意味着系统可以在面对多个看似合理的候选工具时，通过大量模拟来评估哪条路径更可能达成目标，而不是依赖模型的一次性判断。

完整的执行流可以概括为：

Codex → PreToolUse → shortlist → Harness Router → route / MCTS → execute

模型先给出候选工具的 shortlist，再由 Harness Router 决定是直接路由还是启用 MCTS 深度搜索，最后才进入执行。使用方式也提供了两种：既可以作为显式的 skill/MCP 工具调用，也可以通过 hook 透明地介入，对开发者而言灵活度较高。

蒙特卡洛树搜索（MCTS）是一种基于随机采样的启发式搜索算法，最初因在围棋 AI（如 AlphaGo）中的卓越表现而广为人知。其核心思路是：从当前状态出发，通过大量随机模拟（rollout）来估算不同决策路径的期望收益，并在"探索新路径"与"利用已知优质路径"之间动态平衡（即 UCB 公式所描述的 exploration-exploitation 权衡）。

将 MCTS 用于工具路由的类比在于：每一个候选工具相当于一个"落子选择"，每一次模拟相当于假设选择该工具后推演任务的完成情况。通过上千次模拟，系统可以量化地比较"选 fetch_x 还是 get_x"在当前任务语境下的成功概率，而不是依赖模型基于上下文的一次性直觉判断。这种方式在工具语义高度重叠、单次判断可靠性不足时，能够提供更鲁棒的决策依据，但也引入了额外的本地计算开销，因此适合用在路由置信度较低的复杂场景，而非所有调用都走此路径。

它想解决的四个具体成本

作者把这个项目的目标拆得很清楚，主要是为了降低以下四类开销：

1. 错误的工具调用——减少模型选错工具的概率
2. 上下文中冗余的工具描述——不必把所有工具说明都塞给模型
3. Token 使用量——上下文精简后直接带来成本下降
4. 在显而易见的路由决策上浪费的推理——把简单判断交给路由层

这四点几乎覆盖了当前 Agent 工具调用的主要效率瓶颈，方向上是切中要害的。

一个开放的问题：如何衡量路由质量

项目作者在帖子结尾抛出了一个值得整个社区思考的问题：如何在"简单成功率"之外，去衡量工具路由的质量？

他表示特别希望在那些刻意设计得容易混淆的工具集上做基准测试，比如前面提到的 get_x / fetch_x / read_x。因为在这些场景下，传统的工具选择机制会明显变得模糊，正是检验路由层价值的好战场。

这个问题本身也提醒我们：单纯看"调用是否成功"可能不足以评价一个路由系统。是否选择了最优工具、是否避免了不必要的重试、Token 节省了多少、延迟增加了多少——这些维度或许都应该纳入评估体系。

小结

Harness Router 代表了 Agent 工程化中一个正在升温的方向：把工具选择这类关键决策从 LLM 的黑盒判断中抽离出来，交给一个可控、可插拔、带兜底机制的独立层。 无论是 Codex hooks 的集成、fail-open 的稳健设计，还是 MCTS 的引入，都体现出对生产可用性的认真考量。

项目已在 GitHub 开源（Protocol-Lattice/harness-router），对正在构建 Agent 系统、饱受工具调用混乱困扰的开发者来说，值得关注和试用。当然，它的实际效果究竟如何，仍有待更多在真实、复杂工具集上的基准测试来验证。