四条路径，一分钟看完
每一个关于钱的 AI 问题都会撞上同一堵墙：模型看不到你的银行账户。Claude、ChatGPT、Cursor 以及其他工具，一旦拿到交易数据，分析都做得不错。把数据送到模型面前，才是整个问题所在。
实现的方式有四种。你可以把文件交给代理，让它通过你的网上银行操作浏览器，自己对接银行 API，或者把它指向一个替你做抓取工作的托管 MCP 服务器。
每一种在新鲜度、安全性和搭建时间上的取舍都不同。也没有哪一种在所有情况下都是错的，包括看起来最枯燥的第一种。
路径一：手动上传 CSV 和 PDF
最古老的方法仍然管用。从银行网站下载 CSV 或 PDF 对账单，丢进聊天窗口，然后开始提问。
这是我 1 月份的对账单。餐厅花了多少钱？哪些消费看起来像是订阅？
对于某个已结束账期的一次性问题，这样就够了。上一年的报税、某个月的争议、偶尔查看一个不常用的账户。数据不会再变了，所以过期与否无所谓。
作为长期习惯它就撑不住了。对账单一导出就已经过期，每家银行的导出格式都不一样，PDF 会把表格解析弄得一团糟，一整年的交易可能会超过模型的上下文窗口。你还会在 Downloads 文件夹里堆满带账号的文件。偶尔用用还行，每周用就很痛苦。
路径二：屏幕抓取和浏览器自动化
屏幕抓取的意思是，代理，或者代表它的某个服务，使用你真实的用户名和密码登录你的网上银行，读取屏幕上的内容。浏览器自动化代理让这看起来很简单：把凭证粘贴进去，让模型点来点去。
别这么做。你的网银密码是转移你的钱的万能钥匙，而这条路径把它交给了一个同样能点击转账按钮的软件。大多数银行的条款根本就禁止分享凭证，出了问题的话可能会把欺诈责任转到你头上。而且它总在失效：多因素认证提示、CAPTCHA 墙以及银行网站的任何一次改版，都会让自动化流程失效，直到有人发现并去修。
这是早期金融科技在 2010 年前后的做法，那时候还没有更好的选择。现在有了。
路径三：直接对接银行 API
越来越多的银行开放了官方 API，在美国被标准化为 FDX，在欧洲则由 PSD2 等开放银行规则强制要求。访问是令牌化、有作用域、可撤销的。你的密码永远不会离开银行。这确实是正确的基础，而且大多数现代金融应用底下的两条路径就是构建在它之上的。
问题在于谁能用。直接 API 访问是为公司设计的：开发者协议、安全审查，有时候每家银行的接入流程都要花几个月。如果你在三家机构开户，那就是三套要维护、各有怪癖的集成。聚合服务的存在就是为了解决这个问题。它们维护和银行的连接，让应用开发者不用自己操心，你用过的几乎所有金融应用都在它们之上。
对于一个只想让自己的代理回答关于钱的问题的普通人来说，自己走这条路意味着好几周的工作才能得到第一个有用的答案，而且之后你还得给自己的银行数据流当值班工程师。
路径四：托管的 MCP 服务器
MCP（Model Context Protocol）是让 AI 应用调用外部工具的开放标准。银行数据 MCP 服务器给你的代理提供一小组有类型的只读工具，而不是原始文件或一个浏览器会话。代理请求它需要的东西，拿到结构化数据，然后基于此进行推理。
BankBridge 就是我们的实现。你只需通过官方的银行连接层连接一次银行（你的凭证给的是你的银行，绝不会给我们，也不会给你的代理），从那以后你的代理就拥有 11 个工具：list_accounts、search_transactions、get_recurring_charges、get_monthly_cashflow、list_holdings 等等。每一次调用都会从银行实时抓取数据。我们的服务器上不做任何缓存，因此不必担心有你的财务副本被存下来。
我的支票账户现在余额多少？这个月有哪些重复扣款？
这个问题，在任何 MCP 宿主里针对实时数据得到回答，才是整件事的意义所在。它可以在 Claude Desktop、Claude Code、ChatGPT、Cursor、Gemini、Zed，以及我们已经记录过的另外二十多个应用里使用。搭建只要几分钟，认证用 bearer key 或 OAuth 2.1，每连接一家银行 $5/mo。随时取消。
并排对比：新鲜度、安全性、搭建时间、易损性
新鲜度。上传件一导出就过期。抓取在没坏的时候是实时的。直接 API 和 MCP 服务器在设计上就是实时的。BankBridge 在每次提问时都从银行取数，所以"我的余额是多少"意味着此刻，而不是你上次导出的时候。
安全性。上传相对安全，但对账单文件会堆在硬盘上。抓取是最糟糕的选项：完整凭证、完整写入权限、违反条款。直接 API 和托管 MCP 服务器使用令牌化、可撤销的只读访问。BankBridge 没有任何能转账的工具，所以一个糊涂的代理最糟能做的就是问出一个奇怪的问题，而不是发出一笔奇怪的转账。
搭建时间。上传前期零成本，之后每次都要花十分钟导出和清洗，永无止境。抓取要用一个下午搭起来，然后无限期地照看它。直接 API 如果自己做要花几周到几个月。托管 MCP 服务器每家银行只需要几分钟，一次搞定。
什么会坏。上传会因为格式怪癖和上下文长度限制而失效。抓取会因为多因素认证、CAPTCHA 和改版而失效。自研的 API 集成一旦银行改动就会坏，而这时候呼你机的是你自己。托管服务器大多数时候只在一个可以预料的地方会出问题：你改了网银密码之后，银行连接需要一次快速重新授权，两分钟就能修好。
你该选哪一种？
如果你只有一个问题，问的又是某个已结束的月份，那就把对账单上传上去问。一点也不丢人。我们把 BankBridge 和手动 CSV 导出正面比较过，结论并不是"永远别上传"。
别把你的网银密码交给任何代理。演示不行，一次也不行。
如果你在做金融科技产品并且有合规预算，那就直接对接银行 API，或者用它们下面的聚合层。它们就是为这种场景造的。
如果你只是一个想让已经在用的代理持续给出答案的普通人，托管 MCP 这条路才站得住脚。连接一次，然后想到什么就问什么，随时都行：
今年我的网费涨了吗？把 1 月以来 ISP 的每一笔扣款拉出来对比一下。