X-Financial/document/AI报销操作层_影子报销账本_开发文档.md

# AI 报销操作层 / 影子报销账本开发文档

> 版本：v0.1  
> 场景范围：仅聚焦“报销”场景，不包含合同审核、采购付款、总账、税务申报等后续场景。  
> 核心思路：以 Agent 层为业务中枢，在现有 OA / ERP / 费控系统之上构建 AI 原生的报销操作层与影子报销账本。

---

## 1. 项目定位

### 1.1 产品名称

暂定名称：

- AI 报销操作层
- 智能报销预审 Agent
- 影子报销账本
- 报销政策 Agent

推荐对外名称：

> **AI 报销预审中台**

推荐对内技术名称：

> **AI Reimbursement Operation Layer**

---

### 1.2 一句话定义

在企业现有 OA、ERP、费控系统之上，构建一个以 Agent 为核心的 AI 报销操作层，让员工不用直接面对复杂系统，只需上传票据和说明事项，由 Agent 自动完成材料整理、报销草稿生成、制度预审、缺件提醒、风险解释和后端系统同步。

---

### 1.3 核心目标

本系统不是替代 ERP，也不是重新做一套完整费控系统，而是作为现有系统之上的智能操作层。

核心目标包括：

1. 降低员工填单难度。
2. 减少财务审核打回。
3. 提高报销制度执行一致性。
4. 沉淀报销过程证据链。
5. 为后续扩展付款、采购、合同付款等财务 Agent 场景打基础。

---

### 1.4 产品边界

#### 本期做

- 票据 / 附件上传
- OCR 识别
- 报销草稿生成
- 费用类型识别
- 制度规则预审
- 缺件提醒
- 风险解释
- 用户补充确认
- 影子报销账本记录
- 后端系统同步接口预留
- 审计日志与规则命中记录

#### 本期不做

- 不做正式总账
- 不做凭证过账
- 不做税务申报
- 不做银行支付
- 不做完整预算控制
- 不做合同审核
- 不替换原 OA / ERP / 费控系统

---

## 2. 总体架构

### 2.1 架构原则

系统采用“前台 AI 操作层 + 中台 Agent 编排 + 影子报销账本 + 后端系统同步”的架构。

核心原则：

> **用户体验在 AI 报销操作层，正式账务仍在 ERP。**

> **Agent 负责理解、编排与交互；规则负责判断；系统负责留痕；后端负责正式审批和入账。**

---

### 2.2 架构分层

系统分为 6 层：

1. 用户与入口层
2. AI 报销操作层
3. Agent 层
4. 影子报销账本层
5. Policy & Evidence 层
6. System Adapter / 后端集成层

---

### 2.3 分层说明

#### 2.3.1 用户与入口层

面向对象：

- 员工
- 财务审核人员
- 制度管理员
- 系统管理员

入口方式：

- Web
- 企业微信
- 钉钉
- OA 工作台
- 移动端 H5

职责：

- 接收用户报销意图
- 上传票据和附件
- 展示预审结果
- 支持补件交互
- 支持确认提交

---

#### 2.3.2 AI 报销操作层

这是用户直接感知的业务操作层。

主要功能：

- 对话式报销入口
- 票据 / 附件上传
- 报销草稿展示
- 风险与缺件提示
- 预审结果解释
- 用户确认提交

该层的目标是让用户不再直接面对复杂 ERP 字段，而是通过自然语言、文件上传和确认操作完成报销。

---

#### 2.3.3 Agent 层

Agent 层是系统核心中枢，所有业务流程围绕 Agent 层展开。

Agent 层负责：

- 理解用户意图
- 编排任务流程
- 调用 OCR 工具
- 调用规则引擎
- 查询主数据
- 生成报销草稿
- 发起补件对话
- 输出风险解释
- 同步后端系统

核心组件：

- 受理 Agent
- 单据解析 Agent
- 规则校验 Agent
- 解释与补件 Agent
- 同步执行 Agent
- Agent Orchestrator / Workflow

---

#### 2.3.4 影子报销账本层

影子报销账本层用于沉淀报销业务事实，但不是正式总账。

它记录：

- 报销申请
- 报销明细
- 票据索引
- 附件索引
- 风险记录
- 规则命中记录
- 补件会话记录
- 后端同步状态

作用：

- 为前台提供统一业务视图
- 为 Agent 提供流程状态
- 为审计提供过程留痕
- 为后端系统同步提供中间状态

注意：

> 影子报销账本不是会计账，不承担正式记账职责。

---

#### 2.3.5 Policy & Evidence 层

该层负责规则判断和证据归档。

包含：

- 报销制度库
- 费用标准库
- 费用类型字典
- 城市等级 / 补贴规则
- 发票验真结果
- 发票查重结果
- 审计日志
- 证据归档库

作用：

- 为 Agent 提供制度依据
- 为规则引擎提供结构化规则
- 为财务审核提供可追溯证据
- 为后续审计提供完整证据链

---

#### 2.3.6 System Adapter / 后端集成层

负责连接企业已有系统。

可对接系统：

- OA / BPM 审批系统
- ERP / 财务系统
- 费控报销系统
- 预算系统
- 主数据系统
- 发票平台
- 税务接口
- 财务共享中心
- 企业微信 / 钉钉消息系统

职责：

- 查询主数据
- 查询预算信息
- 查询员工信息
- 写入报销草稿
- 发起审批流程
- 同步审批状态
- 同步归档结果

---

## 3. 核心业务流程

### 3.1 流程总览

完整流程如下：

1. 用户上传票据与出差信息
2. Agent 受理并理解任务
3. Agent 调用 OCR 和解析工具
4. Agent 识别费用类型并生成影子报销记录
5. Agent 调用规则引擎完成制度预审
6. Agent 输出风险解释和缺件提醒
7. 用户补充材料并确认
8. Agent 生成标准报销单
9. Agent 同步 OA / ERP / 费控系统
10. 后端完成正式审批、入账与归档

---

### 3.2 主流程时序

```mermaid
sequenceDiagram
    participant U as 用户
    participant UI as AI报销操作层
    participant AO as Agent Orchestrator
    participant OCR as OCR/票据识别
    participant Rule as 规则引擎
    participant Ledger as 影子报销账本
    participant Adapter as 后端适配器
    participant ERP as OA/ERP/费控系统

    U->>UI: 上传票据/说明报销事项
    UI->>AO: 创建报销任务
    AO->>OCR: 调用票据识别
    OCR-->>AO: 返回结构化票据信息
    AO->>Ledger: 创建影子报销记录
    AO->>Rule: 调用制度预审
    Rule-->>AO: 返回规则命中与风险结果
    AO->>UI: 展示风险/缺件/草稿
    U->>UI: 补充材料并确认
    UI->>AO: 提交确认
    AO->>Ledger: 更新报销状态
    AO->>Adapter: 生成标准报销单并同步
    Adapter->>ERP: 写入报销单/发起审批
    ERP-->>Adapter: 返回审批单号/状态
    Adapter-->>Ledger: 回写后端同步状态
```

---

### 3.3 Agent 驱动运行逻辑

```mermaid
flowchart TD
    A[用户上传票据与出差信息] --> B[受理 Agent 理解任务]
    B --> C[单据解析 Agent 识别票据与附件]
    C --> D[生成影子报销记录]
    D --> E[规则校验 Agent 调用制度规则]
    E --> F{是否存在风险或缺件}
    F -- 是 --> G[解释与补件 Agent 发起补件交互]
    G --> H[用户补充材料并确认]
    H --> E
    F -- 否 --> I[同步执行 Agent 生成标准报销单]
    I --> J[同步 OA / ERP / 费控系统]
    J --> K[后端正式审批、入账与归档]
```

---

## 4. Agent 设计

### 4.1 Agent 总体分工

| Agent | 职责 | 输入 | 输出 |
|---|---|---|---|
| 受理 Agent | 理解用户报销意图，收集上下文 | 用户自然语言、上传文件、历史任务 | 报销任务、材料清单、缺失信息 |
| 单据解析 Agent | OCR 识别、字段抽取、费用归类 | 发票、行程单、酒店单、支付截图 | 结构化票据信息、费用明细建议 |
| 规则校验 Agent | 制度预审、超标、查重、合规判断 | 报销草稿、规则库、主数据 | 规则命中记录、风险等级 |
| 解释与补件 Agent | 解释风险、提示缺件、引导修改 | 风险结果、缺件列表、制度依据 | 用户可理解的解释、补件任务 |
| 同步执行 Agent | 生成标准报销单，调用后端接口 | 最终确认数据、影子账本记录 | 后端报销单号、审批状态 |

---

### 4.2 Agent Orchestrator

Agent Orchestrator 是流程编排器，负责管理任务状态和 Agent 调度。

职责：

- 创建任务
- 维护任务状态
- 决定下一步调用哪个 Agent
- 管理多轮对话上下文
- 管理工具调用
- 处理失败重试
- 记录流程日志
- 管理人工确认节点

建议状态机：

```mermaid
stateDiagram-v2
    [*] --> Created: 创建任务
    Created --> MaterialCollecting: 收集材料
    MaterialCollecting --> Parsing: 解析单据
    Parsing --> DraftGenerated: 生成草稿
    DraftGenerated --> PreChecking: 制度预审
    PreChecking --> NeedSupplement: 存在缺件/风险
    NeedSupplement --> MaterialCollecting: 用户补件
    PreChecking --> PendingUserConfirm: 预审通过
    PendingUserConfirm --> Submitting: 用户确认
    Submitting --> Synced: 同步后端成功
    Submitting --> SyncFailed: 同步失败
    SyncFailed --> Submitting: 重试
    Synced --> [*]
```

---

### 4.3 Agent 调用原则

Agent 不直接决定最终财务结果，只负责预审和建议。

原则：

1. 低风险问题可自动提示。
2. 中风险问题需要用户确认。
3. 高风险问题进入人工审核。
4. 所有规则命中必须留痕。
5. 所有 AI 解释必须能追溯到制度或证据。
6. 正式审批和入账仍以后端系统为准。

---

## 5. 核心数据模型

### 5.1 主要实体

| 实体 | 说明 |
|---|---|
| ReimbursementTask | 报销任务，Agent 处理的最小任务单元 |
| ShadowReimbursement | 影子报销记录，表示一次报销业务事实 |
| ReimbursementItem | 报销明细 |
| ExpenseDocument | 票据 / 附件 |
| ExpensePolicy | 报销制度 |
| ExpenseRule | 报销规则 |
| RuleHit | 规则命中记录 |
| RiskFinding | 风险提示 |
| SupplementRequest | 补件请求 |
| ConversationRecord | 会话记录 |
| SyncRecord | 后端同步记录 |
| AuditLog | 审计日志 |

---

### 5.2 表结构建议

#### 5.2.1 reimbursement_task 报销任务表

| 字段 | 类型 | 说明 |
|---|---|---|
| id | string | 任务ID |
| user_id | string | 发起人ID |
| company_id | string | 企业ID |
| task_type | string | 任务类型，如 travel_expense |
| status | string | 任务状态 |
| user_intent | text | 用户原始意图 |
| current_agent | string | 当前处理 Agent |
| created_at | datetime | 创建时间 |
| updated_at | datetime | 更新时间 |

---

#### 5.2.2 shadow_reimbursement 影子报销记录表

| 字段 | 类型 | 说明 |
|---|---|---|
| id | string | 影子报销ID |
| task_id | string | 关联任务ID |
| applicant_id | string | 报销人 |
| department_id | string | 部门 |
| cost_center_id | string | 成本中心 |
| project_id | string | 项目ID |
| reimbursement_type | string | 报销类型 |
| reason | text | 报销事由 |
| total_amount | decimal | 总金额 |
| currency | string | 币种 |
| risk_level | string | 风险等级 |
| precheck_status | string | 预审状态 |
| backend_system | string | 目标后端系统 |
| backend_bill_id | string | 后端单据ID |
| sync_status | string | 同步状态 |
| created_at | datetime | 创建时间 |
| updated_at | datetime | 更新时间 |

---

#### 5.2.3 reimbursement_item 报销明细表

| 字段 | 类型 | 说明 |
|---|---|---|
| id | string | 明细ID |
| reimbursement_id | string | 影子报销ID |
| expense_type | string | 费用类型 |
| amount | decimal | 金额 |
| tax_amount | decimal | 税额 |
| occurred_at | date | 费用发生日期 |
| city | string | 发生城市 |
| vendor_name | string | 商户名称 |
| invoice_id | string | 关联票据ID |
| policy_status | string | 规则校验状态 |
| risk_level | string | 风险等级 |
| remark | text | 备注 |

---

#### 5.2.4 expense_document 票据附件表

| 字段 | 类型 | 说明 |
|---|---|---|
| id | string | 文件ID |
| reimbursement_id | string | 影子报销ID |
| item_id | string | 明细ID |
| document_type | string | 发票、行程单、酒店流水、支付截图等 |
| file_url | string | 文件地址 |
| ocr_status | string | OCR 状态 |
| extracted_json | json | OCR 抽取结果 |
| invoice_code | string | 发票代码 |
| invoice_number | string | 发票号码 |
| invoice_date | date | 开票日期 |
| amount | decimal | 金额 |
| tax_amount | decimal | 税额 |
| seller_name | string | 销售方 |
| buyer_name | string | 购买方 |
| verify_status | string | 验真状态 |
| duplicate_status | string | 查重状态 |
| created_at | datetime | 创建时间 |

---

#### 5.2.5 expense_rule 规则表

| 字段 | 类型 | 说明 |
|---|---|---|
| id | string | 规则ID |
| rule_code | string | 规则编码 |
| rule_name | string | 规则名称 |
| expense_type | string | 适用费用类型 |
| condition_json | json | 条件表达式 |
| action | string | 命中动作 |
| severity | string | 风险等级 |
| message_template | text | 提示文案模板 |
| policy_ref | string | 制度依据 |
| enabled | boolean | 是否启用 |
| version | string | 规则版本 |

---

#### 5.2.6 rule_hit 规则命中表

| 字段 | 类型 | 说明 |
|---|---|---|
| id | string | 命中ID |
| reimbursement_id | string | 报销ID |
| item_id | string | 明细ID |
| rule_id | string | 规则ID |
| severity | string | 风险等级 |
| hit_result | json | 命中详情 |
| explanation | text | 解释说明 |
| suggestion | text | 修改建议 |
| created_at | datetime | 创建时间 |

---

#### 5.2.7 supplement_request 补件请求表

| 字段 | 类型 | 说明 |
|---|---|---|
| id | string | 补件请求ID |
| reimbursement_id | string | 报销ID |
| request_type | string | 补充附件、补充说明、修改字段 |
| target_item_id | string | 关联明细ID |
| message | text | 补件提示 |
| status | string | 待补充、已补充、已关闭 |
| user_response | text | 用户回复 |
| created_at | datetime | 创建时间 |
| resolved_at | datetime | 完成时间 |

---

#### 5.2.8 sync_record 后端同步记录表

| 字段 | 类型 | 说明 |
|---|---|---|
| id | string | 同步ID |
| reimbursement_id | string | 报销ID |
| target_system | string | 目标系统 |
| request_payload | json | 请求报文 |
| response_payload | json | 响应报文 |
| sync_status | string | 成功、失败、重试中 |
| backend_bill_id | string | 后端单据ID |
| error_message | text | 错误信息 |
| created_at | datetime | 创建时间 |

---

## 6. 枚举设计

### 6.1 报销任务状态

| 编码 | 名称 |
|---|---|
| created | 已创建 |
| material_collecting | 收集中 |
| parsing | 解析中 |
| draft_generated | 草稿已生成 |
| prechecking | 预审中 |
| need_supplement | 需要补件 |
| pending_user_confirm | 待用户确认 |
| submitting | 提交中 |
| synced | 已同步 |
| sync_failed | 同步失败 |
| closed | 已关闭 |

---

### 6.2 费用类型

| 编码 | 名称 |
|---|---|
| travel_transport | 差旅交通费 |
| travel_hotel | 差旅住宿费 |
| travel_meal | 差旅餐补 |
| local_transport | 市内交通费 |
| business_meal | 业务招待费 |
| office_supply | 办公用品费 |
| communication | 通讯费 |
| other | 其他 |

---

### 6.3 票据类型

| 编码 | 名称 |
|---|---|
| vat_invoice | 增值税发票 |
| train_ticket | 火车票 |
| flight_itinerary | 航空行程单 |
| taxi_receipt | 打车票据 |
| hotel_bill | 酒店流水 |
| payment_screenshot | 支付截图 |
| travel_order | 行程单 |
| other_attachment | 其他附件 |

---

### 6.4 风险等级

| 编码 | 名称 | 处理方式 |
|---|---|---|
| low | 低风险 | 提醒用户 |
| medium | 中风险 | 需要用户确认或补充说明 |
| high | 高风险 | 建议人工审核 |
| blocked | 阻断 | 不允许提交 |

---

### 6.5 规则动作

| 编码 | 名称 |
|---|---|
| pass | 通过 |
| warn | 警告 |
| require_explanation | 要求说明 |
| require_attachment | 要求补附件 |
| require_approval | 要求特殊审批 |
| block | 阻断提交 |

---

## 7. 规则引擎设计

### 7.1 规则类型

MVP 阶段建议支持以下规则：

1. 必填字段校验
2. 附件完整性校验
3. 票据验真校验
4. 重复报销校验
5. 金额超标校验
6. 日期合理性校验
7. 出差期间匹配校验
8. 费用类型与票据类型匹配校验
9. 发票抬头校验
10. 项目 / 成本中心校验

---

### 7.2 规则示例

#### 规则 1：住宿费超标

```json
{
  "rule_code": "TRAVEL_HOTEL_LIMIT",
  "rule_name": "住宿费标准校验",
  "expense_type": "travel_hotel",
  "condition": {
    "compare": "amount_per_night",
    "operator": ">",
    "target": "policy.hotel_limit"
  },
  "action": "require_explanation",
  "severity": "medium",
  "message_template": "住宿费超出当前城市和职级标准，请补充超标说明或发起特殊审批。",
  "policy_ref": "差旅报销制度-住宿标准"
}
```

#### 规则 2：缺少酒店流水

```json
{
  "rule_code": "HOTEL_BILL_REQUIRED",
  "rule_name": "住宿费必须上传酒店流水",
  "expense_type": "travel_hotel",
  "condition": {
    "required_document_type": "hotel_bill"
  },
  "action": "require_attachment",
  "severity": "medium",
  "message_template": "当前住宿费缺少酒店流水，请补充上传。",
  "policy_ref": "差旅报销制度-附件要求"
}
```

#### 规则 3：票据疑似重复

```json
{
  "rule_code": "DUPLICATE_INVOICE_CHECK",
  "rule_name": "重复发票检查",
  "expense_type": "*",
  "condition": {
    "duplicate_keys": ["invoice_code", "invoice_number", "amount", "invoice_date"]
  },
  "action": "block",
  "severity": "blocked",
  "message_template": "检测到该发票可能已被报销，请确认或联系财务处理。",
  "policy_ref": "费用报销管理办法-重复报销"
}
```

---

### 7.3 规则结果结构

```json
{
  "precheck_status": "need_supplement",
  "risk_level": "medium",
  "rule_hits": [
    {
      "rule_code": "HOTEL_BILL_REQUIRED",
      "severity": "medium",
      "message": "当前住宿费缺少酒店流水，请补充上传。",
      "suggestion": "请上传酒店结账单或住宿明细流水。",
      "policy_ref": "差旅报销制度-附件要求"
    }
  ]
}
```

---

## 8. API 设计

### 8.1 创建报销任务

```http
POST /api/reimbursement/tasks
```

请求：

```json
{
  "user_id": "U001",
  "company_id": "C001",
  "user_intent": "我要报这次北京出差的费用",
  "entry_channel": "web"
}
```

响应：

```json
{
  "task_id": "T202604240001",
  "status": "material_collecting"
}
```

---

### 8.2 上传票据附件

```http
POST /api/reimbursement/tasks/{task_id}/documents
```

请求：

```json
{
  "document_type": "vat_invoice",
  "file_url": "https://example.com/file/invoice001.pdf"
}
```

响应：

```json
{
  "document_id": "D001",
  "ocr_status": "pending"
}
```

---

### 8.3 启动 Agent 处理

```http
POST /api/reimbursement/tasks/{task_id}/agent/run
```

请求：

```json
{
  "start_from": "intake",
  "mode": "precheck"
}
```

响应：

```json
{
  "task_id": "T202604240001",
  "status": "parsing",
  "current_agent": "document_parse_agent"
}
```

---

### 8.4 获取报销草稿

```http
GET /api/reimbursement/tasks/{task_id}/draft
```

响应：

```json
{
  "reimbursement_id": "R001",
  "reason": "北京出差",
  "total_amount": 2380.00,
  "items": [
    {
      "item_id": "I001",
      "expense_type": "travel_hotel",
      "amount": 1200.00,
      "occurred_at": "2026-04-20",
      "risk_level": "medium"
    }
  ],
  "precheck_status": "need_supplement"
}
```

---

### 8.5 获取预审结果

```http
GET /api/reimbursement/tasks/{task_id}/precheck-result
```

响应：

```json
{
  "precheck_status": "need_supplement",
  "risk_level": "medium",
  "summary": "当前报销单存在 1 个缺件问题和 1 个超标风险。",
  "rule_hits": [
    {
      "rule_code": "HOTEL_BILL_REQUIRED",
      "severity": "medium",
      "message": "住宿费缺少酒店流水。",
      "suggestion": "请上传酒店流水。"
    }
  ]
}
```

---

### 8.6 用户补件

```http
POST /api/reimbursement/tasks/{task_id}/supplements
```

请求：

```json
{
  "supplement_request_id": "S001",
  "response_text": "已补充酒店流水",
  "document_ids": ["D003"]
}
```

响应：

```json
{
  "status": "received",
  "next_action": "rerun_precheck"
}
```

---

### 8.7 用户确认提交

```http
POST /api/reimbursement/tasks/{task_id}/submit
```

请求：

```json
{
  "confirmed": true,
  "submit_to": "expense_system"
}
```

响应：

```json
{
  "status": "submitting",
  "sync_id": "SYNC001"
}
```

---

### 8.8 查询同步状态

```http
GET /api/reimbursement/tasks/{task_id}/sync-status
```

响应：

```json
{
  "sync_status": "success",
  "target_system": "expense_system",
  "backend_bill_id": "BX202604240001"
}
```

---

## 9. 前端页面设计

### 9.1 页面清单

MVP 阶段建议包含以下页面：

1. 报销入口页
2. 票据上传页
3. 报销草稿页
4. 预审结果页
5. 补件交互页
6. 提交确认页
7. 任务详情页
8. 财务审核辅助页
9. 制度规则管理页
10. 审计日志页

---

### 9.2 报销入口页

核心元素：

- 对话输入框
- 上传按钮
- 最近任务
- 常用报销类型
- 智能引导问题

示例提示：

- “我要报一次差旅”
- “帮我看这些票能不能报”
- “帮我生成报销单”
- “这张发票为什么不合规？”

---

### 9.3 报销草稿页

展示内容：

- 报销人
- 部门
- 成本中心
- 项目
- 报销事由
- 费用明细
- 票据附件
- 自动识别结果
- 可编辑字段
- 预审状态

---

### 9.4 预审结果页

展示内容：

- 总体结论
- 风险等级
- 通过项
- 风险项
- 缺件项
- 命中规则
- 制度依据
- 修改建议
- 一键补件按钮
- 人工确认按钮

---

### 9.5 财务审核辅助页

展示内容：

- 报销单摘要
- AI 预审结论
- 规则命中列表
- 用户补件记录
- 附件证据链
- 同步状态
- 审计日志

---

## 10. 后端服务设计

### 10.1 服务拆分建议

MVP 阶段可采用模块化单体，后续再微服务化。

建议模块：

| 模块 | 说明 |
|---|---|
| user-service | 用户与权限 |
| task-service | 报销任务管理 |
| document-service | 文件与票据管理 |
| agent-service | Agent 编排 |
| ocr-service | OCR 调用封装 |
| rule-service | 规则引擎 |
| ledger-service | 影子账本 |
| evidence-service | 证据归档 |
| adapter-service | 后端系统适配 |
| audit-service | 审计日志 |

---

### 10.2 推荐技术栈

可选方案：

#### 前端

- React / Vue
- Ant Design / Element Plus
- 企业微信 / 钉钉 H5 SDK

#### 后端

- Java Spring Boot
- Python FastAPI
- Node.js NestJS

#### 数据库

- PostgreSQL / MySQL
- Redis
- MinIO / OSS 文件存储
- Elasticsearch / OpenSearch，可选，用于检索

#### AI / Agent

- Agent Orchestrator 自研
- LangGraph / CrewAI / AutoGen / 自定义 Workflow，可选
- 大模型 API
- OCR API
- 向量数据库，可选

#### 规则引擎

- JSON Rule Engine
- Drools
- 自研轻量规则引擎

---

## 11. 权限与安全

### 11.1 权限角色

| 角色 | 权限 |
|---|---|
| 员工 | 创建报销、上传材料、查看自己的任务 |
| 财务审核人员 | 查看待审核报销、查看预审结果、处理风险 |
| 制度管理员 | 维护制度、规则、费用标准 |
| 系统管理员 | 管理组织、用户、接口配置 |
| 审计人员 | 查看日志和证据链 |

---

### 11.2 安全要求

- 文件上传需做病毒扫描。
- 发票、身份证、银行卡等敏感信息需脱敏展示。
- 所有 Agent 操作需记录日志。
- 所有规则版本需保留历史。
- 所有用户确认动作需留痕。
- 后端接口需有签名、鉴权和重放保护。
- 不允许 Agent 绕过人工确认直接提交高风险单据。

---

## 12. 审计与可解释性

### 12.1 必须留痕的动作

- 用户上传文件
- OCR 识别结果
- Agent 调用记录
- 规则命中记录
- 用户补件记录
- 用户确认记录
- 后端同步请求
- 后端同步响应
- 审核人处理记录

---

### 12.2 解释输出模板

风险解释建议采用统一格式：

```text
问题类型：住宿费超标
命中规则：TRAVEL_HOTEL_LIMIT
制度依据：差旅报销制度-住宿标准
问题说明：当前住宿费为 680 元/晚，超过该城市标准 500 元/晚。
建议处理：请补充超标说明，或发起特殊审批。
风险等级：中风险
```

---

## 13. MVP 版本规划

### 13.1 MVP 目标

用最小范围跑通“上传材料 → 识别 → 草稿 → 预审 → 补件 → 确认 → 同步”的完整闭环。

---

### 13.2 MVP 功能范围

#### 必做

- 用户创建报销任务
- 上传票据 / 附件
- OCR 识别
- 自动生成报销草稿
- 费用类型识别
- 基础规则预审
- 风险与缺件提示
- 用户补件
- 用户确认提交
- 影子报销账本
- 审计日志
- 模拟后端同步

#### 可延后

- 多企业多租户
- 复杂审批流
- 深度 ERP 接口
- 发票实时验真
- 预算强控制
- 移动端完整体验
- 多语言
- 行业模板市场

---

### 13.3 MVP 优先支持的报销类型

建议优先支持：

> 差旅报销

原因：

- 票据类型丰富
- 规则典型
- 缺件场景多
- 价值容易演示
- 客户容易理解

优先支持票据：

- 增值税发票
- 火车票
- 机票行程单
- 酒店流水
- 打车票据
- 支付截图

---

## 14. 里程碑计划

### 阶段 1：原型验证

目标：

- 完成核心流程 Demo
- 完成影子账本基础表
- 完成 OCR 接入
- 完成 5 条基础规则

输出：

- Web Demo
- 报销任务流
- 草稿生成页面
- 预审结果页面

---

### 阶段 2：MVP 可用版本

目标：

- 完整跑通差旅报销
- 支持多轮补件
- 支持规则命中留痕
- 支持模拟后端同步

输出：

- MVP 系统
- 规则配置后台
- 审计日志
- 财务审核辅助页

---

### 阶段 3：试点企业接入

目标：

- 接入一家试点企业
- 对接其 OA / 费控 / ERP 中至少一个系统
- 根据真实制度配置规则
- 验证打回率降低效果

输出：

- 试点报告
- 规则模板
- 接口适配经验
- ROI 数据

---

### 阶段 4：产品化

目标：

- 多企业配置
- 多制度模板
- 多后端适配器
- 管理后台完善
- 权限与安全完善

输出：

- 标准产品版本
- 部署手册
- 运维手册
- 行业模板

---

## 15. 关键指标

### 15.1 业务指标

| 指标 | 说明 |
|---|---|
| 自动草稿生成率 | 上传材料后成功生成草稿的比例 |
| 预审命中率 | 规则识别出问题的比例 |
| 打回率降低 | 接入前后报销打回率变化 |
| 平均填单时间 | 员工完成报销所需时间 |
| 平均审核时间 | 财务审核单据所需时间 |
| 补件一次完成率 | 用户一次补齐材料的比例 |

---

### 15.2 技术指标

| 指标 | 说明 |
|---|---|
| OCR 准确率 | 关键字段识别准确率 |
| 规则执行耗时 | 单次预审耗时 |
| Agent 成功完成率 | Agent 完整跑完流程的比例 |
| 后端同步成功率 | 同步 OA / ERP / 费控成功率 |
| 系统响应时间 | 主要接口响应时延 |
| 任务异常率 | Agent 流程失败比例 |

---

## 16. 风险与应对

### 16.1 规则不准确

风险：

- 制度复杂，规则配置错误会导致误判。

应对：

- 规则上线前必须人工确认。
- 规则命中要显示依据。
- 高风险结果只建议，不自动阻断。

---

### 16.2 OCR 识别错误

风险：

- 票据字段识别不准，导致草稿错误。

应对：

- 关键字段允许人工修改。
- 低置信度字段高亮提示。
- 原图与识别结果并排展示。

---

### 16.3 后端系统难对接

风险：

- 企业 ERP / OA 接口不统一。

应对：

- 先做模拟同步。
- 后端适配器标准化。
- 支持 API 与 RPA 两种方式。

---

### 16.4 AI 幻觉

风险：

- Agent 可能生成不符合制度的解释。

应对：

- 所有解释必须基于规则命中和制度片段。
- 没有依据时必须显示“未找到明确制度依据”。
- 高风险判断进入人工审核。

---

### 16.5 客户担心替换原系统

风险：

- 客户认为系统会冲击现有 ERP / 费控系统。

应对：

- 明确定位为“前台 AI 操作层”。
- 正式审批、入账、归档仍在后端系统完成。
- 强调不替换原系统。

---

## 17. 后续扩展方向

本期只做报销，后续可扩展到：

1. 付款申请
2. 采购申请
3. 合同付款
4. 供应商对账
5. 发票入账
6. 预算执行分析
7. 财务共享审核 Agent

长期目标：

> 构建企业财务运营 Agent Layer。

---

## 18. 附录：推荐目录结构

```text
ai-reimbursement-agent/
├── frontend/
│   ├── pages/
│   ├── components/
│   └── services/
├── backend/
│   ├── task-service/
│   ├── document-service/
│   ├── agent-service/
│   ├── rule-service/
│   ├── ledger-service/
│   ├── evidence-service/
│   ├── adapter-service/
│   └── audit-service/
├── database/
│   ├── migrations/
│   └── seed/
├── docs/
│   ├── api.md
│   ├── rules.md
│   ├── data-model.md
│   └── deployment.md
└── README.md
```

---

## 19. 附录：最小开发任务拆分

### 后端任务

- [ ] 创建报销任务接口
- [ ] 上传附件接口
- [ ] OCR 调用封装
- [ ] 影子报销账本表
- [ ] 报销明细表
- [ ] 规则引擎基础能力
- [ ] 规则命中记录
- [ ] 补件请求接口
- [ ] 后端同步模拟接口
- [ ] 审计日志

### 前端任务

- [ ] 报销入口页
- [ ] 上传附件组件
- [ ] 报销草稿页
- [ ] 预审结果页
- [ ] 补件交互页
- [ ] 提交确认页
- [ ] 财务审核辅助页

### Agent 任务

- [ ] 受理 Agent
- [ ] 单据解析 Agent
- [ ] 规则校验 Agent
- [ ] 解释与补件 Agent
- [ ] 同步执行 Agent
- [ ] Orchestrator 状态机

### 规则任务

- [ ] 必填字段规则
- [ ] 缺附件规则
- [ ] 重复发票规则
- [ ] 金额超标规则
- [ ] 日期异常规则
- [ ] 费用类型匹配规则

---

## 20. 总结

本系统的核心不是重新做一套报销系统，也不是替换 ERP，而是在企业现有系统之上构建一个以 Agent 为核心的 AI 报销操作层。

它的关键价值在于：

- 员工只面对简单前台。
- Agent 负责理解、编排和补件。
- 影子报销账本沉淀业务事实。
- Policy & Evidence 层保证判断可解释、证据可追溯。
- 后端 OA / ERP / 费控系统继续负责正式审批、入账和归档。

一句话总结：

> **前台体验在 AI 报销操作层，正式账务仍在 ERP；所有业务流程围绕 Agent 层展开。**