用Agent直连银行记账
Agent直连记账讨论升级，围绕安全风险、替代方案及半自动化流程展开。
1. 关键信息
- 技术栈：Trey 明确使用 codex (GPT-5.4) + chrome mcp，通过浏览器保存密码实现自动登录。
- Agent优势：相比古法编程，Agent 能自行处理银行界面变动和新账户增加，减少维护成本并沉淀 workflow。
- 替代方案：
- 消费邮件触发：通过处理银行消费通知邮件自动入账，安全性较好。
- PDF 提取：从 Statement PDF 自动生成条目，规避操纵浏览器的风险。
- 半手动 LLM 记账：利用自然语言描述消费，LLM 通过自定义 Skill 修改 Beancount 文件。
- 聚合平台：使用 Credit Karma (Intuit) 或 Monarch Money 等第三方工具查看所有卡片流水。
- 需求核定：记账核心动力在于数据本地化、完整财务复盘（存款、投资及消费）以及类似于日记的心理满足感。
2. 羊毛/优惠信息
- 无
3. 最新动态
- 用户 az8 提出先手动登录十余个个账户（含券商），再交由 Agent 提炼 Skill 进行后续操作，绕过 Fidelity FullView 改版后的不便。
4. 争议或不同意见
- 安全性担忧：多数用户（baifeifei, raymond_0817）对“信任大公司数据安全”持反对比意见，认为出事只是时间问题。
- 操作优雅性：打豆豆质疑网页模拟点击登录不够优雅；hosiet 认为操纵银行前端行为过于“惊悚”。
- 合规与成本：Zwillingsturme 指出 Chase 等银行对 API 获取数据收费，网页操作虽不优雅但对消费者最合规。
- 心态差异：Trey 持 YOLO (You Only Live Once) 心态，认为趋势不可逆，更在意最终结果而非登录过程。
5. 行动建议
- 进阶方案：对于不愿完全放权的开发者，可尝试“邮件触发入账”或“Statement PDF 提取”平衡安全与自动化。
- 轻量选择：若仅需查阅流水，可直接使用 Credit Karma 的 Net Worth Transactions 页面。
- 本地化管理：追求数据隐私的用户可参考 Trey 的 Prompt 思路，结合 Beancount 样例，利用 Chrome MCP 实现本地化记账流程。
- 风险预控：建议先手动登录账户，仅让 Agent 处理数据提炼，避免将登录凭证完全托管。
一直有用beancount记账的习惯，因为卡太多太散，每个把月都要花半天时间登陆各个银行官网，下载账单，导入，人工对账。总是畅想要是有自动化记账就好了。
最近看到agent（Claude Code，codex等）的发展感觉时机已经成熟，直接把账本和浏览器交给agent。初试之下的效果惊为天人，一个小时就帮我搞定了过去几个月的账单。细看之下虽然还有一些错误，但都是可以纠正的，主要整个流程都可以是自动化的，省了大量心神。
安全方面：个人对大公司数据安全还是比较放心的，但比较吓人的是这玩意儿不老老实实一个一个月点击链接下载账单，滑动界面查看更多数据，主动要去探索开发银行网站的api用法。总不会因为这个被某些g点高的银行干死吧。。
感觉还是太费token，最好是做完一次之后能写成一个不用agent参与的script，要不记一次帐几块钱
另外我记得有人提过Plaid的API刷新也是要收费的，这也是很多人自己记账最大的blocker，不知道有没有试过的朋友来讲讲
吃螃蟹的人果然是有的
【引用自 Trey】:
一个一个月点击链接下载账单，滑动界面查看更多数据，
哪家能用啊
我试着browse with gemini说超过5个financial transaction就不做，我都没法说服他下个账单不是financial transaction
所以我下载还在自己/script来，import大部分本来也有script，偶尔没有的或者不好写的就不写script了写个skill
Chrome MCP没这些有的没的
每消费一笔记一下其实挺快的
你就不怕哪天agent被prompt inject好奇心强把你钱转走了？
我也试过，token烧太多了哈哈。后来让agent帮我写了个script，现在每次直接跑，不过有几个银行的账单格式比较奇葩，还是要手动改一下。
不怕，只怕它不干活
还好，现在就是烧token的时代
一直在观望记账，一直懒得动。
想问下这个流程中使用LLM处理而不能使用传统确定性程序的难点在哪里？
naive的想法是，直接拿每次消费的通知/月度账单（发送到邮箱或者截屏之类的方法，不让它有权限进入可操作的程序）喂到程序里，处理下io格式或者本地用个极小的模型提取有用信息，后续就是纯自动化处理脚本就可以了吧。
我以前是这样做的，但这取决于你想花多少时间维护这个，银行界面改变的速度，新账户增加的频率
实际上agent自己也会留下一些它觉得可以长期使用的workflow
我觉得趋势是不可逆的，最终大部分事情都会代理出去，现在是个临界点了
codex (GPT-5.4) + chrome mcp
伸手党求prompt
这个没有技术含量，在repo里面有过去十年自己维护的beancount样例，只需要说”add xxx bank data from x to y using chrome mcp (passwords saved in the browser)”。
【引用自 Trey】:
个人对大公司数据安全还是比较放心的
感觉出事只是时间问题
【引用自 Trey】:
取决于你想花多少时间维护这个，银行界面改变的速度，新账户增加的频率
确实没考虑过这个因素，放弃古法编程，拥抱LLM
我现在的自动是信用卡触发消费，收到邮件，处理邮件入账.
安全性和省心方面还行
【引用自 Trey】:
安全方面：个人对大公司数据安全还是比较放心的
真的不放心
消费触发邮件每个银行都能设置吗
应该都能吧
【引用自 Trey】:
记账
的需求是什么？
我用 Credit Karma，反正报税是 TurboTax 都是 Intuit 一家了把所有银行都链好。看所有卡的流水有个页面： https://www.creditkarma.com/networth/transactions
【引用自 Trey】:
最近看到agent（Claude Code，codex等）的发展感觉时机已经成熟，直接把账本和浏览器交给agent。初试之下的效果惊为天人，一个小时就帮我搞定了过去几个月的账单。
登陆怎么做的…网页模拟点击吗？感觉不够优雅。如果买第三方api又不太需要agent（动作不具备确定性）还不如自己用agent写个网站
自己搞一个plaid key连吗
chase带他说要向api获取数据的收费，作为消费者最合规的大概就是网页去点
感觉不如……从 statement pdf 自动生成消费条目。操纵银行网页前端，无论是有头还是无头浏览器都还是太惊悚了点。
我现在是半手动记账：每次有消费就用自然语言和 llm 描述消费场景/内容/金额/扣款渠道，llm 用（我自己写的）Skill 自动遵照格式修改 beancount 文件。相同的消费可以直接说一句“老样子”llm 可以自己推断然后记账，记完了人工扫一眼确认就行。
还是monarch省心吧
其实是个心态问题，任何事托付给任何人都有风险，YOLO
最优雅的是，我根本不在意它是怎么登录的，任务交给它一小时后只看结果
除了常规理财的需求，还有就是数据的本地化，看到几十个账号完整的消费存款投资情况，跟记日记差不多了
不光是连银行，还要连券商，自己事先登录过十来个账户，不需要Agent登录，然后剩下的事交给Agent去办，然后提炼成Skill。自从Fidelity的FullView改版后我就再不鸟他了。