你的 AI agent 可以读日历、提工单、查数据库，但面对银行 API 大门紧锁。问题不在银行没有 API ——PSD2 已强制欧盟银行开放接口，但认证层只为机构设计，不为 agent 服务。第三方调用银行 API 必须持有 eIDAS QWAC + eSEAL 证书，由 QTSP 签发，审批耗时数周，年费 €2,000–10,000。没有任何 agent 框架内置能生成合格电子印章的工具，也没有独立开发者会为搭一个 MCP 服务器去申请这东西。结果：agent 浪潮席卷其他所有 API，但在银行面前直接撞墙。
这解释了为什么开放银行领域被聚合器（Yapily、TrueLayer、Tink、Plaid）垄断 —— 不是技术更好，而是它们愿意且有能力承担“证书税”：买 eIDAS 证书、完成 AISP/PISP 监管注册、维护每家银行的连接器（各家对 Berlin Group NextGenPSD2 标准的实现都不相同），然后卖给你一把 REST 密钥。副作用是：银行数据成为唯一不能直接对接源头的 API 品类，合规门槛六位数起。
MCP（Model Context Protocol）让情况更尖锐。今年 agent 运行时靠 MCP 服务器注入工具：暴露几个工具，agent 发现并调用。对多数领域就是包一层 REST API 返回 JSON，但银行场景第一步就卡住 —— 包装器需要客户端证书才能完成 TLS 握手。这不是粘贴一个配置值，而是绑定到一个通过监管审查的法律实体的凭据。你发布到 registry 的 MCP 服务器不可能携带它。所以今天的“银行 MCP 服务器”只能对接聚合器，而非银行。
真正值得设计的 agent 原生银行访问模式是：无需强制 agent 栈经过中介，就能获得对自己账户数据的读取权限。PSD2 已经区分了 AIS（读取）和 PIS（写入），两者都有证书负担，但风险画像天差地别 —— 经你同意的只读余额与交易记录，和发起支付完全不同。然而两者都挡在同一堵 eIDAS 墙后。
几种可行的 agent 友好路径已在边缘浮现：1) 沙箱优先、免证书 —— 许多银行开发者门户和聚合器沙箱只需 API 密钥就能暴露测试数据，MCP 服务器可以直接发布并开发；2) AISP-lite / 托管 agent 授权 —— 由持 AISP 牌照的实体向 agent 进程发放作用域受限、绑定用户同意的只读令牌，agent 自身不持有证书；3) 免证书生产读取层 —— 用 API 密钥认证提供经同意的读取访问，证书负担由 API 提供方吸收。这正是作者通过 open-banking.io 构建的方向。
代码层面，一个 MCP 的 list_transactions 工具定义和处理器很简单：只需要 API 密钥和用户同意，无需 mTLS 或 eIDAS。难点在上游：同意流、银行连接器、让集成者跳过 eIDAS 的监管吸收层。
结论：你的 agent 能读 GitHub 但读不了银行流水，不是集成缺失，而是监管设计选择 —— 证书税。随着 MCP 生态吞噬其他 API 表面，银行将成为明显的孤岛，除非我们构建不需要每个集成者都成为金融机构的读取层。免证书、经同意、只读优先的访问是解锁点。
#开发者 #工具 #MCP #PSD2 #eIDAS #OpenBanking #APISecurity #Aggregators #AISP #PISP
@DevToolboxHub