Routed 本地路由适合原型吗

被朋友安利了 Routed，试试看到底好不好用。它是个本地混合路由，简单说，就是给数字助手的技能文件做分流。一句请求进来，它决定交给端侧小模型、本地 GPU 还是云端 API。zero token 我理解是路由判断尽量不消耗外部大模型 token，适合把重复分类、技能选择这类轻活压下来。

我拿两个任务跑了一遍。一个是客户反馈分类，要求把“账单看不懂”“登录慢”“希望导出 PDF”分到计费、性能、功能三类。另一个是读一段 React 组件说明，生成给非技术同事看的摘要。

前者偏规则，后者偏语言理解。我这边主要拿它和 WorkBuddy 做对比。WorkBuddy 我刚用了一周不到，胜在协作空间直观，能把多 Agent 的任务边界摆出来；Routed 这边更像一个路由器，界面很薄，几乎全靠配置和日志看它为什么选这条路。

第一次装有点卡。README 写了安装，但我没看清本地模型路径怎么配，日志里只报 model not found，对着 README 找了几分钟才把路径对上。不过跑通之后确实轻。官方写低于 20ms，我没严格压测，体感很快。分类任务几乎瞬间出结果，日志能看见它先命中关键词，再落到轻量模型。React 摘要没那么理想，它把技术术语原样丢进摘要里，给非技术同事看还是太硬。这更像是下游模型能力不够，Routed 没有把输出对象这个约束传递下去。

工程上，Routed 让我觉得好的地方是透明。它把路由决策拆成可检查的步骤，这对团队排查问题有用。之前我写过一篇多 Agent 协作，观点没变，协作的关键是任务边界能不能被验收。Routed 在这种轻路由上把边界露出来了，但也暴露短板，没有团队权限、审计、版本回滚，也没有把失败案例变成可复用的规则。个人调原型很爽，跨国团队直接上生产，我会打问号。

我现在会把它放在本地实验、成本敏感的小任务和该不该上云的判断里试，不会直接接到团队生产流程上。省 token 只是表层，新人能不能看懂请求怎么被分流、出错怎么归因，才决定要不要继续投入。如果这类本地路由补上日志规范，可能会变成 agent 平台的基础件。

---

📌 本文编译自 Hacker News，原文 https://github.com/bshea-1/Routed

版权归原作者所有，本文为基于公开报道的编译与独立分析。