阿里云Higress团队开源本地智能体路由引擎HiRoute
阿里云Higress（阿里云开源网关项目）团队在云栖大会开源本地智能体路由与协作引擎HiRoute，可按任务类别与难度在低成本模型组和主力模型组之间切换，并将受支持的订阅经CLIProxyAPI（命令行代理接口）接入统一路由计划。
团队自述的工程研究案例中，两个同时通过验收的配对运行显示混合路由的API（应用程序编程接口）等价成本较全程使用主力模型下降约九成，但该口径不含订阅账单节省，另一长任务案例也未设全主力成本基线。
阿里云博客称，Higress团队在AGNTCon + MCPCon China（智能体与模型上下文协议大会中国场）主题演讲中预告HiRoute开源计划，并在云栖大会正式开源。 HiRoute为本地引擎，配置、路由与观测在本地运行，推理由所接入的模型服务完成； 提供macOS桌面应用及Linux上的无头命令行与后台服务。
团队列出的三类碎片化问题为：不同模型在总结研究、复杂推理、写代码和长上下文上的能力与成本差异； 用户使用的工作流各异，如Codex（OpenAI的编程智能体）、Claude Code（Anthropic的编程智能体）等； 算力分散在订阅、不同厂商API（应用程序接口）密钥与本地服务中。
产品支持经CLIProxyAPI接入受支持的订阅，内置决策模型体系，可经OpenRouter（模型聚合路由服务）接入百炼（阿里云模型服务平台）或TypeSafe的Jev。
模块ContextHold（上下文保持模块）识别同一用户轮次内延续历史的调用，保持路由决策稳定以提高KV Cache（键值缓存）命中率，并在上下文压缩或历史重建导致旧前缀断裂时重新评估模型。 首个工程案例要求调研六个消息系统、各产出60张来源核验卡并提交关于Kafka与SQL一致性的决策备忘录；
在两个混合路由与全主力模型均通过原任务验收标准的配对运行中，混合路由的API（应用程序编程接口）等价成本分别降低92.01%和91.39%，通过运行的来源核验平均准确率为99.03%，全主力为99.72%，关键决策评审双方均通过； 三次关键备忘录评审中混合路由与全主力各通过3/3，全用Qwen（通义千问）Flash通过1/3。
成本含全部尝试与路由评估，按冻结的API价格计算，不代表订阅账单节省。 第二案例为给HTTPX（Python的HTTP客户端库）增加同步与异步流式JSON迭代，团队称经济优先计划经Qwen→Astra→Qwen→Astra四个连续阶段，耗时31分36秒，无额外人工提示与手动代码补丁，独立验收通过全部343项检查；
第二次上下文交接时能力得分为0.485，低于0.5阈值，因而再次选择Astra。 该运行保留历史配置，无全Astra成本基线，团队称其只支持交接结果而非降本结论，且首个Astra阶段仅生成摘要、最终实现阶段仍未评分，不同阶段得分不构成受控的模型排名。
此事的价值在于把模型选择从一次性配置变为可按阶段调整的运行时策略，并明确区分任务路由（谁来做）与模型路由（这一阶段需要什么能力）。 团队自述案例显示，经济模型可承担大量调研工作，而关键判断与修复仍需要更强模型，与长任务在调研、设计、实现、验证之间能力需求不均的特点相符。
但降本比例来自特定任务与冻结API（应用程序编程接口）价格下的配对运行，不等于用户实际账单变化； 第二案例缺少全主力基线，只能说明自动交接未中断交付流程，不能证明更省钱。
后续观察信号
- HiRoute的开源仓库与架构文档是否公开，许可证与部署要求为何
- 除阿里云生态外的模型与订阅源支持范围是否扩展
- 是否有第三方对混合路由成本与质量进行独立复测