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 场景描述与流程设计假设我们要实现一个采购审批流程。员工提交采购申请可能是邮件、聊天消息或表单系统需要提取采购物品、数量、预算检查库存和预算余额根据金额决定审批层级发起审批流审批通过后通知采购部门。这个流程的节点如下接收输入邮件/表单/聊天消息模型提取结构化信息物品、数量、预算、紧急程度校验信息完整性不完整则退回补充查询库存系统判断是否需要采购查询预算系统判断预算是否充足根据金额和紧急程度确定审批层级发起审批流程审批结果处理通过则通知采购拒绝则通知申请人其中第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(retries3, retry_delay_seconds2) 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(fMissing field: {field}) return result task def check_inventory(items): # 调用库存系统API response requests.post(http://inventory-system/api/check, jsonitems) return response.json() task def check_budget(department, budget): # 调用预算系统API response requests.get(fhttp://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_threshold0.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 常见问题速查表问题现象可能原因排查方向解决方案JSON解析失败模型输出格式不对检查是否启用JSON模式启用约束解码或Function Calling输出不稳定温度参数过高检查temperature设置设为0固定seed幻觉编造信息prompt指示不明确检查prompt中的边界说明增加null处理指示和few-shot示例流程卡住外部系统超时检查各节点日志增加超时设置和重试机制重复执行幂等性缺失检查外部调用是否带唯一ID增加业务ID去重响应慢模型太大或输出太长检查token数和模型规模量化、换小模型、减少输出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。我在所有模型调用节点都加了原始输出的日志虽然会增加存储成本但排查效率提升非常明显。