Anthropic 在 2026 年 6 月下旬发布了 Claude 应用网关。它是一个自托管服务，捆绑在 claude 二进制文件（v2.1.195+）中。你可以用 claude gateway --config gateway.yaml 运行它，用 PostgreSQL 备份它，它会在你的 Claude Code 部署前放置 OIDC 登录：企业 IdP 会话而非本地管理的 API 密钥。这确实是一个实质性的进步。对于那些对 Bedrock、Vertex、Foundry 或 Anthropic API 直接运行 Claude Code 的团队来说，该网关将身份、模型访问和费用控制集中在一个配置文件后面。
这篇文章讨论的是接下来会发生什么。你的 AI 资产很可能不仅仅是 Claude。你可能运行来自多个供应商的 MCP 服务器。你可能有 OpenAI 或 Gemini 工作负载，通过 vLLM 或 Ollama 自行托管推理，有从不打开浏览器的 CI 流水线，以及在提供商之间委派的代理框架。应用网关仅支持 Claude 和 OIDC。这是一个范围决策，而不是缺陷——但这意味着治理问题只得到部分解决。
这里描述的共部署模型将一个自托管的治理平台放在网关旁边，同时读取网关的遥测数据和其余的代理基础设施。相辅相成，而非竞争：网关处理身份验证，平台处理治理。
应用程序网关的优势
该网关解决了一个特定的重要问题：为Claude Code提供适当的身份层。在它出现之前，每个开发者都使用API密钥或共享凭证，并且没有统一的方法在组织级别执行模型访问、消费上限或管理设置。
有了该网关后：
- 开发者通过您的OIDC身份提供者（每个网关实例一个发行者）进行认证。
- 身份提供者组映射到
gateway.yaml中的模型允许列表和管理设置策略。 - 消费限制可按用户、按组或按组织执行，并通过消费限制管理API管理。
- 遥测数据通过 OTLP/HTTP 分发，并加盖
user.id、user.email和user.groups的时间戳。 - 审计事件（11 种类型：
config.load、session.mint、auth.denied、inference等）以单行 JSON 格式输出到 stderr。
对于其声明的范围来说，这是设计良好的基础设施。Anthropic 发布网关协议并邀请第三方实现，这对于模型提供商来说是异常开放的态度。
它未涵盖的内容
Anthropic 清楚地记录了以下范围决策。这些不是缺陷 —— 它们定义了共同部署边界所在：
- 仅 OIDC。 不支持 SAML，不支持 LDAP。如果您的 IdP 使用 SAML，您需要在网关前设置一个 OIDC 桥接器。
- 单一发布者。 每个网关实例仅支持一个 OIDC 提供者。多租户部署需要独立的实例。
- 仅 Claude。 模型目录仅包含 Claude 模型。OpenAI、Gemini、本地推理及其他提供者不在网关范围内。
- 无服务令牌流。 无人值守的 CI/CD 流程没有通过网关进行非交互式认证的文档路径。
- 无管理 UI。 配置使用 YAML 文件；更改需要重新部署。
- 无 Helm 图表。 网关作为标准部署运行，但没有打包的图表。
除了这些已记录的限制外，还有一些治理层面的关注点，网关并未设计来处理这些问题：
- MCP 服务器清单和状态。 哪些 MCP 服务器已部署，它们暴露了哪些工具，以及它们声明的功能是否与观察到的行为相符——这些都不是网关的工作。
- 跨提供商的策略执行。 一项策略规定“生产数据库对所有代理都是只读的”，需要在 Claude、OpenAI 和自托管模型中统一执行。网关管理 Claude 模型的访问；它不管理这些模型所接触的资源，也不管理其他模型的行为。
- 会话级访问映射。 构建哪个代理会话访问了哪个数据库、对象存储或 API 端点的图——以及该访问是读取还是读取/write——需要关联遥测、钩子和基础设施信号。网关逐字转发OTLP；它不会分析遥测描述的内容。
- 防篡改审计。 网关在 stderr 上发出 JSON 审计事件。如果这些事件要支持合规证据包，则需要落入一个哈希链式、仅追加的账本中。
共同部署模型
架构故意保持简单：网关和治理平台并行运行在您的基础设施中，各自发挥其擅长的功能。
Developer workstations Your infrastructure
┌─────────────────────┐
│ Claude Code │
│ (v2.1.195+) │
└──────┬──────────────┘
│
│ OIDC device flow
│ /v1/messages
▼
┌──────────────────────────────┐ ┌────────────────────────────────┐
│ Claude apps gateway │ │ Olivares AI (self-hosted) │
│ │ │ │
│ • OIDC auth (1 issuer) │ │ • OTLP receiver (gRPC + HTTP) │
│ • Model allowlists │ ──▶ │ • Claude hooks correlation │
│ • Spend limits │ OTLP │ • gateway.yaml posture │
│ • Managed settings │ │ • Audit event ingest │
│ • OTLP fan-out │ │ • Multi-provider governance │
│ • JSON audit on stderr │ ──▶ │ • MCP server inventory │
│ │ logs │ • Access-edge graph (R/RW) │
│ Claude models only. │ │ • Hash-chained audit ledger │
│ OIDC only. │ │ │
└──────────────────────────────┘ │ ALL providers, ALL surfaces. │
└────────────────────────────────┘
▲
Other agent traffic ────────────────────────┘
(OpenAI, Gemini, vLLM, Ollama, MCP servers, CI pipelines)两个数据流将网关连接到平台：
OTLP 分发。 网关的 telemetry.forward_to 配置已经支持 OTLP/HTTP 目标。将其中一个指向 Olivares OTLP 接收器。session.id 属性将网关中继的遥测与 Claude 连接器自身 hooks 接收器的会话运行记录关联起来。由网关添加的身份属性（user.id、user.email、user.groups）遵循操作员属性白名单，并成为会话边和成本样本的归因标签 — 不需要新的接收器代码。
审计事件采集。 claude-apps-gateway 连接器读取网关的 JSON 审计事件。文档中列出的 11 种事件类型（config.load、session.mint、session.refresh、device.authorize、device.verify、auth.denied、access.denied、inference、managed.serve、spend.blocked、admin.denied）被映射到 SDK 观察：与安全相关的拒绝行为成为发现，推理事件成为访问边，会议创建成为身份观察，操作事件成为指标计数器。原始事件中的 PII 在进入任何观察之前已使用 SHA-256 哈希；电子邮件和标识符为化名。
claude-apps-gateway 连接器还会清点 gateway.yaml 本身：OIDC 发行者、IdP-组到模型的映射、上游提供者、OTLP 目标，以及支出管理态势。此清单是结构性元数据——拓扑结构，而非凭证。
来自网关配置的态势发现
该连接器会根据网关配置产生一系列态势发现。这些是治理操作员需要了解的关于网关部署的事项：
| 发现 | 严重性 | 其捕获内容 |
|---|---|---|
| 未配置 OTLP 目标 | 中等 | 遥测未被转发；整个群组对监控不可见 |
| 没有通用策略 | 高 | 未匹配任何 IdP 组的用户可以访问所有模型且没有管理设置 |
| 没有支出限制 | 中 | 支出管理 API 和执行未配置 |
| YAML 中的密钥明文 | 高 | client_secret、jwt_secret 或数据库密码以明文形式书写，而不是使用 ${VAR} 或 ${file:...} 引用 |
| 长会话 TTL (>12h) | 中 | 停用延迟：被吊销用户的会话仍然有效 |
| PKCE 已禁用 | 低 | OIDC 流程未使用用于代码交换的 Proof Key |
| 敏感遥测信号 | 低 | 目标上的 logs: true 或 traces: true — 这些可能携带完整的 bash 命令和文件路径 |
这些发现出现在与其他连接器发现相同的姿态视图中。MCP 连接器可能报告一个未沙箱化工具。Bedrock 连接器可能标记 gap 作为护栏。网关连接器报告缺少一个策略全捕获。一个表面，一个视图。
这在配置中看起来是这样
Claude 连接器在标准 OpenTelemetry 端口上运行 OTLP 接收器，并为 Claude Code 的 PreToolUse/PostToolUse 钩子提供 hooks 端点。与此同时，apps-gateway 连接器读取网关的配置和审计流。两个连接器都在 Apache-2.0 下发布，并且只从 SDK 导入，从不从引擎核心导入。
# olivares.yaml（缩写）
connectors:
- name: olivares.claude
config:
grpc_addr: "127.0.0.1:4317"
http_addr: "127.0.0.1:4318"
hook_path: "/hooks"
enforcement: |
{"rules":[
{"tool":"Bash","decision":"ask","reason":"shell access requires confirmation"},
{"resource_kind":"file","mode":"write","decision":"ask"}
]}
gateway: "direct"
semconv_opt_in: "gen_ai_latest_experimental"
- name: olivares.claude-apps-gateway
config:
config_path: "/etc/claude-gateway/gateway.yaml"
audit_log_path: "/var/log/claude-gateway/audit.jsonl"Claude 连接器上的 gateway 字段会用部署表面（direct、bedrock-mantle、bedrock-legacy、vertex、foundry、claude-platform-aws）标记每个成本样本，因此 FinOps 可以按提供商路径划分支出。semconv_opt_in 字段启用了供应商中立的 GenAI 输入配置文件（固定在 OpenTelemetry semconv v1.41.1），这意味着 OpenAI、Gemini 或任何 OTel 仪表化的代理都使用相同的访问映射和成本管道——不仅仅是 Claude Code。
诚实定位
有些事情值得直接说明。
这不是一个网关替代品。 Olivares 推断代理实现了 Anthropic 发布的网关协议的一个子集（OAuth 发现、RFC 8628 设备授权、托管设置传递，以及支出限制管理界面——视图、写入和按座位执行，其与物理协议的差异已记录）。当该子集足够使用时，它非常有用。它不是网关浏览器 OIDC 流程的完整替代品，并且其群组支出语义故意有所不同（最严格优先，而不是网关的合并规则）。如果 Anthropic 网关符合您的授权要求，请运行它。
该连接器为只读。 claude-apps-gateway 连接器会观察网关的配置和审计输出。它不会修改 gateway.yaml，不会注入策略，也不会拦截 /v1/messages 路径。它是可见性，而非控制。
Olivares AI 处于预发布状态。 该产品未通过 SOC 2、ISO/IEC 27001、欧盟人工智能法案或任何其他框架的认证，也没有正在进行的审计。它的设计目标是针对这些框架所检视的控制目标，因此在需要审计时已经准备就绪。
价值在于组合。 一个团队如果只使用 Claude Code 对一个提供商进行操作，使用一个 IdP，并且没有来自其他供应商的 MCP 服务器，可能会发现单独的网关就足够了。当环境是异构的：多个提供商，来自多个供应商的 MCP 服务器，自托管模型，CI 流水线，以及覆盖整个代理面的合规要求时，共同部署才显得有意义。在这种情况下，“Claude 认证”和“环境治理”确实是不同的问题。
常见问题
Olivares AI 会取代 Claude 应用网关吗？
不。这个原则是“和，而不是或”。Anthropic 网关拥有 Claude Code 的认证会话、模型访问路由和上游选择。Olivares AI 使该部署成为更广泛控制平面内的一个受控面，这个控制平面还涵盖非 Claude 提供商、MCP 服务器、自托管模型及你代理资产的其他部分。如果你已经运行网关，请保持它。
我可以在没有 Claude 应用网关的情况下运行 Olivares AI 吗？
是的。claude-apps-gateway 连接器是可选的。核心 Claude 连接器 (connectors/claude) 可接收 OTLP 遥测数据，并直接从 Claude Code 会话中挂接，无论前面是否有网关。如果您不使用 Anthropic 网关，您会失去其 OIDC 会话认证路径，但仍保留完整管理功能：会话清单、访问边缘映射、成本归属、挂钩执行、MCP 状态以及多供应商视图。
有关详细部署拓扑，请参见 /architecture。有关各供应商的 MCP 服务器管理，请参见 /product/mcp。有关完整产品面，请参见 /product。