太长不读：
一家央企科研机构把报销入口放进了钉钉。员工只需上传发票，后台 Agent 就会跨系统补齐员工、出差、审批和项目信息；AI 与规则引擎完成财务判断，低风险单据交给 RPA 写入集团系统，高风险和不确定单据转给财务人员。
这个项目真正值得学习的，不是 OCR，也不是所谓“多 Agent”。
而是 FDE 通过业务陪跑，把财务人员原本混在一起的工作拆成了四层：
找信息、做判断、控风险、执行操作。
然后把不同技术放到了合适的位置。
一、员工只是上传一张发票，后台为什么这么累？
站在报销员工的角度，流程似乎很简单：
text出差回来
→ 拿到发票
→ 提交报销
→ 等钱到账
但站在财务人员的角度，这张发票只是整个流程的入口。
他还需要判断：
-
• 这是差旅费、招待费，还是其他费用？ -
• 员工有没有对应的出差申请？ -
• 申请是否已经审批通过？ -
• 员工属于哪个部门？ -
• 费用应该归属哪个科研项目？ -
• 应该进入哪个会计科目？ -
• 金额、票据和业务是否符合报销规则？ -
• 有没有重复报销或其他异常？
这些答案往往不在一张发票上，也不在同一个系统里。
财务人员需要在人员、审批、项目和历史业务系统之间来回切换，把零散信息拼成一份完整上下文，然后凭专业经验作出判断。
判断完还没有结束。
他还要登录集团财务网站，创建单据、选择项目、填写科目、逐项录入，最后提交。
所以原来的流程可以压缩成一句话：
前半段靠人找信息、做判断，后半段靠人搬数据、点系统。
业务量一增长，通常只能继续增加财务人力。
二、这不是一个“发票 OCR 项目”
如果只从技术功能看，团队很容易把需求理解成：
把发票识别出来，自动填一下报销表。
这当然能节省一点录入时间，但没有触及真正的瓶颈。
发票 OCR 只能告诉系统：
text开票方是谁
金额是多少
日期是什么
发票号码是什么
它无法单独回答：
text这笔费用为什么发生？
对应哪次出差？
属于哪个项目？
应该进入哪个科目？
能不能自动放行？
公开案例里的 FDE 没有让财务部门坐在会议室里写一份《AI 财务需求说明书》，而是采用了更笨、也更有效的方法：业务陪跑。
他跟着财务人员实际处理一笔业务，观察对方：
-
• 打开了哪些系统； -
• 为什么要查这条信息； -
• 如何判断项目归属； -
• 什么情况下会去问其他同事； -
• 哪些动作只是机械录入； -
• 哪些判断来自多年经验。
很多业务人员可以熟练完成工作，却很难一次性把全部规则说清楚。
所以真正的需求发现，往往不发生在会议室，而发生在业务人员处理真实任务的屏幕旁边。
三、FDE 把财务流程拆成了四层
跟完整个流程以后，项目才逐渐形成清晰的能力分层。
第一层：信息获取
系统不能只识别发票，还需要主动获得：
text发票信息
+ 员工身份
+ 出差申请
+ 审批记录
+ 所属部门
+ 所属项目
+ 历史业务信息
这正是 Agent 比普通表单自动化多出来的价值。
它不是等待用户把所有字段填完整，而是根据当前任务判断自己还缺什么，再到相应的数据源补齐上下文。
第二层：财务判断
上下文齐全以后，系统才开始判断：
-
• 费用类型； -
• 会计科目； -
• 项目归属； -
• 报销规则是否满足； -
• 是否存在异常。
这里不能简单地把整套工作扔给一个大模型。
金额阈值、发票类型、审批状态这类规则应该由确定性程序处理；复杂业务描述和模糊归类，才可能需要模型参与。
更合理的组合应该是：
text明确规则
→ 规则引擎
模糊语义判断
→ AI
高风险或不确定判断
→ 人工复核
第三层：风险分流
案例中还设置了执行判断、监督和风险发现等不同 AI 角色。
它想解决的问题是：
哪些单据可以继续自动处理，哪些必须停下来让财务人员看？
确定、低风险的单据进入自动流程；高风险、信息矛盾或置信度不足的单据进入人工队列。
于是财务人员的工作从：
逐张处理所有单据
变成：
重点处理异常和不确定单据
不过，“多 Agent 相互监督”听起来很先进，并不天然意味着更安全。
如果几个 Agent 使用相似模型、相似提示词和相同错误数据，它们完全可能一起犯同一种错。真正决定风险控制效果的，仍然是评测集、规则边界、置信度设计和人工升级机制。
第四层：系统执行
完成判断以后，还要把结果写进集团财务系统。
老系统通常不会因为 AI 项目重新建设，也未必有完整 API。因此项目把 RPA 当成“手”：
text登录集团财务系统
→ 创建单据
→ 填写字段
→ 提交或等待确认
AI 负责理解和判断，RPA 负责点击和录入。
这是两个完全不同的问题，不能指望一个大模型全部解决。
四、TO BE：员工只需要在钉钉上传发票
最终流程大致变成：
text员工在钉钉发起报销
↓
上传发票
↓
OCR 识别票据
↓
Agent 跨系统获取上下文
↓
AI + 规则引擎判断
↓
风险识别与分流
↙ ↘
低风险确定 高风险/不确定
↓ ↓
RPA 自动执行 财务人工复核
↓ ↓
集团财务系统
员工不需要理解后面的财务处理细节，也不需要再开一个新的“AI 财务平台”。
他原来使用钉钉，现在继续使用钉钉；集团原来的财务系统也继续保留。
AI 被放在两个既有系统之间，接管原来依赖人工完成的信息搬运、部分判断和机械执行。
这是一种很典型的 FDE 思路：
不要求企业先推翻原系统，而是在现有流程中插入一层新的智能能力。
五、为什么这个项目很像真正的 Agent？
现在很多所谓 Agent，本质上仍然只是聊天机器人：用户问一句，它回答一句。
项目 7 不一样。
它需要为了完成一个业务目标，自主组织多种能力：
textOCR
→ 看懂发票
Agent Orchestrator
→ 判断下一步需要什么信息
系统连接
→ 获取人员、审批和项目数据
规则 + AI
→ 完成财务判断
风险层
→ 决定自动执行还是转人工
RPA
→ 操作旧财务系统
它的输出不是一段建议，而是一笔业务状态的变化。
因此这里的 Agent 必须同时处理权限、审计、幂等、失败重试和人工接管。只要系统会真正创建或提交财务单据，工程要求就会比普通问答高出一个量级。
六、从“破冰项目”扩展到 10 个场景
这位 FDE 把第一个场景称为“破冰项目”。
意思是：不要一上来就宣布改造整个财务部门，而是先选择一个业务确实痛、技术边界相对清晰、短期能看到结果的场景。
项目跑通以后，业务人员看到了真实的时间节省，才会主动提出：
“我们另外这个流程，是不是也可以这样做？”
根据公开案例描述，这套方法后来扩展到了大约 10 个 AI 财务相关场景。
案例还提到，某些完整财务业务的处理周期原来可能需要半个月到一个月，改造后缩短到约 1～2 天。
这个数字需要谨慎理解：
它描述的是相关财务业务的完整批处理或流程周期，不代表过去处理一张发票需要一个月。
但它仍然说明，项目优化的不是一次模型响应时间，而是端到端业务交付时间。
七、这个项目最容易被忽略的四个风险
1. 数据到底怎么拿到？
人员、审批、项目和历史业务信息分布在不同系统里。
有没有 API？能不能读数据库？是否只能用 RPA？处理后的结果能否写回？这些集成问题很可能比模型本身更耗时间。
2. 哪些判断允许交给 AI？
确定性规则不应该被包装成模型推理。
真正需要建立的是一张决策表：哪些字段可以自动判断，哪些需要双重校验，哪些情况必须人工审批。
3. 怎样证明监督机制真的有效？
不能因为设置了三个 Agent，就假设错误率自然降低。
需要建立真实历史单据测试集，分别评估科目判断、项目匹配、合规识别、异常召回和错误自动放行率。
在财务场景里，尤其要关注：
本来应该拦截的单据，有多少被系统错误放行。
4. 私有化成本是否值得？
央国企财务数据通常不能直接发送给公共模型。
案例提到了数据不出域、私有模型、算力基础设施，以及两百万元量级一体机投入等现实约束。
因此不能只算节省了多少人工时间，还要把硬件、模型、集成、运维、安全和持续评测成本一起放进 ROI。
八、这个案例给 FDE 的五条方法
第一，跟着业务做一遍，而不是只听业务描述。
隐性判断和系统切换往往只有在真实操作中才会暴露。
第二，先拆任务，再选技术。
找信息、做判断、控风险和录系统分别需要不同能力。
第三，把正常单和异常单分开。
自动化的目标不是消灭财务人员，而是让他们把精力放在真正需要专业判断的地方。
第四，保留现有入口和核心系统。
员工继续使用钉钉，财务结果继续进入集团系统，降低组织采用成本。
第五，先做一个破冰场景，再靠结果赢得扩展。
FDE 不需要用一张宏大的 AI 蓝图说服所有人。一个真正跑通的小闭环，通常比十场宣讲更有力量。
九、FDE 交付的不是机器人，而是新的分工方式
回头看，这个项目并不是简单地让机器替代财务人员。
它重新划分了工作：
text机器
→ 找资料、跑规则、做初步判断、重复录入
人
→ 处理异常、确认风险、维护规则、承担最终责任
真正的改变，是财务人员从“每张单据都亲手搬运一遍”，转向“设计规则并处理例外”。
所以项目 7 最值得记住的一句话是：
真正的企业 Agent 不是陪你聊天，而是能在明确权限和风险边界内，把信息获取、专业判断、人工升级和系统执行串成一条闭环。
下一篇，我们可以继续深挖项目 7 里最容易被包装、也最需要工程验证的一点：所谓“多 Agent 相互监督”，到底什么时候有用，什么时候只是让三个模型一起犯错。
关注「MarvinTalk / 码文说」，一起研究 AI 如何真正进入企业交付现场。