AI 业务流架构：让智能嵌入流程，而非漂浮其外

引言：AI 价值不在模型，而在流程中的位置

很多企业做 AI，习惯先选模型、搭平台、做 Demo，最后才发现：AI 能力很惊艳，但业务部门用不起来。原因很简单——AI 被做成了一个孤立的“聊天窗口”，而不是业务流程中的一个环节。

真正的价值，发生在 AI 嵌入业务流之后：工单自动分类、信贷申请智能初审、供应链异常自动预警、内容生产端到端协同。这些场景的共同点是：AI 不是终点，而是流程中的一个节点。本文系统讲解 AI 业务流架构的设计方法、核心模式与落地要点，并附少量关键代码。

一、什么是 AI 业务流架构？

传统业务流是确定性的：满足条件 A，走分支 1；满足条件 B，走分支 2。规则由人写死。

AI 业务流是在流程中引入概率性决策节点：模型根据输入给出判断，但可能出错。因此架构必须同时处理确定性流转和概率性决策，并设计好人工兜底。

可以这样理解：

核心目标：让 AI 成为流程中可靠的一环，而不是一个需要人工搬运结果的“外部工具”。

二、核心分层：五层架构

一个可落地的 AI 业务流架构通常包含五层：

1. 流程编排层：定义步骤、分支、状态流转。可以是 BPMN 引擎，也可以是代码状态机。
2. AI 能力层：封装模型调用、提示词、工具调用、RAG 检索。
3. 数据与记忆层：流程变量、业务数据库、向量知识库、历史交互。
4. 人机协同层：人工审批、复核、修改、升级。
5. 可观测层：日志、指标、链路追踪、成本核算。

关键原则：流程编排层不关心模型细节，AI 能力层不关心流程走向。两者通过结构化消息解耦。

三、四种关键架构模式

1. AI 作为节点

流程走到某一步，调用 AI 处理，拿到结果后继续流转。

提交申请 → AI 初审 → 人工复核 → 通过/拒绝

适合：分类、提取、摘要、初筛。

2. AI 作为路由

AI 判断输入类型，决定走哪条分支。

用户请求 → AI 意图识别 → 退款流程 / 咨询流程 / 投诉流程

适合：客服、工单分发。

3. AI 作为审批

AI 给出决策建议，但最终由规则或人工确认。

AI 风险评估 → 置信度 > 0.9 自动通过 → 否则转人工

适合：信贷、风控、合规。

4. AI 作为协作者

AI 与人在同一流程中交替工作，人修改 AI 产出，AI 再基于修改继续。

AI 起草合同 → 法务修改 → AI 根据修改生成终稿 → 法务确认

适合：内容生产、代码评审、方案设计。

四、少量代码：状态机编排 AI 节点

下面用一个极简状态机示意 AI 节点如何嵌入业务流。代码量很少，但结构完整。

class WorkflowEngine:
    def __init__(self):
        self.steps = {}

    def register(self, name, handler):
        self.steps[name] = handler

    def run(self, state):
        while state["current"] != "done":
            handler = self.steps[state["current"]]
            state = handler(state)
            # 防止无限循环
            if state.get("steps", 0) > 20:
                state["current"] = "human_escalation"
        return state


# AI 节点：意图识别
def ai_intent(state):
    intent = small_model.classify(state["input"])
    state["intent"] = intent
    state["current"] = "route"
    return state


# 路由节点：根据意图决定分支
def route(state):
    if state["intent"] == "refund":
        state["current"] = "ai_refund_review"
    elif state["intent"] == "complaint":
        state["current"] = "human_agent"
    else:
        state["current"] = "ai_qa"
    return state


# AI 节点：退款初审
def ai_refund_review(state):
    order = get_order(state["order_id"])
    decision = large_model.review(order, state["input"])
    state["decision"] = decision

    # 置信度低于阈值，转人工
    if decision["confidence"] < 0.85:
        state["current"] = "human_review"
    elif decision["approved"]:
        state["current"] = "execute_refund"
    else:
        state["current"] = "human_review"
    return state

这段代码体现了三个关键设计：

1. AI 节点只负责推理，不决定流程走向。
2. 路由节点根据 AI 输出做流转，规则可审计。
3. 置信度阈值触发人工兜底，避免盲目自动化。

五、集成要点：让流程可靠运转

1. 上下文传递

每个节点只接收自己需要的数据，不要传递全量历史。用结构化对象：

state = {
    "trace_id": "t-123",
    "input": "我要退款",
    "order_id": "A1001",
    "intent": None,
    "decision": None,
    "current": "ai_intent"
}

trace_id 贯穿全流程，便于排查问题。

2. 幂等与重试

AI 调用可能超时或失败。每个节点必须幂等，重试不会产生副作用。写操作要加唯一键。

3. 人工兜底

任何 AI 节点都必须有升级路径：置信度低、模型异常、用户不满，都能转人工。

4. 成本控制

• 简单节点用小模型
• 重复请求走缓存
• 设置单流程 token 上限
• 记录每个节点的成本

5. 可观测性

记录每个节点的输入、输出、耗时、成本、置信度。没有这些数据，无法优化流程。

六、典型场景

• 客服工单：AI 分类 → AI 建议回复 → 人工确认 → 自动发送。
• 信贷审批：AI 初审 → 规则校验 → 人工复核 → 放款。
• 内容生产：AI 选题 → AI 初稿 → 人工编辑 → AI 终审 → 发布。
• 供应链异常：AI 检测异常 → AI 生成处理建议 → 人工决策 → 执行。
• 合同审查：AI 提取条款 → AI 标记风险 → 法务确认 → 归档。

共同点：流程可拆、节点可验证、异常可兜底。

七、避坑指南

1. 不要把 AI 做成孤岛：必须嵌入现有业务流，而不是另起一个系统。
2. 不要跳过人工兜底：再高的准确率也有出错的时候。
3. 不要传递全量上下文：节点只拿需要的数据，降低成本与干扰。
4. 不要没有 trace_id：出问题时无法定位。
5. 不要忽略幂等：重试可能造成重复退款、重复发邮件。
6. 不要一次性全自动：从辅助开始，逐步扩大 AI 权限。
7. 不要忘记成本核算：每个节点都要算清 token 消耗。
8. 不要用自然语言传状态：结构化数据是可靠性的基础。

八、演进路线：从辅助到自治

务实建议：多数企业应停在 L2–L3。L4 需要极高的可靠性和安全投入。

结语

AI 业务流架构的本质，是把模型的不确定性，封装成流程中的可靠环节。流程编排负责确定性，AI 节点负责智能决策，人工兜底负责最终安全。三者结合，AI 才能真正从“演示”走向“生产”。

少量代码就能跑通骨架，但真正的难点在于：想清楚每个节点的职责、置信度阈值、异常路径和成本边界。想清楚这些，AI 才能嵌入业务流，创造可衡量的价值。