
一张退款申请单上写着：

- 订单号：`SO-1001`
- 退款金额：`199.00 CNY`
- 退款原因：重复支付

AI 已经准确读出了这些字段。接下来，它是不是就可以调用退款接口了？

答案是否定的。

OCR 识别成功，只能证明系统从图片中提取到了一组候选信息。它不能证明申请单
真实有效，不能证明当前操作人有权代表客户，不能证明订单仍然允许退款，也不能
证明同一笔申请此前没有执行过。

当 AI 只负责回答问题时，一次识别错误通常产生一个错误答案。当 AI 开始操作
业务系统时，同样的错误可能变成一条已经写入数据库的退款记录。此时，真正需要
设计的已经不再是一条更聪明的提示词，而是一条可以解释、可以中止、可以审批、
可以重放且不会产生第二次业务后果的责任链。

本文用一个可复现的演示说明这条链路如何建立：

> 腾讯云 OCR Skill 负责感知，ADP 负责编排，确定性校验器负责关闭歧义，
> BailingHub 负责受治理执行，业务系统保留最终权限。

整个演示使用固定生成的模拟数据，不包含真实客户、真实订单或真实资金操作。

![演示退款申请单](https://developer.qcloudimg.com/http-save/yehe-12621244/0abe0a81b2071b8cbf5da6e65f3f7879.png)

## 一、先把五种责任分开

把 OCR 接到退款 API 上并不困难。困难的是，当退款真的发生时，我们能否回答：

1. 图片里写了什么？
2. 从图片中提取出的字段是否完整、唯一、可用于后续处理？
3. Agent 最多可以触达哪个业务能力？
4. 谁批准了哪一组精确参数？
5. 业务系统在执行时是否仍然允许这次退款？

这五个问题属于不同责任层：

| 层 | 在本次演示中的职责 | 明确不负责 |
| --- | --- | --- |
| 腾讯云 OCR Skill | 提取文字和请求标识 | 业务真实性、审批与授权 |
| 确定性校验器 | 字段完整性、歧义、规范化和稳定请求标识 | 判断谁有权退款 |
| 腾讯云 ADP | 组合 Skill 与任务步骤 | 成为最终业务授权方 |
| BailingHub | 固定路由、风险控制、人工审批、幂等、审计和任务状态 | 替代业务系统权限 |
| 演示业务系统 | 校验业务主体并形成最终业务结果 | 信任模型自行生成的权限事实 |

这个分层最重要的价值，不是让系统显得复杂，而是避免某个组件在无意中承担它
无法正确承担的责任。

OCR 不应该替退款负责；Agent 不应该自己选择可信主体；编排平台不应该因为“流程
跑通”就被视为最终授权者；治理控制面也不应该越过业务系统，替它判断订单状态和
真实权限。

## 二、真实 OCR 输出比预想的更“薄”

我们在腾讯云 ADP 中安装并调用了腾讯云 OCR Skill，对同一张演示退款申请单进行了
两次真实识别。

ADP 向后续步骤暴露的实际结构是：

```json
{
  "raw_text": "退款申请单\n演示数据/DEMO\n客户退款申请\n...\n订单号:\nSO-1001\n退款金额:\n￥199.00\n退款原因:\n重复支付",
  "RequestId": "2f45a80d-ae52-476f-97c4-87bf86e142df"
}
```

第二次调用即使增加了 `--is-words true`，向上层暴露的仍然只有
`raw_text` 和 `RequestId`，没有逐字段 `TextDetections` 或
`Confidence`。

![ADP 中腾讯云 OCR Skill 的实际输出](https://developer.qcloudimg.com/http-save/yehe-12621244/f3a7d34abec77fb0d372c1ec3b9d55a9.png)

这里出现了一个很容易被忽略的工程陷阱：**置信度缺失不等于置信度很高。**

如果下游为了让流程继续运行，擅自补出 `99%`，系统就制造了一个从未存在过的
安全事实。于是我们选择显式表达“不知道”：

```json
{
  "confidence": {
    "available": false,
    "order_no": null,
    "amount": null,
    "reason": null
  },
  "manual_field_confirmation_required": true
}
```

这并不意味着流程必须永久停止。它意味着流程只能进入一个更保守的分支：允许
生成待治理请求，但审批人必须逐项核对订单号、金额、币种和退款原因。

## 三、不让模型从自由文本里“猜”业务字段

大模型擅长从模糊上下文中补全含义，但退款参数不应该靠补全。

演示中的确定性校验器只接受带明确标签的字段：

| 字段 | 规则 |
| --- | --- |
| `order_no` | 必须存在且只有一个规范值 |
| `amount` | 必须为大于零、最多两位小数的金额 |
| `currency` | 本次演示固定为 `CNY` |
| `reason` | 必须存在且非空 |

如果同一份文本同时出现 `SO-1001` 和 `SO-1002`，它不会猜测哪个“更像”
正确答案，而是返回 `ambiguous_field`。如果同时出现 `199.00` 和
`999.00`，同样关闭失败。如果缺少退款原因，则返回 `missing_field`。

关闭式失败矩阵如下：

| 条件 | 结果 | 是否生成治理请求 |
| --- | --- | --- |
| OCR 响应结构无效 | `invalid_ocr_response` | 否 |
| 缺少必需字段 | `missing_field` | 否 |
| 同一字段出现冲突值 | `ambiguous_field` | 否 |
| 可得置信度低于门槛 | `low_confidence` | 否 |
| 金额不是合法正数 | `invalid_field` | 否 |
| 文档身份无效 | `invalid_source_document_id` | 否 |

本地机器可执行测试矩阵覆盖了成功、缺失、冲突、低置信和无效字段等 13 项场景。
这些测试不能代替真实平台调用，但可以证明：同一输入会得到确定结果，失败不会
悄悄滑入后续执行链路。

## 四、识别请求和业务请求不是一回事

腾讯云 OCR 每次调用都会返回 `RequestId`。它非常适合排查一次 OCR 请求，却
不适合单独作为退款业务的幂等身份。

原因很简单：对同一张图片重新识别，OCR `RequestId` 会变化；但从业务上看，
它仍可能是同一份退款申请。

因此我们额外计算上传文件的 SHA-256，并将以下规范化对象作为治理请求身份的
输入：

```json
{
  "source_document_id": "sha256:<64 hex>",
  "order_no": "SO-1001",
  "amount": "199.00",
  "currency": "CNY",
  "reason": "重复支付"
}
```

对象键排序后使用 UTF-8 编码并计算 SHA-256，最终得到稳定的
`ocr-refund-...` 请求标识。

这样做带来三个性质：

- 同一文档、同一组规范字段重复处理，生成同一治理请求身份；
- OCR `RequestId` 变化不会自动制造一个新的退款意图；
- 订单号、金额或原因发生变化，会生成不同的治理请求身份。

在真实 ADP 归一化中，我们得到：

```json
{
  "decision": "ready_for_governed_submission",
  "authorized": false,
  "governance_required": true,
  "source": {
    "provider": "tencentcloud-ocr",
    "action": "GeneralAccurateOCR",
    "request_id": "226486fe-f8aa-4b54-9385-16cac60f5d83",
    "document_id": "sha256:90c5b7da0a8d2c7534dbc3cb1289405d5419316b8eff307da49bb61ff42b3d29"
  },
  "extracted": {
    "order_no": "SO-1001",
    "amount": "199.00",
    "currency": "CNY",
    "reason": "重复支付"
  },
  "bailinghub_submission": {
    "request_id": "ocr-refund-364b4a63958c5b5e8b444c2af756f60f"
  }
}
```

请注意其中的 `authorized: false`。这不是一个等待后续“修正”的临时字段，而是
这一步最重要的输出：字段已经足以进入治理链路，但还没有获得退款授权。

## 五、路由、主体和凭证必须来自可信环境

如果 Agent 可以根据 OCR 文本自行选择：

- 调用哪个业务路由；
- 代表哪个业务主体；
- 使用哪一组凭证；
- 是否跳过审批；
- 最终调用哪个 API；

那么前面的字段校验并没有建立真正的安全边界。攻击者只需要影响“目标到能力”的
翻译过程，就可能把一段不可信文本变成真实业务后果。

因此，本次演示只允许模型提交两个值：

```json
{
  "request_id": "stable-business-request-id",
  "input": "untrusted normalized task text"
}
```

治理地址、Client Token 和路由由运维环境固定；可信业务主体由受信任上下文注入。
模型不能从 OCR 文本中覆盖这些值。

这也是“把 Agent 接入业务系统”和“把业务权限交给模型”的分界线。

## 六、审批批准的是参数快照，不是一句模糊意图

对于退款这样的高风险写操作，“批准退款”仍然太模糊。审批必须绑定这一次动作的
精确对象。

本次高风险演示任务进入审批等待后，业务系统中的退款记录数仍为 `0`。审批记录
绑定了以下快照：

```json
{
  "tool": "request_demo_refund",
  "scope": "demo.refund.request",
  "risk": "high",
  "subject": "demo-user-001",
  "args": {
    "order_no": "SO-1001",
    "amount": 199,
    "reason": "重复支付"
  },
  "args_hash": "dc6cae16a3217ff4916a90fcdaeb0276fc776ee1b9b7ccecf681ec96f93dfd1e",
  "decision": "approved",
  "decided_by": "demo-manager"
}
```

这意味着审批人批准的是：

> 主体 `demo-user-001` 使用 `request_demo_refund`，为订单 `SO-1001`
> 申请 `199` 元退款，原因为“重复支付”。

它不等于允许 Agent 在审批后重新选择订单、金额或原因。

参数快照的意义，是把人的批准与机器最终执行的内容绑定起来。否则，即使界面上
出现了“已审批”，执行时的参数仍可能因为模型重跑、上下文变化或提示注入发生
漂移。

## 七、治理通过之后，业务系统仍然可以拒绝

在正式审批闭环前，我们先使用一个不被演示业务系统认可的主体发起请求。BailingHub
完成治理流程后，业务 API 仍返回：

```text
unknown or unauthorized subject
```

此时退款记录数保持为 `0`。

随后使用有效演示主体重新验证，批准后业务系统只生成一条演示记录：

```json
{
  "refund_id": "R-20efd3f1",
  "subject": "demo-user-001",
  "order_no": "SO-1001",
  "amount": 199,
  "reason": "重复支付",
  "status": "submitted"
}
```

业务接口返回 `HTTP 202`。这里的 `submitted` 只表示演示业务系统接受了
申请，不表示真实资金已经完成退款。

这个结果验证了一条关键边界：

> 治理控制面负责 Agent 最多可以触达什么、什么时候必须停下来等待批准；
> 业务系统负责这个主体在此刻是否真的有权执行。

前者不能替代后者。订单状态、余额、租户权限、退款额度等动态规则，仍然只能由
掌握最新业务事实的系统正确判断。

## 八、重试不能变成第二次退款

分布式系统中最危险的情形之一，是业务写入已经成功，但响应在返回途中丢失。
调用方看到超时后重试，如果没有稳定任务身份和业务幂等约束，就可能产生第二次
业务后果。

本次演示使用同一个高风险执行请求标识重放：

```text
ocr-refund-e2e-20260729-authorized-001
```

系统返回了同一个任务：

```text
job_id: cb00a87c-a3c8-486c-88d2-8f0087830e08
```

重放后的演示退款记录数量仍然是 `1`，没有出现第二个任务、第二条审批或第二条
退款记录。

工具调用账本同时保存了固定幂等键、完成状态和 `HTTP 202` 结果；审计事件可以
串起接收、审批等待、批准、重跑、工具调用和工具结果。

幂等并不是“请求失败时多试几次”的实现细节。对会形成真实业务后果的 Agent
动作来说，它是责任链的一部分：系统必须能区分一次传输重试与第二个业务意图。

## 九、为什么真实 E2E 要拆成两阶段

为了避免把实验结果写得比证据更完整，这里披露一个重要限制。

本次验证使用了两个独立请求标识：

| 阶段 | 请求标识 | 证明目标 |
| --- | --- | --- |
| ADP 归一化与无副作用治理入口 | `ocr-refund-364b4a63958c5b5e8b444c2af756f60f` | 真实 OCR 输出可以关闭式归一化并进入固定治理入口 |
| 高风险审批与业务执行 | `ocr-refund-e2e-20260729-authorized-001` | 审批快照、业务权限、单次执行与重放去重 |

两个阶段使用相同的演示业务事实，但当前证据不能表述为“同一个 request ID 从
OCR 一直贯穿到业务结果”。

我们选择拆开验证，是为了先隔离两个不同问题：

1. ADP 与腾讯云 OCR 的真实输出形态，是否能被确定性地收敛；
2. 高风险业务动作，是否能在批准前保持零副作用，并在重放时保持单次业务后果。

生产实现可以通过显式的关联对象把感知事件、治理请求和业务执行串联起来，但不能
为了让演示看起来更顺滑，就把两个不同身份悄悄写成同一个。

透明地说明证据边界，是这类治理系统可信度的一部分。

## 十、如何复现确定性部分

演示工程将平台相关调用与确定性逻辑分开。没有腾讯云或 BailingHub 凭证时，仍可
运行本地夹具与测试矩阵：

```bash
cd demo
python3 generate_refund_request.py
python3 -m unittest discover -s tests -v
python3 run_demo.py \
  --ocr-json fixtures/tencent-ocr-refund-request.json \
  --source-file assets/refund-request-SO-1001.png
```

本地命令只生成待提交的受治理请求，不访问网络、不持有业务凭证，也不直接调用
退款 API。

真实平台验证则依次完成：

1. 在 ADP 中调用腾讯云 OCR Skill；
2. 使用辅助 Skill 对 `raw_text`、OCR `RequestId` 和文档 SHA-256
   进行关闭式归一化；
3. 将 `request_id` 与 `input` 原样提交给固定的 BailingHub 路由；
4. 验证无副作用入口；
5. 在隔离的演示退款路由中验证审批前零记录；
6. 审批精确参数快照；
7. 验证业务系统只生成一条演示退款；
8. 使用同一高风险执行请求标识重放并确认记录数不增加。

## 十一、这套方法不只适用于退款

退款只是一个容易看见后果的例子。同样的责任结构也存在于：

- OCR 识别发票后创建付款申请；
- 从邮件中提取客户信息后修改 CRM；
- 解析工单后调整账号权限；
- 从合同中提取条款后触发审批或签署流程；
- 识别运维告警后执行发布、回滚或资源变更；
- 从对话中理解人事请求后修改员工状态。

这些场景都可以让 AI 负责理解和编排，但不能把“理解成功”直接等同于“行动获准”。

一条更稳健的通用路径是：

```text
不可信输入
  -> 感知与提取
  -> 确定性归一化
  -> 固定治理入口
  -> 风险判断与人工介入
  -> 精确参数快照
  -> 业务系统最终授权
  -> 幂等执行与审计证据
```

## 十二、我们实际证明了什么

本次演示已经证明：

- 腾讯云 OCR Skill 的真实输出可以进入确定性归一化；
- 逐字段置信度不可得时，系统不会补造高置信度；
- 缺失、冲突和低置信夹具可以在治理提交前关闭失败；
- 高风险动作在业务执行前进入人工审批；
- 审批绑定精确参数快照；
- 未知或未授权主体会被业务系统拒绝；
- 批准后只产生一次演示业务后果；
- 同一高风险执行请求重放不会产生第二次业务后果；
- 执行账本和审计事件可以追踪治理过程。

本次演示没有证明：

- OCR 内容天然真实；
- 所有订单状态、额度和租户规则都已覆盖；
- 两阶段当前使用同一个 request ID；
- 演示结果等于生产环境安全认证；
- 腾讯云、SkillHub 或其他第三方对 BailingHub 作出认证或推荐。

## 结语：AI 的最后一公里，是把能力接到责任上

“AI 能不能读懂退款单”已经不是最难的问题。

真正困难的是，当 AI 将理解转化为行动时，系统能否保证：

- 不可信内容不能自行变成权限；
- 模型不能选择自己的可信身份和治理路由；
- 高风险动作必须停在正确的人面前；
- 人批准的是精确参数，而不是一张空白支票；
- 业务系统仍然拥有最终拒绝权；
- 网络重试不会制造第二次业务后果；
- 事后可以还原是谁、基于什么输入、批准了什么、执行了什么。

OCR 让 Agent 看见信息，编排让 Agent 组织步骤，治理让企业敢于开放行动，业务
系统则为真实后果保留最后一道权力。

所以，OCR 识别成功之后，AI 仍然不能直接退款。

它必须先走完一条能够承接责任的路。



OCR 识别成功，只能证明系统从图片中提取到了一组候选信息。它不能证明申请单真实有效，不能证明当前操作人有权代表客户，不能证明订单仍然允许退款，也不能证明同一笔申请此前没有执行过。

OCR 识别成功之后，AI 为什么仍然不能直接退款？

人工智能

后端

架构设计

OCR识别退款单后，AI不能直接调用退款接口。系统需验证申请单真实性、操作人权限、订单状态及重复性。腾讯云OCR提取数据，ADP编排流程，确定性校验器验证字段，BailingHub治理执行，业务系统保留最终权限。分层设计确保责任明确，避免错误退款。审批需绑定精确参数快照，业务系统保留拒绝权，重试不会产生二次退款。

代码解释

数据库

SkillHub

路由

Agent

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


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

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

OCR 识别成功之后，AI 为什么仍然不能直接退款？-腾讯云开发者社区-腾讯云

OCR 识别成功之后，AI 为什么仍然不能直接退款？

OCR 识别成功之后，AI 为什么仍然不能直接退款？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐