银行数字化转型最容易被看到的是手机银行、开放银行和智能助手，真正决定这些服务能否稳定扩展的，却是背后的 API 基础设施。德意志银行在拆分单体系统时意识到，仅仅把功能改造成 API 并不够：如果文档、安全策略、版本管理和可观测性仍然分散，系统只会从一个大型单体变成一组难以管理的接口。
因此，德意志银行选择 Google Cloud Apigee 作为统一 API 管理平台，把 API 目录、策略执行、安全控制、流量治理和分析能力放进同一套生命周期体系。这套基础设施不仅服务于开放银行和内部微服务，也为 MCP、A2A 以及 AI 驱动的自动化服务预留了受控接入路径。
API 平台解决的不只是网关问题
API 网关通常被理解为后端服务前的一层代理，但企业级 API 管理的范围更大。德意志银行关注的核心能力可以归纳为四类。
统一治理，同时保留交付速度
所有端点、版本和依赖关系进入统一目录后，开发者可以直接检索已有能力，而不是反复询问某个客户数据接口由谁维护，或者重新实现相同功能。
治理也不应依赖人工审批每一个细节。OpenAPI 定义、请求 Schema 校验、统一错误格式和安全策略可以在平台层自动执行。团队仍然独立发布服务，但必须在明确的护栏内运行。
这种模式的关键是把治理写成机器可执行的契约：
- OpenAPI 描述接口和数据结构；
- OAuth2 Scope 表达调用方权限；
- 配额和限流策略控制使用强度；
- 统一日志记录谁在何时访问了什么；
- API 目录暴露版本、负责人和依赖关系。
像管理员工权限一样管理 API 权限
德意志银行用员工入职来类比 API 安全：新员工不会在第一天获得所有系统权限，服务和自动化代理也不应该拿到过宽的访问范围。
例如，一个账户分析服务可以读取余额和最近 90 天的交易，但不能发起转账。权限应能集中审计、随时收回，并在业务职责变化时更新。OAuth2 Scope 和 API Key 管理正适合表达这种最小权限模型。
自动化调用尤其需要额外约束。一个配置错误的服务可能每分钟发出数千次请求，因此身份认证并不能替代流量控制。限流、配额和异常检测共同决定故障的影响范围。
把韧性与可观测性放进调用路径
银行 API 必须面对凌晨查询、市场波动和合作伙伴流量突增。负载均衡、健康检查、熔断和缓存可以减少后端故障对调用方的影响；统一仪表盘则把实时流量、错误率、消费者用量和合规指标放在同一视图中。
这类数据不只服务运维团队。产品经理可以衡量合作伙伴实际使用了哪些能力，安全团队可以识别异常调用，平台团队则可以根据延迟和错误分布调整容量。
缓存需要谨慎使用。静态参考数据或更新频率低的产品信息适合缓存，账户余额、交易状态等强时效数据则必须明确 TTL、失效条件和一致性要求，不能只为了降低延迟而缓存。
可以这样实践：从 API 契约和最小权限开始
下面是一个可改造的 OpenAPI 示例，假设要发布账户余额查询接口。它定义了 OAuth2、只读 Scope、请求参数和统一错误响应。实际接入 Apigee 时，可以导入这份契约，再在代理层配置令牌校验、Schema 校验和配额策略。
将内容保存为 openapi.yaml，并替换授权地址、服务器域名和数据结构：
openapi: 3.0.3
info:
title: Account Balance API
version: 1.0.0
servers:
- url: https://api.example-bank.com
paths:
/v1/accounts/{accountId}/balance:
get:
summary: Read the current account balance
operationId: getAccountBalance
security:
- oauth2: [accounts.balance.read]
parameters:
- name: accountId
in: path
required: true
schema:
type: string
pattern: '^[A-Za-z0-9-]{8,64}$'
responses:
'200':
description: Balance returned successfully
content:
application/json:
schema:
type: object
required: [accountId, amount, currency, asOf]
properties:
accountId:
type: string
amount:
type: string
pattern: '^-?[0-9]+\\.[0-9]{2}$'
currency:
type: string
minLength: 3
maxLength: 3
asOf:
type: string
format: date-time
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'429':
description: Request quota exceeded
components:
securitySchemes:
oauth2:
type: oauth2
flows:
clientCredentials:
tokenUrl: https://identity.example-bank.com/oauth2/token
scopes:
accounts.balance.read: Read account balances
responses:
Unauthorized:
description: Missing or invalid access token
Forbidden:
description: Token does not contain the required scope
获得只读令牌后，可以用下面的命令验证接口。调用方只申请 accounts.balance.read，不应同时申请转账等无关权限：
TOKEN=$(curl --fail --silent \
-u "$CLIENT_ID:$CLIENT_SECRET" \
-d 'grant_type=client_credentials' \
-d 'scope=accounts.balance.read' \
https://identity.example-bank.com/oauth2/token \
| jq -r '.access_token')
curl --fail --silent \
-H "Authorization: Bearer $TOKEN" \
-H 'Accept: application/json' \
https://api.example-bank.com/v1/accounts/ACC-12345678/balance \
| jq
生产环境还应在 Apigee 代理上增加短时间窗限流和较长周期配额。下面是一个可改造的 Apigee SpikeArrest 策略示例，用于抑制瞬时突发请求；具体速率必须根据后端容量和消费者等级调整：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SpikeArrest name="SA-Protect-Account-Backend">
<DisplayName>Protect account backend</DisplayName>
<Rate>60pm</Rate>
<UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>
限流策略不能代替业务级幂等控制。余额查询通常是只读操作，但转账、支付和账户变更接口还需要幂等键、重复请求检测及明确的重试规则。
AI、MCP 与 A2A 为什么仍然需要 API 治理
面向 AI 的服务并没有让传统 API 管理过时，反而扩大了治理需求。智能助手可能串联账户查询、风险分析和客户通知等多个接口，并以远高于人工操作的频率执行调用。
德意志银行认为，MCP 和 A2A 等新标准可以建立在现有 API 基础之上：MCP 更偏向工具与资源接入，A2A 更关注代理之间的协作。已有的 OpenAPI 契约、OAuth2 体系和审计能力可以继续发挥作用，新型服务器也可以放在 Apigee 代理之后，沿用统一安全控制。
这意味着“AI-ready”不只是增加一个模型接口。平台还需要回答几个具体问题：
- 代理能看到哪些客户数据，Scope 是否足够细；
- 一次任务最多可以调用多少接口；
- 多 API 编排中的每一步能否被追踪；
- 模型或代理配置错误时，能否立即撤销凭证；
- 工具描述和 Schema 是否足够清晰，既能被开发者理解，也能被机器可靠使用。
语义明确的摘要、字段说明和错误定义因此不再只是文档质量问题，它们会直接影响自动化代理选择工具和构造请求的准确性。
落地时应检查什么
API 平台的价值不在于把所有流量集中到一个产品，而在于形成可重复执行的管理方式。企业在采用类似方案时，可以从以下检查项开始：
- 每个 API 是否有负责人、版本、依赖关系和下线计划；
- OpenAPI 契约是否进入 CI，并执行兼容性与 Schema 检查；
- OAuth2 Scope 是否按业务动作拆分，而不是只有一个全能权限；
- 限流、配额、熔断和缓存是否基于后端能力分别设计；
- 日志是否能关联消费者、令牌、请求链路和业务操作；
- 仪表盘是否同时覆盖延迟、错误、使用价值和安全异常；
- MCP、A2A 或其他代理入口是否仍经过同一套认证、授权与审计。
统一治理会增加平台建设成本，也需要服务团队接受契约优先和策略自动化的工作方式。相应的收益是，组织不必在每次接入移动应用、金融科技伙伴或 AI 代理时重新设计安全和运维体系。对大型银行而言，真正的敏捷并不是绕过控制，而是让控制成为默认、自动且可观测的基础能力。