可易

用 Amazon Bedrock AgentCore 构建可自我改进的文档处理

可易团队阅读约 11 分钟

说明如何用 AgentCore 部署可分类、抽取、核验并自学的文档处理系统，含步骤、架构、样例与月成本。

目录

#用 Amazon Bedrock AgentCore 构建可自我改进的文档处理

IDC 研究（https://warekennis.nl/wp-content/uploads/2013/11/bridging-the-information-worker-productivity-gap.pdf）显示，与文档相关的挑战每年为每位信息工作者造成 19,732 美元成本，并使生产率降低 21.3%。接收数百家供应商发票的组织，常常面对因开具方而异、且会在无通知时改变的版式。基于模板的系统在这种规模下需要持续维护。员工最多可以把 30% 的时间花在与文档相关的任务上，手工数据录入错误率在 1%–4% 之间（https://askelie.io/manual-document-processing-costs/）。传统智能文档处理（intelligent document processing, IDP）方案减轻了部分负担，但它们要求为每种文档格式做大量前期配置，并且在各供应商版式不同时会失效。

在本文中，你将学习如何使用 Amazon Bedrock AgentCore（https://aws.amazon.com/bedrock/agentcore/）构建一套智能体式（agentic）IDP 系统，以最少的人工干预对业务文档进行分类、抽取、核验并从中学习。Amazon Bedrock AgentCore 是一个平台，可用任意框架或模型大规模构建、连接并优化智能体（agent）。你的智能体会自动处理新的文档格式，例如供应商发票、采购订单、保险理赔和贷款申请。读完本文后，你可以：

  • 部署一套多智能体 IDP 系统，通常不到 20 分钟。
  • 处理新的文档类型，而无需手工配置模板。
  • 让智能体针对每种新文档格式自行训练，并复用所学内容，从而使该类型的后续文档直接进入抽取，而不必重新训练。

基于规则的文档处理所面临的挑战

许多 IDP 流水线要求你预先为每种文档格式定义模板、抽取规则和核验逻辑。当新供应商发来版式不同的采购订单时，流水线就会中断。这带来三个核心挑战：

  1. 模板僵化： 每种新文档格式都需要手工配置，即便很小的版式变化也可能导致抽取失败。
  2. 不会学习： 相同的抽取错误会在相似文档上重复出现，因为系统不保留先前纠正中的知识。
  3. 扩展负担： 每一个新供应商或文档变体都会成倍增加维护工作，处理来自数百个来源的文档的组织面临持续的运营成本。

智能体式方法应对这些挑战。它不用静态模板，而是由人工智能（artificial intelligence, AI）智能体分析每份文档、生成抽取指令、核验结果，并自动从纠正中学习。随着时间推移，你的系统会建立文档格式知识库（knowledge base），从而用最少的额外配置处理相似文档。

解决方案概述

在本解决方案中，八个专用智能体在运行于 Amazon Bedrock AgentCore 上的两条基于图的工作流中协作。

下图展示使用 Strands Agents（https://strandsagents.com）构建的多智能体工作流图。Strands Agents 是一个用于构建 AI 智能体的开源 SDK。

图 1：多智能体编排工作流图

  • 识别工作流： Analyzer 智能体使用 Amazon Textract（https://aws.amazon.com/textract/）抽取文本，并识别文档类型和发送方。Matcher 智能体使用 Amazon S3 Vectors（https://aws.amazon.com/s3/features/vectors/）中的向量（vector）相似度搜索相似文档。S3 Vectors 是 Amazon Simple Storage Service（Amazon S3）的一项能力。
  • 训练工作流（新文档类型）：找不到匹配时，Instructions 智能体生成抽取提示（prompt），Extractor 智能体抽取结构化数据，Validator 智能体对照 Amazon Aurora DSQL（https://aws.amazon.com/rds/aurora/dsql/）中的模式（schema）和业务规则检查结果。如果核验失败，Instructions Fixer 智能体改进提示并重试。成功后，Save Instructions 智能体持久化这些指令以供复用。
  • 自动化工作流（已知文档类型）：找到匹配时，Extractor 智能体使用已有指令。如果核验失败，Troubleshooter 智能体直接修复抽取的数据，而不修改指令。

工作方式

下图展示该解决方案的基础设施架构。

图 2：AWS 上的智能体式 IDP 基础设施架构

  1. 业务文档到达 Amazon Simple Email Service（https://aws.amazon.com/ses/）（Amazon SES），或直接上传到 Amazon S3。
  2. Amazon EventBridge（https://aws.amazon.com/eventbridge/）触发一个 AWS Lambda（https://aws.amazon.com/lambda/）函数，该函数在 Amazon DynamoDB（https://aws.amazon.com/dynamodb/）中创建跟踪作业，并调用 AgentCore 运行时（runtime）。AgentCore 运行时是 Amazon Bedrock AgentCore 的一项能力。
  3. AgentCore 运行时通过 Strands Agents 编排文档处理。
  4. 你的智能体通过由 AgentCore Identity 和 Amazon Cognito（https://aws.amazon.com/cognito/）管理的机器到机器凭证，安全访问 AWS 资源。AgentCore Identity 是 Amazon Bedrock AgentCore 的一项能力。
  5. 你的 Lambda 函数通过 AgentCore Gateway 的模型上下文协议（Model Context Protocol, MCP）接口，成为智能体可用的工具。AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项能力。
  6. 智能体使用 Amazon Textract 抽取文本，使用 S3 Vectors 中的向量嵌入（embedding）对文档分类，并对照 Aurora DSQL 中的业务规则核验数据。
  7. 智能体通过 MCP 服务器访问企业数据，以便对照业务规则核验抽取的内容。
  8. 你通过托管在 Amazon Elastic Container Service（https://aws.amazon.com/ecs/）（Amazon ECS）上、支持聊天的仪表板监视状态并排查问题。
  9. 你通过 AgentCore Observability 和 Amazon CloudWatch（https://aws.amazon.com/cloudwatch/）遥测了解智能体性能。AgentCore Observability 是 Amazon Bedrock AgentCore 的一项能力。

部署解决方案

按以下步骤把解决方案基础设施和 Web UI 部署到你的 AWS 账户。

前提条件

要部署此解决方案，你必须具备：

  • 一个 AWS 账户（https://portal.aws.amazon.com/gp/aws/developer/registration/index.html）。
  • 对 Amazon Bedrock（https://aws.amazon.com/bedrock/）的访问，并已启用 Amazon Nova 和 Anthropic（Claude）模型。关于各 AWS 区域的模型可用性，参阅 Amazon Bedrock 中按 AWS 区域列出的受支持模型（https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html）。
  • 在受支持区域（https://docs.aws.amazon.com/bedrock/latest/userguide/bedrock-regions.html）中对 Amazon Bedrock AgentCore（Runtime、Gateway、Identity）、S3 Vectors 和 Amazon Aurora DSQL 的访问。
  • 已安装 AWS Cloud Development Kit（https://aws.amazon.com/cdk/）（AWS CDK）v2。
  • 已安装并正在运行 Docker（https://docs.docker.com/get-docker/）（构建和部署容器镜像所必需）。
  • Python 3.11+ 和 Node.js 18+。
  • AWS Identity and Access Management（https://aws.amazon.com/iam/）（IAM）权限，以便创建 S3 存储桶、Lambda 函数、DynamoDB 表、Cognito 用户池、Amazon Elastic Container Registry（Amazon ECR）仓库和 Amazon ECS 服务。
  1. 克隆仓库（https://github.com/aws-samples/aws-ai-intelligent-document-processing/tree/main/guidance/agentic-orchestration）并设置环境：
git clone https://github.com/aws-samples/agenticidp-guidance.git
cd agenticidp-guidance

uv venv
source .venv/bin/activate
uv pip install -r requirements.txt

cd ui/orchestrator
npm install
cd ../..
  1. 部署堆栈：
uv run deploy.py --admin-email your-email@example.com

这会部署六个 AWS CloudFormation（https://aws.amazon.com/cloudformation/）堆栈：Core（S3、Cognito、DynamoDB）、Gateway（Lambda 工具、AgentCore Gateway）、Aurora（Amazon Aurora DSQL）、Agent（AgentCore 运行时、容器）、UI Orchestrator（API 端点）和 Modern UI（Amazon CloudFront（https://aws.amazon.com/cloudfront/）上的 React 应用）。部署大约需要 15–20 分钟。

  1. 在 CloudFormation 控制台中检查每个堆栈显示 CREATE_COMPLETE，以核验部署。

处理文件并查看结果

部署之后，你会收到一封包含 CloudFront URL、用户名和临时密码的电子邮件。

处理一份文档

  1. 登录 Web UI，并选择 Process Document。
  2. 从 infrastructure/sample_data/purchase_orders/training/ 上传一份示例采购订单。
  3. 文档进入智能体工作流：Analyzer 智能体抽取文本并识别发送方和文档类型。Matcher 智能体在向量存储中搜索相似文档。对于新文档类型，训练工作流生成抽取指令、抽取数据、核验数据，并保存指令供将来使用。对于已知文档类型，自动化工作流使用已有指令抽取数据并核验。
  4. 在 Review Jobs and Instructions 选项卡中查看结果，以核验抽取的数据、核验结果和生成的指令。

示例：一种新文档类型（训练工作流）

假设你上传来自新零售商 Two Wheel Store 的第一份采购订单。Matcher 智能体搜索向量存储，没有找到相似文档，于是把作业路由到训练工作流。

Analyzer 智能体使用 Amazon Textract 抽取原始文档文本：

# PURCHASE ORDER
FROM: Two Wheel Store
Order #: PO-2026-0102-2584
Date: 2026-01-02

## Items Ordered
AC-021  Advanced Computer     Qty: 1   $75.61
        Colors: cr4321        @ $75.61
...
SB-004  Folding Classic       Qty: 8   $9634.32
        Colors: cb8901 I Sizes: S     @ $1204.29

TOTAL: $14931.54

Instructions 智能体根据模式生成抽取提示，Extractor 智能体产出结构化 JSON：

{
  "po_number": "PO-2026-0102-2584",
  "retailer_name": "Two Wheel Store",
  "order_date": "2026-01-02T00:00:00Z",
  "line_items": [
    { "sku": "AC-021", "product_name": "Advanced Computer", "quantity": 1, "unit_price": 75.61, "line_total": 75.61 },
    { "sku": "SB-004", "product_name": "Folding Classic",   "quantity": 8, "unit_price": 1204.29, "line_total": 9634.32 }
  ],
  "order_total": 14931.54
}

Validator 智能体对照模式检查结果并失败：

validation_status: INVALID
error: 'SB-004' does not match '^AB-[A-Z]{2}-\d{3}$'

供应商的 SKU 格式（SB-004）与 Acme Bikes 的内部格式（AB-SB-004）不匹配。Instructions Fixer 智能体诊断该不匹配，并向抽取提示加入一条明确的 SKU 转换规则：给供应商 SKU 加上前缀 AB-。第二轮中，七个行项目核验成功，Save Instructions 智能体把改进后的提示持久化到向量存储。这次首次运行的端到端时间为 3 分 49 秒。

示例：一种已知文档类型（自动化工作流）

当来自 Two Wheel Store 的第二份采购订单到达时，Matcher 智能体找到第一次运行所存储的指令，置信度分数为 3.946（阈值：3.7），并把作业路由到自动化工作流：

  • Extractor 智能体直接应用所存储的指令，因此编排器跳过提示生成。训练期间学到的 SKU 转换规则自动应用（EL-002 → AB-EL-002，HB-071 → AB-HB-071，PD-002 → AB-PD-002）。
  • 三个行项目在第一轮即核验通过，订单总额为 5,979.19 美元。
  • 端到端处理在 1 分 30 秒内完成，低于首次运行的 3 分 49 秒。

使用交互式聊天

仪表板包含一个用于排查的聊天界面：

  • 询问 what tools do you have，以查看可用的智能体能力。
  • 询问 list instructions，以查看已存储的抽取指令。
  • 询问 what is the status of job XXXX，以检查处理进度。
  • 询问 what went wrong with job XXXX, how can we update the instructions?，以诊断失败。

理解准确度如何随时间提高

系统通过两个反馈循环随时间改进：

  • 训练循环： 当 Instructions Fixer 智能体在核验失败后改进抽取提示时，改进后的指令会被保存，并用于相似文档。
  • 处理循环： 当 Troubleshooter 智能体修复抽取错误时，它提供详细分析，帮助识别文档格式变化中的模式。

更换模型时，使用 AgentCore Evaluations（https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations.html）确认抽取质量仍然可接受。AgentCore Evaluations 是 Amazon Bedrock AgentCore 的一项能力。该解决方案已经使用 AgentCore Observability，因此具备所需的埋点。

估计成本

你只为所使用的部分付费，因为该解决方案运行在无服务器和按需资源上，没有空闲成本。对于在美国东部（弗吉尼亚北部）每月 10 份训练文档和 1,000 份已处理文档的工作负载，估计成本大约为每月 58 美元。通过 Amazon Bedrock 的基础模型（foundation model, FM）推理约占总成本的 85%，大约每份文档 0.055 美元。实际成本在很大程度上取决于分配给每个智能体的模型。模型选择集中在 agents/orchestratorgraph/utils/config.py 中，因此你可以对较简单的任务使用成本更低的模型，并在需要的地方使用更强的模型。详细价格见 Amazon Bedrock 定价（https://aws.amazon.com/bedrock/pricing/）页面。

按你的用例定制解决方案

你得到的是一个采购订单处理用例，带有合成的自行车公司数据集、预建的 JSON 模式，以及一个对照模拟 ERP 数据库中的产品和供应商记录检查抽取数据的核验 Lambda 函数。要处理你自己的文档，你必须用自己的模式和核验逻辑替换所包含的内容。

定义你的文档模式

创建一个 JSON 模式，定义你希望为每种文档类型抽取的字段。agents/orchestratorgraph/doc_schema/purchase_order_schema.json 中的示例采购订单模式提供了参考。你的模式应指定字段名、数据类型，以及每个字段是在文档中明确写出，还是从上下文推断。

构建你的核验过程

所包含的核验器对照 Aurora DSQL 中的合成供应商和产品表检查采购订单数据。你的生产实现需要针对你的业务规则定制核验过程。例如：

  • 发票核验器可以对照应付账款系统检查供应商 ID，并核验行项目合计与发票总额一致。
  • 合同核验器可以核验文档包含必需条款，并且日期和当事方名称与你的记录一致。
  • 理赔核验器可以对照保单管理系统检查保单号、保障限额和索赔人信息。

要添加新的核验器，创建一个接受抽取 JSON 并返回带详细错误消息的通过/失败结果的 Lambda 函数，然后把它注册为 AgentCore Gateway 中的工具。实现模式参阅 gateway/tools/po_validator_tool/。

更新智能体提示

agents/orchestratorgraph/prompts/ 中的智能体提示引用采购订单术语。更新这些提示，以反映你的文档类型和抽取要求。Orchestrator 智能体、Validator 智能体和 Instructions 智能体各自包含特定于文档类型的语言，你应当加以改写。

最佳实践

在训练和运行智能体式 IDP 系统时记住这些建议。

  • 从有代表性的样本开始： 训练期间每种类型上传 5–10 份文档，包括带格式变化的边界情况，以建立可靠的抽取指令。
  • 使用业务规则核验： 把核验器连接到 Aurora DSQL 中的参考数据（供应商列表、产品目录），以便尽早捕获抽取错误。
  • 监视智能体性能： 使用 AgentCore Observability 和 CloudWatch 跟踪执行路径、识别瓶颈，并衡量抽取准确度随时间的变化。
  • 逐步增加文档类型： 为每种新文档类型创建一个 JSON 模式和对应的核验 Lambda 函数。其余工作由智能体处理。
  • 为生产添加护栏（guardrails）： 应用 Amazon Bedrock Guardrails，对智能体输出强制执行内容过滤和依据检查。当你处理保险理赔或贷款申请等敏感文档类型时，这一点尤其重要。
  • 查阅 OWASP 大语言模型十大风险： 参阅面向大语言模型（large language models, LLMs）和生成式 AI 应用的 OWASP 十大风险（https://genai.owasp.org/llm-top-10/），了解构建使用大语言模型的应用时的安全考虑。

清理

重要： 运行清理之前，导出你想保留的数据。destroy.py 脚本会永久删除已处理文档（S3）、作业历史（DynamoDB）、核验数据（Aurora DSQL）和已学习的抽取指令（向量存储）。

为避免持续计费，移除已部署的资源：

uv run destroy.py

在控制台上核验这六个 CloudFormation 堆栈已删除：AgenticIDP-Core-Dev、AgenticIDP-Gateway-Dev、AgenticIDP-Aurora-Dev、AgenticIDP-Agent-Dev、AgenticIDP-UIOrchestr-Dev 和 AgenticIDP-ModernUI-Dev。

结论

在本文中，你学习了如何使用 Amazon Bedrock AgentCore 构建一套可自我改进的文档处理系统。专用 AI 智能体协作，对业务文档进行分类、抽取、核验并从中学习。这种智能体式方法自动适应新的文档格式，并通过反馈循环随时间提高准确度，用自主学习取代手工模板配置。

后续步骤：

  1. 部署示例解决方案（https://github.com/aws-samples/aws-ai-intelligent-document-processing/tree/main/guidance/agentic-orchestration），并用所含采购订单样本进行测试。
  2. 通过创建 JSON 模式和核验规则，加入你自己的文档类型。
  3. 探索如何把抽取的数据与 ERP、CRM 或内容管理工具等下游系统集成。

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/build-self-improving-document-processing-using-amazon-bedrock-agentcore

  • #AgentCore
  • #文档处理
  • #IDP
  • #部署
  • #成本

继续阅读