Nasiko：给「一屋子 AI 编程 Agent」装上电表和总闸

图：Nasiko 控制台 Dashboard（来自项目仓库 docs/assets/ui-dashboard.png）

一、一个具体的场景

你是一家 40 人的技术团队，工程师们手里同时跑着 Claude Code、Codex、Cursor、OpenCode。月底财务发来一张 3 万美元的账单，你摊开各人的 dashboard 想找出钱花在哪——没人说得清是哪个 Agent、哪个模型、哪个任务花的。

更要命的是第二个月：CTO 说「从下月起统一走 DeepSeek」，但 Claude Code 硬绑 Anthropic 协议、Codex 硬绑 OpenAI 协议，改起来得动每个工程师的本地配置，改错了还不敢回滚。

Nasiko 就是为这两件事而生。它不是又一个 Agent，它是管 Agent 的那一层。

二、它的定位：OpenRuntime

Nasiko Labs 给自己的定义是「The OpenRuntime for agents, coding harnesses, frameworks and tools」——注意是 Runtime，不是 Framework。它不生产 Agent，它接管 Agent 的发现、计量、路由、治理。

这个定位背后有一个明确的政治性表述：「An OpenRuntime belongs to no vendor inside it: your cost history, your policy and your model choice stay with you rather than with whichever harness you happened to install.」 换句话说，它假设你迟早会换 harness，所以成本数据和策略必须留在一个不依附于任何 harness 的地方。

技术上用 Rust 编写，Apache-2.0 协议，Cargo workspace 拆出 30 个 crate：auth、pricing、savings、runtime、orchestrator、llm-router、mcp-gateway、agent-proxy、coding-policy、hitl、oci、flow、observability 等，模块边界切得很细。

三、一个类比：小区总配电室

想象一栋写字楼，每层都有各自的电表（Claude Code 一个、Codex 一个、Cursor 一个），月底你只能拿到一堆分表账单，想知道整栋楼耗电多少只能靠人肉加总。Nasiko 就是总配电室加智能电表系统：

• 发现（discover）：扫到你机器上装了哪些 harness、版本、配置，不需要改你任何原有配置
• 计量（reporting）：每个 Agent 的每轮对话、token、成本落到统一 schema
• 路由（routing）：把「谁该用哪个模型」的决策从本地配置搬到服务端，Claude Code 发的 Anthropic 格式请求可以由你的 OpenAI key 来服务
• 治理（policy）：权限、成本上限、人审（HITL）集中管理

关键设计是非侵入式发现 + 显式选择加入：reporting 和 routing 是两个独立 opt-in，需要时才装 hook 或改 harness 设置，业务代码里不用包 SDK。

四、核心功能

TokenOps：成本归因

这是最实的价值。Agent 拿到的不再是真实 API key，而是 OPENAI_BASE_URL 加一个一小时有效的身份 token——路由在服务端解析 provider/model/key，任何 Agent、任何日志都看不到真实密钥。

成本数据来自 gen_ai.* span 属性，按 agent、按 model 拆开，而不是给你一张混在一起的供应商发票让你反推。每次 dispatch 和 proxy 跳转都会发出真实 OTel span，一次交互在多跳之后仍是一条端到端 trace。

路由：把模型选择权拿回来

nasiko llm-config create --name my-openai --provider openai --model gpt-4o \
  --api-key-secret OPENAI_API_KEY --secret-value "$OPENAI_API_KEY"
nasiko connect claude --config my-openai

之后 Claude Code 的 Anthropic 格式流量会被路由到 OpenAI。绑定方式是各 harness 定制化的：connect claude 改写 apiKeyHelper 和 ANTHROPIC_BASE_URL；connect codex 往 config.toml 里加 model_providers.nasiko；connect opencode 装一个 plugins/nasiko-llm-router.js 并把 nasiko/router 设为新会话的默认模型。

会话上报

nasiko agents discover / install / uninstall / sync 管理各 harness 的事件 hook：Claude 用 Stop 事件，OpenCode 监听 session.idle，Codex 和 Cursor 用更丰富的 hook 集合。完成的轮次先入队到 ~/.nasiko/integrations/queue/，再批量投递到控制面——控制面短暂不可达不丢数据。

五、上手门槛与部署

Nasiko 有两条完全不同的路径：

路径 A：只要 CLI 能力（发现、路由、本地上报），装 Rust CLI 即可，不需要服务端。

路径 B：完整平台（控制台 UI、成本聚合、策略治理），用 Docker：

cp .env.example .env
docker compose up -d

compose 里默认拉起 pgvector/pgvector:pg16 做 Postgres（带向量扩展），UI 在 http://localhost:8080。仓库另有 docker-compose.desktop.yml 和 docker-compose.infra.yml 拆分桌面版与基础设施版。

硬件要求很轻：CPU 2 核、内存 4GB 起、磁盘 20GB，不需要 GPU。数据库起在容器里即可。

有个容易漏的环境变量：AGENT_JWT_SECRET 必须设置，否则 /api/agents/{id}/llm-token 返回 503，网关鉴权会 fail closed。

六、争议与局限

它要求改动全局用户配置。 README 明确警告：~/.claude/settings.json 和 OpenCode 的配置是按用户、全局生效的文件，连一个 Agent 会影响这台机器上所有 Claude Code / OpenCode 进程，不是只影响当前项目。团队批量部署前必须把这个风险讲清楚。

OpenCode 路由存在已知限制。 OpenCode 在自己的数据库里创建会话时就固定了模型，所以恢复一个旧会话不会走路由，得开新会话或手动选「Nasiko Router」。

卸载不是完全干净。 agents uninstall 会移除本地 reporting hook 但保留注册记录与历史；disconnect 恢复路由设置，但正在运行的 harness 可能需要 --force 停止。

隐私边界要看清。 agents install <agent> 默认上报 prompt 与响应内容，需要隐私时必须显式加 --no-content。上报的数据包含对话正文，敏感团队要慎重。

项目很新。 0.1.0 版本，Rust 2024 edition，crate 数量已达 30 个，架构演进空间还很大。

七、行业意义

「Agent 数量爆炸」是 2026 年所有 AI 编码团队共同面对的新问题。当一个工程师同时开着四个 Agent 的时候，AI 编程的瓶颈已经从「模型能不能写对代码」转移到了「成本怎么算清、权限怎么管、模型怎么换」。

Nasiko 代表了这条新赛道：AI 编程的基础设施层。它和 LangSmith、Langfuse 这类可观测性工具重叠，但姿态更激进——它不只是观测，还直接接管路由和密钥分发，坚持「Agent 永远不接触真实 API key」这条安全底线。

对团队的现实价值：一张能拆到 agent 和 model 的成本账单 + 一次改配置就能全公司换模型供应商的能力。对个人：不用再担心 Claude Code 里某个 Key 泄漏到日志里。

Rust 写的、Apache-2.0 开源、自带 Docker 一键部署、UI 完整——从工程完成度看，这是目前开源 Agent 治理工具里最接近「可以直接上生产」的一批。