大模型如何真正接入业务流程？AI流程管理系统落地实践与架构设计

1. 从大模型到业务执行，中间到底缺了什么

很多团队在2024年前后都经历过这样一个阶段：老板拍板要搞AI，技术团队兴冲冲地部署了本地大模型，跑通了对话界面，演示的时候效果惊艳，但一到真实业务场景就发现——模型能聊天，但不会干活。你问它“帮我处理一下这个采购申请”，它能给你写一段看起来很有道理的分析，但它不会真的去查库存、不会真的发起审批流、不会真的把结果写回ERP系统。

这就是当前AI流程管理系统落地时最核心的断层：大模型有认知能力，但没有执行能力。它像一个知识渊博但手脚被绑住的顾问，能告诉你该怎么做，但没法替你做。而业务执行需要的是完整的动作链条——读取数据、判断条件、调用接口、写入结果、通知相关人。这两者之间的鸿沟，就是AI流程管理系统要解决的核心问题。

我过去一年参与过三个不同规模企业的AI流程管理项目，从制造业的采购审批到电商的售后工单，踩过的坑基本覆盖了从模型选型到流程编排的全链路。这篇文章不打算讲空泛的架构图，而是把“大模型怎么真正接入业务流程”这件事拆开揉碎，讲清楚每个环节的技术选择、参数配置和实操细节。适合正在做AI落地的大模型开发工程师、流程自动化负责人，以及想搞清楚“AI到底怎么干活”的技术管理者。

2. 整体架构设计：为什么不能只靠一个模型

2.1 三层架构的必然性

先说结论：任何试图用一个模型端到端解决业务流程的方案，最终都会失败。原因很简单——业务流程需要确定性，而大模型的输出本质上是概率性的。你不可能让一个概率模型直接去执行“给供应商打款”这种操作，万一它今天心情不好（温度参数偏高）多打了一个零呢？

所以AI流程管理系统的标准架构一定是三层：

第一层是认知层，由大模型负责。它的职责是理解非结构化输入（邮件、聊天记录、扫描件、语音转文字），提取关键信息，做意图识别和初步判断。这一层允许模糊，允许概率输出，但输出结果必须是结构化的。

第二层是编排层，由流程引擎负责。它接收认知层的结构化输出，按照预定义的业务规则决定下一步动作。这一层必须是确定性的，if-else逻辑清晰，每个节点的输入输出都有严格校验。

第三层是执行层，由具体的业务系统接口组成。ERP、CRM、OA、数据库、消息队列，这些系统提供原子操作能力，编排层调用它们完成实际动作。

这个架构的核心思想是：让模型做它擅长的事（理解模糊输入），让传统软件做它擅长的事（精确执行）。两者之间通过严格定义的数据契约连接。

2.2 为什么不用Agent框架一把梭

现在市面上有很多Agent框架，比如LangChain、AutoGPT、MetaGPT这些，看起来好像可以一个框架搞定所有事。我早期也试过直接用Agent框架做业务流程，结果发现几个致命问题。

第一个问题是不可观测。Agent自主决策的链路太长，中间每一步的思考过程虽然可以打印日志，但当流程出错时，你很难定位到底是哪一步的判断出了问题。是模型理解错了？还是工具调用参数传错了？还是工具本身返回了异常？排查成本极高。

第二个问题是不可控。Agent的自主性意味着它可能选择你意想不到的路径。比如你让它“处理退款”，它可能先去查了用户历史订单，然后发现这个用户是个VIP，然后自作主张给了一个更高的退款额度。这种“创造性”在业务流程里是灾难。

第三个问题是成本不可预测。Agent框架通常需要多轮模型调用，每一轮都消耗token。一个简单的审批流程如果让Agent自主规划，可能调用模型十几次，成本是固定流程的几十倍。

所以我的建议是：用Agent框架做原型验证可以，但生产环境一定要退回到“模型+固定流程”的模式。模型只在需要理解自然语言的地方出现，流程走向由代码控制。

2.3 模型选型的实际考量

选模型这件事，网上讨论很多，但真正落地时需要考虑的维度其实很具体。

首先是部署方式。云端API和本地部署各有适用场景。云端API的优势是省事，不用管GPU，按token付费，适合流量波动大、初期验证阶段。但缺点也很明显：数据要出企业内网，很多行业（金融、医疗、制造业）合规上过不去；延迟不可控，高峰期响应时间可能翻倍；长期成本高，流量大了之后比自建贵得多。

本地部署的优势是数据不出内网、延迟稳定、长期成本低。但需要一次性投入GPU硬件，而且模型更新、运维都需要专人。我经手的一个制造业项目，最初用云端API，月账单到八千多之后果断转本地部署，用两张RTX 4090跑量化后的模型，三个月就回本了。

其次是模型规模。不是越大越好。7B到14B的模型在信息抽取、意图分类这类任务上，经过适当微调后完全可以达到可用水平。70B以上的模型在复杂推理上确实更强，但推理成本高出一个数量级。我的经验是：先用小模型跑通流程，只在确实需要复杂推理的节点上调用大模型。

第三是量化策略。本地部署时，量化是必选项。FP16的7B模型需要约14GB显存，INT8量化后降到7GB左右，INT4量化后只要4GB。量化会带来一定的精度损失，但在信息抽取任务上，INT8和FP16的差异通常在1%以内，完全可接受。INT4的损失稍大，但在显存紧张时是必要的妥协。

3. 核心细节拆解：从模型输出到业务动作的关键转换

3.1 结构化输出：让模型说“人话”也“说机器话”

大模型最擅长的是自然语言，但业务流程需要的是结构化数据。这个转换过程是整个系统中最容易出问题的环节。

最原始的做法是在prompt里写“请以JSON格式输出”，然后解析模型返回的文本。这种做法的问题在于：模型可能返回带markdown代码块的JSON，可能返回不完整的JSON，可能在JSON前后加解释性文字。你需要写一堆正则表达式来清洗，而且总有漏网之鱼。

更可靠的做法是使用约束解码技术。比如vLLM框架支持的guided decoding，或者Outlines这样的库，可以在解码阶段就限制模型只能输出符合特定schema的token序列。这样出来的结果100%是合法JSON，不需要任何后处理。

如果用的模型服务不支持约束解码，退而求其次的方案是Function Calling。主流模型API都支持这个能力，你定义一个函数签名，模型会返回符合签名的参数。但要注意，Function Calling本质上还是模型生成文本然后解析，只是格式约束更强一些，仍然有失败概率，需要做好重试和降级。

我实际项目中的做法是：约束解码优先，Function Calling兜底，纯文本解析作为最后手段。同时对所有结构化输出做schema校验，校验失败就重试，重试三次还失败就转人工处理。

3.2 流程编排引擎的选择

流程编排层是连接模型和业务系统的桥梁。选什么引擎，取决于你的业务复杂度和团队技术栈。

轻量级场景（流程节点少于20个，没有复杂的并行和回滚需求）：直接用代码编排。Python的Prefect、Airflow，或者干脆自己写一个状态机。优点是灵活，想怎么改就怎么改，调试也方便。

中量级场景（流程节点20到100个，需要可视化配置）：用Camunda、Flowable这类BPMN引擎。它们提供了标准的流程定义语言，业务人员也能看懂流程图，而且有成熟的管理界面和监控能力。

重量级场景（跨部门、跨系统、有严格审计要求）：用企业级集成平台，比如MuleSoft、Apache Camel。这些平台对协议转换、消息路由、事务管理有完善的支持。

我个人的经验是：不要一开始就上重型引擎。先用代码把流程跑通，等流程稳定了、业务人员确实需要可视化配置了，再迁移到BPMN引擎。过早引入重型引擎会让开发效率大幅下降，而且很多功能你根本用不上。

3.3 人机协同的边界设计

AI流程管理系统不是要完全替代人，而是要让人在关键节点做决策。这个“关键节点”的划分，直接决定了系统的实用性和安全性。

我的划分原则是：模型置信度高且操作可逆的，自动执行；模型置信度低或操作不可逆的，转人工确认。

具体来说，信息抽取、分类、摘要生成这类任务，模型输出错了也可以轻松修正，可以自动执行。但涉及资金、合同、对外发送这类操作，必须有人工确认环节。

置信度怎么算？如果是分类任务，可以用模型输出的概率值。如果是生成任务，可以用多个模型投票，或者用另一个模型做校验。我常用的一种简单方法是：让模型在输出结构化结果的同时，输出一个0到1的置信度分数，低于阈值就转人工。虽然这个分数不一定校准得很好，但作为筛选信号已经够用了。

4. 实操过程：一个采购审批流程的完整实现

4.1 场景描述与流程设计

假设我们要实现一个采购审批流程。员工提交采购申请（可能是邮件、聊天消息或表单），系统需要：提取采购物品、数量、预算；检查库存和预算余额；根据金额决定审批层级；发起审批流；审批通过后通知采购部门。

这个流程的节点如下：

1. 接收输入（邮件/表单/聊天消息）
2. 模型提取结构化信息（物品、数量、预算、紧急程度）
3. 校验信息完整性，不完整则退回补充
4. 查询库存系统，判断是否需要采购
5. 查询预算系统，判断预算是否充足
6. 根据金额和紧急程度确定审批层级
7. 发起审批流程
8. 审批结果处理（通过则通知采购，拒绝则通知申请人）

其中第2步需要大模型，第3到8步都是确定性逻辑。

4.2 模型部署与配置

我选择用Ollama部署一个7B的量化模型。Ollama的优势是安装简单，一条命令就能跑起来，而且对消费级显卡友好。

安装命令很简单，Windows和Linux都支持。安装完成后，拉取模型：

ollama pull qwen2.5:7b-instruct-q4_K_M

这个模型是通义千问2.5的7B指令微调版本，Q4_K_M量化，文件大小约4.5GB，在8GB显存的显卡上可以流畅运行。

启动服务：

ollama serve

默认监听11434端口。然后可以通过HTTP API调用：

import requests import json def extract_purchase_info(text): prompt = f"""从以下采购申请中提取信息，以JSON格式输出： {text} 输出格式： {{ "items": [{{"name": "物品名称", "quantity": 数量, "unit": "单位"}}], "budget": 预算金额, "urgency": "紧急程度(高/中/低)", "department": "申请部门" }} """ response = requests.post( "http://localhost:11434/api/generate", json={ "model": "qwen2.5:7b-instruct-q4_K_M", "prompt": prompt, "stream": False, "format": "json" # Ollama支持JSON模式 } ) return json.loads(response.json()["response"])

注意这里的format: "json"参数，这是Ollama提供的JSON模式，会约束模型输出合法的JSON。实测下来，加了这参数之后，解析失败率从15%降到了2%以下。

4.3 流程编排的实现

用Python的Prefect做编排，核心代码如下：

from prefect import flow, task import requests @task(retries=3, retry_delay_seconds=2) def extract_info(raw_input): result = extract_purchase_info(raw_input) # schema校验 required_fields = ["items", "budget", "urgency", "department"] for field in required_fields: if field not in result: raise ValueError(f"Missing field: {field}") return result @task def check_inventory(items): # 调用库存系统API response = requests.post("http://inventory-system/api/check", json=items) return response.json() @task def check_budget(department, budget): # 调用预算系统API response = requests.get(f"http://budget-system/api/balance/{department}") balance = response.json()["balance"] return {"sufficient": balance >= budget, "balance": balance} @task def determine_approval_level(budget, urgency): if budget < 5000: return "部门经理" elif budget < 50000: return "总监" else: return "副总裁" @task def initiate_approval(approval_level, purchase_info): # 调用OA系统发起审批 response = requests.post( "http://oa-system/api/approval", json={"level": approval_level, "info": purchase_info} ) return response.json() @flow def purchase_approval_flow(raw_input): info = extract_info(raw_input) inventory = check_inventory(info["items"]) budget_check = check_budget(info["department"], info["budget"]) if not budget_check["sufficient"]: return {"status": "rejected", "reason": "预算不足"} level = determine_approval_level(info["budget"], info["urgency"]) result = initiate_approval(level, info) return {"status": "submitted", "approval_id": result["id"]}

这个流程里，只有extract_info这一步用到了模型，其他都是确定性逻辑。整个流程的执行时间在3到5秒之间，其中模型推理占2到3秒。

4.4 置信度阈值与人工介入

在extract_info之后加一个判断：

@task def should_auto_proceed(info, confidence_threshold=0.8): # 让模型输出置信度 confidence = info.get("confidence", 0.5) if confidence < confidence_threshold: return False # 金额超过一定阈值也转人工 if info["budget"] > 10000: return False return True

置信度怎么来？可以在prompt里让模型自己评估：

在输出JSON中增加一个字段"confidence"，表示你对提取结果的置信程度，0到1之间。

虽然模型自评的置信度不一定准确，但作为筛选信号是有效的。实测中，置信度低于0.7的样本，人工复核后发现确实有问题的比例超过60%。

5. 常见问题与排查技巧实录

5.1 模型输出不稳定怎么办

这是最常见的问题。同一个输入，模型两次输出可能不一样。原因通常是温度参数设置过高。对于信息抽取任务，温度应该设为0或接近0。在Ollama中可以通过options参数设置：

"options": { "temperature": 0, "top_p": 1, "seed": 42 }

设置固定的seed可以让输出在相同输入下完全一致。但要注意，即使温度设为0，由于浮点数计算的微小差异，不同硬件上输出仍可能有细微差别。

如果温度设为0后仍然不稳定，检查prompt是否足够明确。模糊的指令会导致模型在不同解释之间摇摆。把输出格式、字段含义、边界情况都写清楚，稳定性会大幅提升。

5.2 模型“幻觉”出不存在的信息

比如采购申请里没写部门，模型自己编了一个。这种情况在信息抽取任务中很常见，因为模型被训练成“尽量给出完整答案”。

解决方法是在prompt中明确指示：“如果信息未提供，对应字段填null，不要编造。”同时在后处理中校验，如果关键字段为null，就转人工补充。

另一个技巧是提供负样本。在prompt里给一两个例子，展示信息缺失时应该怎么输出。Few-shot示例对抑制幻觉非常有效。

5.3 流程执行到一半失败了怎么恢复

这是流程引擎要解决的问题。Prefect、Airflow这些工具都支持任务重试和状态恢复。关键是要把每个任务的输入输出持久化，失败后可以从上一个成功节点继续，而不是从头开始。

对于涉及外部系统调用的任务，一定要做幂等设计。比如“发起审批”这个操作，如果因为网络超时重试了两次，不能产生两个审批单。通常的做法是在调用时带一个唯一业务ID，外部系统根据这个ID去重。

5.4 模型响应太慢影响用户体验

7B模型在消费级显卡上的推理速度大约是每秒20到40个token。一个信息抽取任务需要输出200到300个token，耗时5到10秒。如果流程中有多个模型调用节点，总耗时可能超过30秒。

优化方向有几个：一是减少输出token数，只输出必要的字段，不要解释性文字。二是并行调用，如果多个模型调用之间没有依赖关系，可以并发执行。三是用小模型做预处理，比如先用一个更小的模型做意图分类，只把需要信息抽取的请求发给大模型。四是流式输出，让用户先看到部分结果，减少等待焦虑。

5.5 常见问题速查表

6. 工具选型与成本控制的实战经验

6.1 模型服务框架对比

Ollama适合快速验证和小规模部署，安装简单，但并发能力有限，默认只支持单请求处理。vLLM适合生产环境，支持连续批处理和PagedAttention，吞吐量是Ollama的5到10倍，但部署复杂度更高，需要配置GPU和CUDA环境。TGI是HuggingFace的方案，功能介于两者之间。

我的建议是：开发阶段用Ollama，生产环境用vLLM。如果团队没有GPU运维经验，可以考虑用云端的模型服务，虽然成本高一些，但省去了运维负担。

6.2 GPU选型与成本计算

本地部署的硬件成本主要是GPU。以7B模型Q4量化为例，推理需要约5GB显存，加上KV Cache和框架开销，8GB显存的显卡就够了。RTX 4060 Ti 16GB是目前性价比比较高的选择，价格在3000元左右。

如果要跑14B模型，建议16GB显存起步。70B模型需要至少48GB显存，通常用两张RTX 4090或者一张A6000。

成本回收周期怎么算？假设云端API每百万token收费10元，本地部署硬件投入10000元，电费每月200元。如果每月消耗token超过100万，大约10个月回本。实际项目中，一个中等规模的业务流程每月消耗token通常在500万到2000万之间，本地部署的回本周期在半年左右。

6.3 模型微调的必要性与时机

不是所有场景都需要微调。如果通用模型在信息抽取任务上的准确率已经达到90%以上，微调的收益有限。但如果你的业务领域有大量专业术语（比如医疗、法律、制造业），通用模型的表现可能只有70%左右，这时候微调就很有必要。

微调的数据准备是关键。通常需要500到2000条标注数据。数据质量比数量重要，标注一致性要达到95%以上。微调方法首选LoRA，训练成本低，7B模型在单张4090上微调3到4小时就能完成。

微调后的模型要经过严格评估，不能只看准确率，还要看在不同输入分布下的稳定性。我见过微调后模型在训练集上表现很好，但遇到稍微不同的表达方式就崩溃的情况。所以评估集一定要覆盖各种边界情况。

7. 从单点流程到平台化：后续扩展的思考

单个流程跑通之后，下一步自然是平台化。但平台化不是简单的功能堆叠，而是要抽象出可复用的能力。

模型服务层要统一管理模型版本、推理参数、配额限制。不同流程可能用不同的模型，需要有一个路由机制根据任务类型选择模型。

流程模板层要把常见流程抽象成模板，新流程可以通过配置快速生成。比如审批类流程、工单类流程、数据录入类流程，它们的骨架是相似的，只是节点参数不同。

监控告警层要能追踪每个流程的执行状态、模型调用的成功率、平均耗时、token消耗。这些指标是优化和成本控制的基础。

数据回流层要把人工修正的结果收集起来，作为后续微调的语料。这个闭环建立起来之后，系统的准确率会随着使用不断提升。

我在实际项目中的一个体会是：不要追求大而全的平台，而是先把一个流程做到极致，然后把其中可复用的部分抽出来。很多团队一开始就想做通用平台，结果做了一年还在做基础设施，一个实际流程都没跑起来。正确的路径是：单点突破，逐步抽象，自然演进。

另一个体会是关于人机协同的度。初期为了安全，可能所有操作都要人工确认，系统只是个辅助工具。但随着置信度提升和流程稳定，要逐步放开自动化比例。我通常建议每两周回顾一次人工介入的数据，看看哪些环节的置信度已经稳定在高位，可以尝试自动化。这个过程是渐进的，不要一步到位。

最后分享一个排查模型问题的实用技巧：把模型的原始输出完整记录下来。很多问题在事后排查时，因为只记录了结构化结果，丢失了模型的原始输出，导致无法判断是模型理解错了还是后处理逻辑有bug。我在所有模型调用节点都加了原始输出的日志，虽然会增加存储成本，但排查效率提升非常明显。