Build self-improving document processing using Amazon Bedrock AgentCore

使用 Amazon Bedrock AgentCore 构建自我改进的文档处理 | 人工智能

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

IDC 研究表明，与文档相关的挑战每年使每位信息工作者损失 19,732 美元，并降低 21.3% 的工作效率。接收来自数百家供应商发票的组织经常面临布局因发行方不同而变化且未经通知的更新。基于模板的系统在此规模下需要持续维护。员工可能将多达 30% 的时间用于文档相关任务，而人工数据输入的错误率在 1-4% 之间。传统智能文档处理（IDP）解决方案虽然缓解了部分负担，但需要为每种文档格式进行大量前期配置，并且在供应商布局差异时会失效。

在本文中，您将学习如何使用 Amazon Bedrock AgentCore 构建一个智能 IDP 系统，该系统通过最小的人工干预即可对业务文档进行分类、提取、验证和学习。Amazon Bedrock AgentCore 是一个平台，可用于构建、连接和优化大规模代理，支持任意框架或模型。您的代理可自动处理新的文档格式，如供应商发票、采购订单、保险索赔和贷款申请。在本文结束时，您将能够：

• 在 20 分钟内部署多代理 IDP 系统。
• 在无需手动模板配置的情况下处理新的文档类型。
• 让代理自行训练每种新文档格式并复用所学知识，因此后续相同类型的文档可直接进入提取阶段而无需重新训练。

基于规则的文档处理挑战

许多 IDP 管道要求您提前为每种文档格式定义模板、提取规则和验证逻辑。当新供应商发送布局不同的采购订单时，管道会失效。这会带来三个核心挑战：

• 模板僵化：每种新文档格式都需要手动配置，即使布局发生微小变化也可能导致提取失败。
• 无学习能力：由于系统无法保留之前修正的知识，类似文档会重复出现相同的提取错误。
• 扩展负担：每个新供应商或文档变体都会增加维护工作量，处理来自数百个来源文档的组织面临持续的运营成本。

智能代理方法解决了这些挑战。与静态模板不同，AI 代理会分析每份文档，生成提取指令，验证结果，并自动从修正中学习。随着时间推移，您的系统会构建文档格式的知识库，因此处理类似文档时只需极少的额外配置。

解决方案概述

在本方案中，八个专业代理通过运行在 Amazon Bedrock AgentCore 上的两个基于图的工作流程进行协作。

下图展示了使用 Strands Agents（一个用于构建 AI 代理的开源 SDK）构建的多代理工作流图。

图 1：多代理编排工作流图

• 识别工作流：Analyzer 代理使用 Amazon Textract 提取文本并识别文档类型和发送方。Matcher 代理使用 Amazon S3 向量（Amazon Simple Storage Service (Amazon S3) 的一项功能）通过向量相似性搜索类似文档。

• 训练流程（新文档类型）：当未找到匹配项时，指令代理生成提取提示，提取器代理提取结构化数据，验证器代理在 Amazon Aurora DSQL 中检查结果是否符合模式和业务规则。如果验证失败，指令修正器代理优化提示并重试。成功后，保存指令代理会持久化指令以便重复使用。

• 自动化流程（已知文档类型）：当找到匹配项时，提取器代理使用现有指令。如果验证失败，故障排除代理直接修复提取的数据，而无需修改指令。

工作原理

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

图2：AWS 上的 Agentic IDP 基础设施架构

• 业务文档通过 Amazon Simple Email Service（Amazon SES）或直接上传到 Amazon S3 到达。

• Amazon EventBridge 触发一个 AWS Lambda 函数，该函数在 Amazon DynamoDB 中创建跟踪作业，并调用 AgentCore 运行时，这是 Amazon Bedrock AgentCore 的一项功能。

• AgentCore 运行时通过 Strands 代理协调文档处理。

• 您的代理通过 AgentCore Identity（Amazon Bedrock AgentCore 的一项功能）和 Amazon Cognito 管理的机器到机器凭证，安全访问 AWS 资源。

• 您的 Lambda 函数通过 AgentCore Gateway（Amazon Bedrock AgentCore 的一项功能）的 Model Context Protocol（MCP）接口，成为代理兼容工具。

• 代理使用 Amazon Textract 提取文本，使用 S3 Vectors 中的向量嵌入对文档进行分类，并在 Aurora DSQL 中验证数据是否符合业务规则。

• 代理通过 MCP 服务器访问企业数据，以验证提取的内容是否符合业务规则。

• 您可以通过托管在 Amazon Elastic Container Service（Amazon ECS）上的聊天启用仪表板监控状态并排查问题。

• 您可以通过 AgentCore Observability（Amazon Bedrock AgentCore 的一项功能）和 Amazon CloudWatch 远程监控获取代理性能的可见性。

部署解决方案

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

先决条件

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

• AWS 账户。

• 对 Amazon Bedrock 的访问权限，且已启用 Amazon Nova 和 Anthropic（Claude）模型。有关 AWS 区域的模型可用性，请参阅 Amazon Bedrock 中的“按 AWS 区域划分的支持模型”。

• 在支持的区域中访问 Amazon Bedrock AgentCore（运行时、网关、身份）、S3 Vectors 和 Amazon Aurora DSQL 的权限。

• 已安装 AWS Cloud Development Kit（AWS CDK）v2。

• 已安装并运行 Docker（构建和部署容器镜像需要此功能）。

• Python 3.11+ 和 Node.js 18+。

• AWS 身份和访问管理（IAM）权限，用于创建 S3 存储桶、Lambda 函数、DynamoDB 表、Cognito 用户池、Amazon Elastic Container Registry（Amazon ECR）存储库和 Amazon ECS 服务。

• 克隆仓库并设置环境：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 ../..

• 部署堆栈：uv run deploy.py --admin-email [email protected]

此部署将创建六个 AWS CloudFormation 堆栈：Core（S3、Cognito、DynamoDB）、Gateway（Lambda 工具、AgentCore 网关）、Aurora（Amazon Aurora DSQL）、Agent（AgentCore 运行时、容器）、UI Orchestrator（API 端点）和 Modern UI（部署在 Amazon CloudFront 上的 React 应用）。部署大约需要 15 至 20 分钟。

• 通过检查 CloudFormation 控制台中每个堆栈是否显示 CREATE_COMPLETE 状态来验证部署。

处理文件并查看结果

部署完成后，您将收到一封包含 CloudFront URL、用户名和临时密码的电子邮件。

处理文档

• 登录到 Web 界面，选择 Process Document（处理文档）。
• 从 infrastructure/sample_data/purchase_orders/training/ 路径上传一个示例采购订单。
• 文档进入代理工作流：Analyzer 代理提取文本并识别发件人和文档类型。Matcher 代理在向量存储中搜索相似文档。对于新文档类型，训练流程生成提取指令，提取数据、验证数据并保存指令供以后使用。对于已知文档类型，自动化流程使用现有指令提取数据并验证数据。

• 在 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），并将任务路由到自动化流程：

• 提取器代理直接应用存储的指令，因此协调器跳过提示生成。训练期间学习的SKU转换规则会自动应用（EL-002 → AB-EL-002，HB-071 → AB-HB-071，PD-002 → AB-PD-002）。

• 三个项目在首次验证时即通过，订单总额为5,979.19美元。

• 端到端处理时间缩短至1分30秒，较首次运行的3分49秒有所提升。

使用交互式聊天

仪表板包含用于故障排除的聊天界面：

• 询问"你有哪些工具"以查看可用代理功能。

• 询问"列出指令"以查看存储的提取指令。

• 询问"作业XXXX的状态如何"以检查处理进度。

• 询问"作业XXXX出了什么问题，如何更新指令？"以诊断失败原因。

理解准确性如何随时间提升

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

• 训练循环：当指令修正代理在验证失败后优化提取提示时，改进后的指令会被保存并用于类似文档的处理。

• 处理循环：当故障排除代理修复提取错误时，它会提供详细分析以识别文档格式变化的模式。

切换模型时，请使用AgentCore Evaluations（Amazon Bedrock AgentCore的一项功能）确认提取质量仍可接受。该方案已使用AgentCore Observability，因此具备必要的监控功能。

预估成本

您只需为实际使用付费，因为该方案运行在无服务器和按需资源上，没有空闲成本。对于每月处理10份训练文档和1,000份文档的美国东部（北弗吉尼亚）工作负载，预估每月成本约为58美元。通过Amazon Bedrock进行基础模型（FM）推理约占总成本的85%，每份文档约0.055美元。实际成本主要取决于分配给每个代理的模型。模型选择在agents/orchestratorgraph/utils/config.py中集中管理，因此您可以为简单任务使用低成本模型，在需要时使用高性能模型。有关详细定价信息，请参阅Amazon Bedrock定价页面。

为您的使用场景定制解决方案

您将获得一个包含合成自行车公司数据集的采购订单处理用例、预构建的JSON模式，以及一个验证Lambda函数，该函数会将提取的数据与模拟ERP数据库中的产品和供应商记录进行比对。要处理自己的文档，必须将包含的模式和验证逻辑替换为自定义内容。

定义文档模式

创建一个JSON模式，定义您希望为每种文档类型提取的字段。agents/orchestratorgraph/doc_schema/purchase_order_schema.json中的采购订单模式示例可作为参考。您的模式应指定字段名称、数据类型，以及每个字段是否在文档中明确声明或需要根据上下文推断。

构建验证流程

内置的验证器会将采购订单数据与Aurora DSQL中的合成供应商和产品表进行比对。您的生产实现需要根据业务规则定制验证流程。例如：

• 发票验证器可能会将供应商ID与应付账款系统进行比对，并验证明细项总额与发票总额是否一致。

• 合同验证器可能会验证文档是否包含必要的条款，并检查日期和各方名称是否与您的记录一致。

• 索赔验证器可能会将保单编号、承保范围和索赔人信息与您的保单管理系统进行比对。

要添加新的验证器，请创建一个Lambda函数，该函数接受提取的JSON数据并返回通过/失败结果及详细的错误信息，然后在AgentCore Gateway中将其注册为工具。请参考gateway/tools/po_validator_tool/中的实现模式。

更新代理提示

agents/orchestratorgraph/prompts/中的代理提示使用了采购订单术语。请更新这些提示以反映您的文档类型和提取要求。协调器代理、验证器代理和指令代理各自包含特定于文档类型的表述，您需要根据实际情况进行调整。

最佳实践

在训练和运营您的智能文档处理系统时，请牢记以下建议：

• 从代表性样本开始：在训练期间每种文档类型上传5-10个样本，包括格式变化的边缘案例，以构建可靠的提取指令。

• 使用业务规则验证：将验证器连接到Aurora DSQL中的参考数据（供应商列表、产品目录），以便尽早发现提取错误。

• 监控代理性能：使用AgentCore Observability和CloudWatch跟踪执行路径，识别瓶颈，并随时间衡量提取准确性。

• 逐步添加文档类型：为每种新文档类型创建JSON模式并创建对应的验证Lambda函数。代理会自动处理其余部分。

• 为生产环境添加防护措施：应用Amazon Bedrock Guardrails对代理输出进行内容过滤和事实核查。在处理保险索赔或贷款申请等敏感文档类型时，这一点尤为重要。

• 查阅LLM的OWASP Top 10：在构建使用大型语言模型（LLMs）的应用程序时，请参考LLM的OWASP Top 10和生成式AI应用的安全考量。

清理

重要提示：清理之前，请导出需要保留的数据。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代理协作对业务文档进行分类、提取、验证和学习。这种智能代理方法可以自动适应新的文档格式，并通过反馈循环随时间提高准确性，用自主学习取代手动模板配置。

下一步建议：

• 部署示例解决方案并使用包含的采购订单样本进行测试。

• 通过创建JSON模式和验证规则添加您自己的文档类型。

• 探索如何将提取的数据与下游系统（如ERP、CRM或内容管理工具）集成。

如需了解更多关于本文使用的服务和模式的信息，请参考以下资源：

• 欲深入了解本方案中使用的代理框架，请参阅 Strands Agents SDK：深入解析代理架构与可观测性。

• 欲了解 AgentCore Gateway 如何将 API 转换为适用于代理的工具，请参阅 介绍 Amazon Bedrock AgentCore Gateway：变革企业级 AI 代理工具开发。

• 欲了解 Model Context Protocol 的背景及其与 AWS 服务的集成方式，请参阅 在 AWS 上解锁 Model Context Protocol (MCP) 的强大功能。

• 欲了解代理如何在会话间保留上下文信息，请参阅 Amazon Bedrock AgentCore Memory：构建具备上下文感知能力的代理。

• 如需了解 Amazon Bedrock AgentCore 的功能详情，请参阅 Amazon Bedrock AgentCore 文档。

在构建文档处理解决方案方面，AWS 专业服务团队和 AWS 合作伙伴可提供专家指导。

关于作者

'\"