事情的起因很简单但说出来可能很多人都有共鸣。我们公司财务那边有个同事每个月月底都要处理大量的报销发票。各种类型都有——增值税专用发票、普通发票、电子发票格式五花八门。她之前的做法是逐张手动录入 Excel发票代码、号码、开票日期、购买方、销售方、金额……每一张都要对着看、对着敲一个月下来少说也要花两三天时间在这件事上。更麻烦的是手动录入难免出错金额敲错一位对账的时候就是一场噩梦。有一次她跟我抱怨说自己感觉像个人肉 OCR。我当时笑了但笑完之后觉得这个问题确实值得认真对待一下。OCR 识别发票这件事技术上早就不是难题难的是怎么把识别结果自动整理好、直接落到可用的表格里中间不要再多一道人工操作。于是我开始琢磨能不能搭一个工作流把上传发票 → OCR 识别 → 结构化提取 → 写入多维表格这条链路打通。说实话最开始我的第一反应是自己写脚本。调个 OCR 接口解析返回结果再调飞书的 API 写表格逻辑上不复杂。但问题是这条链路里有太多如果……那么……的分支——不同发票类型字段位置不一样识别置信度低的时候要怎么处理飞书写入失败了要不要重试——这些边界情况一旦认真处理起来代码量就上去了后续维护也是个负担。更关键的是财务同事完全不懂代码如果哪天流程需要调整她没办法自己改每次都得来找我这不是一个好的解法。所以我开始认真看 AI Agent 和可视化编排这个方向。Dify 是我最先试的产品体验确实不错界面干净上手快。Coze 也玩了一下生态丰富插件多。但我们团队有一个硬性要求数据不能出公司内网。发票上有供应商信息、金额、税号属于比较敏感的财务数据走公有云 SaaS 在合规层面说不过去。这两个平台在私有化部署这块对我们的场景支持得不够顺畅所以只能继续找别的路子。后来在一个开源社区的讨论帖里我注意到一个项目被反复提到讨论热度挺高。去看了一下是一个基于向量检索的 RAG 框架同时支持可视化工作流编排Apache 2.0 协议开源支持完整的私有化部署。节点化的编排方式每个处理步骤都是一个独立节点节点之间连线定义数据流向模板可以复用。我当时的感觉是这个思路跟我想要的很接近——逻辑可视、可复用、非开发人员也能看懂流程。这个项目就是 FastGPT。拉下来本地跑起来之后我开始搭发票识别这条工作流。整体体验用搭积木来形容确实比较贴切——把 OCR 节点、大模型提取节点、条件判断节点、飞书写入节点依次拖出来连上线配置好每个节点的输入输出参数一条链路就成型了。逻辑改起来也方便比如我后来想在识别结果里加一个发票类型字段直接在提取节点的 prompt 里加一行描述重新测试一下就好不用动其他地方。当然也有让我头疼的地方说出来不怕丢人。节点一多画布上的连线就开始乱尤其是有分支条件的时候线交叉来交叉去看着有点眼花。另外如果要实现比较复杂的循环逻辑比如批量处理多张发票时的迭代控制有一定的学习门槛我自己摸索了一段时间才搞清楚怎么配置比较合理。这些不算致命问题但确实需要花时间适应。说回当时搭完之后的实际效果。财务同事现在的操作是打开对话框把发票图片或 PDF 批量上传进去等一会儿飞书多维表格里就自动多了对应的行发票代码、号码、日期、金额、购销双方信息全都填好了。她跟我说上个月月底的录入工作从两天缩到了半天不到。更重要的是她自己能看懂这个工作流在做什么如果哪个字段识别有问题她知道去哪里反馈、怎么描述问题沟通成本低了很多。后来我想了想这件事带给我的收获不只是发票录入变快了这一层。以前用代码实现一个类似的自动化流程改一次需求就要改代码、重新测试、重新部署整个周期拉得很长。现在用可视化工作流迭代速度快了不少很多调整当场就能改完测完。非开发的同事也能参与进来他们看着流程图就能提出这里应该加个判断或者这个步骤顺序不对需求沟通变得具体多了不再是对着一堆代码说反正你帮我实现一下。私有化部署这一点也让整个方案在公司内部推起来顺畅很多数据合规的问题不用反复解释。不过我也不想把可视化工作流说得太完美。它适合的是快速迭代、业务逻辑多变的场景对于那些性能要求极高、逻辑极度定制化的场景手写代码仍然是更可控的选择。工具本身有边界关键是看你的场景需要什么。我个人觉得未来这类工具会越来越往轻量级自动化和领域专用模板的方向走让更多非技术背景的人也能参与到 Agent 的搭建里来这个方向是有价值的。最后想问问大家你们在落地 RAG 或者 Agent 的时候遇到过哪些比较棘手的问题比如知识库召回率不稳定、多轮对话上下文丢失、大模型幻觉控制这些有没有什么实际踩过的坑或者解法欢迎评论区聊聊。