儲存與發布

這是使用 LoopAgent 最需要先理解的一條規則，也是最容易混淆的地方：「儲存」只更新 Debug 版，「發布」才更新 Online 版。

核心規則

• 在設定頁點儲存（改模型、編輯身分提示、綁定知識庫、加工具……）→ 只寫入偵錯版→ 右側偵錯聊天立即生效，可以馬上驗證。
• 但所有對外渠道（Open API、分享頁、Widget、網站插件、Telegram、Slack、LiveChat、LiveDesk……）執行時用的是最近一次「發布」時凍結的配置快照。

不點「發布」，線上永遠是舊配置。

flowchart LR
    S[點擊儲存] --> DBG[ Debug 版]
    DBG --> DC[Debug 對話立即生效]
    P[點擊發布] --> PROD[Online 版]
    PROD --> CH[對外渠道生效]

常見問題：「我改了配置 / 身分提示，怎麼線上沒變？」——因為只儲存了、沒發布。要讓改動生效到線上，必須再點一次發布 / Release。偵錯聊天正常 ≠ 線上正常。

如果一個 LoopAgent 從未發布過，對外渠道會直接報錯、根本跑不起來。首次接入 API 或渠道前，務必先發布一次。

哪些改動隨發布、哪些即時生效

不是所有東西都要「發布」才生效。區分清楚能少走彎路：

一句話：改配置要發布，改資料 / 組織級資源即時生效。

偵錯聊天

設定頁右側的偵錯聊天用於驗證配置效果：

• 它讀取的是偵錯版配置，儲存後立刻生效，可反覆調整、即時看到效果。
• 偵錯聊天是真實對話，同樣會計費。
• 偵錯 / 預覽態下不攜帶跨輪歷史記憶（每次都是乾淨上下文），屬正常現象。

連發訊息會合併成一條回覆

在智慧體還在生成時又發訊息，這些訊息不會丟。系統會先搶一把會話鎖：搶到的立即處理，沒搶到的先排隊或標記待吸收，最終合併成一條回覆。所以「連發了好幾條、只回了一條」是設計行為，不是丟訊息。

連發訊息有兩種處理模式：QUEUE（佇列） 與 APPEND（追加）。

QUEUE（佇列，預設）

排隊的訊息在訊息邊界合併——必須等當前這條回覆完整結束，才把後續訊息作為新的一輪處理。

• 訊息①搶到會話鎖，立即處理並獨立產出回覆①。
• 訊息②③在①還在處理時到達，搶鎖失敗，進入佇列排隊。
• 直到①處理完、釋放鎖，系統才自動補跑一輪，把佇列裡的②③一次性合併成一條回覆。

訊息②本身不會有單獨的回覆——這是最容易被誤當成「丟訊息」的一點。

APPEND（追加）

追加的訊息不必等本輪結束，在下一次請求模型時就被吸收進正在進行的這一輪。

• 訊息②在①還在執行時到達，不入佇列、不等①結束，只標記為「待吸收」。
• 引擎跑到下一次循環、向模型發起請求時，就把②的內容一併帶上。

合併發生在循環邊界，比 QUEUE 更早：不會新建訊息，也不會多出回覆，客戶看到的仍是被「追加」影響過的那條回覆①。適合執行中即時補充、糾偏。

多模態連發：輪間連發的訊息若帶有圖片、檔案、音訊等多模態內容，合併處理時也會一併提交給模型回應——前提是所選模型支援對應的多模態輸入能力，並已在輸入設定裡開啟該類別。

單條排隊 / 追加訊息的正文上限為 8192 字元。