做财务审计原型时，最省事的方案往往是写一段超级 Prompt：把报销制度、发票字段、ERP 操作规程和报告格式全部交给 GPT-4o，一次生成审核结果。
演示阶段看起来能跑，进入生产环境后，代价很快暴露。修改一条制度，可能影响其他判断；模型同时处理 OCR、计算、检索和报告撰写，出了错很难定位；每审核一张单据，还要重复携带大段规则，占用上下文和调用成本。
ALOU Data 对 Agentic Workflow 的定义是：多个 Agent 通过自主规划、工具调用、协作与反思完成复杂任务。王吉伟整理的相关资料汇总收录了 25 篇智能体工作流论文，并按架构、系统、基准和方法论等 6 类梳理。
放到财务审计里，重点很具体：拆清职责、固定接口、保留证据。Agent 的自由度反而要收紧。
先划清规则、工具和模型的边界
多 Agent 不能简单理解成三个聊天机器人排队接力。发票去重、金额计算和字段匹配，本来就更适合代码、SQL 或规则引擎。大模型主要处理非结构化信息和文字解释。
| 审计任务 | 更合适的执行方式 | 输出要求 |
|---|---|---|
| 发票号码去重、日期范围检查 | SQL、规则引擎 | 明确的通过或不通过 |
| 金额、税额和数量核对 | 计算程序 | 原值、计算值、差异字段 |
| OCR 字段提取、费用类目映射 | OCR 模型或受控 LLM | 结构化字段及原文位置 |
| ERP、入库记录、付款流水查询 | 预先批准的 API 工具 | 查询结果和事务记录 |
| 异常原因说明 | LLM 加固定模板 | 规则编号、证据和建议动作 |
模型可以提取和解释，确定性计算仍交给程序。这样更容易测试，也方便替换模型。初筛节点是否需要 GPT-4o，应由同一批样本上的测试结果决定，不能只看参数规模。
三个节点，各自只管一段
Agent A：规则校验
Agent A 接收发票 OCR 结果、报销单和当前制度版本，逐项检查抬头、必填字段、费用归属及报销条件。它不写长篇分析，只输出固定字段：
单据 ID
规则 ID
判定：通过 / 不通过 / 待复核
证据字段
制度版本
发现抬头不一致或关键字段缺失时，由编排器决定退回或转人工，不再继续访问 ERP。规则变更也只影响对应检查项，不必重写整段 Prompt。
Agent B：数据比对
通过初筛的单据进入 Agent B。它调用只读接口，查询 ERP 采购订单、入库记录和银行付款流水，再由代码完成单价、数量、税额等字段的匹配。
Agent B 只拿标准化字段，不需要读取整本财务制度。遇到“未找到采购单”时，可以按受控流程检查 OCR 是否把 O 识别成 0、把 I 识别成 1。原值和修正候选必须同时保存，不能直接覆盖票据内容。
Agent C：异常整理
Agent C 汇总前两个节点的证据，生成财务人员能快速阅读的异常说明，例如采购订单与入库记录一致，但发票税额字段存在冲突。
风险等级应来自企业已有的审计规则表。没有经过校准的数据，就不要让模型临时编造置信度百分比。Agent C 也不需要数据库写入权限，它的任务是整理冲突字段、附上证据来源，并把材料送到人工审批环节。
编排器负责收口
一条可控的审计链路可以这样组织：
报销单 / 发票 / OCR 结果
↓
字段标准化
↓
Agent A：规则校验 ── 不通过或待复核 → 人工或退回
↓ 通过
Agent B：数据比对 ── 无法确认 → Agent C
↓
Agent C：异常整理
↓
人工审批
编排器负责触发、分支、超时、重试和人工接管。每个节点只能接收约定的数据结构，输出不符合格式时不得继续向下执行。
财务制度可以通过 RAG 检索，但制度版本、生效日期和适用主体要由制度库明确管理。模型不能自行猜测哪份文件更新，也不能把检索到的旧条款当成现行规则。
所谓“反思”，最好写成可审计的重试规则。比如 ERP 没有返回对应采购单，系统先检查接口状态，再核对字段格式；允许模糊查询时，也必须记录查询参数和候选结果。仍然无法确认，就转人工。Agent 不能借“自我纠错”修改原始证据或绕过校验规则。
Agent B 的权限要单独设计
财务工作流接触 ERP 和银行流水，权限设计比 Prompt 写法更先决定系统能否上线。
每个 Agent 应使用独立的服务身份。Agent A 只能读取制度和单据字段；Agent B 只能调用白名单内的只读接口；Agent C 只接收完成脱敏的证据包。身份证号、银行卡号等与当前任务无关的字段，不应进入模型上下文。
RBAC 可以继续使用，同时还要在 API 网关补上更细的限制：
- 限定允许调用的接口、参数和数据范围；
- 为每次请求记录事务 ID、时间戳和调用结果；
- 对输出执行 DLP 检查和敏感字段脱敏；
- 保留规则版本、模型版本和工具调用日志；
- 把票据及 OCR 文本视为数据，禁止其中的内容改写系统指令。
这些记录要能回答一个实际问题：某张单据为什么被拦截，依据的是哪条制度，读取了哪些系统数据，最后由谁确认。
验收时，按节点算账
改造效果不能只看一张总分。更可靠的做法，是用同一批经过人工确认的历史单据，对单一 Prompt 和多 Agent 工作流做平行测试，并固定制度版本和判定口径。
至少分别检查这些指标：
- OCR 与字段提取错误发生在哪些票据类型；
- 每条规则的漏检和误报情况；
- ERP 对账失败是字段问题、接口问题还是确有异常；
- Agent C 的说明有多少被财务人员接受或改写；
- 每张单据调用了哪些工具和模型，耗时与成本如何；
- 任意结论能否回溯到原始单据、系统记录和制度条款。
如果一个错误无法定位到 OCR、规则、接口或说明节点，这条链路仍然难以维护。样本、基线和统计口径没有公开，也不宜宣称精确的漏检率或降本比例。
德勤的相关内容将 Agentic AI 概括为从“提效工具”走向“决策核心”。在审计场景中，更稳妥的边界是让 Agent 参与取数、核验和证据整理，审批与责任仍由获得授权的人承担。
真正需要放弃的，是让一个 Prompt 包办所有职责的设计。Prompt 仍然有用，只是每个节点都应更短、输入更窄、输出可验、权限受控。
