在发票报销场景中，AI 最容易展示的能力是 OCR：上传一张发票图片，几秒钟后识别出发票号码、开票日期和金额。但对企业来说，识别只是材料进入系统的第一步。发票是否真实、是否已经报销过、抬头是否符合要求、当前人员能否报销这类费用、金额是否超过标准，这些问题都需要在正式发起报销流程前处理。

我们在云程智能体开发平台中搭建了“发票报销助手”。员工上传发票后，系统会完成票据信息提取、发票验真、重复报销检查和企业制度审核；符合当前规则的票据会写入报销业务模块，并自动发起后续流程。

下面结合这项业务，介绍智能体平台如何把模型、Agent、知识库、Skill、MCP、工作流和企业业务系统组织到同一条办理流程中。

业务流程：报销审核包含哪些环节

当前流程将报销前的检查分成六个环节：

1. 根据当前登录账号获取报销业务模块的访问身份；
2. 识别发票图片，输出统一的结构化字段；
3. 调用发票查验服务，确认发票真实性；
4. 查询报销业务模块，检查同一发票号码是否已经报销；
5. 结合报销人、角色和企业制度进行合规审核；
6. 低风险票据写入报销业务模块，并发起报销流程。

这条流程中，模型负责处理图片和理解制度，工具负责查询与写入业务系统，工作流负责确定执行顺序和异常分支。每项能力都有明确职责，某个环节不符合要求时，流程会在对应节点结束，并向用户说明原因。

下文按业务作用将相关环节合并归纳为四个关键步骤进行说明。

第一步：识别发票并生成结构化数据

用户上传发票后，工作流把图片交给“发票 OCR + 格式化 Agent”。这个 Agent 不负责判断能否报销，只做两件事：读取票面内容，并按照固定格式输出字段。

应用提取的主要信息包括发票类型、发票号码、开票日期、购买方、销售方、项目名称、费用类别、不含税金额、税额和价税合计。对于图片模糊或无法确认的内容，Agent 不进行猜测，而是将字段标记为空，同时写入 uncertain_fields，交给后续环节处理。

这里采用结构化输出，是因为后面的发票验真、重复检查和数据写入都需要准确取用某个字段。自然语言可以方便人阅读，却不适合作为系统接口的稳定输入。例如，“总金额是 27.10 元”在文字中很清楚，但后续接口真正需要的是 total_amount: 27.10。

这个设计也保留了职责边界。OCR Agent 只负责“看到了什么”，不在识别阶段同时判断“能不能报销”，避免票面识别和企业规则混在一个提示词中。

第二步：检查发票真实性和重复报销

票面信息提取完成后，工作流从结构化结果中取出发票号码、开票日期和金额，调用钉钉提供的发票查验 MCP 服务。MCP 在这里承担的是外部专业能力接入：智能体平台不需要自行实现发票查验，只需要按照工具定义传入参数，并读取查验结果。

真实性检查通过后，工作流还会调用报销业务模块的接口，根据发票号码查询现有报销数据。如果系统中已经存在相同号码，流程停止，并提示“该发票不可用，系统中已存在报销记录”。

验真和查重解决的是两个不同问题。验真确认票据本身是否有效，查重判断它是否已经进入企业内部流程。企业在设计类似应用时，不能因为接入了外部验票接口，就忽略内部业务数据中的重复使用问题。

第三步：根据人员身份和企业制度审核

发票真实且未重复报销后，流程进入合规审核。工作流会把当前报销人的姓名、角色和 OCR 结构化数据交给“报销合规审核 Agent”，由它检索企业报销审核制度知识库，并调用对应 Skill 形成审核意见。

应用中配置的企业规则包括：购买方可以是公司抬头，也可以是报销人本人；普通员工和一般角色的金额上限为 500 元，公司领导的金额上限为 5000 元；公司领导可以报销餐饮，普通员工和一般角色的餐饮发票需要转人工复核。不同企业的财务制度并不相同，金额和费用范围应当根据本企业制度配置。

本次上传的餐饮发票购买方为报销人本人，金额为 27.10 元。当购买方与当前登录用户一致、用户角色为公司领导时，系统可以确认个人抬头归属，并匹配“公司领导允许报销餐饮、金额不超过 5000 元”的规则。换成普通员工账号，同一张票据会得到不同的审核结果，这也是身份信息参与业务判断的实际意义。

合规 Agent 会输出命中的制度规则、字段完整性、风险原因、需要补充的材料和建议处理结果。工作流随后将结果归纳为低、中、高三个风险等级，只有低风险分支继续自动办理，其他情况会停止流程并显示审核意见，交由财务人员处理。

第四步：写入报销业务模块并发起流程

通过前面检查的低风险票据，会由工作流调用报销业务模块的 HTTP API。系统先写入票据表单，取得表单记录 ID，再调用流程接口发起报销流程并自动完成第一步。成功后，发票数据和流程实例都可以在报销业务模块中查询。

这个环节说明了智能体平台与业务系统的关系。云程智能体开发平台负责处理 AI 能力、规则判断和流程编排，报销业务模块继续承担表单、业务数据和审批流程。企业不必为了增加 AI 能力而推翻原有系统，可以通过 Tool、MCP 或标准 API，把 AI 处理结果送入已经在使用的业务系统。

身份衔接同样是这条链路的一部分。应用根据智能体平台的当前登录账号获取报销业务模块的访问凭证，因此两个系统需要完成用户同步。最终写入记录和发起流程时，业务系统仍然知道是谁提交了这张发票，而不是以一个无法追溯的公共账号代办。

平台能力：一个场景中使用了哪些组件

从配置角度看，这个应用并不是由一个大模型从头处理到尾，而是使用了多种平台能力：

平台能力	在本应用中的作用
工作流	固定办理顺序，控制成功、重复、验真失败和风险分支
OCR Agent	识别发票图片并输出统一字段
合规审核 Agent	结合人员身份、票据数据和企业制度生成审核意见
知识库	保存抬头、角色、费用类型、金额和日期等报销规则
Skill	约束合规审核步骤、风险等级和输出内容
MCP	接入外部发票查验服务
HTTP Tool	获取业务系统身份、查询重复票据、写入数据并发起流程
运行追踪	查看每个节点的输入、输出和分支结果

这种组合方式比“让模型自己决定所有事情”多了一些配置，但业务边界更清楚。OCR 结果有问题，可以检查识别节点；验真失败，可以查看 MCP 返回；制度判断不合适，可以调整知识库和 Skill；写入失败，则检查报销业务接口。每一类问题都有相对明确的定位范围。

从一张发票进入报销流程的过程可以看到，企业智能体应用的价值并不只在模型识别得有多快，还在于能否读取当前用户身份、执行企业规则、连接已有系统，并把每一步组织成可检查、可调整的业务流程。这也是云程智能体开发平台希望解决的问题。

---

云程智能体开发平台已提供在线体验环境，欢迎体验发票报销助手等应用。

体验地址：http://www.yunchengxc.com