使用 OpenClaw 实现文档处理自动化

每项业务都依赖文档运行。发票、合同、采购订单、交货收据、合规报告、费用报销——数量永远不会减少，而且手动处理它们的成本是巨大的。保守估计，手动发票处理的平均成本为每份文档 12 至 16 美元，错误率在 3% 至 5% 之间。将其乘以每月数千份文档，自动化的案例就不言而喻了。

OpenClaw 的文档处理代理将 OCR、结构化数据提取、验证规则和 ERP 集成结合到单个自治管道中。其结果是系统可以接收文档，了解其类型和内容，根据业务规则验证数据，并将提取的信息路由到正确的目的地，而无需对大多数文档进行人工干预。

要点

• OpenClaw 文档代理通过统一的管道处理 PDF、扫描图像、带附件的电子邮件以及结构化文件格式（CSV、XML、EDI）。
• OCR 质量评分门控 AI 提取 — 低质量扫描会在处理继续之前触发重新扫描请求。
• 提取层结合使用布局分析、命名实体识别和基于 LLM 的解析，以实现跨文档格式的最大准确性。
• 在任何数据到达您的 ERP 之前，验证技能会根据供应商主记录、采购订单号、税码和业务规则检查提取的数据。
• 异常处理仅将真正不明确的文档路由给人类 - 代理提供了一个预先填写的表格及其最佳猜测，因此人类只需确认而不是重新输入。
• 管道可立即处理 300 多种文档类型；可以通过低代码模式编辑器添加自定义模板。
• 对于干净文档，从文档接收到 ERP 输入的端到端延迟平均低于 90 秒。
• ECOSIRE 构建和管理与 Odoo、SAP、QuickBooks 和自定义 ERP 集成的 OpenClaw 文档处理管道。

---

文档处理架构概述

生产 OpenClaw 文档处理管道由六个阶段组成，每个阶段都作为一项或多项技能实现：

Document Ingestion
        ↓
[ Classifier Agent ]     — document type detection, routing
        ↓
[ Extraction Agent ]     — OCR + structured data extraction
        ↓
[ Validation Agent ]     — business rule validation, master data lookup
        ↓
[ Enrichment Agent ]     — GL coding, cost center assignment, approver lookup
        ↓
[ Integration Agent ]    — ERP/downstream system write
        ↓
[ Exception Agent ]      — handles ambiguous documents, requests human review

每个代理独立运行并通过任务总线进行通信。任何阶段失败的文档都会被路由到异常代理，而不会丢失上游阶段已完成的工作。

---

文档摄取：接受每种格式

文档通过多种渠道到达：电子邮件附件、文件系统删除、API 上传、传真到电子邮件网关和供应商门户。摄取层将所有这些标准化为标准文档任务。

export const DocumentIngester = defineSkill({
  name: "document-ingester",
  tools: ["email", "storage", "queue"],
  async run({ input, tools }) {
    let rawFile: Buffer;
    let mimeType: string;

    if (input.source === "email") {
      const attachment = await tools.email.getAttachment(input.emailId, input.attachmentIndex);
      rawFile = attachment.buffer;
      mimeType = attachment.mimeType;
    } else if (input.source === "storage") {
      rawFile = await tools.storage.get(input.storageKey);
      mimeType = detectMimeType(rawFile);
    }

    // Normalize to PDF for consistent downstream processing
    const normalizedPdf = mimeType === "application/pdf"
      ? rawFile
      : await convertToPdf(rawFile, mimeType);

    const storageKey = `incoming/${Date.now()}-${generateId()}.pdf`;
    await tools.storage.put(storageKey, normalizedPdf);

    return {
      storageKey,
      originalSource: input.source,
      originalMimeType: mimeType,
      pagCount: await getPdfPageCount(normalizedPdf),
    };
  },
});

规范化步骤将 Word 文档、Excel 文件、图像文件（JPEG、PNG、TIFF）和电子邮件 HTML 正文转换为 PDF，然后再将其传递给下游。下游代理仅接收 PDF，这极大地简化了 OCR 和布局分析。

---

文档分类：了解您拥有什么

在提取开始之前，分类器代理会识别文档类型。分类很重要，因为不同的文档类型需要不同的提取模板——发票看起来与交货收据完全不同。

分类器使用两阶段方法：

第 1 阶段 — 布局分析：分析文档的视觉结构（表格位置、页眉块、页脚图案、徽标放置），以将文档类别缩小到一小组候选者。

第 2 阶段 - 内容分类：文本中的关键短语和结构模式确认特定的文档类型。分类器产生类型标签和置信度分数。

export const ClassifyDocument = defineSkill({
  name: "classify-document",
  tools: ["storage", "classification-model"],
  async run({ input, tools }) {
    const pdfBuffer = await tools.storage.get(input.storageKey);
    const layoutFeatures = await extractLayoutFeatures(pdfBuffer);
    const textContent = await performOcr(pdfBuffer, { mode: "fast" });

    const classification = await tools.classificationModel.classify({
      layoutFeatures,
      textContent: textContent.slice(0, 2000), // First 2000 chars for speed
    });

    if (classification.confidence < 0.70) {
      return {
        type: "unknown",
        confidence: classification.confidence,
        requiresManualClassification: true,
      };
    }

    return {
      type: classification.label,
      confidence: classification.confidence,
      requiresManualClassification: false,
      extractionTemplate: TEMPLATE_MAP[classification.label],
    };
  },
});

常见文档类型及其提取模板是预先构建的：供应商发票、贷项凭证、采购订单、交货单、银行对账单、合同、费用报告和报关单。可以通过模板编辑器添加新文档类型，而无需更改代码。

---

OCR 和提取：准确提取数据

萃取剂是大部分技术复杂性所在。它将 OCR 输出与布局分析和基于 LLM 的解析相结合，从非结构化文档生成结构化数据。

在 AI 提取开始之前评估 OCR 质量。如果 OCR 的平均字符置信度低于 0.80（表示扫描模糊、分辨率低或页面倾斜），代理会将文档标记为重新扫描，而不是继续处理不可靠的文本。

对于通过 OCR 质量检查的文档，提取分三遍进行：

第 1 遍 - 模板匹配：对于已知的供应商和文档格式，提取模板提供字段位置（坐标或正则表达式锚点）。对于已知来源的结构化文档，模板匹配快速且准确。

第 2 步 — 命名实体识别：NER 识别模板匹配遗漏的金额、日期、地址、标识符（发票号、采购订单号、增值税号）和行项目边界。

第 3 轮 — LLM 推理：对于不明确的字段或当前两轮产生低置信度值时，LLM 会解析周围的文本上下文以推断正确的值。

export const ExtractInvoiceData = defineSkill({
  name: "extract-invoice-data",
  tools: ["storage", "ocr-service", "llm"],
  async run({ input, tools, memory }) {
    const buffer = await tools.storage.get(input.storageKey);
    const ocrResult = await tools.ocrService.extract(buffer, { enhanceScannedPages: true });

    if (ocrResult.averageConfidence < 0.80) {
      return { success: false, reason: "LOW_OCR_QUALITY", ocrConfidence: ocrResult.averageConfidence };
    }

    // Pass 1: Template matching
    const templateFields = applyTemplate(ocrResult, input.extractionTemplate);

    // Pass 2: NER for missing fields
    const nerFields = await extractWithNer(ocrResult.text, { fieldTypes: ["amount", "date", "id"] });

    // Pass 3: LLM for remaining low-confidence fields
    const lowConfidenceFields = mergeAndFindGaps(templateFields, nerFields, { minConfidence: 0.85 });
    const llmFields = lowConfidenceFields.length > 0
      ? await tools.llm.extractFields(ocrResult.text, lowConfidenceFields)
      : {};

    const extracted = mergeExtractions(templateFields, nerFields, llmFields);
    await memory.working.set("extractedData", extracted);

    return { success: true, data: extracted, fieldConfidences: getFieldConfidences(extracted) };
  },
});

---

验证：在错误到达 ERP 之前捕获错误

提取的原始数据绝不会直接写入您的 ERP。在发布任何内容之前，验证代理会根据您的业务规则和主数据检查每个字段。

供应商发票的验证检查包括：

• 供应商存在：供应商名称和增值税号与供应商主数据中的记录匹配。
• PO 匹配：发票上的 PO 编号与未结 PO 匹配，且金额在容差范围内（为了实现发票灵活性，通常为 ±5%）。
• 重复检测：该供应商的发票号码在过去 180 天内尚未得到处理。
• 税收计算：行项目总计加税等于发票总计，在舍入容差范围内。
• 货币和汇率：外币发票根据发票日期的汇率进行验证。
• GL 期间：发票日期属于开放会计期间。

export const ValidateInvoice = defineSkill({
  name: "validate-invoice",
  tools: ["erp", "vendor-master"],
  async run({ input, tools }) {
    const errors: ValidationError[] = [];

    // Vendor validation
    const vendor = await tools.vendorMaster.findByVatNumber(input.data.vendorVat);
    if (!vendor) errors.push({ field: "vendorVat", code: "VENDOR_NOT_FOUND" });

    // PO match
    if (input.data.poNumber) {
      const po = await tools.erp.getPurchaseOrder(input.data.poNumber);
      if (!po) errors.push({ field: "poNumber", code: "PO_NOT_FOUND" });
      else if (Math.abs(po.totalAmount - input.data.totalAmount) / po.totalAmount > 0.05) {
        errors.push({ field: "totalAmount", code: "PO_AMOUNT_MISMATCH" });
      }
    }

    // Duplicate check
    const isDuplicate = await tools.erp.invoiceExists({
      vendorId: vendor?.id,
      invoiceNumber: input.data.invoiceNumber,
    });
    if (isDuplicate) errors.push({ field: "invoiceNumber", code: "DUPLICATE_INVOICE" });

    return {
      valid: errors.length === 0,
      errors,
      validatedData: errors.length === 0 ? input.data : null,
    };
  },
});

验证失败会路由到异常代理，而不是默默地删除文档。异常代理创建一个预填充了提取的数据和特定验证错误的审核任务，以便人们可以仅更正标记的字段。

---

丰富：添加业务上下文

干净、经过验证的数据在发布到 ERP 之前仍然需要业务背景。丰富代理添加文档不包含的信息：总帐科目代码、成本中心分配、税务处理代码、审批工作流分配和付款条件。

丰富规则在策略存储中定义，可以引用供应商属性、行项目描述、部门、项目代码和金额阈值。大多数丰富规则都是确定性查找；对于不明确的情况（带有可以映射到多个总帐帐户的描述的行项目），法学硕士提供了带有解释的排名建议列表。

---

ERP集成：第一次准确写入数据

集成代理将经过验证、丰富的数据发布到您的 ERP。它使用幂等 API 调用以及从原始文档的哈希派生的相关 ID — 如果重试 ERP 写入（由于网络超时），则可以防止重复记录。

export const PostToErp = defineSkill({
  name: "post-to-erp",
  tools: ["erp"],
  async run({ input, tools }) {
    const correlationId = hashDocument(input.storageKey);

    const result = await tools.erp.createVendorBill({
      correlationId, // ERP uses this for idempotency
      vendorId: input.enrichedData.vendorId,
      invoiceNumber: input.enrichedData.invoiceNumber,
      invoiceDate: input.enrichedData.invoiceDate,
      lineItems: input.enrichedData.lineItems,
      taxLines: input.enrichedData.taxLines,
      paymentTerms: input.enrichedData.paymentTerms,
      glCodes: input.enrichedData.glCodes,
    });

    return {
      erpRecordId: result.id,
      erpRecordUrl: result.url,
      posted: true,
    };
  },
});

发布后，原始文档将链接到 ERP 记录，并使用完整的元数据存档在您的文档管理系统中。审计跟踪是完整的：从电子邮件附件或文件通过每个处理阶段到最终的 ERP 条目。

---

异常处理：重要时的人机交互

并非每个文档都能得到干净的处理。异常代理处理四类异常：

1. 分类失败：无法有足够的信心确定文档类型。
2. 提取失败：无法提取关键字段（总金额、供应商 ID、发票编号）。
3. 验证失败：提取的数据未通过业务规则检查。
4. 集成失败：ERP 拒绝过帐（例如，关闭会计期间、帐户锁定）。

对于每个异常，代理会在您的帮助台或工作流程系统中创建一个审核任务，并使用预填写的表格显示代理的最佳尝试和特定错误。人工仅更正失败的字段并批准 - 代理处理重新提交。

---

常见问题

准确的 OCR 需要什么文档分辨率？

对于打印文档，150 DPI 是可接受的 OCR 结果的最低要求；为了可靠提取，建议使用 300 DPI。对于手写文档或字体非常小的文档，首选 400 DPI 或更高。 OCR 质量评估技能在提取开始之前将文档标记为低于阈值，从而自动触发重新扫描请求。

系统如何处理多页文档？

多页文档通过页边界检测进行处理。对于发票，代理会识别标题页、行项目页和任何延续页。布局分析图层可以正确重建跨越分页符的行项目。对于其他文档类型（合同、报告），代理会处理所有页面并聚合从每个页面提取的字段。

系统可以从人类所做的更正中学习吗？

是的。当人类更正异常文档时，更正结果将反馈给知识代理。如果相同的更正模式出现超过三次（例如，新供应商总是以非标准方式格式化其发票），系统会自动为该供应商建议新的提取模板。管理员审查并批准建议的模板，系统从那时起应用它，而无需对该供应商进行人工审查。

手写文档如何处理？

手写文档是最具挑战性的类别。 OCR 层对这些文档使用专门的手写识别模型，并且传递到 AI 提取的置信度阈值更高（印刷文档为 0.90 与 0.80）。在实践中，大多数企业文档工作流程可以通过流程变更（电子提交门户、数字签名工作流程）消除手写文档。对于必须处理手写文档的组织，ECOSIRE 建议对手写文档进行人工审核的混合方法。

支持哪些语言提取？

OpenClaw 的文档处理支持 40 多种 OCR 语言，并针对英语、德语、法语、西班牙语、阿拉伯语、中文（简体和繁体）、日语和葡萄牙语等主要商业文档格式验证了提取模板。对于其他语言，OCR 可以工作，但提取模板的质量取决于您的文档样本集。 LLM 推理层可以原生处理多种语言。

如何维护文档机密性？

文档在传输中 (TLS 1.3) 和静止时 (AES-256) 均进行加密。每个文档都在独立的上下文中进行处理，组织之间不会共享任何文档内容。对于高度敏感的文档（法律合同、财务报表），您可以将管道配置为使用本地 LLM 作为推理层，从而将文档内容完全保留在您的网络范围内。

发票处理的典型准确率是多少？

对于来自已知供应商且具有模板匹配的结构化发票，模板校准后，字段级准确度通常超过 99.5%。对于来自新供应商的非结构化发票，第一次尝试的准确性通常为 95-98%，并且随着系统了解供应商的格式而提高。跟踪的关键指标是异常率——配置良好的管道的异常率低于总文档量的 5%。

---

后续步骤

手动文档处理是一个成本中心，不会增加任何竞争价值。 OpenClaw 文档处理自动化将其从人员密集型操作转变为自动化管道，无需人工干预即可处理 95% 以上的文档量。

ECOSIRE 的 OpenClaw 实施团队 专门构建与 Odoo、SAP、QuickBooks 和自定义 ERP 集成的文档处理管道。我们处理文档分类模板设计、OCR 校准、验证规则配置、ERP 集成和异常工作流程设置 - 在六到八周内交付可投入生产的系统。

联系 ECOSIRE 以开始对您当前操作进行文档处理审核。