流程編排模式與除錯技巧
六個可複用的編排模式 + 一套標準除錯流程。搭建新 Agent 時，先看你的需求匹配哪個模式，不要從空白畫布憑空開始。
六個常用編排模式
模式 1:直連問答 (最小 Chatflow)
Start ─▶ LLM ─▶ Answer適用：單一職責的問答助手。任何 Chatflow 都應該先搭出這個骨架跑通，再加複雜度。
模式 2:意圖路由 (客服類標配)
Start ─▶ Question Classifier ─┬▶ 分支A(LLM 知識問答)─┐
├▶ 分支B(Tool 查資料) ─┼▶ Branch Aggregator ─▶ Answer
└▶ 分支C(兜底話術) ─┘適用：使用者問題型別多樣的場景。語義級分流用 Question Classifier，欄位級判斷 (如"金額 > 0") 用 IF Else。
模式 3:工具增強 (先查後答)
Start ─▶ Tool / Http Request ─▶ LLM(基於資料作答)─▶ Answer適用：回答需要即時資料 (行情、公告)。要點：讓 LLM 只基於工具返回的資料作答,在提示詞中明確"資料以工具返回為準，不得編造"。
模式 4:自主 Agent(讓模型自己決定調什麼)
Start ─▶ Agent(掛載多個工具)─▶ Answer適用：任務路徑不固定、需要多步推理的場景。Agent 節點採用 Function Calling 模式：模型通過函式呼叫自主使用工具，迴圈執行直到任務完成。注意：自主性越強越要用試執行覆蓋各種輸入，並配合合規護欄。
模式 5:流水線加工 (Workflow 標配)
Start ─▶ Http Request(取數)─▶ LLM(結構化輸出)─▶ Variables Transformer(排版)─▶ End適用：研報生成、內容加工等一次進一次出的任務。
模式 6:批次處理
Start ─▶ Iteration(並行)[ 子流程: LLM / Code ] ─▶ LLM(彙總)─▶ End適用：對列表逐項處理再彙總。資料量大時開 Iteration 並行模式，並配置錯誤處理避免單項失敗拖垮整體。
編排原則
- 先跑通最小鏈路，再逐段加節點 —— 每加一個節點就試執行一次，問題定位永遠只在最新加的一段
- 單一節點單一職責 —— 一個 LLM 節點又分類又生成又排版，不如拆成分類器 + 生成 + Transformer，分開各自可測
- 凡分支必有兜底 —— Question Classifier 設"其他"分類，IF Else 用好 Else 分支，不讓任何輸入走進死路
- 給節點寫註釋 —— 複雜流程裡每個節點的註釋寫清"輸入什麼、做什麼、輸出什麼",團隊協作和三個月後的自己都會感謝你
- 控制成本 —— LLM/Agent 節點是主要成本來源：能用 IF Else/Code 判斷的不用 LLM 判斷;記憶視窗開夠用的最小值;批次任務評估呼叫次數
標準除錯流程
1. 單節點試執行
除 IF Else、Branch Aggregator 等純路由/聚合節點外，處理類節點 (LLM、Agent、Tool、Code、Iteration、Loop、Parameter Extractor 等) 均可點選節點上的執行按鈕單獨測試 (以節點上是否出現執行按鈕為準)。配置完一個節點立即試執行，不要攢到最後。
2. 全流程測試的用例設計
每個 Agent 至少準備三類用例：
| 用例型別 | 例子 | 驗證什麼 |
|---|---|---|
| 正常輸入 | "什麼是市盈率？" | 主流程正確 |
| 邊界輸入 | 空訊息、超長文本、中英混雜、表情 | 流程不報錯、有兜底 |
| 越界輸入 | "幫我推薦一隻必漲的股票" | 合規護欄生效 |
3. 常見故障定位表
| 現象 | 先查什麼 |
|---|---|
| 流程沒走到預期分支 | 試執行分類器/條件節點，看分類結果或條件值;檢查分類描述是否可區分 |
| LLM 輸出不穩定 | 提示詞是否有明確格式約束;需要精確欄位就改結構化輸出 |
| Http Request 失敗 | 先在節點內試執行看狀態碼;檢查 URL、請求頭、鑑權、引數 |
| Iteration 部分元素失敗 | 查錯誤處理配置;單獨拿失敗元素的資料試執行子流程 |
| 回答帶出了不該說的內容 | 把 bad case 加進 System Prompt 的 ❌ 示例;必要時在下游加規則校驗 |
4. 上線前回歸
提示詞或流程有改動時，把三類用例完整跑一遍再發布，避免"改好一處、弄壞另一處"。