自己动手的说法
“不就是在一个银行聚合器 API 上套一层 MCP 吗，能有多难？”这个直觉是对的。答案是：从概念上讲不算难，但在你的 agent 能可靠地回答“这个月我在吃饭上花了多少钱？”而不撒谎、不崩溃、不泄漏别人的数据之前，有 8 个生产级别的部分你必须做对。下面逐一说明。
真实的工作量长什么样
我们过一遍 BankBridge 在每一次 agent 查询时实际做的事，这就是你在自己动手版本里要一个个实现的东西。
认证：bearer + OAuth + PKCE + DCR
个人单用户场景，用一个静态的 bearer token 就够了。但如果是一个每个终端用户都要连接自己银行的消费级应用，你就需要 OAuth 2.1，配上动态客户端注册（RFC 7591）和 PKCE。这意味着：一个注册端点、一个授权端点、一个令牌端点、令牌轮换、刷新令牌的处理，以及 MCP 规范要求的两个 /.well-known/ 路径下的发现元数据。哦对了，agent 客户端（Claude.ai、Perplexity、VS Code Copilot）在支持哪些授权类型上各有各的小怪癖。
实时抓取 + 错误分类
幼稚的做法是把银行数据缓存起来让工具调用更快。这是一场关于隐私和准确性的灾难在等你，过期的余额、过期的交易列表、不必要的 PII 堆在你的服务器上。正确的做法是每次查询都实时抓取。
实时抓取意味着每一次调用都必须把上游错误分类到至少四个桶里：
- 需要重新认证，银行需要重新登录（通常每季度一次）。非致命；其他连接仍然会返回数据。返回一个结构化的警告，附带重新认证的 URL。
- 标记为死亡，连接被永久性破坏了。标记给夜间对账的定时任务；从其他银行照常返回干净的结果。
- 重试，上游临时故障。指数退避（我们做 3 次重试，200ms → 600ms → 1800ms），之后再把错误抛出。
- 静默跳过，N 家银行中的某一家单次调用超时。汇入 warnings 数组，不作为错误抛出。
再加上一个超时上限（我们在 HTTP 客户端层面用 15 秒，单次工具调用用 7 秒），这样一家卡死的银行就没法卡住一次 agent 工具调用。
计费 + 取消安全
每一家连上的银行都会给你产生聚合器费用，所以你需要按银行计价。Stripe 订阅的 quantity = 银行数量，添加时按比例计费（在计费周期中间），移除时按整周期结算（这样才不会撞上 Stripe 的 $0.50 最低收费下限）。
最难的部分是取消泄漏：当用户取消时，每一个银行连接条目都必须被移除，否则你会继续被上游聚合器扣钱。我们的六层防御：webhook 处理器、同步时校验、MCP 时校验、夜间对账定时任务、支付失败重试路径，以及每次移除的审计日志。任何一层都能覆盖大多数情况；六层加在一起保证零泄漏。
29 个宿主的兼容矩阵
每一个说 MCP 的宿主都有自己的安装流程、自己的深链接方案（Cursor、VS Code、LM Studio、Warp）、自己的 OAuth 边界情况（Claude.ai、Perplexity），以及自己的默认超时时间。你需要为每个宿主维护一个文档页面，把用户的密钥预填到代码片段里，并在宿主更新它们的配置 schema 时（他们每隔几个月就会更新一次）保持代码片段跟得上。
我们今天已经有 29 个宿主集成。哪怕你只在意 Claude 和 ChatGPT，这两家加起来也已经是七个产品（Code、Desktop、web、Cowork、ChatGPT、Apps SDK、Enterprise），对应七种安装流程。
成本账
聚合器接入本身，Transactions 是 $0.30–$0.60/家银行每月，Investments 是 $1–$2/家银行每月。单用户部署的主机成本大概 $5/mo。你会花一个工程师的周末在 MCP 服务器骨架上，再花一个周末在 OAuth 上。之后每一两个月，你还要花一天时间修宿主兼容性、升级聚合器 SDK 或者补一个实时抓取的边界情况。
就算你把自己的工程时间估到 $75/小时，跟 BankBridge 的 $5/mo 的盈亏平衡点大概落在“每月一小时维护”附近。你是不会守得住这个数的。
什么时候自建才真的有意义
- 你需要一个 BankBridge 不支持的功能（资金流转、我们聚合器名单里没有的银行、自定义的数据分类）。
- 你在做一个和 BankBridge 竞争的消费级产品，这 $5/mo 会是你自己的利润。
- 你有严格的合规要求（HIPAA，为某个具体客户拿的 SOC 2 Type II），必须端到端拥有基础设施。
- 你就是真心喜欢维护这一类底层管道。这也没什么不好。
对其他所有人，独立开发者、独立创始人、个人财务爱好者、小团队运维搭起来的场景，这笔账和这段时间都不站在你这一边。付这 $5 吧。