ARTICLE · 1312510
阿里开源 HiRoute 架构拆解与源码解读
阿里开源 HiRoute 架构拆解与源码解读大家好，我是玄姐。 阿里开源 HiRoute ：它最值得关注的地方，不是能省多少 Token，而是把 Agent 的执行过程改造成了一套可决策、可接管、可追溯的本地控制系统。 很多团队选模型，仍然停留在静态分工：写代码用强模型，查资料用便宜模型，定下来之后，整个会话就不再调整。我认为这个粒度太粗。一个研发任务里，读文件、找资料、改文案、做架构取舍、处理疑难缺陷，难度显然不在同一水平。真正需要路由的，不是一个笼统的任务标签，而是任务在时间线上的每一个阶段。 这也是我理解 HiRoute 的核心视角：它不是简单替 Agent 换一个模型入口，而是在 Agent 和模型之间，加了一层本地控制平面。 
我举一个典型的研发任务。 用户先让 Agent 调研三个候选方案，再核对官方资料，随后比较架构取舍，最后补一份说明文档。如果全程使用强模型，大量资料整理也在消耗高成本上下文。如果全程使用经济模型，真正影响质量的架构判断又可能失守。 静态配置解决不了这个矛盾，因为它默认整个任务只有一种难度。阶段路由换了一个思路：场景负责定义候选模型和验收标准，当前阶段该由谁执行，则等到这一步到来时再判断。
原文给出的成本案例中，在相同验收标准下，混合模型方案比全程使用主力模型节省约九成费用。我需要强调，这个数字来自特定任务的 API 等价估算，不能直接当成所有项目都能复现的承诺。对我来说，比数字更重要的是它揭示的结构：复杂任务内部确实存在大量可以降本的简单阶段。 我把这套原则压缩成一句话：复杂度负责创造降本机会，胜任度负责阻止冒险降本。 如果只看产品界面，HiRoute 像是一个带路由功能的模型网关。把代码地图和 Gateway 文档放在一起，我更愿意用四条链路理解它。 
第一条是控制链。CLI 或 Desktop 经过 client-core 调用 daemon，Application 负责业务工作流，存储与原生适配器负责保存状态、修改 Agent 接入配置。用户编辑的是草稿，只有发布后，配置才成为新请求的执行依据。 第二条是执行链。Agent 请求进入 Gateway 后，系统依次完成认证与权限绑定、协议规范化、历史与续接识别、分支决策、候选规划与冻结，再交给 gateway-core 执行。真正发请求、提交响应、处理取消和资源清理的是执行核心，不是外层的决策模型。 第三条是证据链。Observation 记录实际执行事实，本地存储提供会话、用量、费用估算与胜任度查询。这里记录的不只是最后用了哪个模型，还包括当时为什么选、实际谁执行、后来如何评价。 第四条是协作链。Router 可以把独立任务委派给 Worker 计划，每份计划绑定执行 Agent。Worker 内部仍然可以按阶段进行模型路由，所以任务协作和模型选择不是同一层的问题。 对应到源码，我会先看下面这些模块，而不是一上来就钻进某个供应商的适配代码： 
这张模块表也反映出我的阅读顺序：先看控制权和执行权怎样划分，再看某个功能怎么写。后者会频繁变化，前者才决定系统是否可靠。 内置决策模型采用 System One 思路，沿任务时间线独立回答三个问题： 我喜欢这个设计，不是因为它把提示词写成了三段，而是因为它把不同性质的判断拆开了。任务难度是对未来的估计，阶段评分是对过去的评价，问题相关性则连接过去和未来。让同一个模型在一次回答里直接权衡所有规则，最后只吐出一个模型名，出错以后很难知道它究竟错在哪一项。 在两组模型的按难度分流中，我可以把核心条件写成下面的伪代码： 这里有一个很重要的边界：决策模型负责给出判断，HiRoute 负责应用已发布的阈值、选择模型组、检查候选资格并执行。调整信任度，本质上是调整分流阈值，不是重写一大段路由提示词。路由文档给出的新计划默认简单概率阈值是 0.8，胜任度下限默认是 0.5，这些值可以按场景调整。 我还要特别提醒一个二次开发时容易混淆的地方：内置决策模型和自定义扩展，并不是完全相同的责任划分。当前扩展协议允许自定义服务直接返回任务类别和常规组或主力组，扩展返回的阶段评分只用于观察，HiRoute 不再替它应用内置阈值与低分保护。不过，候选资格检查、故障接力和执行记录仍然由 HiRoute 负责。读扩展 API 时，不能把内置 System One 的规则原样套到自定义扩展上。 低分保护看起来简单，真正难的是评分归属。 我认为 HiRoute 在这个问题上做了几道必要的限制：评分必须来自本次决策，评价的是上一实际执行阶段；证据必须完整；任务类别、已发布计划版本和评分标准必须一致。缺失评分和部分证据评分都不能当成零分，旧低分也不会在后续每一轮反复生效。 这意味着，写稿阶段的低分不能莫名其妙地触发审稿阶段升级，改过评分标准之后，也不能拿旧分数直接控制新规则。系统先把评分绑定到真实发生过的阶段，再决定它是否适用于当前请求。 第三个问题也很关键。假设上一阶段确实没做好，但用户已经换了一个不相关的问题，继续让主力模型接管就没有必要。当前文档规定，之前的问题相关概率低于 0.5 时，可以解除历史约束，随后仍按当前难度选组。解除保护不等于一定回到常规组，复杂任务依然会使用主力。 所以我不把低分保护理解成惩罚机制，而把它看成一个有范围、有期限的风险闸门。它只在证据有效且问题仍然相关时阻止降本，证据消失或者问题翻篇后，系统重新判断。 同样不能混淆的是故障和胜任度。候选模型不可用，可以触发有边界的故障接力，但系统不会因此制造一个零分。服务超时是可用性问题，回答没做好是能力评价问题，把两者混在一张成绩单里，后面的信任度调整一定会失真。 阶段路由有一个天然风险：如果每次工具调用都重新选模型，一个 Agent 回合里可能不断换脑。上下文前缀被打断，缓存频繁失效，工具调用的前后语义也更容易漂移。 HiRoute 的处理方式是，在新用户消息等边界重新判断；能够识别为同轮工具续接，并且本轮冻结决策仍可复用时，继续沿用已有决策。若重新判断后仍选中同一组，只要历史能够衔接、原模型仍满足请求要求，系统还会优先沿用上一轮模型，以延续上下文并提高缓存复用机会。 我把一次典型过程简化为： 这道边界同时解决了两个问题。对成本来说，同轮持续增长的前缀更容易复用供应商缓存，尽管实际缓存能否命中仍取决于供应商。对工程质量来说，已经开始向客户端交付回答后，系统不会在同一回答里悄悄换另一个模型接着输出。 故障接力也有边界。常规组候选耗尽后，可以接力到同类别的主力组；直接选中主力时，只在主力组内接力，不会偷偷降回常规组；候选耗尽则明确失败。对我来说，这种可解释的失败，比表面成功但行为已经偏离计划更安全。 我在 Gateway 代码里很关注一个设计：已接受的发布会被编译成不可变的请求执行依据，随后再完成分支决策、候选规划和冻结。路由计划不是一段随时可以被人改掉的提示词，而是一份带版本的运行合同。 这个设计带来三个直接收益。 第一，草稿和线上分离。修改连接、任务条件或评分标准后，需要重新选择版本并发布，才会影响新请求。 第二，历史不被新配置改写。会话里保留的是当时的选择原因、阈值和实际执行。今天改了草稿，不能回头修改昨天为什么选错。 第三，选择和执行分开记账。计划选中了哪个组，实际由哪个候选执行，中间是否发生故障接力，分别记录。没有这套区分，运维人员很容易把计划选择误当成真实调用。 我认为这才是 HiRoute 从一个省钱工具走向工程基础设施的分水岭。没有版本和证据，智能路由只是一段自动化提示词；有了版本和证据，它才可以被审计、回放和纠偏。 很多团队接新模型的方式只有两个状态，不用或者全量替换。HiRoute 把这件事改成了按难度逐步放量。 这里的信任度不是给模型打一个主观分数，它实际保存的是简单概率阈值。阈值越高，只有足够简单的工作才交给常规组；阈值降低后，常规组才有机会承担更多阶段。无论调到哪个档位，适用的低分保护仍然可以生效。 我把整个流程理解为一次面向真实任务的灰度发布： 我不建议把模型表现报告看成一个自动调参器。它更像一份灰度证据清单：样本是否足够、评分覆盖是否完整、低分是否集中在某类任务、成本是否按同一口径比较。尤其是未评分和部分证据，不能被悄悄算成成功或者失败。 模型路由回答的是，这一步由哪个模型执行。任务路由回答的是，这件独立工作由哪个 Agent 执行。我把它们看成两条正交的轴。 以 Hermes 作为常驻 Router 为例，它负责理解意图、选择计划、提交任务和汇总结果。HiRoute 的 Worker 计划绑定具体执行 Agent，例如资料搜集、工程编码或代码审查分别使用不同计划。每个 Worker 在自己的上下文里执行，内部仍然可以按阶段选择常规组或主力组。 这样组合之后，Router 不会被一个长任务占住，Worker 之间也不会共享一大段互相干扰的上下文。更重要的是，我不需要为了让不同 Agent 分工，就放弃对模型成本和质量的细粒度控制。 但这里有几条边界必须在落地前说清楚： 所以我不会把 Worker 直接用于必须严格只读或者强隔离的任务。目录隔离也不是锁，多个任务共用工作目录时，仍然要避免互相覆盖。 如果我把 HiRoute 用到真实团队，不会第一天就开启全部自动化。我会按下面三步推进。 第一步，先用固定模型验证接入。检查 Agent 协议、工具调用、上下文长度、权限和本地记录是否正常。这个阶段的目标不是省钱，而是建立可信的执行链路。 第二步，在低风险任务上启用按难度分流。配置常规组和主力组，先采用偏保守的信任阈值。逐条查看路由时间线，重点核对简单概率是否符合直觉、低分是否归因正确、故障接力是否被误读为能力差。 第三步，证据足够后再调整信任度，并引入 Worker。对可独立验收的任务做委派，对必须强隔离的任务保留在更严格的环境里。不要把所有 Agent 同时接入，先把一个研发场景跑完整。 度量上，我也不会只盯 Token 单价。至少需要四组指标：
这里最容易踩的坑，是把简单概率理解成任务成功率。文档已经明确，0.9 的简单概率只表示决策模型更倾向于认为它简单，并不表示执行模型有九成把握做对。路由评估看的是是否遵循既定策略，任务验收看的是最终有没有把事情做成，两套口径不能互相替代。 我最后把 HiRoute 的架构价值压缩成一句话：不是让便宜模型替代强模型，而是让每一次模型选择都有理由，每一次执行偏差都有接管，每一次策略调整都有证据。 单看 System One 的三问，它并不神秘；单看模型代理，也早已不新鲜。真正有意思的是，HiRoute 把阶段判断、不可变发布、同轮冻结、有界接力、执行证据和灰度回放串成了一条闭环。 当 Agent 开始承担长任务，我认为团队需要管理的就不只是提示词和模型清单，而是每一次执行的决策权。谁有权判断，谁有权选组，谁负责执行，谁记录事实，谁允许策略生效，这些问题回答清楚，智能路由才不是一个更复杂的黑盒。 如果你对企业级 AI 原生研发体系（Skills、SDD、Harness、Loop、知识飞轮、评测、治理度量）感兴趣，去 AITutor 领取双11福利。 AITutor 双11福利：AITutor 是每个人的 AI 原生学习伙伴，汇集大量 AI 实践案例，4500+ 门 AI 课程、7×24 小时 AI 导师已全面开放。双 11 期间 Pro 会员从 199 元/月优惠到仅11.11 元/月，11 月 11 日 23:59 截止，长按识别下方二维码直接开通 👇 
PS：双 11 AI 落地福利专场，点击预约直播。
https://github.com/higress-group/HiRoutePS：
想深入学更多 AI 实战案例，可以上 AITutor。
双 11 限时优惠：Pro 会员 199 元/月，活动期间仅 11.11 元/月，11 月 11 日 23:59 截止，扫下方二维码直接开通。
一、先把问题说准：按场景选模型，为什么不够用
二、总体架构：我把它拆成四条链路
三、决策机制：三个问题，比直接点名一个模型更稳
上一阶段做得怎么样？输出胜任度评分，用于后续保护和模型表现报告。
当前这一步有多简单？输出简单概率，决定当前工作有没有进入常规组的机会。
上一阶段的问题还会延续吗？判断已经暴露的问题是否仍影响接下来的工作，决定低分保护应该保持还是解除。
可以进入常规组 = 当前简单概率达到信任阈值并且没有适用于本轮的完整低分保护否则 = 进入主力组
四、低分保护：不是一次差评，就永久切换强模型
五、冻结决策：既保护缓存，也保护执行语义
新消息 A：重新决策，冻结模型组与有序候选工具续接 A1：继承本轮决策工具续接 A2：继续继承本轮决策新消息 B：重新判断，允许保持原模型，也允许切换上下文无法连续或决策不可复用：重新建立有效决策
六、发布与证据：路由配置也需要版本化
七、新模型试用：信任度不是评分，而是灰度门槛
先让新模型处理低风险、足够简单的阶段，主力模型保留接管能力。
在会话时间线里检查实际执行、后续评价、低分保护和费用估算。
证据足够后，用自己的历史记录回放新的信任度设置，查看分流比例会怎样变化。
回放只是生成调整依据，最终仍由人决定是否发布，单次低分不会自动改写计划。
八、两条路由轴：选 Agent 和选模型，不要混成一件事
委派只有一层，执行 Agent 不能继续向下委派。
一份计划绑定一种执行 Agent，失败时不会自动换成另一种 Agent。
Worker 的执行权限不等于操作系统沙箱，它可以按自身能力读写文件、运行命令和访问网络。
取消任务只停止这次运行，已经写入的文件和已经完成的外部动作不会自动回滚。
九、我的落地建议：先跑通证据，再逐步放开智能
十、结语：我认为真正值钱的是控制闭环
PS：双 11 AI 落地福利专场，点击预约直播。
十一、 加我微信
扫码加我👇有很多不方便公开发公众号的我会直接分享在朋友圈，欢迎你扫码加我个人微信来看👇
加星标★，不错过每一次更新！
⬇戳”阅读原文“，立即体验AITutor
