1. 從模型很聰明到流程真能跑AI流程管理系統(tǒng)的核心命題很多團隊在2024年前后都經歷過這樣一個階段花了幾周時間把大模型跑起來Demo演示時效果驚艷領導點頭、同事鼓掌然后……就沒有然后了。模型躺在服務器里業(yè)務部門該填的表還在填該走的審批還在走AI和真實業(yè)務之間隔著一道看不見的墻。這道墻的本質是大模型的能力邊界與業(yè)務流程的執(zhí)行需求之間存在結構性錯位。大模型擅長理解、生成、推理但它不擅長記住這個審批單已經流轉到第幾級、不擅長保證金額超過5萬必須走財務總監(jiān)節(jié)點、更不擅長在流程卡住時主動催辦。而流程管理系統(tǒng)恰恰相反——它精于狀態(tài)機、權限、節(jié)點流轉但對非結構化輸入一段自然語言描述、一張模糊的發(fā)票照片、一封語焉不詳的郵件幾乎無能為力。AI流程管理系統(tǒng)要解決的就是把這兩者的能力拼接起來讓大模型做它擅長的語義理解和決策建議讓流程引擎做它擅長的狀態(tài)管理和執(zhí)行約束。聽起來簡單但真正落地時會發(fā)現難點根本不在調通API而在于一系列工程細節(jié)——意圖識別準確率不夠怎么辦、模型輸出格式不穩(wěn)定怎么兜底、流程節(jié)點如何與模型調用解耦、人工介入的時機怎么設計、成本怎么控制。這篇文章面向的是正在或即將把大模型接入業(yè)務流程的技術負責人、全棧工程師和產品經理。我會從架構分層、模型選型、意圖路由、執(zhí)行引擎、人工兜底、成本優(yōu)化六個維度把從大模型到業(yè)務執(zhí)行這條鏈路拆開講清楚。不堆概念只講能落地的方案和踩過的坑。2. 架構分層為什么不能把大模型直接塞進流程引擎2.1 直接集成的三種典型翻車方式我見過不少團隊的第一版方案是這樣的在流程引擎的某個節(jié)點里直接寫一段代碼調用大模型API拿到返回結果后解析JSON然后決定下一個節(jié)點走哪里。這種直連方式在Demo階段跑得通但上線后幾乎必然出問題而且問題往往以三種形式出現。第一種是超時拖垮流程。大模型API的響應時間波動很大快的時候1-2秒慢的時候十幾秒甚至超時。如果流程引擎的節(jié)點是同步等待模型返回一個慢請求就會把整個流程實例卡住。更糟的是如果流程引擎用的是數據庫行鎖來保證狀態(tài)一致性這個鎖會被一直持有其他流程實例也跟著排隊。第二種是輸出格式漂移。你今天讓模型返回{action: approve}它老老實實返回了。明天換個輸入它可能返回{action: approve, reason: ...}或者干脆用自然語言說我認為應該批準。流程引擎的解析代碼一旦遇到非預期格式要么拋異常要么靜默走錯分支——后者更危險。第三種是狀態(tài)不一致。模型調用成功了但流程引擎在寫狀態(tài)時失敗了或者流程引擎寫成功了但模型調用其實超時了只是客戶端沒正確處理。這種不一致在分布式環(huán)境下會被放大最終導致模型以為批了、流程以為沒批的詭異狀態(tài)。2.2 推薦的四層架構經過多個項目的迭代我目前比較推薦的架構是四層分離層級職責關鍵技術選型接入層接收業(yè)務請求、鑒權、限流API Gateway 令牌桶智能層意圖識別、實體抽取、決策建議大模型 規(guī)則引擎編排層流程定義、狀態(tài)管理、節(jié)點路由狀態(tài)機引擎如Temporal、Camunda執(zhí)行層具體業(yè)務動作發(fā)通知、寫庫、調外部系統(tǒng)消息隊列 Worker這個分層的核心思想是智能層和執(zhí)行層通過編排層解耦智能層的輸出不是直接執(zhí)行指令而是帶置信度的建議。編排層根據建議和預設規(guī)則決定是否執(zhí)行、是否需要人工確認。舉個例子。用戶提交一段自然語言幫我申請下周三到周五的差旅去上海預算大概3000。接入層收到請求后智能層做三件事識別意圖是差旅申請抽取實體時間、地點、預算然后輸出一個結構化建議{ intent: travel_request, confidence: 0.92, entities: { start_date: 2025-01-15, end_date: 2025-01-17, destination: 上海, budget: 3000 }, suggested_action: create_travel_flow }編排層拿到這個建議后先檢查置信度是否超過閾值比如0.85再檢查預算是否超過某個金額需要額外審批然后才決定是直接創(chuàng)建流程還是轉人工確認。執(zhí)行層只負責在流程節(jié)點被觸發(fā)時執(zhí)行具體動作完全不關心這個節(jié)點是被模型觸發(fā)的還是被人手動觸發(fā)的。2.3 為什么狀態(tài)機比工作流引擎更適合AI場景傳統(tǒng)工作流引擎如Activiti的設計假設是流程路徑在定義時就基本確定運行時只是按圖走。但AI流程管理系統(tǒng)的特點是部分路徑是運行時動態(tài)決定的——模型可能建議走A分支也可能建議走B分支甚至可能建議創(chuàng)建一個原本不存在的節(jié)點。這種情況下輕量級狀態(tài)機如Temporal的Workflow比傳統(tǒng)BPMN引擎更合適。狀態(tài)機的優(yōu)勢在于狀態(tài)轉換是顯式定義的每次轉換都可以附帶條件判斷和副作用而且狀態(tài)機天然支持等待外部事件——比如等待人工確認、等待模型異步返回——不會阻塞線程。注意如果你的團隊已經在用Camunda這類引擎不必強行替換?？梢栽谝娴腟ervice Task里調用智能層把模型輸出作為流程變量然后用網關節(jié)點做條件路由。關鍵是不要讓模型調用出現在網關的條件表達式里而是提前算好。3. 模型選型不是越大越好而是越穩(wěn)越好3.1 流程場景對模型的真實需求很多團隊選模型時的第一反應是用最強的但在流程管理場景里這個思路往往是錯的。流程場景對模型的需求和聊天場景完全不同輸出穩(wěn)定性 創(chuàng)造力流程需要的是可預測的結構化輸出不是天馬行空的回答。一個7B的微調模型如果輸出格式穩(wěn)定比一個70B的通用模型更合適。延遲敏感流程節(jié)點等待模型返回的時間直接影響用戶體驗。P99延遲超過5秒的模型在交互式流程里基本不可用。成本可控流程調用是高頻的一次差旅申請可能觸發(fā)3-5次模型調用。如果每次調用成本0.1元一天1000個流程就是300-500元一個月就是上萬元。數據合規(guī)很多企業(yè)的流程數據涉及內部信息不能隨便發(fā)到外部API。3.2 三種部署模式的取舍目前主流的部署模式有三種各有適用場景模式一公有云API適合快速驗證和低頻場景。優(yōu)點是開箱即用、模型能力強缺點是數據出域、成本隨調用量線性增長、延遲不可控。如果只是做POC或者流程量很小每天幾百次這是最省事的選擇。模式二私有化部署開源模型適合數據敏感、調用量大的場景。目前7B-14B級別的開源模型如Qwen2.5-7B、Llama3.1-8B在意圖識別和實體抽取任務上經過少量微調后可以達到接近GPT-4的水平。部署工具方面Ollama適合快速驗證vLLM適合生產環(huán)境的高并發(fā)推理。這里有個經驗數據在意圖分類任務上一個用2000條標注數據微調過的Qwen2.5-7B準確率通常能到92%-95%而GPT-4零樣本大概是88%-91%。微調后的7B模型不僅更準而且延遲從2秒降到200毫秒成本從每次0.05元降到幾乎為零只算電費。模式三混合模式這是我最推薦的方案。高頻、簡單的任務意圖分類、實體抽取用本地小模型低頻、復雜的任務長文檔理解、多輪推理用云端大模型。比如用戶提交一段自然語言申請先用本地7B模型做意圖識別和實體抽取如果置信度低于閾值再調用云端大模型做二次判斷。3.3 微調還是提示工程這是被問得最多的問題。我的判斷標準很簡單如果任務可以用明確的規(guī)則描述清楚比如抽取所有日期和金額優(yōu)先用提示工程 輸出格式約束如JSON Schema、Function Calling。如果任務需要領域知識比如判斷這個報銷單是否符合公司差旅政策且你有至少500條標注數據考慮微調。如果任務需要多步推理且規(guī)則難以枚舉先用提示工程 Few-shot效果不夠再考慮微調。微調的技術路線目前比較成熟的是LoRA/QLoRA用一張24G顯存的卡就能微調7B模型。數據格式建議用instruction/input/output三元組輸出部分嚴格遵循你期望的JSON結構。訓練時注意把loss計算限制在output部分不要讓模型去學input的分布。實操心得微調數據里一定要包含負樣本——即那些看起來像目標意圖但實際不是的樣本。比如幫我查一下上次去上海的差旅報銷到哪了這看起來像差旅申請實際是查詢。沒有負樣本的微調模型會把所有相關輸入都分類成目標意圖導致流程誤觸發(fā)。4. 意圖路由與實體抽取讓模型輸出可執(zhí)行的結構4.1 從自然語言到流程指令的轉換鏈路用戶輸入的自然語言和流程引擎需要的結構化指令之間隔著三層轉換第一層是意圖識別判斷用戶想干什么。是申請、查詢、審批、還是取消這一步的輸出是一個分類標簽。第二層是實體抽取從文本里提取關鍵參數。時間、金額、人員、地點、事由。這一步的輸出是一個鍵值對集合。第三層是指令映射把意圖和實體映射成流程引擎能理解的指令。比如intenttravel_requestentities{...}映射成createProcess(travel_approval, params)。這三層可以一次性讓模型輸出也可以分步做。一次性輸出的優(yōu)點是延遲低缺點是錯誤會累積分步做的優(yōu)點是每步可校驗、可兜底缺點是延遲高。我的建議是如果模型能力足夠7B以上微調過一次性輸出如果用的是小模型或零樣本分步做。4.2 輸出格式約束的四種手段讓模型穩(wěn)定輸出JSON有四種手段按可靠性從低到高排列手段一提示詞里寫請輸出JSON?？煽啃宰畹湍Ｐ徒洺贘SON前后加解釋文字。手段二Few-shot示例。給2-3個輸入輸出示例可靠性中等。適合簡單任務。手段三JSON Schema約束。用支持結構化輸出的API如OpenAI的response_format、vLLM的guided_json可靠性高。這是目前最推薦的方式。手段四后處理 重試。無論用哪種方式都要加一層后處理用正則提取JSON塊用json.loads解析失敗則重試或降級。這是最后的兜底。import json import re def parse_model_output(text): # 嘗試直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 嘗試提取JSON塊 match re.search(r\{.*\}, text, re.DOTALL) if match: try: return json.loads(match.group()) except json.JSONDecodeError: pass # 降級返回None觸發(fā)人工處理 return None4.3 置信度閾值與路由策略模型輸出的置信度如果是分類任務通常是softmax概率如果是生成任務可以用logprob或讓模型自評是決定路由的關鍵。我的經驗閾值是置信度 0.9直接執(zhí)行無需人工確認。0.7 置信度 ≤ 0.9執(zhí)行但標記異步人工復核。置信度 ≤ 0.7轉人工處理模型輸出作為參考。這個閾值不是拍腦袋定的而是根據業(yè)務容錯率反推的。如果錯誤執(zhí)行的代價很高比如錯誤批準了一筆大額付款閾值要調高到0.95甚至0.98如果錯誤執(zhí)行的代價只是多走一步人工確認閾值可以降到0.6。注意置信度校準是個坑。很多模型的softmax概率是過度自信的——它說0.95實際準確率可能只有0.8。上線前一定要用驗證集做校準畫出可靠性曲線必要時用溫度縮放Temperature Scaling重新校準。5. 執(zhí)行引擎流程節(jié)點如何與模型調用解耦5.1 異步調用與狀態(tài)回寫流程引擎調用模型時最忌諱同步阻塞。正確的做法是流程節(jié)點觸發(fā)時向消息隊列發(fā)一條模型調用請求然后流程實例進入等待狀態(tài)模型調用完成后向流程引擎發(fā)一個回調事件流程實例被喚醒繼續(xù)執(zhí)行。這種異步模式的好處是流程引擎不會因為模型慢而卡住模型調用可以重試而不影響流程狀態(tài)多個流程實例可以并發(fā)等待不占用線程。具體實現上如果用Temporal可以用Workflow.await()等待一個信號如果用Camunda可以用External Task模式模型調用方作為外部Worker完成后調用complete接口。5.2 冪等性與重試模型調用可能失敗超時、限流、網絡抖動必須支持重試。但重試帶來一個問題如果第一次調用其實成功了只是響應沒收到重試會導致重復執(zhí)行。解決方案是冪等鍵每次模型調用請求帶一個唯一ID比如flowInstanceId nodeId attempt模型服務端記錄已處理的ID重復請求直接返回緩存結果。流程引擎?zhèn)纫惨ＷC同一個節(jié)點的執(zhí)行結果只被消費一次。# 偽代碼帶冪等鍵的模型調用 def call_model_with_idempotency(request_id, payload): # 檢查是否已處理 cached redis.get(fmodel_result:{request_id}) if cached: return json.loads(cached) # 調用模型 result model_client.invoke(payload) # 緩存結果設置過期時間 redis.setex(fmodel_result:{request_id}, 3600, json.dumps(result)) return result5.3 人工介入節(jié)點的設計AI流程管理系統(tǒng)里人工介入不是異常處理而是流程的正常組成部分。設計時要考慮三個問題什么時候介入置信度低、金額超限、涉及敏感操作如刪除、付款、模型明確表示不確定。介入時看到什么不能只給人工一個請?zhí)幚淼目瞻醉?。要把模型的原輸入、模型輸出、置信度、建議動作都展示出來人工只需要做確認/修改/拒絕三選一。介入后怎么回流人工的修改結果要作為反饋數據存下來用于后續(xù)的模型迭代。這是持續(xù)優(yōu)化的關鍵——沒有反饋閉環(huán)的AI流程系統(tǒng)準確率會一直停在初始水平。6. 成本與延遲優(yōu)化讓系統(tǒng)跑得久、跑得省6.1 緩存策略流程場景里很多模型調用是重復的。比如差旅申請的意圖識別用戶輸入千變萬化但意圖標簽就那幾個?？梢詫σ鈭D識別結果做語義緩存把用戶輸入向量化在向量庫里查相似度超過0.95的歷史請求直接復用其意圖標簽。實體抽取的緩存更直接如果兩個請求的文本高度相似編輯距離小于閾值實體大概率相同。但要注意時間、金額這類實體可能變化緩存時要排除這些字段。6.2 模型分級調用不是所有請求都需要大模型。可以設計一個分級路由第一級規(guī)則匹配。如果用戶輸入命中預設關鍵詞如請假、報銷直接走對應流程不調模型。第二級小模型。7B模型做意圖分類置信度高則直接執(zhí)行。第三級大模型。小模型置信度低時調用云端大模型做二次判斷。實測下來這個分級路由能把模型調用量降低60%-70%其中規(guī)則匹配覆蓋約30%小模型覆蓋約40%只有不到30%的請求需要大模型。6.3 批處理與流式輸出如果流程允許異步比如夜間批量處理報銷單可以把多個請求攢成一批一次性發(fā)給模型。批處理能顯著提高GPU利用率降低單位成本。對于交互式流程如果模型輸出較長比如生成審批意見可以用流式輸出讓用戶先看到部分結果降低感知延遲。但要注意流式輸出和結構化輸出JSON有沖突——JSON必須完整才能解析。折中方案是先流式輸出自然語言部分最后再輸出一個完整的JSON塊。7. 上線后的持續(xù)迭代反饋閉環(huán)怎么建7.1 反饋數據的采集系統(tǒng)上線后最重要的資產不是模型而是反饋數據。每次人工介入、每次用戶修改模型建議、每次流程走錯分支都是寶貴的標注數據。采集時要記錄原始輸入、模型輸出、置信度、人工修正結果、最終執(zhí)行結果。這些數據積累到一定量比如500-1000條就可以用來微調模型形成使用-反饋-微調-提升的閉環(huán)。7.2 A/B測試與灰度發(fā)布模型更新不能全量上線。建議用A/B測試新模型先處理10%的流量對比準確率、延遲、人工介入率等指標達標后再逐步擴大?；叶劝l(fā)布時要注意流程狀態(tài)不能因為模型版本切換而混亂。同一個流程實例要么全程用舊模型要么全程用新模型不能中途切換。實現上可以在流程實例創(chuàng)建時記錄模型版本后續(xù)節(jié)點都按這個版本調用。7.3 監(jiān)控指標上線后要盯住幾個核心指標指標含義健康范圍意圖識別準確率模型分類正確的比例 90%實體抽取F1實體抽取的綜合指標 0.85人工介入率需要人工處理的流程比例 20%P99延遲模型調用的99分位延遲 3秒單流程成本每個流程的平均模型成本根據業(yè)務定這些指標要接入監(jiān)控大盤設置告警。特別是人工介入率如果突然升高往往意味著模型效果下降或輸入分布發(fā)生了變化。8. 幾個真實踩過的坑最后分享幾個我在實際項目中踩過的坑都是文檔里不會寫的。坑一模型對否定不敏感。用戶說我不需要報銷模型可能還是識別成報銷申請。解決辦法是在微調數據里加入否定樣本或者在提示詞里明確要求注意否定詞?？佣r間實體抽取的歧義。下周三到底是哪一天模型可能算錯。穩(wěn)妥的做法是模型只負責抽取下周三這個文本具體日期轉換用規(guī)則引擎做因為規(guī)則引擎可以拿到當前日期計算更可靠。坑三多輪對話的狀態(tài)丟失。用戶先說申請差旅模型問去哪里用戶說上海這時候如果每次調用都是獨立的模型就不知道上海是回答去哪里。解決辦法是在流程實例里維護一個對話上下文每次調用模型時把歷史對話一起傳進去?？铀哪Ｐ洼敵龅慕痤~單位不一致。有時候輸出3000有時候輸出3000元有時候輸出3千。后處理時要做歸一化把所有金額統(tǒng)一成分或元的整數。坑五忽略模型的幻覺。模型可能會編造不存在的流程節(jié)點或審批人。解決辦法是在執(zhí)行層做白名單校驗模型建議的節(jié)點必須在流程定義里存在否則拒絕執(zhí)行并轉人工。這些坑的共同點是模型的能力邊界需要用工程手段來兜底。不要指望模型100%正確而是設計一個即使模型出錯也不會造成嚴重后果的系統(tǒng)。這才是AI流程管理系統(tǒng)落地的關鍵。