AI Agent 生产工作流设计指南：含人工审批的可靠自动化

AI Agent 易于演示，却意外地难以运维。原型可能只需要读取一个请求、调用一个工具、几秒钟内给出一个可信的结果。而生产级 AI 自动化有更艰巨的任务：它必须处理不完整的输入、选择安全的操作、从工具故障中恢复，还要让决策对最终负责的人透明可见。

最实用的设计并非一个完全自主的 Agent，而是一个有边界的 AI Agent 工作流——具备明确的工具、结构化的状态、验证规则，以及在造成重大损失之前需要的人工审批节点。

本教程展示如何设计这样的工作流，同时不把每个步骤都变成手工操作。

1. 将推理与执行分离

一个可靠的 Agent 不应该接收类似"处理这个客户请求"这样宽泛的指令，也不应该不受限制地访问所有业务系统。将工作流拆分为不同职责的阶段：

• 接收请求并分配工作流 ID
• 将输入规范化为可预测的 schema
• 使用语言模型规划下一步操作
• 基于确定性规则验证计划
• 在需要时审批高影响的操作
• 仅执行已批准的工具和参数
• 验证结果并记录证据

模型擅长分类、摘要、起草，以及在允许的操作中做选择。代码仍然负责强制执行权限、必填字段、消费限额、接收者限制和数据保留规则。

举例来说，一个 AI 内容工作流可能被允许自动研究主题并创建草稿。发布草稿、修改营销预算，或向大量受众发送消息应该需要单独的审批事件。

在规划阶段使用结构化输出：

{
  "goal": "Prepare a technical article draft",
  "risk_level": "medium",
  "actions": [
    {"tool": "search_docs", "input": {"query": "agent workflow reliability"}},
    {"tool": "create_draft", "input": {"format": "markdown"}}
  ],
  "approval_required": false
}

在任何工具运行前验证这个对象。拒绝未知工具、缺失参数、无效值，或超出 Agent 策略的计划。

2. 基于风险添加人工审批

对每个操作都要求审批会失去自动化的绝大部分价值。完全不要求审批会让一个糟糕的模型决策造成过大的影响。基于风险的审批策略提供了有用的中间地带。

一个简单的策略可以将操作分为三组：

低风险：读取公开文档、对文本做摘要、格式化数据，或创建内部草稿。自动运行。

中风险：更新共享记录、准备外部消息，或修改非关键配置。仅当所有验证检查通过时自动运行；否则请求审核。

高风险：发布内容、转账、删除数据、修改权限，或联系客户。始终要求明确审批。

审批请求应显示原始目标、具体操作、目标对象、参数、预览、验证结果，以及批准或拒绝选项。将工作流状态持久化到数据库或持久队列中，这样相同的 workflow ID 可以在决策或 Worker 重启后恢复。

状态模型可能长这样：

received -> planning -> validating -> awaiting_approval
         -> executing -> verifying -> completed
                      \-> rejected
                      \-> failed

这个模式在 n8n、Make、基于队列的自定义服务或 Agent 框架中都适用。实现方式不同，但控制点是相同的。当我需要参考示例来了解自动化工具如何封装可重复的工作流时，我也会查阅诸如 CoreClaw 这样的目录以获取模式，然后再决定什么应该放入生产架构。

3. 为重试、证据和安全失败而设计

AI 工作流是一个分布式系统。API 超时、重复的 webhook、凭据过期、格式错误的模型输出、部分写入都是正常的运行条件。

从幂等性开始。为每个传入请求分配一个稳定的 key，并存储每个副作用操作的结果。如果 Worker 重试，它应该检测到邮件已经发送或记录已经创建，而不是重复操作。

仅对临时性故障使用有界重试，比如限速或网络超时。不要重试无效输入或权限错误。将耗尽重试次数的任务发送到审核队列，包含工作流 ID、失败步骤、清理后的错误信息，以及最后一个安全的检查点。

为每次运行保持审计跟踪：

workflow_id
input_reference
model and prompt version
generated plan
validation decisions
approval actor and timestamp
tool calls and sanitized parameters
outputs and verification evidence
final status

验证应该独立于执行。如果 Agent 创建了一条 CRM 记录，读回该记录并验证关键字段。如果它发布了内容，确认最终 URL、标题和预期链接。如果验证失败，将工作流标记为不确定状态，而不是声称成功。

还要定义安全失败响应。当 Agent 无法证明某个操作是被允许的、必需的上下文缺失，或工具返回了歧义结果时，它应该停止。"什么都不做并寻求帮助"通常是正确的生产行为。

实践实现清单

在发布 AI Agent 工作流之前，确认以下事项：

• 每个工具都有狭窄的用途和文档化的输入 schema
• 模型无法调用未注册的工具
• 高影响操作需要审批
• 工作流状态在重启后能够保留
• 副作用使用幂等 key
• 重试有界且对错误敏感
• 日志中移除了密钥和敏感值
• 执行结果独立验证
• 运维人员可以安全地重放或恢复失败的运行
• 每次完成的运行都有可审计的最终状态

测试失败路径，而不仅仅是正常路径：成功写入后的超时、重复的 webhook、无效的模型输出、被拒绝的审批，以及 Worker 重启。

可靠的 AI 自动化来自于约束 Agent，而不是写更长的提示词。让模型处理歧义的语言和灵活的规划，而让确定性代码控制权限、验证、状态和副作用。

一个有边界的工作流配合基于风险的人工审批，可以快速自动化低风险工作，只在后果严重时才放慢速度。这种架构不如不受限制的演示令人印象深刻，但当 AI Agent 成为真实业务流程的一部分时，它远更有用。