使用 Amazon Quick Automate 构建智能体自动化流程的最佳实践

Agentic automation 正在改变企业运行业务流程的方式。Amazon Quick Automate 是 Amazon Quick 中的多智能体自动化能力，可以协调不同部门的多个智能体，打通内部系统、UI/API 和第三方应用，帮助组织大规模构建、部署和维护自动化。相较于传统自动化，智能体需要在非结构化输入、跨系统数据和频繁变化的业务规则中做判断，也因此带来了可靠性、可观测性和运维上的新挑战。如果不在职责边界、人工监督、确定性防御措施和评估机制上做刻意设计，很容易获得脆弱且难以信任的工作流。

第一步是挑对流程。适合智能体的流程通常需要协调多个记录系统，输入常是邮件、扫描件等非结构化或半结构化内容，决策不能靠简单 if-then 完成，而且会频繁出现传统脚本难以处理的异常。供应商发来 PDF 发票需要匹配采购订单并走审批，或者新员工入职需要 HR、IT、后勤等多个系统协同，都是典型场景。选好流程后，先定义可衡量的成功目标，比如周期缩短、错误率下降、吞吐量提升或单笔成本下降，再用这些指标衡量后续每一步是否值得加入，避免范围蔓延。

最容易被跳过的是“目标流程”设计。从手工流程搬到一个由智能体驱动的流程，不是把旧步骤原样复制后挂上一个智能体，而是重新思考当智能体承担大部分工作时，工作应当怎样流动。很多旧步骤只是用来弥合系统鸿沟的：从 PDF 重新录入数据、把文档在多个收件箱间传递、从 A 工具下载再上传到 B 工具。这些步骤应当直接删除。人工交接时间可以从一天缩短到几秒；工作也不会长时间滞留在队列里等人发现。经验法则是：尽量删除一切能删的步骤；如果没有偶尔被逼着加回几个，说明删得还不够深。完成这一步后，再绘制现状流程，主要用于识别差距。

智能体本身的设计原则是单一职责。一个什么都要做的智能体难以构建、难以调试，也更贵，因为职责过宽意味着需要更多指令、工具和推理步骤。在发票处理流程中，可以让一个智能体专门读取并结构化发票，另一个负责与采购订单/合同比对并标识差异，第三个按金额和类别决定审批路径。每个智能体足够小，可独立测试和优化。Quick Automate 能帮助限制每个智能体的工具和动作范围，Automation Assistant 会根据流程描述完成一部分工具裁剪；Structured Output 则要求智能体返回固定结构的数据，例如规范的供应商名、发票号、行项目与总额，从而让步骤间交接可靠。

并非每个工作流步骤都需要智能体。若能用代码精确表达逻辑、或只要按结构化字段判断分流的场景，应使用 Quick Automate 的确定性步骤；它们运行快、行为可预测且成本更低。而且 Quick Automate 按智能体执行时长计费，而不是按 token 计费，因此减少不必要的智能体推理能明显降低成本。较好的做法是把需要判断的步骤交给智能体，例如理解非模板化的供应商邮件、从扫描合同中提取付款条件、判断一张发票与两个采购订单都部分匹配时如何处理；而凡是能完整写出规则的部分，交给代码或确定性分支即可。多个智能体也可以用确定顺序链接，模拟真实运营团队的固定交接。

人机协作要落在真正高风险和异常场景。Quick Automate 支持两种模式。阻塞式 HITL 会在智能体需要帮助时暂停工作流，等审批人确认后再继续，适合无法匹配任何采购订单的发票、大额付款、发送合同等场景。非阻塞式 HITL 则只是通知人工并继续处理下一个事务，适合需要监督但不想拖慢整体进度的场景，也适合允许异步响应的异常。阈值调节可以从两个错误看：送审过多会造成评审员“橡皮图章”，送审过少会漏掉本应升级的高风险错误。建议先设置偏保守的阈值，统计分析评审员实际修改智能体建议的比例，再逐步放宽自动处理范围。每个审阅节点应尽量附带原始 PDF、图片和智能体的摘要，并为超时未响应定义升级路径。

最后，智能体每次执行的行为并不完全相同，因此持续评测比传统自动化更重要。最好的评测数据来自历史流程：过去人工处理过的真实案例既是输入也是参考答案。可先构建测试集，覆盖正常与异常情形，在发布前以及每次改动后运行评测，观察成功率和失败模式。可观测性应当作为基本要求内建在自动化和人工介入点中，记录智能体的输出、采取的步骤、审批结果和异常中断，当流程漂移或出错时才能快速定位并恢复信任。