深度研究：nkmc.ai — Agent 的互联网网关

来源: https://nkmc.ai

日期: 2026-02-22

一句话总结

nkmc 是一个 API 网关，让 AI Agent 用 5 个类 Unix 命令访问任何 API，自动处理认证、凭证管理和计费——Agent 永远不接触原始密钥。

核心理念

"One JWT. One gateway. All APIs."

口号："不直接暴露 API 生态的复杂性，也不过度抽象。Agent 与互联网之间，恰到好处的一层。"

工作原理

Agent 侧

5 个类 Unix 命令通过网关浏览和操作 API：

类似 ls、cd、cat、man 的导航命令
支持 Unix 管道风格串联：cat | write（从一个 API 读数据写入另一个）
nkmc auth 获取 JWT token（24h 有效）

认证自动化（核心亮点）

当 API 需要认证时，nkmc 通过三层查找自动解析凭证：

1. 网关内置凭证

2. 用户配置的凭证

3. 可选集成 1Password / Bitwarden（通过 @shipkey/core）

Agent 永远不接触原始 API Key — 网关为每个 Agent→服务请求签发短期 JWT。

API 提供者侧

面向 API 开发者的工具链：

npx nkmc generate --register --domain my-api.example.com — 扫描项目路由和 schema
自动生成 skill.md 并注册到网关
DNS TXT 验证域名所有权
@nkmc/core SDK — 服务端中间件，验证网关签发的 JWT
解决了 Agent 无法通过人类 OAuth/session 认证的问题

商业模式

通过 Stripe Checkout 计费（信用卡 + 微信支付）
402 响应触发认领流程：Agent 调用付费 API → 生成认领链接 → 开发者 GitHub 登录关联
按 API 调用计费

技术栈

CLI: @nkmc/cli（npm 包）
SDK: @nkmc/core（服务端 guard 中间件）
认证: JWT（网关签发，短期有效）
多语言支持：英文、中文、日文

🔍 深度分析

与 xAPI 对比

刚好今天也研究了 xAPI.to，两者定位相似但路径不同：

维度	nkmc.ai	xAPI.to
定位	API 网关（基础设施层）	API 聚合平台（应用层）
Agent 接口	类 Unix 命令	MCP 原生
认证	JWT 自动解析 + 密码管理器集成	统一 API Key
API 上架	开发者自助注册（CLI 扫描+生成）	平台管理
关键创新	Agent 不接触密钥 + 三层凭证解析	50+ API 一站访问
Web3	无	钱包连接 + 加密支付

nkmc 更偏基础设施：它不聚合 API，而是提供让 Agent 安全访问任何 API 的通道。xAPI 更像"API 商店"。

亮点

1. 凭证安全 — Agent 不接触原始密钥是重要设计。当前大多数方案要么把 API key 写在配置里，要么通过环境变量传递。nkmc 的三层查找 + JWT 中转更安全。

2. 开发者友好 — CLI 自动扫描项目、生成 skill.md、注册到网关。让现有 API 快速 Agent-ready。

3. 类 Unix 范式 — 用 ls、cat、管道等开发者熟悉的概念操作 API，降低 Agent 的学习成本。

4. 双向市场 — 既服务 Agent 调用者，也服务 API 提供者。

质疑

1. 为什么不用 MCP？ — 不用 MCP 而用自定义的类 Unix 命令，可能限制了与现有 Agent 框架的兼容性。

2. 极早期 — 搜索引擎无索引，无社区讨论

3. 网关单点 — 所有 API 调用走网关，延迟和可靠性是问题

4. 冷启动 — 双边市场需要同时有 API 提供者和 Agent 用户

对我们的价值

@nkmc/core guard 中间件 — 如果我们想让自己的 API 对外部 Agent 可用，这是一个参考方案
凭证管理思路 — 三层查找 + 密码管理器集成的设计值得借鉴
skill.md 标准 — 和 xAPI 一样，自动生成 skill 文件的思路是对的

总结：nkmc 试图成为 Agent 访问互联网的"网关层"——不是聚合 API，而是提供安全、统一的访问通道。核心创新是凭证自动化（Agent 不碰密钥）和开发者工具链（一行命令让现有 API Agent-ready）。类 Unix 命令范式有创意但不确定能否比 MCP 更流行。处于极早期，理念先进，值得观察。