Amazon Bedrock AgentCore 文档处理以学习循环取代固定模板

Amazon 推出了一套由八个智能体组成的参考系统，改变了 Amazon Bedrock AgentCore 文档处理应对陌生业务文件的方式。该系统不再要求为每种版式新建模板，而是生成提取指令、验证自身输出，并保存成功的指令供后续复用。

这改变了文档自动化领域的核心竞争。传统智能文档处理，即 IDP，依赖预定义字段、模板以及与已知格式绑定的规则。Amazon 的方案则将更多配置移入运行时学习循环，由智能体决定如何处理每一份新文档。

这一转变并未消除人工工程工作。团队仍需定义架构、业务规则、权限和可接受的错误水平。因此，真正的竞争是自适应智能体编排与可预测的模板处理之间的较量，而不是自动化与人工数据录入之间的较量。

Amazon Bedrock AgentCore 文档处理从验证失败中学习

Amazon 的参考架构将每份陌生文档视为一个临时训练问题，而非永久性的模板项目。

AWS 于 2026 年 10 月 14 日发布了这项 智能体式 IDP 设计。其目标是处理发票、采购订单、保险理赔、贷款申请及其他版式因发送方而异的文档。

该架构通过两个基于图的工作流协调八个专用智能体。开源软件开发工具包 Strands Agents 在 AgentCore Runtime 内控制工作流图。

第一个工作流识别进入系统的内容。Analyzer 智能体使用 Amazon Textract 提取文本，并识别文档类型和发送方。随后，Matcher 智能体会在 Amazon S3 Vectors 中搜索语义相似的文档。

向量相似度比较的是内容的数学表征，而非要求文件名或模板完全匹配。这让系统即使面对轻微的版式差异，也能将新文件关联到已知的文档系列。

匹配成功后，文档会进入自动化工作流。Extractor 智能体检索此前保存的指令，并将其应用于新文件。Validator 智能体则根据架构和业务规则检查生成的结构化数据。

匹配不成功时，系统将走更长的训练路径。Instructions 智能体为陌生格式创建提取提示词。Extractor 将源内容转换为结构化数据，Validator 则对结果进行测试。

验证失败会激活 Instructions Fixer 智能体。它诊断不匹配问题，修订提取指令，并将文件送入下一轮尝试。成功的指令会进入向量存储，以供未来具有相似特征的文档使用。

这正是该系统在 Amazon 描述中“自我改进”的原因。它不会在每次错误后重新训练基础模型，而是改进围绕模型构建、可复用且针对具体文档的提示词与转换层。

这一区别很重要。模型再训练可能需要精心整理的数据集、评估管线和大量运营控制。更新提取指令的范围更窄、速度更快，也更容易审查。

AWS 还区分了已知格式和新格式所涉及的失败情况。如果已知格式未通过验证，Troubleshooter 智能体会修复提取的数据，而不会立即改写已存储的指令。

这种分离机制可保护共享指令不受单个异常文件影响。损坏的扫描件或孤立的内容错误，不应必然改变应用于该发送方所有未来文档的规则。

因此，该工作流形成了两个反馈循环。训练循环会在验证失败后改进可复用指令；处理循环则记录故障排查细节，以揭示反复出现的格式变化。

这比仅仅要求大语言模型读取文档并返回 JSON 更具规范性。分类、提取、验证、修正和持久化成为具有可观察结果的独立阶段。

系统也保留了确定性控制。每种支持的文档类型都需要一个 JSON 架构，用于定义预期字段和数据类型。业务验证器仍负责判断提取值是否满足运营要求。

对于企业团队而言，这一边界至关重要。模型提出一种解释，但验证规则决定输出是否能够继续流转。智能体式灵活性位于明确的质量关卡之后。

模板式 IDP 团队为何面临压力

该架构给那些经济模式依赖人工配置和维护每种供应商版式的 IDP 系统带来了压力。

当文档保持稳定时，模板处理表现良好。团队将字段映射到已知区域、应用解析规则，并根据预期值测试输出。由于工程师控制每一次转换，工作流依然易于理解。

当数百家发行方使用不同版式时，这种模式的成本会变得高昂。新供应商带来新的配置工作，而现有供应商也可能在未通知的情况下变更字体、列、标签或页面结构。

即使一次微小的修改，也可能移动采购订单编号，或让行项目表格跨越多个页面。严格的模板可能将这种变化理解为缺失内容，或者更糟的是，返回看似合理却不正确的值。

Amazon Bedrock AgentCore 文档处理将这种维护负担转移到匹配和指令生成层。首次成功处理会为被判定为足够相似的文档创建可复用的处理资产。

AWS 使用来自虚构零售商 Two Wheel Store 的合成采购订单演示了这一机制。由于向量搜索未找到合适匹配，第一份文档进入训练工作流。

Extractor 读取了该零售商的库存单位编号，但 Validator 拒绝了其中一个值。零售商使用 SB-004，而虚构买方的内部架构要求带有前缀且模式更长的编号。

Instructions Fixer 添加了一条转换规则，将供应商值转换为预期的内部格式。第二次尝试时，全部七个行项目均通过验证。

在 AWS 的示例中，首次运行耗时 3 分 49 秒。系统随后保存优化后的指令，使同一零售商的另一份文档能够绕过提示词生成步骤。

后续一份采购订单与存储指令匹配，报告的置信度得分为 3.946，高于 3.7 的阈值。它在首次尝试中验证了三个行项目，并在 1 分 30 秒内完成。

这些数字说明了预期的复利效应。第一个陌生格式会消耗额外的推理和验证周期；后续案例复用由此产生的指令，需要的工作流步骤更少。

不过，这些证据来自 AWS 的合成演示，而非独立的生产基准测试。该示例证明参考实现能够执行其设计的循环，但无法证明其在不受控企业文档中的准确性。

对模板供应商的压力依然真实存在。买方现在可以评估，学习型指令能否在不牺牲验证纪律的前提下减少接入劳动力。这使可衡量的维护成本降低成为采购讨论的核心。

现有 IDP 平台可以通过多种方式应对。它们可以加入生成式提取能力、采用语义版式匹配，或提供自己的可复用修正循环。许多平台还会将这些方法与现有光学字符识别相结合。

最可能的结果并非模板立即消失，而是模板适用范围发生变化。稳定格式可以保留确定性映射，而可变格式则进入智能体辅助处理。

这种混合路线将吸引受监管团队。他们可以为可预测文档保留既有控制，同时在例外情况、新供应商和低风险文档类别上测试自适应工作流。

这一变化也会影响内部工程团队。他们不再为每种版式构建一个解析器，而必须设计可跨文档系列运作的架构、验证服务、置信度策略和升级路径。

这项工作类似于维护一个运营知识系统。团队需要可搜索的指令、修正历史和可靠的检索能力，就像技术文档的可搜索知识库。

AgentCore 文档处理如何跨 AWS 服务运作

这一学习循环依赖于协调的存储、身份、验证和可观测性服务，而非一次异常强大的模型调用。

文档通过 Amazon Simple Email Service 或直接上传至 Amazon S3 进入系统。Amazon EventBridge 随后激活 AWS Lambda 函数，后者会在 DynamoDB 中创建跟踪任务。

Lambda 函数调用 AgentCore Runtime，由其中的 Strands 工作流协调专用智能体。该运行时可以使用通过 Amazon Bedrock 启用的 Amazon Nova 或 Anthropic Claude 模型。

这种模型灵活性支持面向特定任务的路由。团队可以将较简单的工作分配给一个模型，并将能力更强的模型保留给模糊提取或故障排查。

AgentCore Gateway 通过 Model Context Protocol 将 Lambda 函数作为兼容智能体的工具公开。MCP 是一种标准接口，使模型能够发现并以结构化输入调用外部工具。

这种设计将业务逻辑置于语言模型之外。采购订单验证器可以继续作为一个查询供应商和产品记录的 Lambda 函数。智能体调用它，而不是自行编造验证结果。

Amazon Aurora DSQL 存储了示例验证器所使用的合成业务数据。生产部署必须以真实的企业系统替换这些模拟记录和规则。

发票实现可以确认供应商标识符，并重新计算行项目总额。合同工作流可以检查必需条款、日期和法人实体。理赔工作流则可验证保单与承保信息。

身份也成为处理设计的一部分。AgentCore Identity 和 Amazon Cognito 为访问 AWS 资源的智能体提供机器对机器凭证。IAM 策略决定这些智能体可以使用哪些服务和操作。

这一控制很重要，因为智能体式工作流会跨多个系统采取操作。分类需要访问文档，验证需要参考数据，持久化则需要保存可复用指令的权限。

AgentCore 文档将该平台描述为一种用于部署和运行智能体的基础设施，不依赖于单一框架或模型。IDP 示例将这套基础设施应用于一个边界明确的业务流程。

运营可视性来自 AgentCore Observability 和 Amazon CloudWatch。AWS 表示，该平台可以记录会话、延迟、时长、令牌使用量、错误以及智能体执行中的步骤。

这些追踪信息可帮助运营人员区分多种故障类型。Textract 可能误读源文件，检索可能选中了错误的指令，提取可能遗漏字段，或者验证可能拒绝实际上正确的内容。

如果没有这种区分，团队只能看到失败的最终结果。有了追踪信息，他们便能定位责任环节，并决定是否修改提示词、阈值、架构或验证器。

AgentCore Gateway 还围绕工具访问建立了一个受治理的边界。团队可以将授权、护栏、请求控制和可观测性置于代理自身应用代码之外。

该架构包含一个托管在 Amazon Elastic Container Service 上的仪表板。运营人员可以查看任务和已存储的指令，检查验证结果，并通过聊天界面查询工作流故障。

Amazon 将该示例打包为六个 CloudFormation 堆栈，涵盖核心存储与身份管理、Gateway 工具、Aurora、代理运行时、编排端点以及 React 界面。

AWS 表示，在前置条件准备就绪后，部署通常需要 15 至 20 分钟。这些前置条件包括 Docker、AWS Cloud Development Kit、受支持的模型、区域服务访问权限和相应权限。

公开的示例代码库使该架构可供审查。其中包含部署代码、提示词、架构、验证器、工作流逻辑和合成采购订单数据。

这种透明度让该公告比概念图更具实用价值。工程团队可以检查服务依赖关系，并以自己的架构和验证规则替换示例组件。

它也揭示了实施负担。生产部署仍然需要安全审查、数据保留控制、监控、异常处理、参考数据连接，以及覆盖代表性文档的测试。

因此，AgentCore 与模板处理的区别，并非在于“配置”与“不配置”之间的对比。关键在于，团队是要配置每一种视觉布局，还是配置可共享的架构、验证器和自适应指令。

“自我改进”止步于验证边界

系统可以改进可复用指令，但无法独立决定何为符合企业业务要求的正确性。

AWS 要求团队为每种文档类型创建 JSON 架构。该架构定义字段名称、数据类型，以及每个值是显式出现还是必须推断得出。

团队还必须创建符合自身运营规则的验证器。示例验证器理解一个虚构的采购订单系统，但它无法了解真实公司的供应商、合同、容差或审批政策。

这正是 AgentCore 文档处理方式的核心权衡。代理减少了与特定布局相关的工作，但与业务相关的配置仍然必不可少，且变得更加重要。

薄弱的验证器可能批准表述流畅却错误的提取结果。过于僵化的验证器则可能拒绝合理的例外情况。两种失败都会削弱学习循环，因为验证结果会引导后续修正。

检索带来了另一项风险。Matcher 代理使用语义相似度来定位已存储的指令。较高的相似度评分并不能保证两份文档拥有完全一致的字段含义或转换规则。

供应商可能会在发票和贷项通知单中复用同一布局。文档看似相似，却可能产生相反的会计影响。元数据、文档分类和保守的阈值必须防止不安全的指令复用。

AWS 示例给出了一个匹配阈值，但该数值仅适用于演示。生产团队需要基于自身的文档组合、错误匹配成本和可接受的审核负荷进行评估。

提示词注入也是一项担忧，因为文档中包含不受信任的文本。文档可能包含看似是对模型下达指令的语言。工作流必须将文档内容与受信任的系统指令和工具权限分离。

AWS 建议对敏感文件采用内容控制和依据验证。OWASP 维护的LLM 安全风险目录也指出了提示词注入、敏感数据泄露、过度代理权限和不安全输出处理等问题。

最小权限原则可以降低步骤被攻破后的损失。提取代理不应因为需要读取一个源文件，就获得广泛的写入权限。工具调用应强制执行输入架构和授权要求。

对于不确定或影响重大的情形，人工审核仍然合适。低置信度分类、反复验证失败、异常总额或意外的文档类型，都应进入受控的异常队列。

该架构还应防止无休止的修正循环。重试次数限制、超时机制和 token 预算可以约束无法满足其验证器要求的工作流。

指令持久化本身也需要治理。团队需要为影响后续文档的提示词提供版本控制、作者记录、测试结果、审批状态和回滚机制。

一次成功的修正并不能证明其是一条通用规则。修复某家供应商文档的前缀转换，可能会在该供应商更改编号系统后失效。

因此，代表性测试至关重要。AWS 建议每种类型从五到十份文档开始，包括边界情况和格式变体。这仍是解决方案作者提供的指导，而非普遍适用的充分性阈值。

准确率衡量还必须覆盖精确字段匹配以外的内容。团队应追踪分类错误、错误的指令匹配、验证失败、人工覆盖以及下游撤销情况。

延迟同样值得关注。示例中的训练路径比复用路径耗时更长，因为多个代理会生成、测试并修订指令。更多重试会增加处理时间和模型消耗。

模型本身也可能变化。较新版本可能会以不同方式解释相同的提取提示词。AWS 建议开发者使用 AgentCore Evaluations 在模型变化时检查质量。

模型更新进入生产环境前，应先运行评估。有用的测试集应包括干净文档、低质量扫描件、布局变化、缺失字段、冲突值和对抗性内容。

团队应将代理式工作流与当前基线进行比较。关键问题不是演示是否有效，而是新系统是否改善了经准确率调整后的人工成本、延迟和异常率。

因此，“自我改进”这一标签需要精确理解。系统会记住经过验证的提取策略并加以复用，但它并不会消除政策决策、独立测试或可追责的人类所有权。

三个信号将表明学习循环能否经受考验

下一项检验是，该架构能否减少生产维护工作，同时不造成更大的验证和治理负担。

第一个信号是真实文档组合中的独立性能数据。团队应关注字段级准确率、错误指令匹配、验证通过率、人工审核率，以及在布局变化情况下的表现。

成功的结果将增强 Amazon 的论点：可复用指令能够替代大量模板维护工作。高异常率则意味着，代理式灵活性可能只是转移了工作。

比较必须涵盖首次出现和重复出现的格式。该架构明确会对陌生文档投入更多工作，因此汇总平均值可能掩盖成本高昂的训练案例或不佳的检索表现。

第二个信号是，组织能否将已存储指令作为生产资产进行治理的证据。有效的部署应展示提示词版本、验证历史、审核决策和回滚控制。

清晰的治理将支持自适应模型，因为团队可以检查后续文档为何遵循某项已学习的转换规则。不透明的指令变更会削弱信任，尤其是在金融、保险和法律工作流中。

可观测性必须将代理追踪与业务结果关联起来。一次在技术上成功的运行，仍可能造成代价高昂的下游错误。团队需要在源文档、提取记录、验证、修正和最终系统更新之间建立关联。

第三个信号是，IDP 供应商和企业团队如何将自适应代理与确定性控制结合起来。竞争对手不必复制 Amazon 精确的八代理图来回应这一前提。

他们可以在成熟的工作流产品中提供生成式提取，加入语义匹配，或引入修正记忆。他们也可以强调具有更强保障的、更窄范围的自动化。

可信的生产模式很可能是混合式的。确定性方法可处理稳定、高容量的表单，而代理则在更严格的审核阈值后处理新布局和异常情况。

这一结果仍将验证 Amazon 的核心论点。文档处理将不再把每种陌生布局都视为一个完整的模板开发项目。

评估 Amazon Bedrock AgentCore 文档处理的开发者，应从受限的文档类别和明确的基线开始。衡量当前的配置时间、提取准确率、异常量和人工修正工作量。

随后通过自适应工作流测试相同的文档。应包括此前未见过的布局、字段发生变化的已知布局、低质量扫描件，以及不应匹配已存储指令的文档。

在允许每项修正影响后续文件前，检查每一项修正。确认验证器测试的是业务含义，而不仅仅是有效的 JSON 语法或预期字段名称。

最后，确定自动化必须在哪里停止。哪些验证失败需要审核？哪些工具操作需要单独批准？运营人员能够多快禁用一项有缺陷的指令？

Amazon 提供的是一套具体架构和可运行代码，而非所有文档操作都应实现自主化的证据。机会在于让格式学习能够复用，同时让正确性仍由外部定义。

这就是买家在未来数月应采用的评判标准。如果该系统能在不削弱控制力的前提下降低接入和维护成本，自适应 IDP 将获得有说服力的生产应用案例。

如果验证、审核和提示词治理消耗了节省下来的人力，模板处理仍将保有重要优势。决定性问题不在于代理能否阅读文档，而在于组织能否信任这些代理所记住的内容。