Nasiko 智能体控制平面
为容器化 AI 智能体提供集中部署、路由、网关与可观测性。
- Star 数
- ★ 12k
- 最近更新
- 14 天前
- License
- NOASSERTION
- 主语言
- Rust
- FA 评分
- 39/100 · 缺口较多
30 秒速览
- 运行形态
- 可在哪里用
- 通用 · 跨平台OpenAI API
- 费用
- 软件免费，模型调用费用自付
- 上手难度
- 中 · 需要几步配置
- 开始前需要
- 典型场景
- 平台工程师需要在本地 Docker Compose 环境中登记、构建并发布内部 FastAPI 智能体时。
- 不适合
- 仍在使用 A2A 1.0 之前协议版本的现有 Agent 团队
- 不想维护 Docker、Postgres、Redis、S3 等基础设施的个人用户
这个 Agent 能做什么，适合哪些场景？
Nasiko 是面向生产环境 AI 智能体生态的开发者控制平面，采用云原生微服务架构。平台包含 FastAPI Backend、Router Service、Auth Service、Chat History、Kong Registry 与 Kong API Gateway，并通过 Web UI、Python CLI 和桌面应用提供入口。智能体以包含 AgentCard.json、Dockerfile 和 Python 项目的目录或 ZIP 包上传，并可通过 Kong 的 /agents/{agent-name}/ 路径访问。Router Service 使用 LangChain 分析查询、匹配 AgentCard 能力并返回带置信度的候选智能体 URL。它可用 Docker Compose 本地运行，也文档化了通过 Terraform、Helm、BuildKit 部署到 DigitalOcean 或 AWS Kubernetes 的流程。
用户可通过 nasiko agent upload-directory ./my-agent --name my-agent 上传智能体目录，或通过 nasiko agent upload-zip agent.zip --name packaged-agent 上传 ZIP；智能体必须提供 AgentCard.json，用于声明 capabilities、examples、端点及协议版本。后端将上传处理交给 Redis Stream Listener，并衔接构建系统、容器镜像仓库、Kubernetes 部署和 Kong 注册。查询可发送到 /router/route?query=...：Router Service 以 LangChain 执行查询分析、能力匹配、置信度评分和回退选择，返回 agent_url 与 confidence。Kong Gateway 将 /api/、/auth/、/router/、/app/ 和动态智能体路由到相应服务；Phoenix 用于请求与 LLM 跟踪，Chat History 保存并检索对话记录。
- 平台工程师需要在本地 Docker Compose 环境中登记、构建并发布内部 FastAPI 智能体时。
- 运营团队需要让用户请求依据 AgentCard.json 的能力描述自动路由到翻译、合规检查或 GitHub 类智能体时。
- 需要经由 Kong Gateway 统一暴露 /agents/{agent-name}/、/api/、/auth/ 和 /router/ 路径的团队。
- 需要用 Arize Phoenix 跟踪智能体请求和 LLM 调用，同时保留可检索对话历史的团队。
- 准备在 DigitalOcean 或 AWS 的 Kubernetes 集群部署容器化智能体，并使用 BuildKit 构建镜像的团队。
如何安装或部署这个 Agent？
前提：Docker、Docker Compose、Python 3.12+，建议至少 4GB 内存。克隆仓库后执行：
git clone https://github.com/Nasiko-Labs/nasiko.git
cd nasiko
cp .nasiko-local.env.example .nasiko-local.env
pip install uv
uv sync编辑 .nasiko-local.env，至少为生产安全配置 USER_CREDENTIALS_ENCRYPTION_KEY；可选配置 OPENAI_API_KEY、MINIMAX_API_KEY、GITHUB_CLIENT_ID 与 GITHUB_CLIENT_SECRET。随后启动：
docker compose -f docker-compose.local.yml --env-file .nasiko-local.env up -d用 curl http://localhost:8000/api/v1/healthcheck 验证后，可在 http://localhost:9100/app/ 打开界面。
如何使用这个 Agent？
将 NASIKO_API_URL 设为 http://localhost:9100，使用自动生成于 orchestrator/superuser_credentials.json 的凭据执行 nasiko login，然后运行 nasiko status。上传目录智能体：
nasiko agent upload-directory ./my-agent --name my-agent智能体目录应包含 AgentCard.json、Dockerfile、pyproject.toml 和 src/main.py 等文件。部署后可调用：
curl -X POST http://localhost:9100/agents/my-agent/analyze -H "Content-Type: application/json" -d '{"text": "Sample document content"}'或让路由器选择目标：
curl "http://localhost:9100/router/route?query=analyze this document"这个 Agent 有哪些优点和局限？
- 将智能体注册、容器构建、Kubernetes 部署与 Kong 自动注册串联为一条部署流程。
- AgentCard.json 同时用于能力声明和 Router Service 的 LangChain 路由决策，返回明确的 agent_url 与 confidence。
- Kong、Phoenix、MongoDB、Redis 和聊天历史服务覆盖网关、跟踪、会话/缓存与对话持久化等运行环节。
- 同时提供 Web UI、Python CLI 和 REST API，并文档化本地 Docker Compose 与 Kubernetes 部署路径。
- 本地运行依赖 Docker、Docker Compose 和 Python 3.12+，且建议至少 4GB 内存。
- 智能体需遵循特定目录结构并提供 AgentCard.json、Dockerfile 和 Python 项目配置；不符合该包格式的现有智能体需要改造。
- Kubernetes 智能体部署依赖 BuildKit，生产引导流程还涉及 Terraform、Helm、容器镜像仓库和云账户配置。
- 路由模型虽支持 OpenAI、MiniMax 与 OpenRouter，但 API 密钥、模型和 ROUTER_LLM_PROVIDER/ROUTER_LLM_MODEL 仍需自行配置。
- 仓库元数据标注 License 为 NOASSERTION，而 README 声称使用 Apache 2.0；采用前应核实实际 LICENSE 文件及许可状态。
这个 Agent 与同类方案有什么区别？
README 将直接访问各服务定位为开发用途，并建议生产访问经 Kong Gateway 的 /app/、/router/ 与其他网关路径；它没有列出独立竞品可供功能比较。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| Nasiko 智能体控制平面 当前 | 39 · 缺口较多 | 自托管服务免费 + 模型费 | ★ 12k | 14 天前 | Rust | OpenAI API |
| ContextForge 网关 | 49 · 缺口较多 | 自托管服务免费 | ★ 4.8k | 今天 | Python | Claude.ai · OpenAI API · Claude API |
| SkillHub | 56 · 缺口较多 | 自托管服务免费 | ★ 5.4k | 1 天前 | Java | Codex |
| AutoCVE 漏洞审计平台 | 44 · 缺口较多 | 自托管服务免费 + 模型费 | ★ 1.2k | 2 个月前 | Python | — |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
证据显示：README 描述了基于角色的认证（RBAC）、JWT 和 GitHub OAuth，但未提供权限模型细节，也未提及用户确认机制。数据流图展示了请求路由和可观测性，但未明确数据流透明度。敏感数据处理方面，提到了加密密钥和密码，但未说明存储和访问控制。依赖安全方面，pyproject.toml 列出了大量依赖，但未提供漏洞扫描或锁定文件。外部影响方面，描述了部署和路由，但未明确外部副作用。回滚方面，提到了热部署和回滚，但未提供具体机制。来源归属方面，未提供贡献者指南或归属政策。扣分原因：权限模型不明确，用户确认缺失，数据流透明度不足，敏感数据处理细节缺失，依赖安全未验证，外部影响未明确，回滚机制未详细说明，来源归属未提供。
证据显示：README 和测试文件在架构描述上基本一致，但测试文件引用了未包含在源文件中的数据文件（如 agent_cards、registries.json），导致自洽性不足。依赖可用性方面，pyproject.toml 列出了依赖，但未提供锁定文件或版本固定策略。失败消息方面，测试代码中有错误处理，但未提供面向用户的失败消息。扣分原因：测试数据缺失，依赖锁定缺失，失败消息未面向用户。
证据显示：README 明确了目标受众（开发者）和多种场景（本地开发、生产部署、CLI、Web UI）。能力边界方面，描述了核心功能，但未明确限制。触发精度方面，路由系统基于查询分析，但未提供精确的触发条件。环境适配方面，提供了 Docker Compose 和 Kubernetes 部署选项，但未提供详细的配置说明。扣分原因：能力边界不明确，触发精度不足，环境配置细节缺失。
证据显示：README 提供了清晰的信息架构，包括快速开始、文档链接和架构图。安装说明详细，包括 Docker Compose 和 CLI 安装。命名稳定性方面，项目名称和版本号明确，但未提供命名约定。示例和 FAQ 方面，提供了示例代理和路由示例，但未提供 FAQ。已知限制方面，未提及任何限制。许可证方面，提供了 Apache 2.0 许可证。版本控制和变更日志方面，未提供 CHANGELOG 或版本历史。维护责任方面，未明确维护者或贡献指南。扣分原因：命名约定缺失，FAQ 缺失，已知限制未提及，版本控制缺失，维护责任不明确。
证据显示：输出可用性方面，提供了 CLI、Web UI 和 REST API，输出格式清晰。边际价值方面，提供了集中管理、智能路由和可观测性，具有明显价值。成本效益方面，提供了 Docker Compose 一键部署，但未提供性能基准或成本分析。扣分原因：成本效益未量化，性能数据缺失。
证据显示：README 中的声明（如功能列表）未提供具体证据或测试结果。跨来源验证方面，测试文件存在，但未提供测试结果或覆盖率。事实与推断分离方面，README 中的描述多为断言，未区分事实和推断。扣分原因：声明缺乏证据，测试结果未提供，事实与推断未分离。
- 源码中未见：执行前用户确认开启或自行加上执行前确认；先在沙箱或测试环境跑通，确认行为后再接入真实数据。
- 源码中未见：依赖安全审查安装前固定版本并做一次依赖扫描（如 npm audit、pip-audit）；优先放在容器里运行。
- 测试文件引用了未包含在仓库中的数据文件，无法验证测试是否可运行。
- 依赖未锁定，存在供应链风险。
- 权限模型和用户确认机制不明确，需在生产环境谨慎配置。
- 未提供已知限制和版本历史，维护责任不明确。
最近版本
来自该项目 GitHub Releases 的最新发布记录，说明为上游原文摘录，未经本站改写或测试。
-
v1.0.0 Nasiko v1.0.0 - Desktop App for macOS
发布说明摘录
Nasiko v1.0.0 - Initial Release 🖥️ Desktop App (macOS) This release includes the native macOS desktop application for Nasiko. Download & Install 1. Download: Click on nasiko.zip below to download 2. Extract: Unzip the downloaded file 3. Install: Move Nasiko.app to your Applications folder 4. Permissions: Run `xattr -dr com.apple.quarantine /Applications/Nasiko.app` if needed Features - 🎯 Native macOS interface built with SwiftUI - 🔄 Real-time agent monitoring and status - 📊 Visual analytics dashboard …在 GitHub 查看 ↗