从9点到9点15：一个审批，救了一个早上的“等待”

先讲一个真实场景。

上午9点，我刚打开电脑，微信弹出一条消息。

财务小王：“李经理，我的报销单提交了，超期垫付了3000多，麻烦审批一下。”

我放下手里的紧急需求文档，打开钉钉工作台，点进“审批”应用，找到待办列表，往下划了好几页才翻到小王的单子。

点开一看：3000多块，出差和客户吃饭。抬头、金额、发票号……来回核对了五六分钟，终于点下了“通过”。

再回来看文档，刚才的灵感已经彻底断了。

这还只是一笔，而财务那边每天要处理几十上百笔。 后来他们引入了一款办公Agent，情况完全变了。

现在的流程是这样的：

9:10 小王在群里@财务Agent说：“报销昨天上海差旅，高铁票281，餐费85，超了标准15，已注明原因。”
9:11 Agent自动创建审批单，顺手校验发票真伪和预算余额，把超标的定性为“待上级复核”，直接推给我。
9:12 我收到卡片消息，点开一看，所有关键字段一目了然，点击“通过”。
9:12:10 小王收到消息：“报销单已通过，预计3个工作日内到账。”

从9点到9点12分，整个过程不到一刻钟，小王省了填单追人的功夫，我更没被打断过。多出来的时间，足够多写两页文档。

所以这篇就来聊聊：怎么在飞书/钉钉/企微上，做一个能听懂“我要报销”的Agent？

原理不清楚也没关系，我会和你一步步拆解背后是怎么做到的。

1. 先让Agent“住进”你的工作台

核心问题就一个：用户怎么跟Agent说话？说完了，Agent去哪里执行？

平台帮你做好了第一步：机器人消息接口。

以飞书为例，创建一个企业自建应用，开通接收消息的能力。钉钉、企微的套路一模一样——都是注册机器人，拿到一个“接收消息的URL”，然后把Agent的业务逻辑挂上去。用户在群里@机器人或者私聊它，消息会推送到你的这个URL。

有了通道还不够，更重要的是谁在说话。

钉钉和企微的做法比较直接：每个用户在平台里都有一个唯一的userId。业务逻辑里判断“发送者是谁”，决定他能发起什么类型的报销单。

飞书稍微绕一点，需要拿到用户的open_id。有一个小技巧：创建审批实例时，把发起人的open_id传成机器人的open_id，就可以用机器人身份代员工提交申请。对员工来说，这个过程是无感的——他只觉得“有人听懂了我的话”。

跨平台的技术实现原理是统一的：

• 微信/企微：XML格式

• 钉钉/飞书：JSON格式

你可以在中间做一些协议转换处理，适配三家的差异，让Agent的核心业务只关心“内部标准消息”怎么写。这样一来，同样的逻辑就能一次开发，三端发布。

2. 让Agent看懂：“报销出差高铁票281，餐费85”

用户说话的口吻各不相同。

• “帮我报销上周去上海出差的高铁票，281块。”

• “报销单：餐费85，差旅281。”

• “小王报销3000超了标。”

这背后靠的是大模型（LLM）的结构化提取能力。

Ramp公司的研究提供了一个很好的参考。他们的报销Agent在面对一笔报销请求时，会输出三种结果：Approve（批准） 、Reject（驳回） 和 Needs Review（需人工复核） 。这里的逻辑就是让Agent自己判断有没有把握。同时Agent的每一步决策都要求附上依据，比如引用“差旅报销标准第3条”这种具体条款。

结合国内场景，具体落地可以这样做（伪代码思路）：

# 提示词里的核心逻辑

用户说：“上周五去上海拜访客户，高铁282，午餐85，打车去火车站25。”

你要返回如下JSON结构：
{
  “categories”: [“transport”, “meal”, “transport”],
  “subtotals”: [282, 85, 25],
  “total”: 392,
  “date”: “2025-05-02”,
  “customer”: “上海XX公司”,
  “need_review”: false,
  “reasoning”: “餐费85在标准内，无需复核”
}

用户在群里@Agent并发送消息时，LLM会做实体识别和时间解析，然后返回这个JSON数据。

这里有一个原则：不要让Agent充当“最终裁判”的角色。对于超标的特殊情况，就要触发“需人工复核”，交给真人审批。就像前面小王的超规餐费，Agent老老实实推送给了我。

通过这种方式，超过65%的标准报销可以实现全自动处理，而剩下的那些“模棱两可”的单据则由真人兜底，彻底释放财务人员的人力。

3. 验证发票真伪：Agent的“火眼金睛”

报销的核心凭证是发票。这个环节最怕两件事：假发票、重复报销。

不少平台已经开始融合OCR（光学字符识别）、NLP和大模型来落地智能审单系统。员工只需在聊天窗口上传一张图片，Agent就能自动提取发票代码、号码、金额、开票日期，然后调用国税局的查验接口进行四要素比对。同时，还会去后台数据库里排查这张发票是否在短期内被同一人或他人重复提交过。

这种自动化流程避免了人工打开发票附件、肉眼比对和手动录入的繁琐操作。验证无误后，系统直接生成报销单；遇到异常码或重复提示，则立即驳回并告知原因。

Ramp的做法也值得借鉴：Agent在做决策的同时生成可解释的说明，把验证结果和拒绝原因直接推送给员工。打通发票查验和预算校验后，员工就不需要再操心“发票合规性”或者“部门额度够不够”这种抽象问题了。

4. 兜底设计：当Agent拿不准的时候

AI绝不完美，必须设置兜底方案。

• 超规判断：分类后如果某项费用超出公司标准，Agent拒绝自动通过，直接推给经理复核，并标注超标金额。

• 信息不全：发票缺号码或OCR识别不清时，Agent回复“缺少必要信息，请重新上传或补充填写”。

• 权限不足：如果员工不属于任何有报销权限的部门，Agent会应拒绝请求。

在此基础上，还要加上审计日志机制：Agent的“谁、什么时间、做了什么报销操作、有无异常”这些行为都自动记录下来。一旦出现财务争议，在后台就可以一键追溯到当时每一步的原始输入和Agent推理的过程。

写在最后：Agent不是取代财务，是让财务做更有价值的事

有些团队可能会担心：让Agent插手钱的事，出错了怎么办？

回头看看小王的例子。他以前的核销过程至少要经历“自己填单→上传发票→填写事由→等待上级审批”四个环节，每个环节都要手动折腾。现在直接一句话@财务Agent，系统自动完成复杂度最高的发票核验与预算匹配，只要规则设计得足够周全，出错概率反而比人工操作更低。

浪潮通软提出的理念很到位：利用“OCR+NLP+大模型”技术融合，让员工只需发起报销意图，系统自动完成填单、验票与合规校验。在实操中，Agent充当的是财务“助手”的角色，而不是彻底取代财务的职位。它替财务打掉了验票、理单、催填这些附加值最低的工作，让财务能从表格里走出来，介入更有价值的预算分析和成本控制。

同理，你的“一句话触发报销审批”也可以一步步建成。从零开始，你会发现最难的不是实现逻辑，而是说服自己：有些东西，真的可以交给机器去办。