构建可靠财务Agent：从最小任务集到人工审批的必要工程化

Show HN 上每隔一段时间就会出现 “Agents that run your finances” 这类项目。光看标题很兴奋：让 AI 代理接管你的财务，自动记账、自动分类、自动提醒，甚至自动把钱安排得明明白白。但我把这类项目拆开看之后，结论通常比较保守：它能解决的真实问题不是“让 Agent 替你赚钱”，而是把账单整理、支出分类、预算追踪、缴费提醒这些重复劳动接过去。

如果你正好在考虑自己做一套个人或小团队的“财务 Agent”，这篇文章值得看完。我不打算贴一个完整的成品工程，因为我手上也没有官方源码，更不打算编一个“别人家的仓库”来误导你。我会按真正落地的顺序讲清楚三件事：第一，哪些财务任务适合交给 Agent；第二，一个最小可运行版本应该怎么搭；第三，为什么“能跑通”和“能放心用”之间有非常长的一段路。

1. 财务 Agent 真正值钱的地方，是替代重复账务而不是替你投资

1.1 把“记账、分类、汇总、提醒”当成最小任务集

先给这类项目定个位。所谓管钱，真正的高频场景往往不神秘：每个月把信用卡账单、工资卡流水、报销单、发票台账整理清楚，把一笔笔消费按餐饮、交通、居住、购物分类，算一下这个月预算还剩多少，再提醒哪张账单快到期。一个人或者一个小团队在这些事上面花的时间，远比想象中多。

这些任务具备一个共同特点：规则相对固定、数据量大、单次判断不难，但反复做很烦。这正是 Agent 能切入的地方。

一个最简单的财务 Agent，最小任务集可以是：

• 读取导入的账单或交易记录。
• 对每一笔交易给出支出分类。
• 按月份、账户、分类生成汇总。
• 对比预算并输出超标提醒。
• 把原始记录和结果整理成一份可检查的报告。

每一步都不需要 Agent 做太惊险的判断。真正的难点是让每一笔账都稳定、可重复、可解释地处理完。

另外我建议一开始不要直接做“自动缴费”“自动转账”“自动申购”这类任务。原因后面会详细说，核心就一句话：财务场景里，一次错误执行的代价，远远大于一次慢一点的人工确认。

1.2 为什么 Demo 很容易，长期稳定很难

Show HN 上的项目往往看起来跑得很顺，因为演示只覆盖了很干净的数据。比如几千行账单，字段统一，没有乱码，没有重复记录，没有商户改名，也没有退款和调账。

真实财务数据完全不是这样。同一个商户可能有全名、简称、英文名、收款方备注；一笔原路退款可能和原消费不是同一天；负数金额不一定代表收入，可能是退款、手续费调整或押金退回；日期格式、货币单位、千分位分隔符也可能五花八门。我见过很多财务自动化项目死在第一步，因为光是把真实账单清洗到模型能读的状态，就要做大量规则处理。

所以，做这类 Agent，先别想着模型能力不够，先确认数据处理层能不能扛住脏数据。一个把规则、清洗、校验做好，再用模型做分类和建议的方案，往往比“把整张表直接丢给大模型”更稳定。

2. 开工前先划边界：只读、低危任务自动，高危操作留人工

2.1 可以自动化的任务范围

我在设计这类系统时，会把任务按“读取数据、生成结果、修改状态”分三档。只有第一档和第二档可以放开，第三档要卡得很死。

可以自动化的任务包括：

• 导入银行或支付平台导出的账单文件。
• 清洗重复字段，识别缺失金额、异常日期。
• 对支出进行候选分类，并给出分类理由。
• 生成月度开销汇总和趋势变化。
• 按预算线输出“哪些分类即将超支”的提醒。
• 把处理结果打包成 CSV 或报告文件。

这些任务有一个共性：它们不直接改变资金状态，也不向外网发起资金操作。就算分类结果错了，最坏的情况是报告需要重跑，不会造成资金损失。

2.2 无论 Agent 多聪明都不该自动执行的操作

下面这些操作，我建议放进“永远人工确认”清单：

• 发起转账、付款、还款。
• 绑定或解绑银行卡、支付账户。
• 修改账户联系人、默认扣款渠道。
• 确认可疑交易或提交争议。
• 同意任何形式的贷款、分期或授权协议。
• 删除或覆盖历史账目。

有人会觉得，既然模型已经能读懂账单，为什么不能自动判断某笔缴费是否扣款？因为在这类场景里，模型面对的不是一个“文本预测问题”，而是一个有状态、有后果的外部操作。一次误判可能导致重复扣款、渠道选错、授权泄露。更麻烦的是，财务系统通常没有“跑错了删掉重来”这个选项，所有操作都会留痕。

所以，不管底层模型多强，我都建议把外部操作隔离在 Agent 的决策链路之外。Agent 可以给人类操作员生成一张“建议执行清单”，但执行前必须由人点确认。

2.3 数据接入用“只读导出”而不是主账号授权

很多人做财务 Agent 时，第一反应是接银行开放 API，让 Agent 直接读取账户流水。这个想法本身没问题，但要注意授权范围和权限模型。

在国内环境下，银行和支付平台开放接口的申请门槛、可用范围、文档成熟度差别很大。如果只是自己记账，我更建议先把账单下载成 CSV、Excel 或 OFX 这类开放格式，再交给 Agent 处理。这样有几个好处：数据在本地可控，不会有接口鉴权过期的问题，也不会因为测试代码误调用了某个写接口。

如果确实要接 API，至少要满足三个条件：

• 使用单独的只读应用凭证，不借用个人主账号。
• 权限范围只开到“交易记录查询”，不开转账、付款等写权限。
• 密钥存在本地加密存储或系统钥匙串，不写进配置文件、日志和代码仓库。

我自己做原型时，基本都会用“导出文件 + 本地 SQLite”起步，先把主链路跑通，再考虑要不要接更复杂的实时接口。

3. 最小可用账务 Agent：工具、编排、审批三层分开

3.1 先准备干净的数据样本和运行环境

动手之前，先准备一份不敏感的交易样本。数量不用多，三五十条就够。关键是要覆盖常见情况：正常消费、退款、转账、手续费、不同币种或账户、空备注、重复行。

建议把样本统一成下面这样的结构：

transaction_id,date,merchant,amount,currency,account,category,notes txn_0001,2025-01-01,某某便利店,-23.50,CNY,日常账户,, txn_0002,2025-01-02,某外卖平台,-32.00,CNY,日常账户,, txn_0003,2025-01-03,某公司工资,15000.00,CNY,工资账户,,

这里的transaction_id很重要，它是后续去重的唯一依据。如果没有唯一编号，也可以用“账户 + 日期 + 金额 + 商户”组合生成一个哈希值。注意，去重键不能只用商户和金额，否则两笔相同金额的消费会被误删。

运行环境按通用方式准备即可。Python 环境，装好 pandas、openpyxl、sqlite3 这类基础库。如果使用云端大模型，需要准备好对应 SDK 和 API Key；如果打算本地跑，要考虑显存、内存和模型大小。原始项目材料没有给出具体实现，所以我这里不写死任何具体依赖版本，建议落地时先确认基础环境能正常安装和运行。

3.2 工具层：把每次操作变成可调用的函数

Agent 能力稳定的关键，不在于一个巨大的提示词，而在于把操作拆成很小的“工具”。工具越单一，模型调用时越不会出错。

以账单分类任务为例，我一般会准备下面几个工具：

• list_transactions(page)：分页读取交易。
• categorize_transaction(transaction_id, candidate_category, reason)：给某个交易打候选分类。
• summarize_expense(category, start_date, end_date)：汇总某个分类或时间段的支出。
• check_budget(category, month)：对比预算，返回剩余额和超支比例。
• confirm_write(transaction_id)：把候选分类写入正式表，需要人工批准。

这里有一个核心原则：模型可以调用categorize_transaction，但只能写入“候选区”，不能直接落到正式表。正式表只能由人工确认后的程序去更新。

3.3 编排层：模型只负责选工具和生成摘要

Agent 的编排层可以理解成一个小循环：模型读取当前状态，决定调用哪个工具，把工具结果放回上下文，再决定下一步做什么。伪代码大致是这样：

# 伪代码，仅用于说明控制流 MAX_STEPS = 10 state = {"transactions": [], "draft": [], "pending_confirm": []} for step in range(MAX_STEPS): action = llm.select_action( tools=tools, state=state, task="请处理本月账单并分类" ) if action.type == "call_tool": result = execute_tool(action.tool_name, action.arguments) state[action.tool_name] = result elif action.type == "generate_report": print("生成报告...") break elif action.type == "ask_human": print("等待人工确认...") break else: break

这里每一个工具都要有清晰的描述和参数类型，否则模型很容易把日期格式、金额单位传错。工具结果要直接、短小。如果一次返回五百条记录，模型的上下文会很快被撑爆。所以工具设计里我会强制分页，模型必须分批读取，不要让单个工具返回全量数据。

另外要给 Agent 设置“最大步数”。财务任务不需要一个能无限推理的 Agent。正常情况下，读取、分类、汇总、生成报告，几步内就该结束。如果超过步数还停不下来，大概率是数据里有异常或工具设计有问题，而不是模型不够聪明。

3.4 审批层：写入之前必须停在草稿区

审批层是财务 Agent 和普通聊天助手最不一样的地方。普通 Agent 可以直接回复文字；财务 Agent 涉及状态修改时，必须形成“草稿—确认—执行”的链路。

我习惯把每一笔建议写成一行待确认记录：

{ "transaction_id": "txn_0001", "suggested_category": "餐饮", "confidence": 0.82, "reason": "商户名称包含餐饮字号，金额接近日常工作餐水平", "human_status": "pending" }

只有当你看到这份记录，点了批准，程序才会把suggested_category写入正式库。模型可以犯错，但只要错误停留在草稿区，就不会污染正式账本，也不会影响后续的统计结果。

注意：如果你发现 Agent 一直在“自信地”给出分类，但没有留下理由，那这个工具设计还不合格。没有理由的分类结果，在财务场景里无法审计。

4. 结果可信要靠三层校验，不能靠模型“说得像”

4.1 金额必须做勾稽校验，不允许模型自由生成数字

我见过很多 AI 记账演示，最后让模型直接输出一段总结，比如“本月总支出 28863 元”。这里隐藏一个风险：如果这个数字是模型在上下文中估算出来的，哪怕差几毛钱，整份报告都不能用。

更稳妥的做法是：所有汇总数字都由代码从结构化数据里计算，模型只负责解释这些数字，不负责生成数字。也就是说，模型可以说“本月交通支出比上月增长 15%”，但这个 15% 必须是程序根据两个明确数组算出来的，不能是模型凭感觉写的。

还需要做一个基础勾稽：把原始交易按账户加起来，验证借方合计和贷方合计是否等于账单期末余额变化。如果对不上，说明导入时可能有漏行、重复行或金额字段解析错误，这时候应该直接中断流程，而不是让模型继续生成报告。

4.2 分类要有理由和确认池，不硬猜

交易分类看起来简单，实际上有不少模糊场景。比如一笔在大型超市的消费，可能同时包含食品、日用品、宠物用品。这时候要求模型只给一个分类，很容易误导预算分析。

我建议在分类任务里加入一个“待确认”类别。当模型置信度偏低或商户信息不足时，不要把结果硬塞进某个分类，而是放到待确认池。后续可以通过规则补充或人工处理。判断标准可以这么设：

• 分类置信度高于阈值时，自动进入候选区。
• 低于阈值时，进入待确认池。
• 单个商户一周内多次出现但分类不一致时，进入规则审查。

阈值具体设多少，要看你自己的数据。常见做法是先跑一遍历史数据，观察分类置信度分布，再决定是 0.75、0.85 还是 0.9。不要照搬别处的参数。

4.3 每条输出都要能回溯到原始记录

财务 Agent 的输出一定要有“血缘”。所谓血缘，就是从原始交易行，到清洗后的中间表，到模型分类结果，再到汇总报告，每一步都能追回去。

我一般会给每笔交易保留这些字段：

• raw_line：原始 CSV 或 Excel 里的整行数据。
• normalized_json：清洗后的结构化数据。
• prompt_snapshot：模型当时看到的输入片段。
• tool_calls：模型调用的工具和参数。
• human_action：最终是否有人工确认，确认人是谁，确认时间是什么。

有了这些信息，哪怕半年后发现某笔分类错了，也能快速定位是清洗规则的问题、模型判断的问题，还是人工确认时看漏了。没有血缘，一旦出错，就只能全量重跑，而且很难解释为什么之前的结果会不一样。

5. 从单条账单到整月批量：工程化才是分水岭

5.1 先用一条样本验证主链路

不要一开始就把整年账单丢进去。我会先挑一笔最简单的，比如一笔标准餐饮消费，走完“读取—分类—生成报告—人工确认”的完整链路。

这一步要验证的是：

• 文件能不能正常读入。
• 金额字段是不是正确的数值类型。
• 分类工具能不能返回结果。
• 草稿能不能正常生成。
• 人工确认后，正式表有没有更新。

主链路通了之后，再逐渐增加样例。先加到三笔，再试一笔退款，再试一笔分类模糊的大超市订单。每加一种数据形态，都可能暴露出新的清洗或工具设计问题。

5.2 批量任务要盯四个点

单条任务跑通之后，批量处理听上去只是加个循环，但工程上需要额外注意四件事。

第一，日志要有任务编号。每跑一批账单，生成一个批次号，日志里记录batch_id, transaction_id, status, error_message, model_used, elapsed_ms。这样后面查问题才不会大海捞针。

第二，处理要幂等。同一笔交易被重复跑两次，结果应该完全一致，并且不会生成两条重复记录。幂等做不好，定时任务一重跑，账目就会翻倍。

第三，失败要单独处理。批量任务里某一笔数据格式不对，不应该让整个批次崩溃。程序要把失败原因写进错误表，继续处理后面的数据，等跑完之后统一检查。

第四，输出文件名不能覆盖。每次运行，输出文件都要带上批次号或时间戳，例如report_20250115_1530.csv。否则你很难区分哪份报告对应哪批数据，时间一长就会搞混。

5.3 定时任务和通知要克制

有人会把财务 Agent 做成每天定时跑的任务，自动汇总前一天的账目，再通过邮件或即时通讯推送提醒。这个想法合理，但要注意几点。

推送频率要低。每天给用户发十条模型生成的提醒，很快就会被忽略。更好的做法是：平时不打扰，只在出现异常、分类确认池积压、预算接近超支时发一条通知。

定时任务要保留“跳过”能力。比如某天账单文件没有更新，任务应该自动识别并跳过，而不是用旧数据重跑一遍生成一份误导报告。数据源没变时重复计算，看起来很勤劳，实际上没有新增价值。

如果定时任务里依赖模型生成摘要，还要格外注意模型输出的随机性。模型不是每次都把同样一句话换个说法那么简单，它可能在无意义的地方改变结论。定时任务里如果要强一致输出，建议先跑规则统计，再让模型基于统计结果做自然语言润色，不要让模型直接主导数值部分。

6. 成本、隐私和性能：别只看能不能跑通

6.1 云端模型与本地模型怎么选

财务数据天然敏感，选云端模型还是本地模型，不只是性能问题，更是隐私问题。

如果只是本地测试和学习，我建议先接云端模型，因为迭代速度快。如果要把真实财务数据长期跑起来，且不希望把账单明细送到外部接口，那就优先考虑本地模型。

有一点要提醒：本地模型性能不代表“一定能装进普通电脑”。它的正常运行需要同时满足模型显存或内存要求、依赖库兼容性、运行时稳定性三个条件。如果你的机器配置比较紧张，可以先把上下文长度缩短、批量数降低、少开并发，先验证准确率，再谈速度。

6.2 密钥、权限和敏感数据怎么处理

处理财务数据时，密钥管理不能偷懒。API Key 不要写在.py文件、.env文件直接放进项目仓库，也不要出现在日志打印里。常见做法是把密钥放到系统环境变量、密钥管理服务或系统钥匙串中。

程序运行时，如果有完整的账单原始文件，我建议：

• 原始文件放在受限目录，不让 Agent 随意写。
• 中间结果脱敏后再打印日志。
• 日志里不输出完整卡号、身份证号、手机号等敏感字段。
• 定期清理老批次文件和临时目录。

6.3 “能长期用”的判断标准

怎么判断自己这套财务 Agent 能不能长期用？我有一套简单的验收标准：

• 连续跑 1000 笔交易，不出现重复写入。
• 同一个月度数据连续跑两次，汇总结果一致。
• 给同一笔模糊交易跑三次，分类结果要么一致，要么明确进入待确认池，不会一会儿是餐饮，一会儿是购物。
• 断网、接口超时、文件损坏时，任务能记录失败并安全退出，不影响正式表。
• 每一天的运行日志都能告诉你：处理了多少条、成功多少、失败多少、失败原因是什么。

只要有一条不满足，我就不认为它达到了“Agent 托管财务”的水平。它更像是一个会说话的记账脚本，可以看，但不敢真托管。

7. 常见报错与排查顺序

7.1 分类不对先查输入，别急着换模型

遇到分类错误，第一个反应不应该是“这个模型不行，换个更强的”。更常见的原因是输入数据本身有问题。

先看原始记录里的商户名是否被截断，备注是否为空，金额单位是否是小数分。再看清洗层有没有把退款、手续费误当成正常消费。最后才看提示词里分类定义是否清楚。

我遇到过这样的案例：某笔订单在账单里显示为负数，模型直接归为“收入”。实际上那是原路退款。问题不在模型判断能力，而在于我没有在清洗层给负数金额打上“退款”标记。补一条规则之后，这个错误就消失了。

7.2 卡住和超时按日志、参数、资源顺序查

任务卡住是高频问题，但多数不是玄学。排查顺序可以固定为：先看日志，再看参数，再看资源。

日志能告诉你它到底卡在哪一步。如果是调用模型超时，可能是网络波动或单次请求太长。如果工具没有返回，可能是分页参数传错或者函数抛了异常但没被捕获。如果进程被系统杀掉，很可能是内存不足。

参数层面要检查MAX_STEPS、单次读取条数、超时时间、重试次数是不是设得太保守。不要一上来就允许五十步推理或者一次读一万条记录，这既浪费 token 也容易让模型上下文超限。

资源层面主要看内存和 CPU 有没有一直被占满。批量任务出现内存持续上涨时，优先怀疑是不是把全量数据都灌进了模型上下文，或者循环里没用分页导致环境变量越积越大。

7.3 失败重试的最终检查

最后说一个批量任务最容易忽略的地方：失败重试不是“重新跑一遍”那么简单。重新跑之前，要先确认上一轮有没有已经写入正式表的半截数据。

我会在每次写入前都做一次“按 transaction_id 查重”。正式表里如果已经存在这条记录，就直接跳过或更新，而不是新增。否则，一个断点让模型跑了一半，你重启任务，账目就会多出重复分类。

如果你准备长期维护这套系统，我更建议把“候选区、正式区、审计日志”三张表拆开。候选区放模型未确认结果，正式区放人工批准后的数据，审计日志记录每一次运行和操作。结构简单一点，但出错时能救命的，恰恰是这些基础设计。

踩过几轮之后，你可能会发现，真正让财务 Agent 可靠的，不是某个模型的推理能力，而是数据清洗、权限隔离、人工审批、幂等重试和审计这些看起来“不够 AI”的部分。Agent 负责提效率，人负责兜底，这套组合才更接近“能跑你的财务”而不是“玩你的财务”。