在发票报销场景中AI 最容易展示的能力是 OCR上传一张发票图片几秒钟后识别出发票号码、开票日期和金额。但对企业来说识别只是材料进入系统的第一步。发票是否真实、是否已经报销过、抬头是否符合要求、当前人员能否报销这类费用、金额是否超过标准这些问题都需要在正式发起报销流程前处理。我们在云程智能体开发平台中搭建了“发票报销助手”。员工上传发票后系统会完成票据信息提取、发票验真、重复报销检查和企业制度审核符合当前规则的票据会写入报销业务模块并自动发起后续流程。下面结合这项业务介绍智能体平台如何把模型、Agent、知识库、Skill、MCP、工作流和企业业务系统组织到同一条办理流程中。业务流程报销审核包含哪些环节当前流程将报销前的检查分成六个环节根据当前登录账号获取报销业务模块的访问身份识别发票图片输出统一的结构化字段调用发票查验服务确认发票真实性查询报销业务模块检查同一发票号码是否已经报销结合报销人、角色和企业制度进行合规审核低风险票据写入报销业务模块并发起报销流程。这条流程中模型负责处理图片和理解制度工具负责查询与写入业务系统工作流负责确定执行顺序和异常分支。每项能力都有明确职责某个环节不符合要求时流程会在对应节点结束并向用户说明原因。下文按业务作用将相关环节合并归纳为四个关键步骤进行说明。第一步识别发票并生成结构化数据用户上传发票后工作流把图片交给“发票 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
