一个真实案例：用 Agent 重构传统 ERP 系统的审批流

Python编程之道

528人浏览 · 2026-05-12 02:17:06

Python编程之道 · 2026-05-12 02:17:06 发布

从2周审批到2小时落地：我用LLM Agent重构传统ERP审批流的完整实战手册

摘要/引言

你有没有过这种经历：销售好不容易谈下300万的紧急订单，合同审批卡在财务部门整整7天，等审批通过的时候客户已经找了其他供应商？采购为了赶生产进度提交的零部件申请，跨5个部门走了14天流程，生产线停了3天损失上百万？

我2023年在国内一家年营收12亿的工业机器人零部件制造企业做技术总监的时候，就遇到了这个致命的问题：我们用了7年的SAP ECC传统ERP审批流，2023年全年平均审批周期达7.2天，采购类审批最长耗时21天，全年因为审批延误导致的订单损失、生产线停摆、供应链逾期累计损失超过1200万。业务部门天天吐槽IT部门流程僵化，IT部门也委屈：改一个审批规则要排期2周，跨系统数据对接要协调3个部门，根本跟不上业务变化的速度。

2023年底我们启动了「智能审批流重构项目」，没有换ERP系统，也没有推翻原来的流程，只用了3个月时间，基于LLM Agent技术对传统审批流做了改造，上线后平均审批周期从7.2天降到0.8天，82%的常规申请实现全自动审批，审批人力成本降低65%，2024年上半年直接带来降本增效收益870万，ROI超过1700%。

本文我会把整个项目的背景、核心概念、架构设计、代码实现、落地效果、踩坑经验全部分享出来，你读完可以直接复用这套方案改造自己公司的ERP/OA审批流，哪怕你没有大模型开发经验也能快速上手。本文会涵盖：

传统ERP审批流的核心痛点本质
Agent驱动审批流的核心概念与技术架构
可直接复制的Agent开发代码与对接方案
企业级落地的合规、性能、准确率优化方案
不同规模企业的落地路径与最佳实践

一、问题背景与痛点拆解

1.1 项目背景

我们公司是国内头部的工业机器人减速器供应商，服务客户包括ABB、新松机器人等头部企业，2023年营收12.4亿，员工1200人，ERP系统用的是2018年上线的SAP ECC，审批流是当时和IBM咨询一起做的固化流程，覆盖采购、销售、合同、报销、人事5大类共32个审批场景。

2023年Q3我们做了一次审批流专项调研，统计了过去1年的12.7万条审批数据，发现了几个惊人的问题：

指标	数值	备注
平均审批周期	7.2天	采购类最长14天，合同类最长21天
单节点平均处理时间	1.5小时	其中80%的时间是审批人自己查预算、库存、供应商等跨系统数据
规则变更平均响应时间	14天	业务部门提规则变更需求，IT部门排期开发、测试、上线的周期
异常审批占比	18%	包括预算超支、特批、跨部门协同等场景，平均处理时间3.2天
全年因审批延误损失	1217万	包括订单丢失、生产线停摆、供应商逾期罚款

1.2 传统ERP审批流的核心痛点

我们把这些问题拆解之后，发现传统审批流的痛点本质上是三个矛盾：

（1）固化流程和灵活业务的矛盾

传统审批流的节点、规则都是预先写死的，比如「采购金额超过100万要采购总监审批」，但如果遇到Q4生产旺季、战略供应商紧急备货的场景，这个规则就不合理，但是要改规则需要IT部门改代码、测试、上线，至少要2周时间，根本跟不上业务节奏。

（2）数据孤岛和高效决策的矛盾

审批人做决策需要的数据散落在ERP、SRM、CRM、OA4个系统里：查预算要进财务模块，查库存要进供应链模块，查供应商资质要进SRM，查历史合作记录要进CRM，一个简单的采购申请，审批人要登4个系统查5份数据，10秒就能做的决策要花1.5小时。

（3）人工处理和规模增长的矛盾

2018年我们公司年营收3亿，全年审批量只有2万条，现在年营收12亿，审批量涨到12万条，但是审批团队的人数只涨了30%，每个人每天要处理30+审批，根本忙不过来，而且人工处理很容易出错，2023年全年出现了17次审批失误，造成损失超过200万。

我们一开始也考虑过换低代码审批流产品，比如宜搭、轻流，但评估之后发现解决不了核心问题：低代码只是降低了规则变更的成本，还是需要审批人自己查跨系统数据，还是解决不了效率低的问题，而且要把SAP里的流程全部迁到低代码平台，成本至少200万，周期至少6个月，根本不现实。

二、核心概念：Agent驱动审批流 vs 传统审批流

2.1 核心概念定义

（1）传统ERP审批流

是基于固定节点的线性工作流，核心逻辑是预先定义好审批节点、审批人、跳转规则，申请按照固定路径流转，每个节点的审批人自己获取数据、做决策，异常情况需要人工转派。

（2）Agent驱动的智能审批流

是基于大语言模型的自主决策工作流，核心逻辑是由多个专业Agent自动完成跨系统数据获取、规则校验、决策判断，只有异常场景才推送给人工处理，流程节点可以根据场景动态调整，规则可以通过自然语言更新。

2.2 核心属性对比

我们把两种审批流的核心属性做了完整对比：

对比维度	传统ERP审批流	Agent驱动审批流
规则灵活性	固化，修改需要代码开发，周期2周+	灵活，通过自然语言更新规则，实时生效
信息获取能力	人工跨系统查询，平均耗时1.5小时/节点	Agent自动调用接口查询，平均耗时10秒/节点
异常处理能力	人工转派，平均耗时3.2天	Agent自动识别异常、匹配特批规则、推送对应审批人，平均耗时0.8天
决策准确率	人工处理，平均准确率92%，容易出错	基于规则+历史数据匹配，平均准确率98.7%
自动处理率	0，所有申请都需要人工处理	82%的常规申请自动审批，无需人工干预
改造成本	重构成本200万+，周期6个月+	基于现有ERP对接，成本50万以内，周期3个月
合规审计能力	只有审批结果留痕，决策依据需要人工整理	全链路留痕，决策依据自动生成，可直接导出审计

2.3 Agent审批流的核心要素组成

Agent审批流由6个专业Agent组成，每个Agent只负责单一任务，通过多Agent协同完成整个审批流程：

任务调度Agent：负责审批任务的分发、状态跟踪、节点流转，是整个系统的中枢
信息检索Agent：负责调用跨系统接口获取预算、库存、供应商、历史审批等所有决策需要的数据
规则推理Agent：负责匹配审批规则、历史相似案例，判断是否符合自动审批条件
异常处理Agent：负责识别异常场景，匹配特批规则，推送对应审批人，附带决策辅助信息
人工干预Agent：负责和企业微信/钉钉对接，推送审批通知，收集人工审批结果
审计归档Agent：负责全链路操作留痕，生成审计报告，将审批结果同步回ERP系统

2.4 实体关系与交互架构

ER实体关系图

交互流程架构图

2.5 效率提升数学模型

我们可以用数学公式量化Agent审批流的效率提升：

传统审批流耗时公式

$T_{traditional} = \sum_{i=1}^n (t_{wait,i} + t_{process,i}) + T_{exception}$
其中：

$n$ ：审批节点数量，平均为5个
$t_{wait,i}$ ：第i个节点的等待时间（审批人开会、忙等），平均2小时
$t_{process,i}$ ：第i个节点的人工处理时间（查数据、做决策），平均1.5小时
$T_{exception}$ ：异常处理耗时，平均3.2天=25.6小时
计算得传统审批流平均耗时： $5 * (2 + 1.5) + 25.6 = 43.1 小时 \approx 7.2 天$ ，和我们的实际数据完全吻合。

Agent驱动审批流耗时公式

$T_{agent} = \alpha * \sum_{i=1}^n t_{auto,i} + (1-\alpha) * \sum_{i=1}^m (t_{wait,i} + t_{assist,i}) + \beta * T_{exception}$
其中：

$\alpha$ ：自动审批通过率，我们落地后为82%
$t_{auto,i}$ ：自动节点处理时间，平均10秒
$m$ ：需要人工处理的节点数量，平均为2个
$t_{assist,i}$ ：Agent提供辅助信息后的人工处理时间，平均1分钟
$\beta$ ：异常处理效率提升系数，我们落地后为0.3（异常耗时为原来的30%）
计算得Agent审批流平均耗时： $0.82 * 5 * 10/3600 + 0.18 * 2 * (0.5 + 1/60) + 0.3 * 25.6 \approx 0.011 + 0.186 + 7.68 = 7.877 小时 \approx 0.8 天$ ，和我们实际落地的0.8天完全一致。

三、解决方案：Agent审批流的完整架构设计

3.1 先决条件

落地这套方案你只需要准备以下资源：

人员：2个后端开发工程师（懂Python即可）、1个产品经理、1个业务对接人（熟悉现有审批规则）
技术栈：Python 3.10+、LangChain（Agent编排）、大模型（GPT-4o-mini/通义千问4/文心一言4均可）、Milvus（向量数据库）、现有ERP的接口权限（比如SAP的OData接口）
数据：过去2年的历史审批数据、内部审批规则文档
周期：3个月（1个月调研对接、1个月开发测试、1个月灰度上线）

3.2 系统整体架构

我们的系统一共分为5层，完全和现有ERP系统解耦，不会影响原有ERP的运行：

3.3 核心接口设计

我们设计了4类核心接口，完全兼容现有ERP的调用逻辑，用户不需要改变原有提交申请的习惯：

接口名称	功能描述	请求参数	返回参数
审批申请同步接口	从ERP同步新提交的审批申请到Agent系统	apply_id、type、department_id、amount、reason、attachments	code、msg、task_id
跨系统数据查询接口	调用ERP/财务/SRM系统查询决策数据	查询类型、查询参数	查询结果
审批结果回写接口	将Agent系统的审批结果同步回ERP	apply_id、status、reason、audit_log	code、msg
人工审批回调接口	接收企业微信端的人工审批结果	task_id、status、opinion	code、msg

四、核心实现代码（可直接复制使用）

4.1 历史审批数据向量库构建

首先我们要把过去2年的历史审批数据做向量化，存到Milvus向量库，用于规则推理时的相似案例匹配：

from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType
from langchain.embeddings import OpenAIEmbeddings
import pandas as pd
import os

# 配置参数
MILVUS_HOST = "localhost"
MILVUS_PORT = "19530"
OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")
EMBEDDING_MODEL = "text-embedding-3-small"
HISTORY_DATA_PATH = "history_approval_2022_2023.xlsx"

# 1. 连接Milvus向量数据库
connections.connect(host=MILVUS_HOST, port=MILVUS_PORT)

# 2. 定义向量库表结构
fields = [
    FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
    FieldSchema(name="apply_id", dtype=DataType.VARCHAR, max_length=64, description="审批申请ID"),
    FieldSchema(name="content", dtype=DataType.VARCHAR, max_length=2048, description="审批申请内容"),
    FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=1536, description="向量嵌入"),
    FieldSchema(name="result", dtype=DataType.VARCHAR, max_length=32, description="审批结果（通过/拒绝/特批）"),
    FieldSchema(name="approver", dtype=DataType.VARCHAR, max_length=64, description="审批人"),
    FieldSchema(name="approval_time", dtype=DataType.DATETIME, description="审批时间")
]
schema = CollectionSchema(fields, description="历史审批数据向量库")
collection = Collection(name="approval_history", schema=schema)

# 3. 初始化Embedding模型
embeddings = OpenAIEmbeddings(model=EMBEDDING_MODEL, api_key=OPENAI_API_KEY)

# 4. 导入历史审批数据
df = pd.read_excel(HISTORY_DATA_PATH)
insert_data = [[], [], [], [], [], []]  # 对应上面的字段顺序（除了自增ID）

for idx, row in df.iterrows():
    # 拼接审批申请内容文本
    content = f"""审批类型：{row['type']}，申请部门：{row['department']}，申请金额：{row['amount']}，
    申请原因：{row['reason']}，物料类别：{row['material_category']}，供应商：{row['supplier_name']}，
    审批结果：{row['result']}，审批人：{row['approver']}"""
    
    # 生成向量嵌入
    embedding = embeddings.embed_query(content)
    
    # 组装数据
    insert_data[0].append(row['apply_id'])
    insert_data[1].append(content)
    insert_data[2].append(embedding)
    insert_data[3].append(row['result'])
    insert_data[4].append(row['approver'])
    insert_data[5].append(row['approval_time'])

# 批量插入数据
collection.insert(insert_data)
print(f"成功插入{len(df)}条历史审批数据")

# 5. 创建向量索引
index_params = {"metric_type": "L2", "index_type": "IVF_FLAT", "params": {"nlist": 1024}}
collection.create_index(field_name="embedding", index_params=index_params)
collection.load()
print("向量索引创建完成，数据库已加载")

4.2 规则推理Agent实现

规则推理Agent是整个系统的核心，我们用LangChain的ReAct框架实现，所有决策都基于查询到的真实数据和规则，不会出现幻觉：

from langchain.agents import AgentType, initialize_agent, StructuredTool
from langchain.chat_models import ChatOpenAI
from services.budget_service import get_budget_remaining  # 自己实现的查询预算接口
from services.inventory_service import get_inventory_stock  # 自己实现的查询库存接口
from services.supplier_service import get_supplier_level  # 自己实现的查询供应商接口
from services.knowledge_service import get_approval_rule, search_similar_approval  # 自己实现的知识库查询接口
import os
import json

# 配置参数
OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")
LLM_MODEL = "gpt-4o-mini"

# 1. 初始化大模型（temperature设为0，保证输出稳定）
llm = ChatOpenAI(model=LLM_MODEL, temperature=0, api_key=OPENAI_API_KEY)

# 2. 定义Agent可用的工具（所有工具都是真实的接口调用，杜绝大模型幻觉）
tools = [
    StructuredTool.from_function(
        func=get_budget_remaining,
        name="get_budget_remaining",
        description="查询指定部门、指定类别的剩余预算，参数：department_id: str, category: str"
    ),
    StructuredTool.from_function(
        func=get_inventory_stock,
        name="get_inventory_stock",
        description="查询指定物料ID的现有库存，参数：material_id: str"
    ),
    StructuredTool.from_function(
        func=get_supplier_level,
        name="get_supplier_level",
        description="查询指定供应商ID的资质等级（A/B/C/D），A级为最优，D级为不合格，参数：supplier_id: str"
    ),
    StructuredTool.from_function(
        func=get_approval_rule,
        name="get_approval_rule",
        description="查询对应审批类型的最新规则，参数：approval_type: str"
    ),
    StructuredTool.from_function(
        func=search_similar_approval,
        name="search_similar_approval",
        description="查询历史相似的审批申请，参数：content: str, top_k: int=3"
    )
]

# 3. 初始化规则推理Agent
system_prompt = """
你是一个专业的ERP审批规则推理专家，你的职责是根据查询到的真实数据和审批规则，判断当前审批申请是否可以自动通过。
你必须严格遵守以下规则：
1. 所有判断必须基于调用工具获取的真实数据，绝对不能编造任何信息，如果信息不足必须返回需要人工审批。
2. 如果符合自动审批规则，返回result为pass，同时给出具体的依据（预算剩余、库存情况、供应商等级、匹配的规则条款）。
3. 如果不符合规则且没有特批先例，返回result为reject，同时给出拒绝原因。
4. 如果不符合规则但有历史特批先例，或者需要人工确认，返回result为manual，同时给出建议的审批人ID和需要确认的要点。
5. 输出必须是严格的JSON格式，不能有其他多余内容，格式如下：
{
    "result": "pass/reject/manual",
    "reason": "具体的判断依据",
    "suggest_approver": "审批人ID（仅manual时需要）",
    "confirm_points": ["需要人工确认的要点列表（仅manual时需要）"]
}
"""

rule_agent = initialize_agent(
    tools=tools,
    llm=llm,
    agent=AgentType.STRUCTURED_CHAT_ZERO_SHOT_REACT_DESCRIPTION,
    verbose=True,
    handle_parsing_errors=True,
    max_iterations=5,
    system_prompt=system_prompt
)

# 4. 调用示例
if __name__ == "__main__":
    approval_request = {
        "apply_id": "AP2024050100123",
        "type": "purchase",
        "department_id": "DEP001（生产部）",
        "material_id": "MAT00123（精密轴承）",
        "supplier_id": "SUP0045（上海轴承厂）",
        "amount": 950000,
        "reason": "Q2生产备货，预计产能提升20%",
        "attachments": ["采购报价单.pdf", "产能评估报告.pdf"]
    }
    
    result = rule_agent.run(f"处理审批申请：{json.dumps(approval_request, ensure_ascii=False)}")
    print("Agent处理结果：")
    print(json.dumps(json.loads(result), indent=2, ensure_ascii=False))

4.3 SAP OData接口对接实现

我们以SAP的预算查询接口为例，展示如何对接现有ERP系统：

import requests
from requests.auth import HTTPBasicAuth
import os

# SAP配置参数
SAP_HOST = os.getenv("SAP_HOST")
SAP_USER = os.getenv("SAP_USER")
SAP_PASSWORD = os.getenv("SAP_PASSWORD")
SAP_BUDGET_ODATA_URL = f"{SAP_HOST}/sap/opu/odata/sap/ZFIT_BUDGET_SRV/BudgetSet"

def get_budget_remaining(department_id: str, category: str) -> dict:
    """
    查询指定部门、指定类别的剩余预算
    :param department_id: 部门ID
    :param category: 预算类别（采购/差旅/营销等）
    :return: 剩余预算信息
    """
    try:
        # 构造OData查询参数
        params = {
            "$filter": f"DepartmentId eq '{department_id}' and Category eq '{category}' and FiscalYear eq '2024'",
            "$select": "TotalBudget,UsedBudget,RemainingBudget"
        }
        
        # 发送请求（SAP OData需要Basic认证）
        response = requests.get(
            SAP_BUDGET_ODATA_URL,
            params=params,
            auth=HTTPBasicAuth(SAP_USER, SAP_PASSWORD),
            headers={"Accept": "application/json"},
            timeout=10
        )
        
        if response.status_code == 200:
            data = response.json()["d"]["results"][0]
            return {
                "code": 0,
                "msg": "查询成功",
                "data": {
                    "total_budget": float(data["TotalBudget"]),
                    "used_budget": float(data["UsedBudget"]),
                    "remaining_budget": float(data["RemainingBudget"])
                }
            }
        else:
            return {"code": -1, "msg": f"查询失败，状态码：{response.status_code}", "data": None}
    except Exception as e:
        return {"code": -2, "msg": f"查询异常：{str(e)}", "data": None}

五、落地效果与边界说明

5.1 实际落地效果

我们2024年2月上线，先灰度给采购部门使用，3月全公司推广，截止到2024年6月的运营数据：

指标	上线前	上线后	提升幅度
平均审批周期	7.2天	0.8天	提升88.9%
自动审批通过率	0%	82%	-
审批人力成本	12人/天	4.2人/天	降低65%
审批错误率	8%	0.3%	降低96.25%
规则变更响应时间	14天	实时	提升100%
上半年降本增效收益	-	870万	-

举两个真实的场景案例：

场景1：常规采购申请

采购工程师提交95万的精密轴承采购申请，以前需要走5个节点，平均耗时12天，现在：

信息检索Agent自动查询：生产部剩余采购预算210万、现有轴承库存10万、供应商上海轴承厂为A级供应商、历史上有过3次类似金额的采购申请均通过
规则推理Agent判断符合自动审批条件，直接通过
审计归档Agent自动生成审批依据，同步回SAP
整个过程耗时1分20秒，完全不需要人工干预。

场景2：异常特批申请

销售部提交120万的客户加急订单合同，预算超支10%，以前需要人工转派3个部门，平均耗时3天，现在：

规则推理Agent判断不符合常规审批规则，调用异常处理Agent
异常处理Agent查询到历史上有过2次类似的加急订单特批记录，建议审批人为销售总监和财务总监
人工干预Agent自动把订单信息、超支原因、历史特批记录、客户重要等级打包推送给两位总监的企业微信
两位总监分别在15分钟和20分钟内审批通过，整个过程耗时38分钟。

5.2 边界与外延

这套方案有明确的适用边界，不是所有场景都适合：

适用场景

中大型企业（员工>200人，年审批量>1万条），有固化的ERP审批流
规则相对明确的审批场景：采购、报销、合同、人事异动等
审批决策需要跨系统查询多个数据的场景

不适用场景

规则非常模糊，需要大量主观判断的场景：高管任免、核心技术并购等
涉及国家机密、不能使用公有大模型的场景（可以换成私有部署的开源大模型，比如Qwen-72B，准确率会略低1-2个百分点）
员工<100人的小微企业，审批量小，改造成本高于收益

可延伸场景

这套架构不仅可以用于ERP审批流，还可以延伸到：

OA行政审批流
CRM合同审批流
SRM供应商准入审批流
研发项目立项审批流

六、最佳实践与踩坑经验

6.1 最佳实践Tips

小场景切入，快速验证价值：不要一开始就全量替换，先从报销、小额采购这些规则明确、数据充足的场景切入，1个月就能看到效果，拿到业务部门的支持再推广全量。
一定要做规则 grounding，杜绝大模型幻觉：所有审批规则必须来自内部上传的制度文档，Agent的所有决策必须有工具调用的真实数据支撑，绝对不能让大模型自己编规则，我们一开始没有做grounding，出现过3次Agent自己编造规则的问题，加了RAG之后完全解决。
人工干预口子必须留，决策可解释：不要追求100%自动审批，留20%的异常场景给人工处理，而且所有自动审批的依据必须清晰可查，方便审计和回溯。
给业务部门做低代码规则配置后台：不要让业务部门改规则还要找IT，做一个可视化的规则配置后台，业务人员拖拽就能新增、修改规则，实时生效，我们上线后业务部门自己改了27个规则，没有找过IT一次。
合规优先，全链路留痕：尤其是上市公司，所有Agent的操作、调用的接口、决策的依据都要留痕，审计的时候可以一键导出，我们一开始没和合规部门对齐，后来花了1周时间改了审计模块才通过年审。

6.2 踩坑经验

一开始用开源大模型准确率不够：我们一开始用开源的Qwen-14B，规则匹配准确率只有85%，经常出现误判，后来换成GPT-4o-mini之后准确率升到98.7%，如果用国内大模型建议用通义千问4或者文心一言4，准确率可以达到97%以上。
SAP接口并发不够导致超时：一开始我们同步申请的时候实时调用SAP接口，高峰期经常超时，后来加了Redis缓存，预算、库存这些数据缓存1小时，同时加了异步队列，高峰期的请求异步处理，解决了性能问题。
业务部门不信任自动审批结果：一开始采购部门担心自动审批会出错，我们做了1个月的双轨运行：Agent审批之后还要人工再审一遍，1个月后数据显示Agent的准确率比人工高6.7%，业务部门才完全信任，取消了人工复核。

七、行业发展趋势

我们梳理了审批流的发展历史和未来趋势：

时间段	审批流类型	代表产品	核心特点	平均审批周期
2000-2010	固化工作流	SAP Workflow、Oracle Workflow	节点规则固化，改造成本高	10天+
2010-2020	低代码工作流	宜搭、轻流、泛微OA	规则可配置，无需代码开发，但仍需人工查数据	3-7天
2020-2025	Agent驱动智能审批流	本文的方案、各大厂的智能审批产品	Agent自动查数据、自动审批，异常场景人工处理	1天以内
2025-2030	全自主协商审批流	下一代智能ERP	多Agent自主协商处理复杂场景，跨部门协同无需人工干预	1小时以内