去年搭客服問答工作流的時(shí)候我把知識(shí)庫召回段落、訂單查詢結(jié)果、歷史對(duì)話全部用模板節(jié)點(diǎn)拼進(jìn)系統(tǒng)提示詞里。剛上線幾天效果還行等到對(duì)話輪次變多、用戶問法千奇百怪之后問題就暴露了每次請(qǐng)求的 token 消耗肉眼可見地漲回復(fù)開始抓不住重點(diǎn)有些用戶明明在問發(fā)貨時(shí)間模型反而在復(fù)述產(chǎn)品參數(shù)。后來我把這些“臟文本”統(tǒng)一交給 Dify 的代碼節(jié)點(diǎn)做清洗、去重、截?cái)?、重組Prompt 從三千多字壓到九百字上下成本下來了回復(fù)穩(wěn)定性反而好了不少。這篇就用這個(gè)客服案例講講Dify 代碼節(jié)點(diǎn)到底怎么精簡 Prompt以及我在落地過程里踩過的一些坑。1. 先看問題Prompt越拼越長token和效果一起失控1.1 長Prompt是怎么長起來的只要在 Dify 里搭過復(fù)雜工作流的人基本都經(jīng)歷過這個(gè)演變過程。一開始系統(tǒng)提示詞只有一段角色設(shè)定加兩三句要求跑通之后開始接知識(shí)庫把召回結(jié)果用模板節(jié)點(diǎn)拼進(jìn)去接著為了上下文連貫把歷史對(duì)話也拼進(jìn)去后面接了訂單查詢、物流查詢這類工具又要把工具返回的 JSON 原樣塞進(jìn)去。每一步單獨(dú)看都合理但疊加到一起一次請(qǐng)求的系統(tǒng)提示詞就能輕松超過三千字。這里有個(gè)特別容易忽略的點(diǎn)Dify 的模板節(jié)點(diǎn)本質(zhì)上是“變量占位符加靜態(tài)文本”它沒有任何智能只會(huì)把變量原樣替換進(jìn)去。知識(shí)庫召回多少段它就塞多少段歷史對(duì)話有多少輪它就把多少輪全部平鋪在提示詞里。開發(fā)階段一次兩次測試感覺不到問題等真實(shí)用戶進(jìn)來對(duì)話輪次一多、知識(shí)庫檢索條目一多Prompt 長度就會(huì)指數(shù)級(jí)膨脹。我當(dāng)時(shí)的客服工作流里Prompt 的主要來源有三個(gè)。第一個(gè)是知識(shí)庫召回段一次召回 8 到 10 段每段平均 350 字光這里就有三千多字第二個(gè)是歷史對(duì)話測試的時(shí)候只有兩三輪上線后用戶會(huì)有意無意聊十幾輪全量拼進(jìn)去至少兩千字第三個(gè)是訂單查詢結(jié)果工具返回的 JSON 有幾十個(gè)字段真正用到的其實(shí)只有訂單狀態(tài)、物流單號(hào)、最新節(jié)點(diǎn)這幾項(xiàng)。三個(gè)來源加起來單次請(qǐng)求的消耗非?？捎^。1.2 長Prompt的真實(shí)代價(jià)長 Prompt 的代價(jià)不只是花錢。第一是 token 費(fèi)用。按當(dāng)時(shí)粗略統(tǒng)計(jì)三千多字的中文提示詞經(jīng)模型分詞后大概要消耗 2000 到 3000 token。假設(shè)每天有幾千次對(duì)話請(qǐng)求這里多出來的成本就是純浪費(fèi)。而且用戶每多問一句歷史對(duì)話就會(huì)更長下一次請(qǐng)求的費(fèi)用又會(huì)上漲這是一個(gè)持續(xù)惡化的過程。第二是效果漂移。模型對(duì)超長上下文的注意力是有限度的當(dāng)知識(shí)庫段落、歷史對(duì)話、工具結(jié)果擠在一起真正和當(dāng)前問題相關(guān)的關(guān)鍵信息會(huì)被淹沒。用戶問“我的訂單為什么還沒到”模型如果被一大段產(chǎn)品介紹干擾回出來的內(nèi)容就會(huì)偏題。很多團(tuán)隊(duì)遇到這種問題會(huì)去調(diào)整模型參數(shù)或者換更大的模型但根源往往只是 Prompt 里的噪聲太多。第三是維護(hù)成本。模板節(jié)點(diǎn)里的變量引用一多改需求的時(shí)候根本不知道哪一段對(duì)應(yīng)哪個(gè)上游節(jié)點(diǎn)。想加一句“請(qǐng)用簡體中文回答”得在模板里翻半天還容易誤刪變量。相比之下代碼節(jié)點(diǎn)把所有文本處理集中到一個(gè)入口規(guī)則寫在 Python 函數(shù)里改動(dòng)和排查都清楚得多。下面是精簡前后同一份 Prompt 的結(jié)構(gòu)對(duì)比可以直觀感受到差距組成部分精簡前精簡后知識(shí)庫召回段8 到 10 段每段約 350 字去重后最多保留 3 段每段 300 字以內(nèi)歷史對(duì)話全部輪次約 2000 字最近 3 輪每輪 150 字以內(nèi)訂單查詢結(jié)果完整 JSON約 1200 字白名單 4 個(gè)關(guān)鍵字段約 120 字合計(jì)長度約 3500 字約 2500 token約 900 字約 600 token看到這個(gè)對(duì)比之后我才意識(shí)到Prompt 精簡不是摳那幾十個(gè)字而是把整個(gè)工作流里冗余的文本來源逐一收緊。2. 代碼節(jié)點(diǎn)在Dify里的定位它不是補(bǔ)丁是文本加工中心2.1 模板節(jié)點(diǎn)解決不了的事情有人可能會(huì)問Dify 里不是有模板節(jié)點(diǎn)、條件分支節(jié)點(diǎn)嗎為什么一定要用代碼節(jié)點(diǎn)模板節(jié)點(diǎn)能做的只是拼接。你可以用{{變量}}把上游內(nèi)容插進(jìn)一段文字里但你沒辦法在模板里寫“如果這段內(nèi)容超過 300 字就截?cái)唷薄叭绻@一段和前面重復(fù)就去掉”“如果 JSON 里沒有某個(gè)字段就補(bǔ)一句占位”。模板節(jié)點(diǎn)的定位是給靜態(tài)文案服務(wù)的不是給數(shù)據(jù)處理服務(wù)的。條件分支節(jié)點(diǎn)能做判斷但判斷之后你還是要回到模板節(jié)點(diǎn)里重新拼一份 Prompt。如果三個(gè)分支分別要拼三份不同的 Prompt模板里就會(huì)塞進(jìn)大量重復(fù)的靜態(tài)文本維護(hù)起來比不用分支還要痛苦。而且條件分支節(jié)點(diǎn)需要配置多條規(guī)則規(guī)則復(fù)雜之后排錯(cuò)非常費(fèi)眼每次都像在做邏輯迷宮。真正適合干這件事的是代碼節(jié)點(diǎn)。你可以把代碼節(jié)點(diǎn)理解成一個(gè)透明的小型 Python 函數(shù)它接收上游節(jié)點(diǎn)的輸出執(zhí)行完邏輯后把結(jié)果交給下游。所有清洗、去重、截?cái)?、重組都可以在一個(gè)函數(shù)里完成規(guī)則是確定性的輸入相同就永遠(yuǎn)輸出相同這恰好是 Prompt 預(yù)處理最需要的性質(zhì)。2.2 代碼節(jié)點(diǎn)的輸入、輸出和運(yùn)行邊界用代碼節(jié)點(diǎn)之前先把它的運(yùn)行機(jī)制看清楚可以少走很多彎路。Dify 的代碼節(jié)點(diǎn)支持 Python 和 Node.js 兩種運(yùn)行時(shí)。平時(shí)做文本處理Python 就夠用標(biāo)準(zhǔn)庫里的re、json、math基本覆蓋所有場景。節(jié)點(diǎn)有一個(gè)主入口函數(shù)接收你配置的輸入變量返回一個(gè)字典字典的鍵就是你在界面上配置的輸出變量。配置輸入變量的時(shí)候要明確指定類型。常用的有字符串、數(shù)字、數(shù)組、對(duì)象、布爾值。這里有個(gè)習(xí)慣值得養(yǎng)成所有變量統(tǒng)一用小寫下劃線命名比如knowledge_text、history_text避免后面寫代碼時(shí)大小寫不一致導(dǎo)致排查半天。代碼節(jié)點(diǎn)運(yùn)行在受控環(huán)境里不能假設(shè)它能訪問外部網(wǎng)絡(luò)也不要依賴第三方庫。有人想在代碼節(jié)點(diǎn)里直接用某個(gè) pypi 庫做語義壓縮實(shí)際執(zhí)行就會(huì)發(fā)現(xiàn)環(huán)境里沒有這個(gè)庫。所以代碼節(jié)點(diǎn)適合做規(guī)則明確的文本處理不適合做需要模型推理的語義任務(wù)。語義層面的壓縮應(yīng)該交給 LLM 節(jié)點(diǎn)代碼節(jié)點(diǎn)只負(fù)責(zé)把模型能力之外的臟活累活接過來。2.3 什么情況適合上代碼節(jié)點(diǎn)什么情況別硬上根據(jù)我這段時(shí)間的使用經(jīng)驗(yàn)代碼節(jié)點(diǎn)適合處理四類問題。第一清洗。比如從知識(shí)庫召回的文本里去掉空行、去掉重復(fù)段、去掉 HTML 標(biāo)簽這些活用正則表達(dá)式寫幾行就完事模板節(jié)點(diǎn)完全做不了。第二截?cái)?。把超長文本按照長度閾值或者句末標(biāo)點(diǎn)截?cái)啾Ａ粝鄬?duì)完整的信息。第三結(jié)構(gòu)重組。把多個(gè)上游輸出按業(yè)務(wù)需要重新排列成固定格式再喂給 LLM 節(jié)點(diǎn)。第四輕量路由。在代碼里通過關(guān)鍵詞或正則判斷當(dāng)前請(qǐng)求屬于哪個(gè)意圖輸出一個(gè)狀態(tài)字段給下游條件分支節(jié)點(diǎn)用能省掉不少分支規(guī)則的配置。反過來有些場景不應(yīng)該硬上代碼節(jié)點(diǎn)。比如你想讓歷史對(duì)話變得更精煉把它從兩千字壓成兩百字摘要這是語義壓縮應(yīng)該用 LLM 節(jié)點(diǎn)。代碼節(jié)點(diǎn)只能做“砍掉最近三輪以外的內(nèi)容”這種機(jī)械截?cái)嘧霾坏健皫陀脩艨偨Y(jié)他上一輪的核心訴求”。再比如需要生成自然語言文案這也應(yīng)該交給模型。代碼節(jié)點(diǎn)什么都管最后會(huì)變成一個(gè)又臭又長的正則堆反而難維護(hù)。3. 完整實(shí)操把一段三千字的Prompt壓到九百字3.1 先想清楚輸入輸出再動(dòng)手寫代碼我們以客服問答工作流為例目標(biāo)是把系統(tǒng)提示詞從三千字壓到九百字。第一步不是寫代碼而是梳理清楚這個(gè)代碼節(jié)點(diǎn)的輸入和輸出。輸入變量我配置了四個(gè)knowledge_text字符串知識(shí)庫召回的所有段落原始文本。history_text字符串歷史對(duì)話記錄格式可能是“用戶xxx\n客服xxx”。tool_result字符串訂單查詢工具返回的 JSON 字符串。user_query字符串用戶當(dāng)前問到的問題。輸出變量我配置了兩個(gè)prompt_text字符串壓縮并組裝好的完整系統(tǒng)提示詞。estimated_tokens數(shù)字提示詞長度的粗略估算方便日志里觀察每次壓縮后的體量。這里有個(gè)經(jīng)驗(yàn)輸出變量不要只定義一個(gè) prompt_text。多返回一個(gè)估算 token 數(shù)之類的調(diào)試字段后續(xù)在運(yùn)行日志里能直接看到效果不用去數(shù)文本長度。等跑穩(wěn)定了再?zèng)Q定要不要留著這個(gè)字段給后面的節(jié)點(diǎn)用。3.2 一套能直接抄的壓縮代碼下面這段代碼就是我當(dāng)時(shí)用的壓縮邏輯注釋寫在關(guān)鍵位置方便對(duì)照。如果你用的 Dify 版本代碼節(jié)點(diǎn)入口是main(inputs: dict)這種老式簽名我會(huì)在第 4 節(jié)單獨(dú)給兼容寫法。import re import json def _clean(text, default): if not text: return default return str(text).strip() def _cut(text, limit): text re.sub(r\s, , text).strip() if len(text) limit: return text cut text[:limit] # 盡量在句號(hào)處斷開避免從句子中間截掉 if 。 in cut: return cut.rsplit(。, 1)[0] 。 return cut def _dedup(paragraphs): seen, result set(), [] for p in paragraphs: key p[:40] if key not in seen: seen.add(key) result.append(p) return result def main( knowledge_text: str , history_text: str , tool_result: str {}, user_query: str , ): knowledge_text _clean(knowledge_text) history_text _clean(history_text) tool_result _clean(tool_result, {}) user_query _clean(user_query) # 1. 知識(shí)庫分段、去重、限長 paragraphs [p.strip() for p in re.split(r\n, knowledge_text) if p.strip()] paragraphs _dedup(paragraphs) knowledge_buf [] current_len 0 for p in paragraphs: if current_len 1000: break p _cut(p, 300) knowledge_buf.append(p) current_len len(p) 1 knowledge_final \n.join(knowledge_buf)[:1000] # 2. 歷史對(duì)話只保留最近 3 輪每輪限長 150 字 lines [l.strip() for l in history_text.splitlines() if l.strip()] if len(lines) 6: lines lines[-6:] history_final \n.join(lines) if len(history_final) 900: history_final history_final[-900:] # 3. 訂單查詢結(jié)果只提取關(guān)鍵字段 tool_fields {} try: parsed json.loads(tool_result) except Exception: parsed None if isinstance(parsed, dict): for key in [order_status, tracking_no, latest_event, refund_status]: if key in parsed: tool_fields[key] parsed[key] elif isinstance(parsed, list) and parsed: record parsed[0] if isinstance(record, dict): for key in [order_status, tracking_no, latest_event, refund_status]: if key in record: tool_fields[key] record[key] tool_final json.dumps(tool_fields, ensure_asciiFalse) # 4. 組裝精簡后的系統(tǒng)提示詞 prompt f你是某電商平臺(tái)的客服助手。請(qǐng)嚴(yán)格依據(jù)下方資料回答用戶問題資料不足時(shí)如實(shí)說明。 【知識(shí)庫】 {knowledge_final} 【歷史對(duì)話】 {history_final} 【訂單信息】 {tool_final} 【用戶問題】 {user_query} return { prompt_text: prompt.strip(), estimated_tokens: max(1, len(prompt.strip()) // 3), }這段代碼跑通之后我的 Prompt 長度就從三千字掉到了九百字左右。需要注意estimated_tokens用的是len(text) // 3這種粗略估算中文按每三個(gè)字符約等于一個(gè) token 來算實(shí)際值會(huì)隨模型分詞器有波動(dòng)但用于觀察壓縮趨勢已經(jīng)足夠了。3.3 壓縮策略里的幾個(gè)取舍很多人第一次寫這種代碼會(huì)陷入一個(gè)誤區(qū)想把所有信息都保住于是截?cái)嚅撝挡桓以O(shè)太低。實(shí)際上概率模型不是靠“記住所有內(nèi)容”來回話的它靠的是抓住與當(dāng)前問題最相關(guān)的部分。思路要轉(zhuǎn)換一下Prompt 里應(yīng)該只留“和當(dāng)前用戶問題有關(guān)”的信息而不是把整個(gè)上下文搬進(jìn)去。知識(shí)庫部分我選擇去重加限長。去重的指紋取每段前 40 個(gè)字符足夠區(qū)分兩段不同的內(nèi)容。限長分兩層單段限長 300 字避免某一段特別長的段落獨(dú)占上下文整體限長 1000 字給歷史對(duì)話和工具結(jié)果留出空間。這里用到的是典型的分層預(yù)算思路先定總預(yù)算再分給每個(gè)模塊而不是讓每一段都在極限邊緣。歷史對(duì)話部分只保留最近 3 輪。這個(gè)取舍一開始我也猶豫擔(dān)心丟掉前面幾輪的背景信息。實(shí)際測試下來客服場景里用戶當(dāng)前問題與最近幾輪的語義關(guān)聯(lián)最強(qiáng)前面那些已經(jīng)被答過的內(nèi)容對(duì)當(dāng)前問題幫助有限。如果后面發(fā)現(xiàn)某些用戶確實(shí)需要跨很多輪才能說清需求那就是另一套方案再加一個(gè) LLM 摘要節(jié)點(diǎn)把老對(duì)話壓成一段摘要再接上最近幾輪。工具返回結(jié)果部分用白名單字段提取只保留訂單狀態(tài)、物流單號(hào)、最新節(jié)點(diǎn)、退款狀態(tài)這幾個(gè)字段。JSON 里其他字段比如庫存編碼、內(nèi)部備注模型根本不需要知道。這一步節(jié)省的 token 量非常驚人因?yàn)?JSON 字段名的重復(fù)率高刪掉無關(guān)字段等于直接砍掉一大截文本。3.4 把精簡后的Prompt接回LLM節(jié)點(diǎn)代碼節(jié)點(diǎn)寫完下一步是把prompt_text接進(jìn) LLM 節(jié)點(diǎn)的系統(tǒng)提示詞里。在 Dify 編輯器里L(fēng)LM 節(jié)點(diǎn)的系統(tǒng)提示詞輸入框右側(cè)可以選擇變量找到上一級(jí)代碼節(jié)點(diǎn)的prompt_text輸出選中即可。注意別把用戶當(dāng)前問題再重復(fù)塞進(jìn)系統(tǒng)提示詞user_query應(yīng)該直接走用戶輸入否則用戶問題出現(xiàn)兩次模型反而可能混亂。跑通之后先在一次真實(shí)請(qǐng)求里看看運(yùn)行日志。日志里能找到代碼節(jié)點(diǎn)返回的prompt_text內(nèi)容確認(rèn)沒有出現(xiàn)“本來是 JSON 卻變成了字符串”“歷史對(duì)話全堆在一起”這類問題。我第一次接入時(shí)工具結(jié)果字段沒有order_status代碼直接拋了異常節(jié)點(diǎn)標(biāo)紅工作流中斷。這就是為什么代碼里必須對(duì)tool_result解析做異常容錯(cuò)線上真實(shí)返回的數(shù)據(jù)永遠(yuǎn)比你測試時(shí)拿到的樣例更臟。這里順帶說一句不是所有工作流都需要把系統(tǒng)提示詞做成本文這種固定格式。如果你的場景里知識(shí)庫召回?cái)?shù)量本來就少、歷史對(duì)話也不長那模板節(jié)點(diǎn)拼接完全夠用沒必要為精簡而精簡。代碼節(jié)點(diǎn)的價(jià)值在復(fù)雜場景下才會(huì)充分體現(xiàn)。4. 落地時(shí)最容易翻車的四個(gè)細(xì)節(jié)4.1 空值問題None不是空字符串別直接拼接代碼節(jié)點(diǎn)最常見的翻車點(diǎn)就是上游節(jié)點(diǎn)沒有傳值。比如用戶第一輪提問時(shí)歷史對(duì)話為空history_text可能是None也可能是空字符串。如果你在代碼里直接寫history_text.splitlines()空字符串沒問題None會(huì)直接報(bào)AttributeError。后來我養(yǎng)成了一個(gè)習(xí)慣代碼節(jié)點(diǎn)入口統(tǒng)一走一遍兜底處理任何輸入變量都先轉(zhuǎn)成字符串再處理。這也是上面代碼里_clean函數(shù)存在的意義。別嫌這一步麻煩代碼節(jié)點(diǎn)一旦在運(yùn)行中拋異常整條工作流直接中斷下游 LLM 節(jié)點(diǎn)連執(zhí)行的機(jī)會(huì)都沒有這個(gè)代價(jià)遠(yuǎn)比多寫兩行兜底大得多。我的兜底規(guī)則是給所有輸入變量提供默認(rèn)值kwargs風(fēng)格優(yōu)先函數(shù)內(nèi)部再用_clean()統(tǒng)一收斂。這樣即使上游節(jié)點(diǎn)沒輸出也能保證代碼不炸最多返回一段內(nèi)容較空的 prompt讓模型根據(jù)現(xiàn)有信息回答或者走人工轉(zhuǎn)接分支。4.2 JSON解析工具返回結(jié)果沒你想的那么規(guī)整工具節(jié)點(diǎn)返回的字段界面上看是結(jié)構(gòu)化 JSON但只要轉(zhuǎn)成字符串再傳進(jìn)代碼節(jié)點(diǎn)就可能出現(xiàn)各種奇怪情況。最常見的兩個(gè)第一個(gè)是 JSON 字符串首尾帶多余空白字符第二個(gè)是字符串里夾雜了模型或者工具自己添加的解釋文字導(dǎo)致json.loads直接失敗。我遇到最典型的一次是返回的 JSON 里帶了一個(gè)多余的尾逗號(hào)標(biāo)準(zhǔn) JSON 解析直接報(bào)錯(cuò)。排查了半天才發(fā)現(xiàn)是上游處理環(huán)節(jié)拼接字符串時(shí)留下的。解決方案是在解析前做一層預(yù)處理先把首尾空白去掉再嘗試把一些不標(biāo)準(zhǔn)的尾逗號(hào)替換掉。如果這樣都解析不出來就退回一個(gè)空字典不要讓異常冒泡出去。另外輸出 JSON 時(shí)一定要用ensure_asciiFalse。否則 Python 會(huì)把中文字段變成\uXXXX形式的轉(zhuǎn)義序列拼進(jìn) Prompt 里模型也能讀但視覺審計(jì)日志時(shí)幾乎沒法看排查問題的效率會(huì)下降很多。4.3 輸出變量名對(duì)不上節(jié)點(diǎn)就給你顏色看代碼節(jié)點(diǎn)的返回字典鍵必須和你配置的輸出變量完全一致。我在初期犯過一次低級(jí)錯(cuò)誤配置的輸出變量叫prompt_text代碼里返回的字典鍵寫成了prompt結(jié)果節(jié)點(diǎn)運(yùn)行失敗錯(cuò)誤提示還不算特別直觀我花了十幾分鐘才找到原因。正確做法是配置完輸出變量后回到代碼區(qū)核對(duì)一遍函數(shù)末尾的return字典。如果你配置了多個(gè)輸出變量一個(gè)都不能少。這里推薦一個(gè)調(diào)試小技巧臨時(shí)多設(shè)置一個(gè)輸出變量debug_info類型選字符串把中間處理完的各段文本拼進(jìn)去返回。只要運(yùn)行一次日志里就能看到每一段到底被處理成了什么樣比我對(duì)著代碼猜半天高效得多。4.4 新老版本入口函數(shù)差異和調(diào)試習(xí)慣Dify 的代碼節(jié)點(diǎn)在不同版本里的入口寫法略有變化。老版本模板生成的代碼是def main(inputs: dict) - dict: knowledge_text inputs.get(knowledge_text, ) ... return {prompt_text: prompt.strip()}新版本里更常見的是具名參數(shù)風(fēng)格也就是第 3 節(jié)代碼里那種直接寫def main(knowledge_text: str, ...)的形式。如果你照著網(wǎng)上某篇文章復(fù)制代碼但節(jié)點(diǎn)一直報(bào)參數(shù)錯(cuò)誤先看一眼自己版本的點(diǎn)子模板用的是哪種簽名再做對(duì)應(yīng)調(diào)整。我自己現(xiàn)在遇到代碼節(jié)點(diǎn)問題時(shí)調(diào)試順序是固定的先看運(yùn)行日志有沒有拋異常再確認(rèn)輸入變量是否真的傳到了節(jié)點(diǎn)最后才去看代碼邏輯。很多人一上來就盯著代碼看實(shí)際上有一半的問題出在節(jié)點(diǎn)配置或者上游輸出上代碼是背鍋的。把調(diào)試順序固定下來之后排錯(cuò)速度會(huì)快很多。5. 再往前走一步把代碼節(jié)點(diǎn)用在更多環(huán)節(jié)5.1 歷史會(huì)話摘要化而不是單純截?cái)嗟?3 節(jié)的代碼里歷史對(duì)話用的策略是只保留最近 3 輪。這個(gè)策略在大部分客服場景夠用但如果用戶問的問題牽扯到很早之前的對(duì)話單純截?cái)嗑蜁?huì)丟失信息。更好的方案是組合使用把較早的歷史對(duì)話交給一個(gè) LLM 摘要節(jié)點(diǎn)讓它用 200 字左右概括用戶的訴求和已確認(rèn)的信息然后把這個(gè)摘要作為歷史對(duì)話字段傳進(jìn)代碼節(jié)點(diǎn)。代碼節(jié)點(diǎn)負(fù)責(zé)拼接時(shí)只把“摘要 最近 3 輪”拼進(jìn)去。這樣既保住了長期背景又控制了長度。兩個(gè)節(jié)點(diǎn)各司其職摘要交給模型拼接和截?cái)嘟唤o代碼互不干擾。5.2 按意圖過濾工具結(jié)果字段工具結(jié)果的字段白名單可以做得更聰明一些。比如用戶詢問物流代碼節(jié)點(diǎn)可以只返回tracking_no和latest_event用戶詢問退款就只返回refund_status和相關(guān)說明。在代碼節(jié)點(diǎn)里用幾個(gè)關(guān)鍵詞正則分組判斷意圖然后動(dòng)態(tài)決定提取哪一組字段比在界面上配一堆條件分支要清爽得多。if 退款 in user_query or 退貨 in user_query: wanted_keys [refund_status, latest_event] elif 物流 in user_query or 到哪 in user_query: wanted_keys [tracking_no, latest_event] else: wanted_keys [order_status, tracking_no, latest_event]這種做法把路由邏輯收斂在代碼內(nèi)部輸出結(jié)構(gòu)更一致下游 LLM 節(jié)點(diǎn)收到的始終是“訂單信息”模塊只是內(nèi)容按意圖變化。條件分支節(jié)點(diǎn)仍然有用但更適合做“是否需要轉(zhuǎn)人工”這種粗粒度的流程控制而不是細(xì)粒度字段篩選。5.3 把清洗邏輯沉淀成可復(fù)用模塊代碼節(jié)點(diǎn)的代碼是可以復(fù)用的。如果你在多個(gè)工作流里都要做知識(shí)庫文本清洗可以把這段邏輯保存成一份標(biāo)準(zhǔn)代碼每次新建代碼節(jié)點(diǎn)時(shí)直接粘貼然后只修改輸入輸出變量名。我習(xí)慣把這套代碼維護(hù)在一個(gè)本地文檔里字段名變更時(shí)統(tǒng)一改再重新粘到各個(gè)工作流。更進(jìn)一步可以在 Dify 里把“文本清洗 Prompt 組裝”抽成一個(gè)獨(dú)立的工作流然后在其他工作流中通過子流程調(diào)用。這樣清洗規(guī)則只需要維護(hù)一處任何調(diào)整都不會(huì)牽一發(fā)動(dòng)全身。唯一要注意的是子流程的輸入輸出參數(shù)要定義清楚否則上游傳參時(shí)很容易對(duì)不上變量名。我自己現(xiàn)在搭工作流的標(biāo)準(zhǔn)動(dòng)作是先列一份“這份 Prompt 里哪些內(nèi)容是可裁剪的”清單再?zèng)Q定哪些交給代碼節(jié)點(diǎn)、哪些交給摘要模型。把裁剪規(guī)則定清楚、字段名統(tǒng)一之后很多時(shí)候效果提升比換更強(qiáng)的模型來得還明顯。代碼節(jié)點(diǎn)看起來只是一個(gè)小工具但它讓整個(gè) Prompt 供應(yīng)鏈變得可控了。最后再分享一個(gè)小技巧所有代碼節(jié)點(diǎn)里返回的字段命名盡量穩(wěn)定。比如prompt_text、estimated_tokens這種名字我用到現(xiàn)在沒變過。字段名一旦到處都是后續(xù)換人維護(hù)光對(duì)齊變量就要花半天。穩(wěn)定命名帶來的長期收益往往比寫好幾行壓縮邏輯還要值。