AI 业务流不是“把提示词串起来”,而是把 LLM、工具调用、规则引擎、人工审核、状态持久化编排成可重试、可观测、可审计的生产流程。传统 BPM 处理的是确定性任务;AI 业务流面对的是概率性输出,因此核心设计原则是:用确定性外壳包裹概率性内核。模型只在受控节点做判断,流程的推进、回滚、补偿和审计由状态机负责。
一条专业的 AI 业务流通常包含五层:
关键约束:每个节点必须可重入;所有写操作携带幂等键;LLM 输出必须校验 schema;低置信度自动转人工;全链路记录 token 与耗时。
下面用 LangGraph 实现一条退款审批业务流:加载订单 → LLM 分类 → 条件路由 → 自动通过/拒绝/人工审核。
# pip install langgraph langchain-openai
from typing import TypedDict, Literal
from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage
import json
class FlowState(TypedDict):
order_id: str
reason: str
order: dict | None
decision: str | None
refund_id: str | None
need_human: bool
audit: list[str]
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
def load_order(state: FlowState):
# 生产环境应查数据库,并做租户隔离
order = {"id": state["order_id"], "amount": 299,
"status": "paid", "days_since_purchase": 3}
return {"order": order, "audit": state.get("audit", []) + ["load_order"]}
def classify(state: FlowState):
prompt = f"""判断退款理由是否合规,只返回 JSON:
{{"decision":"approve|reject|human","confidence":0-1}}。
理由:{state['reason']}
订单:{json.dumps(state['order'], ensure_ascii=False)}"""
resp = llm.invoke([HumanMessage(content=prompt)])
data = json.loads(resp.content)
need_human = data["decision"] == "human" or data["confidence"] < 0.75
return {"decision": data["decision"], "need_human": need_human,
"audit": state["audit"] + ["classify"]}
def approve(state: FlowState):
# 幂等键:refund_{order_id},重复执行不会重复退款
refund_id = f"refund_{state['order_id']}"
return {"refund_id": refund_id, "audit": state["audit"] + ["approve"]}
def reject(state: FlowState):
return {"audit": state["audit"] + ["reject"]}
def human_review(state: FlowState):
# 生产环境应挂起流程,写入人工工单,等待回调后 resume
return {"decision": "human_pending",
"audit": state["audit"] + ["human_review"]}
def route(state: FlowState) -> Literal["approve", "reject", "human_review"]:
if state["need_human"]:
return "human_review"
return "approve" if state["decision"] == "approve" else "reject"
builder = StateGraph(FlowState)
builder.add_node("load_order", load_order)
builder.add_node("classify", classify)
builder.add_node("approve", approve)
builder.add_node("reject", reject)
builder.add_node("human_review", human_review)
builder.set_entry_point("load_order")
builder.add_edge("load_order", "classify")
builder.add_conditional_edges("classify", route, {
"approve": "approve",
"reject": "reject",
"human_review": "human_review"
})
builder.add_edge("approve", END)
builder.add_edge("reject", END)
builder.add_edge("human_review", END)
graph = builder.compile()
if __name__ == "__main__":
result = graph.invoke({
"order_id": "A1001",
"reason": "商品破损",
"audit": []
})
print(result)这段代码展示了 AI 业务流的典型模式:LLM 只负责“分类与置信度”,路由、幂等、审计由确定性代码完成。低置信度不硬判,而是转人工,避免模型幻觉直接造成资金损失。
第一,持久化检查点。LangGraph 可接 Postgres checkpointer,Temporal 则天然持久化。进程崩溃后能从最后节点恢复,而不是重跑整条链。
第二,结构化输出。示例用 json.loads,生产应使用 response_format={"type":"json_object"} 或 Pydantic 校验,失败则重试或转人工。
第三,评估与回归。为分类节点建立标注集,每次换模型或改提示词都跑离线评估,监控准确率、人工转接率、单均成本。
第四,成本与限流。按租户设置 token 预算;相同请求走缓存;批量任务异步化;记录每次调用的 token、延迟、模型版本。
第五,人工协同。人工节点不是异常,而是业务流的一等公民。工单系统、Slack 审批、邮件回复都可作为 resume 信号。
总结:AI 业务流的竞争力不在模型,而在编排。把概率性智能放进确定性流程,用状态机、幂等、审计和人审兜底,才能让 AI 真正进入核心业务,而不是停留在演示阶段。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。