跳到主要内容

Workflow-Agent混合架构

核对日期：2026-05-09。

1. 定义与边界​

Workflow-Agent 混合架构把稳定、可审计、合规要求高的路径交给代码 workflow，把开放性强、需要语言理解或动态工具选择的局部步骤交给 Agent。

Anthropic 将 workflow 定义为由预定义代码路径编排 LLM 和工具的系统，将 agent 定义为由 LLM 动态控制流程和工具使用的系统。混合架构的重点是明确两者边界，而不是追求“全自动”。

2. 为什么重要​

企业生产系统通常需要稳定流程：权限校验、审批、写库、通知、回滚、审计。这些不适合完全交给模型动态决定。但流程中的某些环节，如摘要、分类、证据抽取、异常解释、方案建议，适合由 Agent 完成。

适用：

  • 客服退款、理赔、采购审批、财务报销。
  • 数据管道中需要 LLM 判断的局部步骤。
  • 高风险动作必须经过确定性 gate。

不适用：

  • 任务路径完全开放且探索性极强。
  • 没有明确业务状态和审批规则。

3. 核心机制​

原则：

  • workflow 控制“是否能做、何时做、做完如何记录”。
  • Agent 处理“如何理解、如何解释、如何生成候选方案”。
  • 高风险副作用由 workflow 执行，不由模型自由执行。

4. 架构模式​

模式Agent 位置例子
Agent as classifier入口分类，workflow 分支工单分类、风险等级判断
Agent as extractor从文本抽取结构化字段合同条款、发票信息
Agent as recommender生成候选动作，规则审批退款建议、补偿建议
Agent as exception handlerworkflow 异常时解释和建议自动化失败诊断
Workflow as guardrailAgent 每步都经过状态机 gate生产变更助手

5. 工程实现​

def refund_workflow(ticket):
    user = authenticate(ticket.user_id)
    order = get_order(ticket.order_id)

    facts = agent_extract_refund_facts(ticket.text, order)
    validate_schema(facts)

    risk = rules.evaluate_refund_risk(order, facts)
    if risk.requires_human:
        approval = request_approval(order, facts, risk)
        if not approval.approved:
            return close_case("rejected")

    preview = agent_draft_customer_message(order, facts)
    refund_id = commit_refund(order, facts.amount, idempotency_key=ticket.id)
    audit_log(ticket, facts, risk, refund_id)
    return preview

状态字段：

workflow_state:
  status: awaiting_approval
  agent_outputs:
    extracted_facts_ref: facts_123
    draft_ref: draft_456
  rule_decisions:
    risk_level: high
    reason: amount_exceeds_threshold
  audit:
    trace_id: trace_abc
    idempotency_key: ticket_789

6. 生产实践​

  • Agent 输出只作为候选事实或建议，进入 workflow 前必须 schema 校验。
  • workflow 状态是事实源，Agent memory 不能替代业务数据库。
  • 所有 commit 动作集中在确定性服务层。
  • 为每个 Agent 步骤设置重试策略和 fallback。
  • 对审批 UI 展示原文、抽取字段、风险理由和将执行的具体动作。

7. 常见反模式​

  • workflow 只是薄壳，实际权限和动作由 Agent 决定。
  • Agent 输出未校验就写入业务系统。
  • 同一状态在 workflow、Agent memory、前端三处各存一份且无主从。
  • 失败后重新跑 Agent 导致重复扣款、重复发信。
  • 人工审批只显示“是否批准”，不显示具体参数和证据。

8. 评测方法​

  • Workflow Completion Rate：流程是否按状态机正确完成。
  • Agent Extraction Accuracy：字段抽取是否准确。
  • Gate Effectiveness：高风险动作是否被正确拦截。
  • Human Approval Quality：审批人是否能看到足够证据。
  • Regression Tests：业务规则变更后旧案例是否保持预期。

9. 安全与治理​

  • 最小权限：Agent 步骤优先只读，写操作由 workflow commit。
  • 防注入：用户文本和外部资料作为数据字段，不得修改 workflow 规则。
  • 审计：保存 Agent 输出、规则判断、审批人、commit 参数。
  • 补偿：对外部副作用定义撤销或人工处理流程。

10. 工程手册补充​

10.1 控制流、状态流、工具流​

Workflow-Agent 混合架构的原则是：确定性流程负责边界，Agent 负责不确定判断。

流放在 Workflow放在 Agent
控制流状态转移、重试、超时、审批、补偿对模糊输入做判断或生成候选
状态流持久化 typed state、checkpoint、审计临时上下文、候选解释、草稿
工具流高风险写工具、支付、外发、生产变更只读搜索、草稿生成、摘要
观测流每个节点固定事件名和状态码LLM 输入输出、评分、拒绝原因

10.2 工程示例​

nodes:
  validate_request:
    type: workflow
    retry: none
  classify_intent:
    type: agent
    output_schema: IntentDecision
    max_tokens: 800
  policy_gate:
    type: workflow
    deny_if:
      - "risk == high and approval_id is null"
  preview_action:
    type: tool
    side_effect: false
  commit_action:
    type: tool
    side_effect: true
    idempotency_key: "${run_id}:${action_id}"

失败恢复：

  • Agent 节点输出不合 schema：重试一次，仍失败则进入人工队列。
  • Workflow 节点失败：按确定性错误处理，不让 Agent 猜测系统状态。
  • commit 节点超时：使用 idempotency key 查询外部状态，再决定补偿或继续。
  • 用户中途修改目标：生成新 workflow run，旧 run 标记 superseded。

上线清单：

  • 每个 Agent 节点都有输入 schema、输出 schema、最大预算和 fallback。
  • 所有副作用工具都在 workflow 节点执行，并有幂等键。
  • 端到端 trace 能看出“哪个判断来自模型，哪个动作来自代码”。
  • 评测同时覆盖节点级准确率、流程完成率、人工审批命中率、补偿成功率。

11. 权威资料​