把大模型从演示变成能值班的系统时，落地架构与案例框架几乎总会先露出工程缺口。下面按可执行的顺序来拆：先讲它解决什么、卡在哪，再讲选型时看哪些数字，最后落到智能体和网关该怎么接。本文面向要上线的工程师，不写空泛趋势。
一、参考架构总览
前九篇拆解 Token Exchange 、 scope 、 tool 策略 、 HITL 、 MCP 、 供应链 、 撤销 、 审计 。本文给出 可部署的参考架构 、开源组件能力边界、迁移阶段——案例仅用 公开文档可核实 的部署模式描述，不写虚构金融机构故事。
flowchart TD User[用户] –> Host[MCP Host / Agent UI] Host –> GW[Agent Gateway] GW –> PEP[Policy Engine OPA/Cedar] GW –> IdP[IdP Keycloak / Entra / Auth0] GW –> MCP[MCP Servers] GW –> APIs[Enterprise APIs] IdP –> GW PEP –> GW GW –> Audit[Audit / OTel Collector] CAEP[CAEP Receiver] –> GW 组件 职责 IdP OAuth/OIDC、Token Exchange、consent、CAEP 发送（若支持） Agent Gateway refresh 托管、Exchange、heartbeat、HITL 队列 Policy Engine to
二、Agent Gateway 内部模块
┌─────────────────────────────────────────┐ │ Agent Gateway │ ├─────────────────────────────────────────┤ │ Delegation Store (consent + constraints) │ │ Token Service (refresh + RFC8693) │ │ Tool Policy Sidecar (OPA) │ │ Approval Queue (HITL) │ │ CAEP Webhook Receiver │ │ Rate Limiter │ └─────────────────────────────────────────┘ 关键路径 ：Agent 请求 → Gateway 验证 agent session → OPA tool 判定 → 需要 HITL 则 pending → Exchange d
商业平台（Azure AI Foundry、Amazon Bedrock Agents 等，B 级）：提供托管 Agent 运行时与部分 IAM 集成—— 本文不背书 ；选型时核对是否支持委托审计字段与 per-tool policy。
三、开源组件能力边界（截至 2026-06）
# 概念配置片段 — 非完整生产文件 http_filters : – name : envoy.filters.http.ext_authz typed_config : grpc_service : envoy_grpc : cluster_name : opa_envoy_plugin ext_authz input 需含 delegator_id 、 agent_id （自 JWT act ）——Gateway 或 RS 解析 JWT 后注入 header X-Delegator-Id 、 X-Agent-Id 。 勿 信任 Client 自报 header 无 JWT 验证。
flowchart LR A[Agent] –> GW[Gateway 转发] GW –> API refresh 迁入 Gateway；Agent 用 opaque session id。
四、Envoy + ext_authz 层
active-active + OPA sidecar；IdP 依 vendor SLA。
mock IdP——禁止 prod refresh token 进 laptop。
五、迁移路径
act 审计覆盖率 100%；Agent 进程 user refresh 数 = 0。
六、公开可核实部署模式（B 级框架）
这一层常见的失败不是名词不会背，而是指标、资源和失效模式没有放在一张图里。先写出延迟预算、显存账和回滚条件，再决定要不要上新组件。
落地时建议先做的 5 件事
- 用自己的 20 条真实请求测 TTFT / TPOT / 失败原因，不要只看公开榜。
- 先写显存和 KV 缓存账，再决定卡数、量化和并发上限。
- 网关层把鉴权、配额、审计和模型路由收口，应用里不要各接各的 Key。
- 工具调用默认拒绝，按白名单放开，高风险动作必须人审。
- 模型升级准备回滚：旧权重、旧 Prompt、旧评测集要能一键切回。
和智能体产品怎么接
对龙虾PRO这类要把 OpenClaw 落到中国业务场景的平台来说，落地架构与案例框架决定的是延迟能不能进对话、成本能不能规模化、出了问题能不能追溯。技能市场、数字员工和网关都应该吃同一套观测与权限，而不是文章里的概念演示。
本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源
常见问题 FAQ
Agent 网关在智能体系统中具体解决什么问题？
根据文章，Agent Gateway 主要解决身份验证、策略执行和工具调用的工程缺口，负责 refresh 托管、Token Exchange、heartbeat、HITL 队列等，确保大模型从演示变成可值班系统，连接 IdP、Policy Engine 和 MCP Servers 等组件。
为什么落地智能体架构时建议先用真实请求测试 TTFT 和 TPOT？
文章强调，要用自己的 20 条真实请求测试 TTFT、TPOT 和失败原因，不要只看公开榜单，因为实际业务场景的性能表现可能不同，这有助于准确评估延迟和成本，避免盲目部署新组件。
如何配置 Envoy + ext_authz 层来支持 Agent Gateway 的鉴权？
文章提到，配置时需在 envoy.filters.http.ext_authz 中注入 X-Delegator-Id 和 X-Agent-Id header，但必须先通过 JWT 验证，不能信任客户端自报，确保身份信息来自网关或资源服务器的解析。
Agent Gateway 的内部模块有哪些关键职责？
内部模块包括 Delegation Store（处理 consent 和 constraints）、Token Service（refresh 和 RFC8693）、Tool Policy Sidecar（OPA 判定）、Approval Queue（HITL）、CAEP Webhook Receiver 和 Rate Limiter，协同完成请求验证和策略执行。
迁移路径中常见的陷阱是什么？
文章指出，失败常因指标、资源和失效模式未整合到同一张图里，例如延迟预算、显存账和回滚条件未提前规划，导致迁移后性能问题或无法回滚，建议先写出这些再决定上新组件。
对于龙虾PRO这类平台，如何将 OpenClaw 落地到中国业务场景？
文章提到，落地架构决定延迟能否进对话、成本能否规模化、问题能否追溯，技能市场和数字员工应与网关共享观测与权限，确保一致性而非停留在概念演示，实现可执行部署。