开源推广协议
#### 本帖使用社区开源推广,符合推广要求。我申明并遵循社区要求的以下内容:
* **我的帖子已经打上 #开源推广 标签:** 是
* **我的开源项目完整开源,无未开源部分:** 是
* **我的开源项目已链接认可 LINUX DO 社区:** 是
* **我帖子内的项目介绍,AI生成、润色内容部分已截图发出:** 是
* **以上选择我承诺是永久有效的,接受社区和佬友监督:** 是
以下为项目介绍正文内容,AI生成、润色内容已使用截图方式发出
本项目为 VimalinxOS 的开源项目之一,以下是该系统的其他开源项目:
本帖使用社区开源推广,符合推广要求。我申明并遵循社区要求的以下内容:
我的帖子已经打上 开源推广 标签: 是
我的开源项目完整开源,无未开源部分: 是
我的开源项目已链接认可 LINUX DO 社区: 是
我帖子内的项目介绍,AI生成、润色内容部分已截图发出: 是
以上选择我承诺是永久有效的,接受社区和佬友监督: 是
以下为项目介绍正文内容,AI生成、润色内容已使用截图方式发出
[A…
啥也不说了先看界面,好看吧 qwq
项目地址:
GitHub - vimalinx/LocalRouter: Loopback-first universal API gateway for local AI...
Loopback-first universal API gateway for local AI Agents.
事情的起因还是八月的一天,我盯着剪切板里面的亿堆API和key突然开始了沉思……
也就是说,我要把我的这些搜索API、调研API、视频提取API、数据获取API……这么一大堆东西,在我的所有Agent里面单独都配一遍?! ^-^
配一遍倒是小事,配完了之后的管理呢?如果有了新的Agent我还要在配一遍?计费和调用怎么算?如果我要换工具该如何确定AI不会偷懒?我该如何确定是那个AI花了我多少钱呢? 挨个问吗?!^-^ ^-^ ^-^
天哪,好像是个很严重的事情诶……
以前玩虾马的时候面对的是一个Agent,问题倒是不大,可是当我现在面对这么多Agent和比较复杂的API服务的管理,我这个飞舞人类明显是力不从心了
不过正当我迷茫的时候,眼神不经意间望向了NewAPI,诶?!有了!
接下来向您隆重介绍:LocalRouter !
一、这是个万能的本地网关,真的很万能!
LocalRouter 是本地各种 API 的一层统一中转,应用和 Agent 只需要调用 127.0.0.1:8317 这一个端口(或者其他自定义的端口),各种服务诸如模型啊、搜索啊、生图生视频啊、OCR啊、TTS啊,等等等等,无论是啥,几乎全都 可以放进来统一调度和使用,计费规则等等的也可以统一管理。
所有的入口如下
/v1 模型兼容接口
/v1beta Gemini 兼容接口(哈吉米你干啥呢
/p/<pack> 自定义服务接口
/w/<pack> 持久化异步任务
/mcp Agent 发现与调用
/manage/mcp 受控维护入口
/docs 文档和运行契约
我们只需要让自己的Agent读完API文档,在LocalRouter里面配一下供应商的服务地址、Key、模型列表之后,其他的每个Agent就都能自动读取文档和调用规则啦!
他还有几个比较实用的特性,比如付费调用前可以只做本机预检避免浪费,长任务可以借助Jobid来持续操作,如果有同一家服务的多把 Key 也可以放进号池集中调用等等。
适配几乎所有服务的原理很简单,就相当于是把接口文档在本地弄了一份出来。套了个壳之后,就可以方便的集中管理配置、Agent自动发现、计费、分配功能、权限管理等等一系列的事情了。
至于具体是如何装下“所有”的API协议的呢?就要靠我们的神秘小 Pack 机制啦 ^-^
标准模型接口可以简单的通过 Channel 提供服务(如llm api),而特殊服务就通过写成 Pack 的整合包来做兼容。
LocalRouter 会把能调用的操作和相关的信息都整理成机器可读的发现信息放在整合包里面,再用 /p/<pack>进行调用。而使用的时候,Agent 可以通过 CLI 或 MCP 查询服务,比较完候选服务后再做本机预检,最后明确选择某个 Pack 和模型发出请求,自动的完整整个配置的流程。
关于配置问题嘛,都什么时代了,还在手配吗?AI!启动! ^-^
在LocalRouter里面,我们可以放心大胆的 交给AI来配置!为了保证稳定性,AI自动进行的服务接入和修改还会经过草稿、review、plan、apply 和线上验证几个步骤,而且全程都是打包好的流程,无须担心 ,出了问题也有回退机制,可以更加放心的让Agent自己走完整流程。(毕竟适配各种协议然后放进去的活可不是人干的啊QWQ)(测试过了,就连luna都能稳定的配好哦)
二、高颜值简单易懂的面板界面
左侧列表显示服务供应商的健康度、上游剩余额度和价格。
绿色环表示当前有多少账号可以使用,
红色 0% 会直接告诉我这个服务已经不可用。
额度来自上游账号或外部维护器返回的数据。
没有的话一般是三种情况:
如果查不到价格则显示“未接入价格”。
Pack 没有配置额度映射时,界面会写“额度未配置”;
已经配置但上游没有返回数据时,界面会写“上游未返回”。
选中服务以后,右侧会展开账号明细。哪个账号可调度、哪个正在冷却、剩多少额度、最近什么时候使用过,在这里都能方便的看到。
实际使用中,一个服务经常不止一个接口。它可能同时提供模型列表、聊天补全、批量任务和文件下载等等的能力。
LocalRouter 的处理方式是,把子服务和计价规则合并成一张表。每一行都能看到操作名、调用路径、计价单位、资料来源和当前启用状态。方便有问题了之后精准追溯。
AI在维护的时候会被skill要求最好让计价单位保留供应商的原表述。
计费方式诸如按请求、按一千次输入、按页和按计算时长都可以自由设置。
三、每个 Agent 都有自己的身份认证
统一入口解决了配置分散的问题,而这个“身份证”机制解决了不同Agent用量计费的问题。
每个 Agent 注册时都要填写本机唯一的编码、显示名称和工作区,还可以记录它使用的是 Codex、Claude、OMP 或其他Agent。LocalRouter 随后会签发一枚与这个身份绑定的 Token。兼容模型调用和 Pack 调用也都会按 Token ID 记到同一个 Agent 名下。
工作台里面可以直接列出每个 Agent 的调用次数、输入输出 Token、成功率、已知成本、最后使用时间和今日额度。每分钟请求数、每日请求数与最大并发也能单独设置。如果想要手动新 Agent 接入的话,点一下“快速接入”,就能拿到这个 Agent 自己的本机配置,不需要复制其他 Agent 的 Key。当然直接让Agent自己接入也可以,自己领证去 XD。
可以选择开启单独放在上方的Agent维护权限。开启以后会出现维护 Key 输入框,可以选择维护Key 的显示、随机生成和保存。维护 Token 用于给指定Agent锁定维护所有服务的权限,比如可以给最好的模型避免糖比模型抽风炸池。该 key 只能访问 /manage/mcp,不能拿去调用模型和普通服务。
嘶、Agent 如何实现可控稳定的服务发现和调用呢?
LocalRouter 会把当前已经发布的 operation、模型、号池、价格和可用状态等等整理成机器可读的一个Pack。Agent 可以通过调用 lr tree 列出服务树,再根据任务分别查询和定位各种服务。
示例如下,我们也可以自己运行下,来看看lr的工作流程。
lr status
lr tree
lr find operation '网页搜索'
lr find model '适合代码任务的模型'
lr find pool search
lr describe search query
lr preflight search query '{"query":"LocalRouter"}'
lr run search query '{"query":"LocalRouter"}'
不同供应商的服务各自独立。Agent 会看到各自的 Pack、调用路径、价格、重试方式和验证状态,有多个候选时可以先比较,再明确选中一个。模型也要用供应商限定的完整 ID 做最终确认。
Agent在添加配置时,如果没有明确指示的付费调用或有副作用的操作许可,会先打个草稿做模拟测试。这一步只会检查本机契约、鉴权、参数、号池、额度和价格等等的东西,不访问上游也不会消耗额度。如果检查失败则会返回明确的原因与下一步动作。长任务可以通过 Job ID 持续查询和管理结果分配,Agent 中断以后还能接着之前的任务继续干。
唔,协议接入吗?朕的AI呢~~~~ 朕懒得干了~~~~
Pack 的编辑会碰到请求转换、认证、号池、价格、重试和异步流程,全是细节怪,手工编辑很容易出错。
LocalRouter 提供了一套受控的维护流程:Agent 先开一个隔离草稿,写入或修改 Pack,再做 lint 和影响检查。复核完成以后生成确定的摘要,之后才能发布。如果线上验证失败,系统会保留草稿并自动尝试恢复上一版,避免把自己改死()
有点复杂,最好还是让AI来干吧 :)
安装方式:(直接把仓库给AI就行,这可是做好了XDG规范的)
源码安装需要 Go 1.25.13 以上版本、Bun 和 Git。
git clone https://github.com/vimalinx/LocalRouter.git
cd LocalRouter
./tools/install-localrouter.sh install
安装器会把 localrouter 和 lr 放进 ~/.local/bin,创建用户服务,并把 LocalRouter 的 Agent 使用说明安装到受支持的 Agent 环境里。完成以后打开下面两个地址即可。
控制台 http://127.0.0.1:8317/
文档 http://127.0.0.1:8317/docs
由于设备限制,这个现在只在Arch Linux里面测试过。
由于代码全程由Gptsol写的,可能有的各种BUG大家就在帖子下面留言,看到了就会修的!也可以提Issue啥的,谢谢各位佬啦 ^-^
写在最后:一个大胆的,关于一个新的 Agent 操作系统的设想
Agent的时代,需要一个Agent和我都作为 (被腌入味了说是我竟然觉得这个词某些场景下很合适 ^-^)的系统。相对应的,AI进行资源调度的基础设施的需求也会原来越旺盛。而这也牵扯出一套新的问题:个人使用的,面向Agent的操作系统应该是啥样的?在这半年的高强度AI使用中,我好像有了点想法。
接下来两个周内,即将正式开源发布的几个项目就是我第一阶段的回答:
LocalRouter:给AI用的本地统一管理各种数据和服务的网关。
GitHub - vimalinx/LocalRouter: Loopback-first universal API gateway for local AI...
Loopback-first universal API gateway for local AI Agents.
AgentSeat:给AI独立的键鼠输入,让Hyprland的GUI也可以在后台支持ComputerUse的轻量小壳子(已开源发布)
AgentsPool:统一协调调度家中所有设备的算力,根据不同设备的性质自动暴露,用来给Agent分配算力的极简协调系统。
Shuheng:旧瓶装新酒,利用Tmux为我的所有Agent提供互联的能力,实现的本机多Agent互相协调的系统。
以上的这些基础设施的项目就是在Shuheng的统一协调下,边用边发现问题,然后由gpt5.6sol(主执行)和kimik3搭伙自动迭代的。
Ai-workspace-template:一个 靠自动薅羊毛来作为目标迭代的(当然现在绝不只是薅羊毛) 通过文件夹规范来实现Agent自主长时间运行并积累经验和不断升级的工作区文件模板。
事实证明,今年年初虾火的时候的很多失败的尝试,在现在的模型能力的加持之下会得出很多出乎意料的效果。一些极简的AI交互模式,如Tmux的SendKey也终于拨云见日,借助一些简单的辅助即可做到很好的协同效果。在现在真的值得去好好探索各种组织结构的能力了,每个版本号都要试试哈哈。
顺便一说,经过实际的探索和尝试 (把科研Deepseek的方法和劲头用到其他模型上之后) ,我绝对能肯定的是,现在的这些第一梯队的前沿AI模型的能力,是被非常严重的低估 了的。就算现在的模型能力停滞不前,也依然有巨大的上限空间没有被触碰到。比如,Agent对编程能力的特化很强,但是这种特化对模型内部其他领域的影响也绝对不少。甚至接下来可能会出现一种引导模型思考让他产出超级高质量结果的“魔法职业”?(正经来说应该是接地的“模型行为学”哈哈)不用OneShot的方法去测试模型 ,而是用一些其他的诸如借鉴心理学的机制去测试,甚至很多很区的模型都能有很好的效果。(这个我现在不太确定究竟是偶然性还是真的是这样,等我探索完善了再下定论,才不是民科呢qwq)
感谢离离子佬开源! ^-^ 本项目参考了一部分的NewAPI的代码实现
还有也参考了CPA的UI和部分代码的实现 ^-^
LocalRouter 目前采用 AGPLv3 开源。
接下来要干的事情有好多啊,希望能和大家一起学习一起加油,芜湖~~~ ^-^