AI Agent Gateway 是 Tuskira 开源的 Agent 网关（Apache-2.0）：一个二进制挡在 MCP 工具服务器与大模型之间，对每次请求做认证、从加密密钥库按请求注入凭据、按 Agent 档案限制可用工具，并记录每一次调用。它把凭据与访问策略集中到一处，而不是散落在每个 Agent 配置里。 定价：开源免费（Apache-2.0），可自托管；商业版/托管服务定价官方暂未公开。编辑评分：⭐ 4.5。
AI Agent Gateway 是什么？
AI Agent Gateway 是 Tuskira 开源的一个 AI Agent 网关。用官方 README 的话说：一个二进制挡在 MCP 工具服务器与大模型之间。
它要解决的问题很具体——Agent 一旦上线，你很难回答「它到底调了什么、用了谁的凭据、有没有越权」。传统做法是把各种 API Key 和工具配置复制进每个 Agent 的配置文件里，结果是凭据散落各处、策略无从统一。这个网关的做法是把这些收拢到一处：所有工具调用和模型请求都先经过它，由它做认证、注入凭据、限制工具范围、记录日志。
项目托管在 GitHub（Tuskira/ai-agent-gateway），采用 Apache-2.0 许可证，属于可自托管的开源软件。仓库 2026-10-01 创建，截至 2026-10-14 仍有提交，GitHub 上 76 stars。
核心功能
1. 统一入口：一个二进制代理两类流量 网关同时面向 MCP 工具服务器和 LLM 提供方。LLM 侧支持 Claude 直连或经 AWS Bedrock，也支持 OpenAI 与 Gemini。对运维来说，少一层组件就少一处故障点，这一点比「再拼三个代理」要省事。
2. 逐请求认证 每个请求都要带上网关签发的 API Key，密钥的作用域绑定到租户与角色。这意味着权限模型是围绕网关建立的，而不是每个下游服务各自一套。
3. 凭据按请求注入 这是设计上比较讲究的一点：工具服务器所需的凭据从加密密钥库里取出、在出站调用时按请求注入，不需要把凭据交给调用方。相比「把 Key 发给 Agent 让它自己带」，暴露面明显更小。
4. 工具权限在调用时强制校验
官方特别强调，工具范围是在每一次 tools/call 上强制执行的，而不只是过滤 tools/list。这个区别很重要：只过滤列表，绕过列表直接构造调用仍然可能成功；在调用点上拦，才更接近真正的边界。生效方式是绑定密钥到某个 Agent 档案；没有绑定时，由调用方在请求头里自报档案。
5. 提示词与资源透传
来自各后端的提示词与资源会统一到同一命名空间下（gw://），并受同一套档案约束。对多连接器场景来说，命名冲突和越权访问这两件事被一起处理了。
6. 原生提供技能与命令
档案上挂的技能与命令可以直接通过 MCP 提供，包括 gateway__skill 工具、以提示词形式暴露的命令，以及 MCP Skills 扩展。适合放参考文本和可复用提示词模板，不需要为它们单独接一个连接器。
7. 每一次调用都留痕 工具调用与模型请求都会被记录。对需要做审计或事后追责的团队，这是网关存在的核心理由之一。
版本/套餐对比
项目走开源路线，没有付费档位可对比，这里列出的是部署与支持信息：
| 项目 | 说明 |
|---|---|
| 许可证 | Apache-2.0，开源免费 |
| 部署方式 | 官方 Quickstart 使用 Docker Compose |
| 自建依赖 | Go 1.27、Node.js 26（构建控制台）、make |
| 支持平台 | macOS、Linux；Windows 经 WSL2（官方标注未测试） |
| 资源占用 | Docker 至少 4 GB，启用 analytics 档案（ClickHouse）建议 8 GB |
| 商业版定价 | 官方暂未公开 |
值不值得用？
优点：
- 思路对。把凭据和策略集中到网关，而不是复制进每个 Agent 配置，这是 Agent 规模化之后绕不开的一步。
- 权限拦截的位置选得准。在
tools/call上强制校验，而不是只过滤列表，说明作者理解这类系统真正会被绕过的点。 - 凭据不落调用方。从加密密钥库按请求注入，减少了把 Key 分发出去的风险面。
- 覆盖面完整。工具调用与 LLM 流量都管，审计和可观测性一并给出，不用再拼装。
- 开源可审计，Apache-2.0，自托管和二次开发都没有障碍。
缺点：
- 非常新。2026-10-01 才创建，接口、文档、示例都还在快速变化期，踩坑概率不低。
- 有部署门槛。官方 Quickstart 依赖 Docker Compose，自建还要 Go 1.27 和 Node.js 26；不想碰容器和构建链的团队会觉得重。
- 平台覆盖有限。官方支持 macOS 与 Linux，Windows 只能走 WSL2 且明确标注未测试——生产环境选型时这条要算进去。
- 面向基础设施层。它不是拿来就用的小工具，个人用户基本用不上。
总体结论： 如果你正在企业里规模化上线 Agent，并且确实需要「谁调了什么、用了什么凭据、有没有越权」这三个问题的答案，这个项目值得在测试环境里跑一遍——它解决的痛点是真的，权限校验的位置也选对了。但项目太新，别急着放进关键链路，先当作候选方案观察一段时间的迭代节奏。
使用建议
- 先用官方 Quickstart 跑通最小闭环。仓库自带 11 个示例，从 Docker Compose 起一个本地实例，确认认证、凭据注入、工具收敛这三条链路都符合预期，再考虑接真实工具服务器。
- 优先验证「调用点拦截」是否真的生效。官方说权限在
tools/call上强制校验——自己构造一次越权调用试试，这是它最核心的卖点，值得亲手确认。 - 别把生产凭据一次性搬进去。先接非敏感的测试工具，确认密钥库与注入流程稳定后再迁移正式凭据。
- 关注迭代节奏而不是首发热度。这种基础设施项目，提交频率和 issue 响应速度比 star 数更能说明它会不会长期维护。
- Windows 环境提前验证。官方标注 WSL2 未测试，如果团队主力是 Windows，这一步要在选型前做掉。
适合谁用？
推荐：
- 正在企业内规模化上线 Agent、需要集中管理凭据与工具权限的平台工程团队
- 需要为 Agent 的工具调用和模型请求留下审计记录的安全与合规人员
- 想把多个 MCP 工具服务器收拢到一个受控入口的运维团队
可考虑：
- 自建 Agent 平台、正在评估「要不要加一层网关」的技术负责人
- 对 MCP 生态的治理实践感兴趣、愿意读代码的开发者
不推荐：
- 个人用户或小团队——基础设施层的组件，日常用不上
- 不想碰 Docker 与构建链、期望开箱即用的团队
- 主力环境是 Windows 且无法接受 WSL2 未测试风险的项目
- 需要成熟商业支持与 SLA 的关键业务系统
