场景：AI 编码 Agent 调用 API 时，你的密钥可能正在裸奔——用 Nenya Gateway 做一层安全守卫
你的 AI 编码 Agent（Cursor、Claude Code、Codex）正在帮你写代码。它需要调用外部 API——GitHub、AWS、Stripe。于是你复制了一个 API Key 到提示词里，Agent 把它塞进 HTTP 请求，请求穿过 LLM 服务商，密钥以明文形式出现在云端日志中。
这不是危言耸听。这是每一个重度使用 AI 编码工具的开发者每天都在做的事。而 Nenya——一个用 Go 写的零依赖 AI API 网关，就是来解决这个问题的。
问题：AI Agent 的密钥裸奔困境
AI 编码工具的核心工作流是：开发者输入需求 → Agent 调用 LLM → LLM 生成代码/命令 → Agent 执行。当 Agent 需要访问外部服务时，API Key 必须出现在请求中。但问题在于：
- LLM 提供商收到包含密钥的完整请求
- Agent 的对话历史可能包含密钥原文
- Cursor/Claude Code 的云端会话日志可能记录密钥
- 当切换提供商或 Agent 工具时，密钥管理完全没有一致性
现有的解决方案无非两种：要么人工盯着每一行输出检查有没有密钥泄露（不现实），要么指望 LLM 自己”懂事”地不打印密钥（更不靠谱）。
Nenya 的思路完全不同——它作为一个透明的中间层，在 Agent 和 LLM 之间做请求拦截和安全过滤。
Nenya 的架构：零依赖的安全中间层
Nenya 用 Go 编写，编译后是一个单二进制文件，零外部依赖。它不依赖 OpenSSL、不依赖 libc 以外的任何动态库，甚至连数据库都不需要。
它的部署位置很清晰：
Cursor / OpenCode / Aider
│
▼ POST /v1/chat/completions
┌──────────────────────────┐
│ Nenya Gateway │
│ ┌─ 密钥脱敏（正则） │
│ ├─ RBAC 权限检查 │
│ ├─ Agent 路由 + 熔断 │
│ ├─ MCP 工具注入 │
│ └─ Token 预算裁剪 │
└──────────────────────────┘
│
▼ 转发至上游
Anthropic / Gemini / DeepSeek / ...
开发者只需要把 Agent 工具的 API 端点改成指向本地 Nenya，所有流量自动经过安全过滤。
三层密钥保护机制
Nenya 在安全层面做了三层防护：
第一层：Tier-0 正则密钥过滤器（始终开启）
这是最基础也最关键的一层。Nenya 内置了一组正则规则，覆盖 AWS Access Key、GitHub Token、Stripe API Key、数据库连接串等常见密钥格式。任何匹配规则的字符串在请求到达 LLM 之前就被替换为 ***。这条规则是”always-on”的，无法被关闭——即使 Nenya 的其他管道全部失效，密钥脱敏依然生效。
第二层：可插拔的拦截器链
除了基础正则过滤，Nenya 还提供三级内容管道：
- RedactInterceptor：用户自定义的正则脱敏规则，覆盖第一层未覆盖的特有密钥格式
- EntropyInterceptor：检测高熵字符串（典型的密钥特征：随机字符序列），自动标记并脱敏
- TFIDFInterceptor：相关性评分，避免过度脱敏导致 Agent 上下文丢失
- BouncerInterceptor：引擎摘要，为后续 token 预算裁剪提供依据
第三层：内存级密钥保护
Nenya 使用 mlock 将密钥锁定在物理内存中，防止被换出到磁盘交换分区。进程启动后密钥存储区被密封为只读，同时禁用 core dump。即使 Nenya 进程被攻击者获取，密钥也不会出现在磁盘上。
Agent 路由与智能回退
Nenya 不仅仅是一个安全过滤器，它还是一个智能路由网关。配置中的 agent 可以定义多条 fallback 链：
{
"agents": {
"coding-agent": {
"strategy": "fallback",
"models": ["gemini-2.5-flash", "claude-sonnet-4", "deepseek-chat"]
}
}
}
当主模型超时或返回错误时，Nenya 自动切换到下一个模型，并带有断路器机制——连续失败的提供商会被暂时移除出路由池，避免重复超时耗费 token。
它还支持延迟感知路由：根据历史响应时间的中位数自动排序提供商，加入 ±5% 的随机抖动防止惊群效应。
MCP 工具的双向集成
Nenya 不仅仅是个 API 网关——它可以连接 MCP 服务器，实现工具的多轮执行：
- Agent 发送的请求中包含工具调用（tool call）
- Nenya 拦截并转发到 MCP 服务器执行
- MCP 服务器的结果回传给 Nenya
- Nenya 将结果合并到 SSE 流中返回给 Agent
这个模式的好处是：Agent 不需要知道 MCP 服务器的存在，所有 MCP 工具的调用对 Agent 透明。且 Nenya 可以在 MCP 工具执行前后做安全检查。
部署体验：一行命令启动
Nenya 的零依赖特性让部署极其简单。用 Docker/Podman 一行命令启动：
podman run -d \ --name nenya \ -p 8080:8080 \ -v ./config:/etc/nenya:ro \ -v ./secrets:/run/secrets/nenya:ro \ -e NENYA_SECRETS_DIR=/run/secrets/nenya \ --cap-drop=ALL \ --cap-add=IPC_LOCK \ --security-opt=no-new-privileges:true \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size=64M \ ghcr.io/gumieri/nenya:latest
配置文件和密钥文件分离，密钥通过 systemd credentials 或容器挂载注入，永不落盘。
对于 Linux 用户，还有更原生的方式——直接安装 deb/rpm 包，用 systemd socket activation 管理生命周期：
sudo systemctl enable --now nenya.socket sudo systemctl enable --now nenya.service
然后配置 Cursor 或 OpenCode 将 API 端点指向 http://localhost:8080/v1/chat/completions，所有流量自动经过安全过滤和智能路由。
适合什么样的团队
Nenya 特别适合以下场景：
- 使用多个 AI 编程工具的团队：Cursor、OpenCode、Aider 一起用，需要一个统一的安全层
- 对密钥安全有合规要求的项目：SOC2、ISO 27001 审计中，不能接受 API Key 出现在 LLM 提供商日志中
- 自建 AI 基础设施的团队：用 Ollama 跑本地模型 + 云端模型做 fallback，Nenya 的统一路由和管理能力刚好匹配
- MCP 工具生态的深度使用者：多个 MCP 服务器的管理和安全接入需要一个统一的入口
结语
AI 编码 Agent 的普及让开发者生产力大幅提升，但也带来了新的安全挑战。你的 API Key 在被发送到 LLM 提供商之前，是否经过了安全检查？如果你同时使用 Cursor、Claude Code 和 Codex，每个工具的密钥管理是否一致？
Nenya 用一个单二进制文件解决了这些问题。它不追求大而全的平台功能，而是专注于一个明确的场景——在 AI 编码 Agent 和 LLM 之间做一层安全、智能、透明的中间层。这正是当下 AI 工具生态中最需要的基础设施。
相关链接