Nasiko-Labs/nasiko

Nasiko 是一个自托管控制平面，用来收拾分散的 Agent 资产：发现机器上已装的编程 Agent CLI、汇总它们的开销、把模型调用路由到你指定的供应商，并把自建 A2A Agent 统一放在一个代理之后。它适合已经同时使用多个 harness 或 Agent 的团队，希望在请求路径上而不是在看板里落实成本归属、访问控制和预算限制。

工作机制

nasiko-server 是单一进程，所有 Agent 间调用、工具调用和 LLM 请求都经过它。这个位置是刻意选择的：README 认为各厂商的私有计量单位无法事后对账，预算上限也只有在请求真正流经的地方才有约束力为什么必须在调用路径上。具体而言，LLM Router 给 Agent 的是 base URL 和短期 JWT 而非真实供应商密钥，供应商、模型和密钥在服务端解析功能列表。MCP Gateway 把 Composio 工具包和自建 MCP 服务器合并成一个按权限过滤的目录，Agent 调用工具时无需持有第三方凭据MCP 工具章节。Redis 中的 flow guards 限制深度、扇出、token 预算和循环。持久状态存放在 Postgres、Redis 和 S3，可选配 OTel/Tempo/Loki 观测架构。

两条不同的使用路径

观测和调度已有的编程 Agent 支持 Claude Code、Codex、OpenCode 和 Cursor CLI（后者目前只支持发现和上报，不支持路由）。发现是只读的，不向机器外发送任何内容；上报和路由是分别安装的独立选项编程 Agent。--no-content 让上报不含提示和回复文本；控制平面短暂不可达时，已完成的轮次会在本地排队。注意 OpenCode 插件装完需重启，Codex 会要求你信任新 hooks。从源码安装 CLI 需要 Rust；旧构建共用同一个 0.1.0 版本号，只看 --version 无法判断某命令是否存在。

部署自己的 Agent 要求运行时精确支持 A2A v1.0；可选 Python、Rust、Go 和 TypeScript，没有专有 SDK。但需要容器运行时，除非改用 nasiko upload 交给服务端构建。

要求与注意事项

最简单的路径只需 Docker Engine 加 Compose V2（即 docker compose 命令，而非旧版 v1），不需要 Rust——服务端在容器内自行编译环境要求。开发者路径需要 Rust 1.85+ 和 just。首次启动前必须设置若干密钥，其中包括单独的 AGENT_JWT_SECRET；缺失时 Agent token 签发返回 503，网关认证会失败关闭。日常重启时不可重新生成 SECRETS_ENCRYPTION_KEY，否则已有的加密 Agent 密钥将无法读取。README 示例中的 S3 凭据是开发用值。

项目采用 Apache-2.0 许可许可证。以上信息全部来自 README，未提供对可靠性或安全性的独立评估。