# 月底报销地狱，我用 WorkBuddy 串起腾讯云 OCR + TTS 三个 Skill 治好了
## 前言：那张对不上的发票

上周五下班前，财务群里 @我：「你 7 月那张云服务器的报销，合计金额加税额跟价税合计对不上，打回了，重新填。」

我翻出那张电子发票核对，确实——我手抄的时候把税额那一栏看串了行。这不是第一次。作为一个后端，我每个月要处理十几张发票：云资源的、出差住宿的、外包服务的。拍照、打开 Excel、抄发票号、抄税号、抄金额、再对一遍价税合计，一张熟练操作也要五到十分钟，明细多的能拖到一刻钟。更烦的是两个隐形雷：**重复报销**靠脑子记，**金额不平**肉眼当场发现不了，全靠财务事后打回，来回一折腾就是半天。
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/401afe16fed94aec29ad404d681fb939.png)

这类活儿的特征很清楚：**规则死板、重复度高、容错率低**。它不需要创造力，只需要耐心，而耐心恰恰是月底最稀缺的东西。

这次腾讯云把 OCR、TTS 封装成了标准 Skill，一键挂进 WorkBuddy。我想试试：能不能在 WorkBuddy 里只说一句「帮我处理这些发票」，剩下的识别、风控、出单、播报全自动？这篇就是从零搭到跑通的完整复盘，所有数据都是真实实测。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/563395326ee75d1f89134fd8c103a2c6.png)

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/e5f95f5ed959c7156d07ebf94ab49504.png)

## 一、先把要什么想清楚：不是「能识别」，是「能提交」

动手前我先给自己划了条线：我要的不是一个 OCR 演示。

单纯调个发票识别接口，返回一堆字段，那只是把「手抄」换成了「看屏幕核对」，省不了几分钟。我要的是一个**业务闭环**：

1. 发票进来 → 自动抽出结构化字段（号码、买卖方、金额、明细）；
2. 自动风控 → 金额勾稽、重复票拦截、超限额驳回、抬头校验；
3. 直接产出一张可提交的报销单（JSON 给系统、Markdown 给人看）；
4. 处理完语音播报「已生成，价税合计 xxx 元」，不用盯屏幕也知道结果。

区别就在这张表里：

| 只调 OCR | 我要的 Agent |
|---|---|
| 返回一堆字段 | 输出可提交的报销单 |
| 不管金额平不平 | 自动勾稽并标风险 |
| 不管是不是本公司抬头 | 购买方白名单校验 |
| 不管重复报销 | 同号票直接拦截 |
| 无反馈 | 语音播报处理结果 |

## 二、方案：三个 Skill 分工，一个 Agent 编排

最终用到三块能力，各司其职：

![三个腾讯云 Skill 分工 + 一个自研 Agent 编排，规则引擎兜住六类业务风控](https://developer.qcloudimg.com/http-save/yehe-10730009/90dc84c178db1501d2a2f43223fe340c.png)

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/ee14d8275c98326803b50140cd63b772.png)


| 环节 | Skill（slug） | 职责 |
|---|---|---|
| 发票识别 | `tencentcloud-ocr-vatinvoice` | 增值税/电子发票全字段，主力 |
| 供应商核验 | `tencentcloud-ocr-bizlicense` | 发票销售方 vs 营业执照交叉比对（可选加分项） |
| 语音确认 | `tencentcloud-tts` | 把「处理完成」变成一句能听的反馈 |
| 编排 + 规则 | `invoice-reimburse-agent`（自研） | OCR 之后的活：跑规则引擎、出报销单、判通过/驳回 |

灵魂是自研的编排 Agent —— **invoice-reimburse-agent**。它不调 API，它做「OCR 之后的事」：把识别结果丢进规则引擎，跑六类业务风控，再决定这张票通过、复核还是驳回。

为什么一定要有这层？因为**OCR 识别对了，业务不一定对**。字段全识别正确，但它可能是一张重复提交的票、一张金额对不上的票、一张超公司单笔限额的票。OCR 管「看得清」，规则引擎管「该不该报」。这层判断才是 Agent 相对裸接口的价值。

## 三、从「不知道怎么配」开始，直接问 WorkBuddy

我最欣赏 WorkBuddy 的一点：**不用先弄懂密钥、OCR 开通、环境变量，遇到不会的直接问它。**

我一上来没查配置教程，直接让它做一次不上传发票的最小自检。它检查了 Skill 文件、鉴权变量、运行依赖，把问题缩小到两处：`TENCENTCLOUD_SECRET_ID/KEY` 没读到、`tencentcloud-sdk-python` 没装。模糊的「Skill 用不了」，到这里变成两个能具体处理的问题。


我不知道密钥去哪建，直接追问「从哪获取 TENCENTCLOUD_SECRET_ID/KEY」。它给了访问管理 CAM 的直达地址、创建步骤、以及「SecretKey 只显示一次」的提醒。我照着进 CAM 建密钥、开通 OCR 服务——这一步涉及账号授权，必须本人做，WorkBuddy 负责诊断和带路，我负责确认。SDK 它直接帮我装进了托管 venv。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/d873bfe2722f55302d62fea14956a49a.png)


这段配置过程反而最能体现 WorkBuddy 的作用：**不知道就问，出错就把现状交给它查。** 用户可以不知道 SecretId 在哪建、OCR 有没有开、Skill 怎么加载环境变量，它会根据实际检查结果给下一步，并把能执行的本地修复做完。

## 四、造一批「有坑」的发票

要检验风控真能拦住问题，光有正常票不够，得主动造坑。我用 Pillow 画了 4 张脱敏发票（主体名、税号、金额全虚构，不涉及任何真实信息），每张对一个风控场景：

| 文件 | 场景 | 预期 |
|---|---|---|
| invoice_1_normal | 正常票，3000+180=3180 平 | 通过 |
| invoice_2_mismatch | 金额不平，小写故意写 5800（实际应 5300） | 驳回 |
| invoice_3_over | 价税合计 66780，超单笔限额 5 万 | 驳回 |
| invoice_4_dup | 与正常票同号码，模拟重复报销 | 驳回 |

![脱敏发票样例：正常票（左）与金额不平票，版式贴近真实电子发票以便 OCR 识别](https://developer.qcloudimg.com/http-save/yehe-10730009/8c4b26d342d203af8474fa5aea305d60.png)

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/4eaee7655d4211cb515bab4ee094d5b8.png)
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/cbdafde77ef73e27b768415bd175266f.png)

## 五、一句话跑通：4 张票，1 通过 3 拦截

真正的重头戏。我让 WorkBuddy 批量处理整个目录，它调编排 Agent 一条命令跑完：

```bash
python skills/invoice-reimburse-agent/scripts/reimburse.py \
  --invoice-dir demo/invoices \
  --output-dir demo/output \
  --tts
```

结果非常干脆——正常票通过，三张问题票全部被精准拦截，各自标出具体风险码：

```
[OK] invoice_1_normal.png   → approved  total=3180.0  risks=[]
[OK] invoice_2_mismatch.png → rejected  total=5800.0  risks=[AMOUNT_MISMATCH]
[OK] invoice_3_over.png     → rejected  total=66780.0 risks=[OVER_LIMIT]
[OK] invoice_4_dup.png      → rejected  total=3180.0  risks=[DUPLICATE_INVOICE]

count=4  approved=1  rejected=3  error=0  total_amount=78940.0
wall_clock≈5.36s（单张≈1.34s）
```

![批量实测：4 张票 1 通过 3 拦截，0 漏检，单张约 1.34 秒](https://developer.qcloudimg.com/http-save/yehe-10730009/d16aff49409496635554038632c844ad.png)

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/0598a3b442dbc98ef064f0b09fbcbb0e.png)


生成的报销单，正常票金额勾稽打钩、建议通过；不平票直接把 500 元差额算给你看、建议驳回：

![报销单结果：正常票金额勾稽通过、建议通过；不平票直接算出 500 元差额、建议驳回](https://developer.qcloudimg.com/http-save/yehe-10730009/788ffd22d7f244ba33ebdcec9b14295c.png)

> 📸 **截图位 7（补）**：WorkBuddy 里打开某张 `reimburse_*.md` 报销单的实际界面（可选）。

## 六、踩坑实录：真实调用远比 demo 曲折

这部分我觉得最有价值。demo 数据永远理想，一接真实接口，坑就来了。

### 坑 1：全电发票的金额字段会「错位」

最隐蔽也最关键。我造的正常票明明写着合计金额 3000、税额 180，但 OCR 返回的「金额信息」里，`合计金额` 和 `合计税额` 竟然**都是 ¥180.00**——真正的 3000 被拆到了「明细条目」里，价税合计小写 3180 跑到了「其他信息」字段。

结果编排脚本抽出来的 total 是 `None`，一张好票差点被误判。

原因是电子/全电发票的返回结构和传统增值税票不完全一致。SKILL 文档提到会做字段映射，但实际落点仍可能有偏差。**光看文档不够，必须打出真实 JSON 逐字段对照。**

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/8db4ccd8946b642ed36e49a377b40b00.png)


解法：给编排脚本加了个 `extract_amounts()` 稳健抽取，三层兜底——价税合计从「小写金额→价税合计→其他信息里的小写」依次找；不含税合计缺失或明显偏小时用明细最大不含税额兜底；两项齐了但价税合计缺就反推。改完正常票恢复 3000/180/3180，勾稽正确通过。

### 坑 2：TTS 资源包耗尽，不能拖垮整条流水线

第一次带 `--tts` 跑，四张票全报 `[ERR]`：

```
TTS 失败: UnsupportedOperation.PkgExhausted（资源包额度已用尽）
```

问题是 TTS 只是最后「锦上添花」的播报，它一失败整张报销单被标成 error 作废了——这不合理。报销单该出还得出，语音是次要的。

解法：把 TTS 调用单独包进 try/except，失败记一条 `tts:{ok:false}` 继续走，绝不影响主流程。**核心链路和增强链路做故障隔离，这是 Agent 编排的一条硬原则。** 我也把这个错误码补进了 TTS 的 SKILL.md，方便下次直接查。

### 坑 3：批量顺序要可控

重复票检测依赖「先见正常票、再见同号票」的顺序。目录默认按文件名排序，我一开始命名让重复票排在了前面，导致「正常」那张反被当重复。加 `1_/2_/3_/4_` 前缀显式控制顺序后才稳定。小细节，批量场景不注意就翻车。

## 七、效果对比：从十分钟到一秒多

用真实接口跑完，数据落到实处：

| 指标 | 人工 | 这个 Agent |
|---|---|---|
| 单张处理 | 5–15 分钟 | **≈1.34 秒** |
| 金额勾稽 | 靠肉眼，易漏 | 自动，差 1 分钱都拦 |
| 重复报销 | 靠记忆 | 同号票直接驳回 |
| 超限额 | 财务事后发现 | 提交前拦截 |
| 4 张票批量 | 半小时起 | **5.36 秒，0 漏检** |

数字之外我更在意**风控前置**：过去这些问题都是财务打回来才知道，现在在我点「提交」之前就被揪出来了，来回沟通成本直接归零。

## 八、一点思考：Skill 是工具节点，Agent 是编排台

做完这个小东西，我对 Skill 和 Agent 的分工有了具体体感。

**Skill 的价值是「可组合的专家能力」**——OCR、TTS 各把一件事做到专业，我不用关心底层模型怎么调。**Agent 的价值是「业务闭环」**——把这些能力按业务逻辑编排，并补上机器能力之外的判断（该不该报、平不平、重不重）。而 **WorkBuddy 是那个编排台**：它把我不懂的配置一路带过，把失败现状接过去查，把专业识别交给腾讯云 Skill，自己只做组织和收尾。

还有一条我越来越信：**财务这类场景，宁可不自动通过，也要把风险明明白白暴露出来。** 我的状态机只有三态——通过、复核、驳回，任何一条 high 级风险都不静默放过。Agent 可以提效，但不能替人背锅，它要把问题端到我面前，而不是替我拍板。

下一步想接的：企业微信审批流自动提单、费控系统费用科目主数据、火车票/行程单等更多票种。Skill 矩阵里这些能力都现成，缺的只是把它们串进闭环的那点编排功夫。

如果你也在被某类单据反复消耗，不妨试试这个思路——把腾讯云 Skill 当积木，让 WorkBuddy 当编排台，用一层薄薄的规则引擎兜住业务，剩下的交给一句话。


![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/cc23d167b77e67e534ec26ea87744819.png)


上周五下班前，财务群里 @我：「你 7 月那张云服务器的报销，合计金额加税额跟价税合计对不上，打回了，重新填。」

月底报销地狱，我用 WorkBuddy 串起腾讯云 OCR + TTS 三个 Skill 治好了

服务端开发

编程语言

人工智能

开发工具

用WorkBuddy+腾讯云OCR/TTS三Skill搭建发票报销Agent，实现4张票5.36秒批处理、1.34秒/张，金额勾稽、重复票拦截、超限额驳回全自动，错误率归零，人工10分钟缩至秒级，附真实踩坑与字段映射方案。

代码解释

访问管理

云服务器

服务器

WorkBuddy 

Agent

JSON

2026上云采购 | AI焕新·智启新局

vtiv

文字识别限时特惠，新用户0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

月底报销地狱，我用 WorkBuddy 串起腾讯云 OCR + TTS 三个 Skill 治好了-腾讯云开发者社区-腾讯云

月底报销地狱，我用 WorkBuddy 串起腾讯云 OCR + TTS 三个 Skill 治好了

月底报销地狱，我用 WorkBuddy 串起腾讯云 OCR + TTS 三个 Skill 治好了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐