AWS发布基于Bedrock AgentCore的自改进文档处理方案，可自动学习新发票格式
AWS机器学习博客介绍一套由8个专用Agent组成的智能文档处理（IDP）系统，声称可在20分钟内完成部署，对新供应商发票格式首次处理约3分49秒，第二次缩短至1分30秒，月处理千份文档的预估成本约58美元。
AI解读：这套方案要解决的具体问题是：同一家企业收到数百个供应商的发票或采购订单，各家的版面不同且会随时变化，基于模板的传统IDP系统需要为每种格式做前置配置，版面一变就可能提取失败。AWS的解法是用Agent自动分析新文档、生成提取指令、验证结果，并在验证失败时修正指令后保存复用。
适用条件比较明确：需要AWS账户、在支持的区域开通Amazon Bedrock（启用Nova与Claude模型）、AgentCore（Runtime、Gateway、Identity）、S3 Vectors和Aurora DSQL，本地还需CDK v2、Docker、Python 3.11+和Node.js 18+。部署六个CloudFormation栈约需15至20分钟。
方案开箱提供的是合成自行车公司的采购订单用例、预置JSON Schema和一个校验Lambda。要处理自己的合同、理赔或贷款申请，使用者必须替换Schema、校验逻辑和Agent提示词——Aurora DSQL中的供应商与产品数据也是模拟数据，需接入真实业务规则。
成本数字来自AWS的估算：在美东（弗吉尼亚北部）每月10份训练文档加1000份处理文档的场景下约58美元，其中Bedrock基础模型推理约占85%，折合每份文档约0.055美元。AWS说明实际费用主要取决于为每个Agent选择的模型。
博客给出的性能数字均来自其示例演示：新供应商Two Wheel Store的首份采购订单走训练流程，因SKU前缀不匹配校验失败、Instructions Fixer补充规则后二次通过，端到端3分49秒；第二份同供应商订单匹配到此前指令，跳过提示词生成，1分30秒完成。这只是单次示例，不能外推为普遍准确率或节省比例。
该方案的设计包含两条反馈路径：训练循环在验证失败后修正并保存提取指令，处理循环由Troubleshooter直接修复数据而不改指令。AWS还建议更换模型时用AgentCore Evaluations确认提取质量，并在处理保险理赔、贷款申请等敏感文档时启用Amazon Bedrock Guardrails。
AWS机器学习博客发布一篇技术文章，介绍如何用Amazon Bedrock AgentCore搭建一套可自改进的智能文档处理（IDP）系统。文章由Erik Cordsen撰写，给出的方案在识别工作流与训练工作流两个图结构中编排8个专用Agent，用于对供应商发票、采购订单、保险理赔和贷款申请等商业文档进行分类、提取、校验和复用学习结果。
文章称，部署整套方案通常在20分钟以内，新文档类型无需人工配置模板。AWS在文中附带了可直接克隆的示例仓库（agenticidp-guidance），并给出合成自行车公司数据集的采购订单用例。
方案由哪些Agent组成，如何区分新格式与已知格式
识别工作流中，Analyzer Agent用Amazon Textract提取文本并判断文档类型与发件方；Matcher Agent在Amazon S3 Vectors中做向量相似度检索，看是否存在同类文档。
检索不到匹配时进入训练工作流：Instructions Agent生成提取提示词，Extractor Agent输出结构化数据，Validator Agent对照Amazon Aurora DSQL中的Schema和业务规则做校验；校验失败则由Instructions Fixer Agent修正提示词并重试，成功后Save Instructions Agent把指令持久化以便复用。
检索到匹配时进入自动化工作流：Extractor Agent直接套用已存指令；若校验失败，由Troubleshooter Agent直接修复提取数据，而不修改指令。
- 8个专用Agent分布在两条图工作流中，基于开源SDK Strands Agents构建
- 新文档类型走训练流程，已知文档类型走自动化流程
- 校验规则存放在Aurora DSQL，向量相似度检索使用S3 Vectors
演示中的两次处理耗时与失败案例
文章用一个具体例子说明训练流程：第一份来自新供应商Two Wheel Store的采购订单被判定为无相似文档，进入训练工作流。Validator Agent校验失败，报错内容为SKU“SB-004”不符合内部格式“^AB-[A-Z]{2}-\d{3}$”。Instructions Fixer Agent据此在提取提示词中增加“给供应商SKU加AB-前缀”的规则，第二次校验时7个行项目全部通过，指令被保存到向量存储。该次端到端耗时3分49秒。
同一供应商的第二份采购订单到达时，Matcher Agent以3.946的置信度匹配到已存指令（阈值3.7），进入自动化工作流。Extractor Agent直接套用存好的指令，跳过了提示词生成环节，训练中学到的SKU转换规则自动生效（EL-002转为AB-EL-002等），3个行项目一次校验通过，订单总额5,979.19美元，端到端耗时1分30秒，低于首次的3分49秒。
- 首次训练流程：3分49秒，含一次校验失败与规则修正
- 第二次自动化流程：1分30秒，直接套用已存指令
- 两次数值均为AWS文章中的单个示例，不代表普遍性能
部署前提与需要替换的部分
文章列出了部署前提：AWS账户；在支持区域开通Amazon Bedrock并启用Amazon Nova与Anthropic Claude模型；开通AgentCore（Runtime、Gateway、Identity）、S3 Vectors和Amazon Aurora DSQL；本地安装AWS CDK v2、Docker、Python 3.11+与Node.js 18+；具备创建S3存储桶、Lambda、DynamoDB表、Cognito用户池、ECR仓库和ECS服务的IAM权限。
执行部署脚本会创建六个CloudFormation栈，分别对应核心资源、Gateway、Aurora DSQL、Agent运行时、UI编排和React前端，约需15至20分钟。部署完成后会通过邮件收到CloudFront地址、用户名和临时密码。
方案自带的是采购订单处理用例、一份JSON Schema，以及一个对照Aurora DSQL中模拟ERP数据的校验Lambda。要处理自有文档，必须替换Schema、校验逻辑和Agent提示词——文章明确指出Orchestrator、Validator、Instructions三个Agent的提示词都含有采购订单术语，需要按自己的文档类型改写。
- 示例校验对照的是合成供应商与产品表，生产环境需接入真实业务规则
- 新增文档类型需自建JSON Schema和对应校验Lambda，并在AgentCore Gateway注册为工具
- 新增校验器需接收提取出的JSON，返回带详细错误信息的通过/失败结果
AWS给出的成本估算与运维建议
成本方面，文章称方案运行在无服务器和按需资源上，没有空闲费用。在美东（弗吉尼亚北部）每月10份训练文档加1000份处理文档的场景下，估算约58美元/月，其中Bedrock基础模型推理约占85%，折合每份文档约0.055美元。文章说明实际成本主要取决于为各Agent指定的模型，模型选择集中在agents/orchestratorgraph/utils/config.py，可为简单任务配低成本模型。
运维建议包括：每类文档先用5至10份有代表性的样本（含格式差异的边缘情况）训练；把校验器接到Aurora DSQL中的供应商列表、产品目录等参考数据；用AgentCore Observability和CloudWatch跟踪执行路径与提取准确率；按文档类型逐步增加Schema和校验函数；生产环境对保险理赔、贷款申请等敏感文档启用Amazon Bedrock Guardrails；并参考OWASP LLM与生成式AI应用十大风险。
文章还提示，更换模型时应使用AgentCore Evaluations确认提取质量仍可接受，因为方案已具备AgentCore Observability埋点。清理阶段运行的destroy.py会永久删除已处理文档（S3）、任务历史（DynamoDB）、校验数据（Aurora DSQL）和已学习的提取指令（向量存储），运行前需先导出要保留的数据。
- 月成本估算约58美元，模型推理占约85%
- 清理脚本会删除文档、任务历史、校验数据和已学指令，需提前导出
- 建议对敏感文档类型启用Bedrock Guardrails