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