Agent 工作流自动化：先把稳定流程写死，再让模型处理例外

把飞书、邮箱、表单、数据库、审批系统接起来，今天已经不难了。真正难的是业务流程里那些不规则、不可预测、又不能乱做决定的部分，例如：

• •用户描述不规范
• •附件内容不完整
• •规则能覆盖 80%，剩下 20% 全是例外
• •动作有副作用，发错一次就要人工补救

所以 Agent 在工作流自动化里最有价值的角色，不是替代整个流程引擎，而是处理传统规则流最难覆盖的“例外判断”。

一个很实用的判断标准是：

更适合规则流的步骤

• •触发器监听
• •字段映射
• •权限校验
• •API 调用
• •幂等去重
• •审批结果回写

更适合 Agent 的步骤

• •解析自然语言描述
• •从附件里抽取半结构化信息
• •对异常输入做分类
• •生成补充说明或人工审核摘要
• •在多个候选路径之间做受限决策

如果把这两类职责混在一起，最后的流程通常会变成“一段 prompt 控整个业务”，既不好测，也不好审计。

比起“用自然语言创建任何工作流”，我更愿意先看一个边界清楚的场景：员工提交报销单后，系统需要先做预审，再决定进入财务复核还是人工退回。

这条链路里，稳定部分很明确：

• •接收表单和附件
• •提取固定字段
• •校验金额、日期、必填项
• •记录审计日志
• •推进到下一状态

真正需要 Agent 参与的，通常是这些地方：

• •发票备注写得很乱，系统要判断实际报销事由
• •附件看起来不完整，但缺的是哪一类材料
• •同一条说明里混了多笔费用，需要先归并
• •需要给人工审核人生成一段简洁的复核摘要

也就是说，Agent 更像是“规则流中的判断模块”，而不是替代整个工作流系统。

自动化场景最怕的，不是模型偶尔答偏，而是流程没有状态边界。

一个更稳妥的设计方式是先画出有限状态：

submitted
  -> normalized
  -> validated
  -> needs_review
  -> approved_for_finance
  -> rejected

每次状态迁移都应该回答三个问题：

• •谁触发的
• •依据是什么
• •失败后回到哪里

只要状态边界清楚，后续即使用 Agent 参与判断，也不会变成难以复盘的黑箱。

在工作流自动化里，我很少建议让模型直接“调用任意工具然后完成流程”。更稳的方式是让模型只产出一个受限决策对象，再由系统决定是否执行动作。

下面这个骨架表达的是同一个意思：模型负责判断，系统负责落地。

from typing import Literal
from pydantic import BaseModel, Field


class ReviewDecision(BaseModel):
    action: Literal["auto_pass", "needs_review", "reject"]
    reason: str
    missing_fields: list[str] = Field(default_factory=list)
    risk_flags: list[str] = Field(default_factory=list)


def apply_decision(claim_id: str, decision: ReviewDecision, workflow_api) -> None:
    if decision.action == "auto_pass":
        workflow_api.move_to_next_step(claim_id, "finance_check")
        return

    if decision.action == "needs_review":
        workflow_api.create_manual_task(
            claim_id=claim_id,
            title="报销单需要补充材料",
            notes=decision.reason,
            checklist=decision.missing_fields + decision.risk_flags,
        )
        return

    workflow_api.reject_claim(claim_id=claim_id, reason=decision.reason)

这样做有两个直接好处：

• •模型输出被限制在固定 schema 里，更容易验证和回放
• •真正有副作用的动作都在业务系统里执行，更容易做权限和审批控制

Workflow 自动化里最容易失控的地方，是工具太多、权限太宽、动作太直接。

第一版工具集最好克制到 3 到 5 个，并且每个工具都要明确：

• •输入数据来自哪里
• •是否会写入外部系统
• •是否允许自动重试
• •是否需要人工审批
• •是否要记录幂等键

比如“发送付款通知”这种动作，风险明显高于“查询员工信息”。这两种工具不应该接受同样的自动化权限。

很多自动化 demo 到这里就结束了，但真实系统里，异常处理比 happy path 更重要。

至少要提前设计这几件事：

重试策略

网络超时、第三方接口限流、短暂依赖故障，应该自动重试；资料缺失、业务规则冲突则不该盲重试。

去重与幂等

同一条 webhook 或同一份审批单，不能因为重复触发就执行两次外部动作。

死信与人工队列

当流程无法自动恢复时，要有明确的人工处理入口，而不是让任务静默消失。

审计日志

每次状态迁移、模型决策、工具调用，都应该带上 trace id、输入摘要和结果状态，方便复盘。

这部分做不好，流程越自动化，后面越难查问题。

对自动化链路来说，“跑完了”不代表“跑对了”。更值得持续跟踪的通常是：

• •自动通过率
• •人工接管率
• •补件率
• •错误路由率
• •单次运行延迟
• •单次运行成本

如果你引入了 Agent，却只能回答“用户感觉还行”，那就说明评估层还没建立起来。

1. 先让模型生成流程，再考虑治理

自然语言生成节点图可以作为原型工具，但真正上线前，节点、条件、工具权限都必须回到可审计的配置层。

2. 把规则判断也交给模型

金额上限、审批链、权限归属这类规则应该由系统硬编码或配置化，而不是让模型猜。

3. 一开始就追求全自动闭环

多数业务流程第一版都更适合 agent assist，也就是 Agent 提建议、生成摘要、补充结构化字段，真正高风险动作保留人工审批。

如果你要把 Agent 放进工作流自动化里，我更建议按这个顺序做：

• •先选一个低风险、重复度高的单一流程
• •把状态机、工具边界、审批点先写清楚
• •只让模型处理非结构化输入和例外判断
• •用结构化输出约束模型决策
• •上线前补齐 trace、重试、死信和人工接管
• •再根据失败样本迭代 prompt、规则和工具

这个顺序虽然不花哨，但更容易做成长期可维护的系统。

Agent 不是用来“接管一切自动化”的，而是用来补上传统 workflow 引擎最不擅长的那部分能力：

• •读懂不规范输入
• •解释例外
• •生成给人的说明
• •在受限范围内做分类与路由

只要把边界守住，让系统掌握状态和副作用，让模型只处理变化和模糊，工作流自动化才会既智能，又可控。

• •OpenAI Agent Builder
• •OpenAI Agents SDK
• •OpenAI Safety In Building Agents
• •LangChain Middleware Overview
• •LangSmith Observability