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