在昨天的 Day 12 中，我們為系統建立了嚴密的錯誤警報機制（Error Trigger），確保工作流具備高可用度。然而，目前的待辦助理每次接收訊息時，都像是在跟一個「完全失憶」的全新對象說話——如果你隨後發送「把剛才的會議改成下午兩點」或「取消倒垃圾」，模型根本不知道「剛才」指的是什麼。

今天我們要解鎖大語言模型最核心的能力之一：「對話記憶（Conversation State）」。透過在 n8n 追蹤並傳遞 Dify 的 conversation_id，讓 AI 助理具備上下文記憶，支援任務追問、修改與補充！

為什麼需要傳遞 conversation_id？

Dify 的 Chatbot / Agent API 是標準的狀態化（Stateful）設計：

1. 首次對話：呼叫 API 時若不帶 conversation_id（傳空字串或省略），Dify 會在回傳時自動生成一組全新的 conversation_id。
2. 多輪對話延續：後續呼叫若帶上同一組 conversation_id，Dify 便會自動載入該會話的所有歷史聊天紀錄，讓模型能精準理解「這項任務」、「改為下週」等代名詞與修訂指令。
3. 區隔使用者工作階段：在實際多用戶場景下，不同的 Chat ID 應該綁定各自獨立的會話 ID，避免彼此的上下文混淆。

核心實作步驟說明

1. 修改 HTTP Request 節點的 Payload 設定

• 回到呼叫 Dify API 的 HTTP Request 節點。
• 將發送給 Dify 的 JSON Body 補上 conversation_id 欄位：

{
  "inputs": {},
  "query": "={{ $json.body.message }}",
  "response_mode": "blocking",
  "conversation_id": "={{ $json.body.conversation_id || '' }}",
  "user": "={{ $json.body.user_id || 'ironman-user' }}"
}

(說明：透過 JavaScript 的 || '' 邏輯，若外部傳入空值則發起新對話，若帶入歷史 ID 則延續該會話)。

2. 擷取並回傳 Dify 的 conversation_id

• 點開接在 HTTP Request 後方的節點或回應處。

• 檢視 Dify 成功回傳的 JSON 結構，其中會包含兩個核心欄位：

• answer：模型提煉出的 JSON 任務清單字串。

• conversation_id：本次會話的專屬 UUID。

• 我們可以透過一個簡單的 Set / Edit Fields 節點，將 conversation_id 傳遞給後續流程或記錄到快取。

3. 在 Telegram 回報中附帶會話代碼

• 點開發送推播的 Telegram 節點。
• 在通知訊息底部加入當前的會話資訊，方便後續串接追蹤：

✅ *AI 待辦任務處理完成！*

📋 *任務*：{{ $json.name }}
⏰ *時間*：{{ $json.property_time }}

💬 *會話 ID*：`{{ $('HTTP Request').item.json.conversation_id }}`

4. 驗證上下文修改功能

• 第一輪測試：傳入「下週一早上九點要開會」，Dify 建立會議任務並回傳一組 conversation_id（例如 conv_abc123）。
• 第二輪追問測試：帶上該 conversation_id，發送「把剛才的會議改成早上十點」。
• 檢視 AI 輸出：模型不會新建一筆新任務，而是成功回傳調整時間後的任務結構，驗證上下文延續成功！

今天我們成功打通了會話記憶的傳遞通道，讓待辦助理具備了真正的互動式修改能力。明天「Day 14」我們將針對解析邏輯做最後昇華——「智慧狀態判斷（CRUD 路由）」，讓 n8n 能根據 Dify 判斷出的意圖（新增、修改、刪除），自動走向不同的 Notion 操作分歧！