智能体自动化真正进入生产环境后，挑战通常不在于“能不能调用模型”，而在于如何控制不确定性：哪些决策交给智能体，哪些步骤必须保持确定性，什么时候要求人工复核，以及出现异常时能否快速还原现场。围绕 Amazon Quick Automate 设计业务流程时，可以把它视为一套编排能力，而不是一个能够独立承担所有工作的万能代理。
先选择适合智能体参与的流程
并非所有流程都值得智能体化。最合适的候选流程通常同时具备几个特征：输入包含邮件、文档或自然语言等非结构化内容；判断规则很难完全写成条件表达式；允许在有限范围内出现概率性结果；业务价值足以覆盖评估、审核和运维成本。
例如，下面这些任务通常适合让智能体参与：
- 从客户邮件中识别诉求、紧急程度和相关产品。
- 汇总多份材料，生成供员工确认的处理建议。
- 根据知识库为工单补充分类、摘要和推荐动作。
- 在多个系统之间收集信息，形成结构化审批材料。
相反，金额结算、权限授予、合规封禁和不可逆的数据删除，不应该只依赖模型判断。这类动作适合由确定性代码执行，并在前面设置严格校验或人工审批。
评估候选流程时，可以先回答四个问题：
- 失败一次会造成什么损失？
- 输出是否能通过规则、样例或人工判断验证？
- 流程中哪些动作可撤销，哪些不可撤销？
- 是否存在足够多的历史案例用于建立评估集？
如果失败代价高、结果难验证且动作不可撤销，那么应缩小自动化范围，而不是直接追求端到端无人运行。
让智能体负责判断，让代码负责约束
一个可靠的自动化流程通常由两类步骤组成。
智能体步骤适合处理语义理解、归纳、信息检索和候选方案生成。例如判断工单意图、提取合同条款、草拟回复。
确定性步骤适合处理格式校验、权限检查、金额计算、状态转换、API 参数构造和幂等写入。例如验证订单编号、检查退款上限、写入审批记录。
与其设计一个拥有大量工具、同时负责分析和执行的“大智能体”，不如拆成职责明确的小智能体。每个智能体只接收完成任务所需的上下文，只能使用必要工具，并输出有明确字段的结构化结果。这样更容易测试，也能减少提示词变化对整个流程的影响。
下面是一份可改造成 Quick Automate 工作流配置的示意 YAML。字段名称是假设性的，重点是展示边界划分，并不代表具体产品 API：
workflow: customer-refund-review
version: 1
inputs:
- ticket_id
- customer_message
steps:
- id: load_order
type: deterministic
action: orders.get_by_ticket
input:
ticket_id: "{{ inputs.ticket_id }}"
- id: classify_request
type: agent
objective: >
Determine whether the customer is requesting a refund and extract
the stated reason. Do not approve or execute a refund.
input:
message: "{{ inputs.customer_message }}"
order_summary: "{{ steps.load_order.output.summary }}"
output_schema:
type: object
required: [intent, reason, confidence]
properties:
intent:
enum: [refund, replacement, question, other]
reason:
type: string
confidence:
type: number
minimum: 0
maximum: 1
- id: validate_policy
type: deterministic
action: refund_policy.check
input:
order_id: "{{ steps.load_order.output.order_id }}"
reason: "{{ steps.classify_request.output.reason }}"
- id: require_review
type: condition
when: >
steps.classify_request.output.confidence < 0.85 or
steps.validate_policy.output.amount > 100 or
steps.validate_policy.output.policy_exception == true
then: human_review
else: prepare_refund
- id: prepare_refund
type: deterministic
action: refunds.create_draft
input:
order_id: "{{ steps.load_order.output.order_id }}"
idempotency_key: "refund-{{ inputs.ticket_id }}"
这个设计有三个关键点：智能体无权直接退款；策略检查由确定性服务完成；最终写入使用幂等键。即使模型重复执行或工作流重试，也不应产生两笔退款。
人工复核不是兜底按钮，而是一条正式路径
生产流程中的人工介入需要有明确触发条件。仅仅加一个“人工确认”节点还不够，因为审核员可能拿不到判断依据，也可能成为新的性能瓶颈。
常见触发条件包括：
- 模型置信度低于经过评估确定的阈值。
- 输出缺少必填字段或违反结构约束。
- 涉及高金额、高权限或不可逆操作。
- 多个数据源互相矛盾。
- 输入可能包含提示注入、敏感信息或异常附件。
- 当前案例与历史评估集差异较大。
审核界面至少应展示原始输入、智能体结论、引用证据、规则校验结果和拟执行动作。审核结果也不应只记录“通过”或“拒绝”，还要保存修正后的字段和原因。这些数据可以转化为后续评估案例，帮助团队判断应调整提示词、工具权限还是业务规则。
人工审核也有成本。可以按风险分层：低风险且高置信度的案例自动推进，中等风险进入抽样审核，高风险始终强制审批。阈值必须来自实际评估数据，而不是凭直觉设定。
用离线评估阻止提示词回归
智能体输出具有概率性，因此普通单元测试只能覆盖部分问题。团队还需要维护一组包含正常案例、边界案例和恶意输入的评估集，并在修改提示词、模型、工具或知识库后重新运行。
下面的 Python 脚本可以直接运行，用于评估一个“工单分类智能体”的结构化结果。示例通过固定预测数据演示流程；接入 Quick Automate 后，只需把 run_agent 替换为实际工作流调用，并从环境变量读取凭证。
from dataclasses import dataclass
@dataclass
class Case:
case_id: str
message: str
expected_intent: str
minimum_confidence: float
CASES = [
Case("refund-clear", "Please refund order A-102.", "refund", 0.85),
Case("replacement", "The screen is cracked. Send a replacement.", "replacement", 0.80),
Case("ambiguous", "This purchase did not work out.", "other", 0.00),
]
# Replace this function with your Quick Automate workflow invocation.
def run_agent(case: Case) -> dict:
sample_outputs = {
"refund-clear": {"intent": "refund", "confidence": 0.96},
"replacement": {"intent": "replacement", "confidence": 0.91},
"ambiguous": {"intent": "other", "confidence": 0.42},
}
return sample_outputs[case.case_id]
def evaluate() -> int:
failures = []
for case in CASES:
result = run_agent(case)
intent_ok = result.get("intent") == case.expected_intent
confidence_ok = result.get("confidence", 0) >= case.minimum_confidence
if not intent_ok or not confidence_ok:
failures.append(
f"{case.case_id}: expected={case.expected_intent}, got={result}"
)
accuracy = (len(CASES) - len(failures)) / len(CASES)
print(f"cases={len(CASES)} accuracy={accuracy:.1%}")
for failure in failures:
print(f"FAIL {failure}")
return 1 if failures else 0
if __name__ == "__main__":
raise SystemExit(evaluate())
运行方式：
python eval_automation.py
真实项目还应增加字段完整率、人工转交率、错误执行率、引用正确率、延迟和单次运行成本等指标。对于高风险动作，“最终分类正确率”并不足够，还要单独统计错误自动执行的比例。
可观测性要覆盖一次完整业务执行
只记录模型输入和输出无法解释整个自动化流程。一次执行可能经历数据读取、智能体判断、工具调用、策略校验、人工等待和外部系统写入。日志和追踪数据应使用统一的 workflow_run_id 串联这些阶段。
建议至少记录以下信息：
- 工作流、提示词、模型和规则的版本。
- 每个步骤的开始时间、结束时间、状态和重试次数。
- 工具调用名称、参数摘要、结果状态和幂等键。
- 智能体输出的结构化字段、置信度和证据引用。
- 人工复核的触发原因、等待时长和修改内容。
- Token、运行时延、外部 API 调用量和估算成本。
日志需要对客户信息、凭证和敏感业务字段做脱敏。调试便利不能成为永久保存完整提示词和原始文档的理由。团队还应设置留存期限与访问控制，并区分可用于评估的数据和受合规限制的数据。
告警也应面向业务结果，而不只是 HTTP 错误率。例如人工转交率突然翻倍、某个意图分类占比异常、单次执行成本快速上涨，往往比一次模型请求失败更能说明系统已经偏离预期。
上线前的控制清单
将 Quick Automate 工作流投入生产前，可以逐项确认：
- 智能体的目标单一，工具权限遵循最小化原则。
- 每个智能体输出都有可验证的结构定义。
- 金额、权限、状态和不可逆动作由确定性逻辑控制。
- 外部写入具备幂等键、超时、重试上限和补偿策略。
- 人工复核有明确触发规则，并展示足够证据。
- 历史案例已经形成版本化评估集，并接入变更检查。
- 日志能够通过运行 ID 还原完整执行链路。
- 敏感数据已经脱敏，并配置访问权限与保留期限。
- 团队准备了暂停工作流、降级到人工处理和回滚版本的方案。
更稳妥的落地方式是从“生成建议但不执行”开始，随后进入影子运行和小流量自动执行，再逐步扩大范围。生产级智能体自动化的核心不是消除所有人工步骤，而是明确每一种不确定性由谁处理、依据什么证据处理，以及出错后如何停止和恢复。