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