Amazon Quick Automate构建生产级Agent自动化最佳实践

Agentic 自动化正在改变企业的业务流程运行方式。AI Agent 不再遵循僵化的脚本，而是能够理解上下文、适应变化，并与人员和与其他 Agent 协作以推进工作。Amazon Quick Automate 是 Amazon Quick 中的一个多 Agent 自动化能力，帮助组织规模化地构建、部署和维护这些自动化。它协调跨部门、跨系统、UI 和 API 交互以及第三方应用程序的 Agent 团队。当团队从试点走向生产时，从一开始就应用正确的设计模式，对于构建可靠、可观测且能适应变化的自动化至关重要。

Agentic 自动化也带来了独特的运营挑战。流程跨越多个系统，输入通常是非结构化或半结构化的，业务逻辑频繁变化。在这些环境中部署 Agent 时，如果不在责任边界、人工监督、确定性 guardrails 和评估方面做出深思熟虑的设计选择，就会导致脆弱的工作流、不可预测的行为，以及信任的侵蚀。

在这篇文章中，我将分享使用 Amazon Quick Automate 构建生产级 Agentic 自动化的最佳实践。你将学到如何选择正确的流程、如何围绕清晰的职责设计 Agent，以及如何将它们与确定性步骤结合使用。你还将学到如何在关键环节应用人工审核，以及如何评估和观测你的 Agent，以便你能够信任它们的行为。流程比技术更重要。我见过的最常见错误是团队在真正理解他们打算自动化的流程之前就直接进入自动化设计。构建自动化并不是困难的部分。理解流程实际如何运行，才是决定自动化是否成功的关键。

流程质量决定 Agent 质量

第一步是识别正确的流程。几乎所有好的自动化都始于一个业务问题，而不是出于使用 Agent 的愿望。你通常是在试图解决一些具体的问题，比如高运营成本、低客户满意度、慢周转时间或让团队疲惫不堪的繁琐手动工作。基于 Agent 的自动化的良好候选者往往具有一些共同特征。它们协调多个记录系统，接收非结构化或半结构化的输入（如电子邮件和文档）。它们涉及的决策需要上下文判断，而不是基本的 if-then 逻辑，而且它们经常出现传统自动化脚本处理不好的异常。以 PDF 形式收到的供应商发票就是一个典型例子。它必须与采购订单匹配，被路由到正确的审批流程，并过账到 ERP 系统。新员工入职也是一个例子，新员工会触发 HR、IT 和设施系统的工作，而这些系统很少相互通信。

选择流程之后，在构建任何东西之前先定义成功的标准。商定你正在追求的可衡量结果，无论是缩短周期时间、降低错误率、提高吞吐量还是降低每笔交易的成本。明确的目标能让项目保持诚实，并帮助你抵御范围蔓延，因为任何拟议的新增都可以用它在多大程度上推动你商定的指标来衡量。

团队最常跳过的步骤是设计 to-be 流程（目标流程）。从手动流程转向 Agent 驱动的流程，并不是用 Agent 替代旧步骤的简单复制。当一个能力强大的 Agent 承担大部分工作时，这是重新思考工作应该如何流动的机会。有些步骤的存在只是为了弥合断开系统之间的差距，比如将 PDF 中的数据重新键入电子表格、通过三个收件箱路由文档以保持可见性，或者从一个工具下载文件再上传到另一个工具。这些步骤应该完全消失。曾经需要一天才能完成的交接可以在几秒钟内完成。工作不再等待在队列中等人注意到，因为 Agent 在前一步完成后立即拿起下一步。某些手动检查变得不必要了，而其他一些则变得更加重要，因为你现在希望在特定时刻让人来确认 Agent 的判断。有一个经验法则很有智慧：删除每一个你能删除的步骤。如果你没有被偶尔强迫添加回一些步骤，说明你裁剪得不够彻底。以这种精神勾勒 to-be 流程可以防止你将浪费自动化。只有在这项工作之后，你才应该映射当前状态，主要是为了找到你现在的位置和你想要到达的位置之间的差距。

用清晰、有界的职责设计 Agent

一个试图做所有事情的单一 Agent 很难构建、很难调试，也很难信任。它的运行成本也更高，因为一个广泛的 Agent 需要更多的指令、更多的工具和操作，而且它处理的每个任务通常需要更多的推理步骤。专注的 Agent 可以同时控制质量和成本。

要遵循的原则是，自动化中的每个 Agent 应该拥有一个内聚的职责。例如，在发票处理自动化中，一个 Agent 读取并结构化收到的发票。另一个 Agent 将提取的数据与采购订单和合同进行核对，以识别差异。第三个 Agent 根据金额和类别决定正确的审批路径。这些 Agent 中的每一个都足够小，可以推理、可以独立测试，可以在不干扰工作流其余部分的情况下改进。当出现问题时，你立即知道要看哪个 Agent。

Quick Automate 中的两个特性使专注的 Agent 特别有效。第一个是根据每个 Agent 的可用范围来缩小指令、工具和操作的能力。你可以让文档提取 Agent 访问文档读取能力，如 Amazon Textract 或 Amazon Bedrock Data Automation。同时，你保留它不需要的其他文档处理工具。Quick Automate 为你处理大部分这类复杂工作。Automation Assistant 根据你提供的流程描述，在构建自动化时适当地缩小工具范围。第二个特性是 Structured Output，你可以在其中定义 Agent 必须返回的数据的确切形状。例如，数据提取 Agent 可以被要求以定义的 schema 生成供应商名称、发票编号、行项目明细和总额，而不是自由格式的文本。这使得到下一步的交接是可靠的，并消除了一整类解析错误。

将 Agent 与确定性步骤结合

工作流中的并非每个步骤都应该是 Agent。Quick Automate 的优势之一是你可以将 Agentic 步骤与确定性步骤混合使用。你在真正需要判断的地方应用判断，在其他地方则回退到可预测的执行。这种组合使得自动化既灵活又可靠。

Quick Automate 提供不依赖模型的确定性步骤，有意识地选择它们可以保持自动化的快速、可预测和更便宜。Code 步骤运行你定义的精确逻辑，非常适合数据转换、计算和遵循固定契约的集成。确定性控制流评估结构化字段，并将工作发送到固定路径，而无需任何模型推理。例如，对于高于审批阈值的发票总额进行检查，每次执行都以相同的方式快速运行。有时候你确实希望自动化在遇到偏差时失败，而不是让 Agent 即兴绕过它。确定性步骤给你正是这种可预测的停止。使用 Quick Automate，你还可以按确定性顺序链接 Agent。这模拟了真实运营团队运行流程的方式，在固定序列中一个人的输出成为下一个人的输入。请注意，Quick Automate 按 Agent 小时数收费，即执行时长，而不是按 Token 收费。确定性序列和步骤的实际好处是它们运行快速并缩短整体执行时间。

Agent 在真正需要判断的步骤上赢得自己的位置。例子包括：解释不遵循模板的供应商电子邮件、读取扫描合同以提取付款条款、决定如何处理部分匹配两个采购订单的发票，以及起草一份清晰的消息回复供应商。一个好的经验法则：如果你能完全写下规则，就使用确定性步骤。如果正确的操作取决于理解非结构化内容或权衡上下文，就使用 Agent。

在高风险和异常处理中使用人工介入

对于高风险业务流程，完全自主的自动化很少是正确的选择。好消息是你不需要在完全自主和持续监督之间做出选择。使用 Quick Automate，你可以在关键时刻纳入人工介入（Human-in-the-Loop，HITL），它支持两种截然不同的模式。

阻塞式人工介入步骤是指 Agent 确定它需要人类帮助，并等待响应后再继续。考虑一张无法干净地匹配任何采购订单的发票。Agent 不是猜测，而是暂停，向财务审核员展示案例，并在审核员确认如何继续后才恢复。释放大额付款、向客户发送合同，或向记录系统发布更正都是类似的情况。在每种情况下，你都希望工作流停止并保持，直到人类批准。非阻塞式人工介入步骤则不同，它通知人员后继续处理下一笔交易而不等待。这适合你想要监督但又不想减慢流程的情况。它也适合人类在时间范围内异步回复的情况，这样自动化可以在一些异常等待人工解决的同时继续处理其他案例。

决定包含多少人工审核是一个调优问题，用假阳性和假阴性的角度来思考会有帮助。如果你将太多案例路由给人工，就会产生假阳性，意味着 Agent 在它本可以自己处理的案例上请求帮助。你的审核员然后开始橡皮图章式地批准，这悄悄地否定了目的。如果你将太少案例路由给人工，就会产生假阴性，意味着 Agent 在它应该升级的案例上继续执行。这些错误会损害信任，而且撤销起来可能代价高昂。理想的水平介于这两种失败模式之间，反映业务的需求，你通过观察真实数据来找到它。比你认为需要的更保守一些，并测量审核员实际改变 Agent 提议操作的频率。当证据表明 Agent 在某一类案例中是可靠的，逐步提高自动处理的阈值。

无论你在哪里放置审核步骤，都要给审核员足够的上下文以便快速决策。使用 Quick Automate，你可以创建包含相关图像和 PDF 的人工审核表单，以及 Agent 的摘要。审核员看到的是实际的发票或合同，而不是对其的简单描述。还要决定当审核员没有及时回复时会发生什么，因为没有超时限制的阻塞步骤可能使整个流程停滞。一个设计良好的升级路径保持工作继续进行。

评估你的 Agentic 工作流

因为 Agent 行为可能在每次运行之间有所不同，评估在这里比在传统自动化中更重要。它应该被对待为一门持续的学科，而不是上线前的一次性测试。目标是提供证据地了解每个 Agent 在它实际将遇到的各种输入上的表现情况。

良好的评估始于代表性数据，在大多数情况下你已经有了。你的流程处理过的历史工作给你提供了大量真实输入以及人们得出的结果。你实际上是为大部分评估集提供了ground truth。你的目标是覆盖你的 Agent 在生产中将遇到的全部分布，包括干净案例、混乱案例、真正的边缘案例以及 Agent 应该拒绝的无效输入。历史数据捕获了合成示例很少能复现的奇怪格式问题、缺失字段和矛盾。将这个集合视为一种活的资产，每次生产中出现你未曾考虑的案例时它都会增长。

Quick Automate 通过其自定义 Agent 单元测试功能帮助你在单个 Agent 级别进行评估。使用此功能，你为一个单独的 Agent 定义预期的输入和输出，并隔离运行它。你可以确认提取 Agent 拉取了正确的字段，或者路由 Agent 选择了正确的路径，然后才组装完整的工作流。首先在单个 Agent 上测试每个 Agent 使失败更容易诊断。当你在过程中更改了 Agent 的指令或工具时，重新运行其单元测试会立即告诉你你是改进了它还是引入了回归。

将可观测性构建到自动化中

基于 Agent 的自动化比传统工作流需要更深入的可观测性，因为 Agent 通过任务的路径可能在每次执行之间不同。你无法改进你看不到的东西。目标是不仅了解运行是否成功，还要了解 Agent 为什么做出它们所做的选择。

Quick Automate 在产品中提供了这种可见性。它捕获每次执行及其步骤、每个 Agent 调用的工具、它收到的输入，以及它到达决策的路径。当结果看起来错误时，你可以打开该特定运行并准确查看发生了什么。指标流入 Amazon CloudWatch，这意味着你可以在其他运营工具旁边监控你的自动化、构建仪表板和设置警报，而无需搭建单独的系统。

深思熟虑地管理身份和访问

在企业系统上运行的 Agent 需要凭证，你如何处理身份验证既塑造了自动化的安全性，也塑造了它的覆盖范围。Quick 支持两种模式，为每个自动化选择合适的模式很重要。对于按计划或触发器运行且无人在场的企业自动化，Quick 支持服务身份验证，即自动化本身持有一个身份以及它需要操作所需的权限。这种模式适合无人值守的常驻流程，因为自动化可以可靠地自行运行，每个操作都可归因于该服务身份。对于聊天、Agent 和代表个人行为的个人 Flows，Quick 支持基于用户的三足 OAuth。自动化在该用户的同意和访问下运行，而不是使用共享的服务凭证。

用 Agent 自动化业务流程是从脆弱的、基于规则的脚本向能够理解上下文并随时间改进的自适应工作流的转变。成功的自动化往往始于一个真实的业务问题和一个重新设计的目标流程。它们使用具有限定工具和结构化输出的专注 Agent，并将 Agentic 步骤保留给真正的判断，而在其余地方依赖确定性序列和步骤。最重要的是，它们在人工审核值得其价值的地方应用人工审核，并将评估和可观测性视为持续的学科，而不是事后考虑。

要开始使用，请访问 Amazon Quick Automate 或参阅 Quick Automate 文档。