Nasiko-Labs/nasiko · 上手攻略
- 仓库：Nasiko-Labs/nasiko
- 链接：https://github.com/Nasiko-Labs/nasiko
- 分类：ai
- 作者：Tom
- 更新：2026-08-19
是什么
Nasiko 是一个面向 AI Agent 的开发者控制平面（Developer Control Plane），用 Rust 编写，核心定位是：运行多个 Agent 时，用单一进程解决"谁调用谁、谁持有哪个 key、调用成本几何、为什么失败"这四个工程难题。
它基于 A2A 协议（Agent-to-Agent Protocol）工作——任何讲 A2A 的 Agent（Python / Rust / Go / TypeScript 均可）都可以接入 Nasiko，不需要改造 Agent 本身，也不需要专有格式或绑定。
传统多 Agent 系统的问题：每个 Agent 各自暴露公网地址，路由逻辑分散，流量无法统一观测，key 管理混乱。Nasiko 的解法是所有 Agent-to-Agent 流量强制经过同一个代理进程，所有 ACL / 限流 / 追踪在同一个 checkpoint 执行。
解决什么问题
- 路由混乱：多 Agent 互相调用时 Caller 需要知道被调用方的地址和协议细节。Nasiko 的 3 阶段路由引擎（embedding 相似度初筛 → 对话上下文重排 → LLM 最终选）让调用方只需描述任务，由系统决定派给哪个 Agent。
- 密钥泄露风险：Agent 日志或代码里可能打印真实 API Key。Nasiko LLM Router 给 Agent 提供
OPENAI_BASE_URL+ 短效身份 Token，真实 Key 在服务端解析，Agent 侧永远不接触。 - 观测盲区：Agent 间调用链断裂，失败时难以定位。Nasiko 每个请求发出 OTel span，端到端 trace 覆盖全部 hops，Token 用量和成本自动从
gen_ai.*属性采集。 - 循环调用：多 Agent 互相触发可能形成死循环。Redis 级联限流（深度、扇出、Token 预算、超时、循环检测）阻止失控调用链。
- 多 Agent 密钥管理：每个 Agent 的 secrets 用 AES-256-GCM 静态加密，仅在部署时注入。
快速安装
方式一：Docker（推荐，无需 Rust 环境）
# 克隆仓库
git clone https://github.com/Nasiko-Labs/nasiko.git --depth 1
cd nasiko
# 单节点启动（自带 Postgres + Redis + OCI Registry）
docker compose up -d
# 确认服务运行
docker compose ps
方式二：源码编译（需要 Rust）
# 克隆仓库
git clone https://github.com/Nasiko-Labs/nasiko.git --depth 1
cd nasiko
# 编译 CLI
cargo build --release -p nasiko
# 编译服务端
cargo build --release -p nasiko-server
# 启动服务端
./target/release/nasiko-server
⚠️ 依赖：Docker（用于 Agent 容器运行时）、Postgres、Redis、S3 兼容存储（用于嵌入式 OCI Registry）。纯源码部署需要自行准备这些基础设施。
CLI 安装
# 方式一：从源码编译
cargo install --path cli/
# 方式二：从 GitHub Releases 下载二进制（如果有提供）
# 参见 https://github.com/Nasiko-Labs/nasiko/releases
核心用法
登录与集群连接
# 连接到控制平面
nasiko connect <control-plane-url>
# 认证（使用部署时配置的 ADMIN_USERNAME / ADMIN_PASSWORD）
nasiko auth login
创建并部署第一个 Agent
# 从模板脚手架新项目
nasiko new research-agent
# 进入目录，编写 Agent 逻辑（AgentCard.json 定义能力）
cd research-agent/
# 推送到内置 OCI Registry（无需外部镜像仓库）
nasiko push
# 部署到集群
nasiko deploy
运行时管理
# 查看运行中的 Agent
nasiko ps
# 实时查看日志
nasiko logs <agent-id> -f
# 重新构建并部署（拉取最新代码后）
nasiko deploy --rebuild
本地开发流程（完整示例）
# 1. 克隆模板
nasiko new --template claude-sdk my-agent
# 2. 进入目录，修改 src/ 和 AgentCard.json
cd my-agent/
# 3. 本地构建测试
docker build -t localhost:5001/my-agent:latest .
# 4. 推送 + 部署
nasiko push
nasiko deploy
# 5. 与 Agent 对话
nasiko chat <agent-id>
YAML 配置路由示例（核心能力）
Nasiko 支持通过 YAML 配置条件路由，以下为示意（具体语法需参考 docs.nasiko.com）：
# 路由规则示例（伪 YAML，非直接可用）
routes:
- name: research-routing
triggers:
- intent: "查找论文"
- intent: "做文献调研"
agent: claude-research-agent
guards:
max_depth: 3
timeout_ms: 30000
⚠️ 路由 YAML 语法需以官方文档为准，上例仅用于说明概念。2026-08-19 尚未 fetch 到完整路由配置 schema。
MCP Gateway 用法
# 通过 Nasiko 给所有 Agent 提供统一的 MCP 工具接入
# 只需一个固定 URL，Agents 通过 tools/list 和 tools/call 访问 Composio toolkit 或自建 MCP Server
# 凭据由 Nasiko 持有，Agent 侧不接触
典型适用场景
| 场景 | 为什么用 Nasiko |
|---|---|
| 多 Agent 产品化部署：需要统一路由、限流、观测的生产环境 | A2A 代理 + Flow Guards 覆盖核心痛点 |
| 企业 Agent 内网部署：API Key 不能暴露给 Agent | LLM Router 服务端解析 Key |
| 研究团队多 Agent 实验：需要可复现的路由和追踪 | OTel + Tempo/Loki 完整链路观测 |
| 多框架混用：团队 Agent 分别用 Python / TypeScript / Rust | A2A 协议无关语言，零绑定接入 |
| 快速 Demo / 比赛：需要在几分钟内部署可观测的多 Agent 系统 | Docker Compose 一键起，CLI 几步完成部署 |
坑与注意
- 需要 Docker 运行时：Nasiko 本质是 Agent 容器管理器，没有 Docker 则 Agent 无法运行。纯 bare-metal 环境需要额外配置 containerd 等。
- Rust 工具链要求（源码编译时）：需要 Rust 1.75+，
cargo在 PATH 中。CI/CD 环境建议用rustup管理版本。 - 数据库依赖：Postgres + Redis 是必需的后端，没有内置 SQLite 等轻量替代，生产部署需要运维这两层。
- OCISecret 管理边界：AES-256-GCM 加密的是静态 secrets，但密钥管理（KEK）方案在文档中描述有限，企业使用前需确认密钥轮换方案。
- A2A 协议版本：Nasiko 基于 A2A 协议，如果 Agent 使用了不兼容的 A2A 实现，代理层可能无法正确解析。
- 中文文档稀缺：主文档为英文，中文社区资源少，遇到问题更多依赖 GitHub Issue 或 Discord。
与同类对比
| 特性 | Nasiko | LangChain Agents | CrewAI | Microsoft AutoGen |
|---|---|---|---|---|
| 核心定位 | 多 Agent 控制平面/代理 | LLM 应用开发框架 | 多 Agent 编排 | 多 Agent 对话框架 |
| A2A 协议 | ✅ 原生 A2A | ❌ | ❌ | ❌ |
| Agent 语言 | 任意（协议驱动） | Python 为主 | Python | Python / .NET |
| 路由机制 | 3阶段智能路由（Embedding+Rerank+LLM） | 固定 Chain / React | 固定角色分配 | 预定义对话模式 |
| API Key 安全 | ✅ 服务端解析，Agent 不接触 | ❌ | ❌ | ❌ |
| 限流/循环检测 | ✅ Redis 级联 Flow Guards | ❌ | ❌ | ❌ |
| OTel 可观测性 | ✅ 全链路 | 部分（LangSmith 付费） | ❌ | ❌ |
| 嵌入式 OCI Registry | ✅ | ❌ | ❌ | ❌ |
| 上手门槛 | 中（需懂 Docker/A2A） | 低~中 | 低 | 中 |
| 生产成熟度 | 较新（Stars 4.4k，2025~） | 高（Stars 55k+） | 中 | 中 |
一句话总结：如果你需要管理多个 Agent 之间的通信、路由、Key 安全和可观测性，Nasiko 是目前最专注这个细分场景的开源方案；如果你只需要快速跑一个 LLM 应用，选 LangChain 或 CrewAI 更成熟。
推荐结论
Nasiko 填补了"多 Agent 生产运营"这个介于"跑起来"和"管起来"之间的空白——它不帮你写 Agent 逻辑，而是帮你把已有的 Agent 可靠地跑起来、连起来、看得见。对于需要 A2A 互通、Key 安全、循环防护和全链路 OTel 观测的团队，Nasiko 是目前 Star 增速最快的专注选手，值得在研发进入多 Agent 阶段时优先评估。