一切都從這個問題開始
「為什麼不能像其他 App 一樣，讓每個角色都有自己的對話泡泡？」
我們很常收到這個問題。老實說，這是個好問題。大多數聊天 App 都會把訊息顯示成獨立的泡泡——一人一個。那為什麼我們的群組聊天要把多個角色的回應合併在同一則訊息裡呢？
答案不是偷懶，也不是疏忽。這是一個刻意的工程選擇，來自我們花了好幾個月，實驗三種截然不同的 AI 群組對話做法。
三種架構
打造多角色 AI 對話時，每個平台都面臨同樣的抉擇。做法恰好只有三種，而每一種都會對成本、品質和使用者體驗帶來深遠的影響。
1. 結構化輸出（JSON 陣列）
這是業界最常見的做法。你請 AI 回傳一個 JSON 陣列，其中每個元素代表一個角色的回應：
[
{
"speaker": "夏洛克",
"emotion": "好奇",
"content": "真有意思。這泥巴的痕跡顯示……"
},
{
"speaker": "華生",
"emotion": "困惑",
"content": "福爾摩斯，你這是什麼意思？"
}
]吸引人之處：
- 只需一次 API 呼叫，只消耗一次點數
- 容易解析，並顯示成獨立的訊息泡泡
- 可以包含豐富的中繼資料（情緒、動作、場景描述）
- 非常適合用來產生使用者的回覆建議
實際情況：
- 只有昂貴的頂級模型（Claude、GPT-4）能穩定支援結構化輸出——大多數平價模型很難維持一致的 JSON 格式
- 格式錯誤會讓整個回應失效
- JSON 指令會消耗 Token，壓縮創作空間
- 模型感覺「綁手綁腳」——創意往往因此打折
- 內容限制變得更嚴格：結構化輸出模式常會觸發更嚴厲的內容過濾，讓成人向或尺度較大的角色扮演情境更容易失敗
- 上下文污染：你的對話紀錄裡會塞滿 JSON 結構
- 錯誤處理變得複雜：串流到一半解析失敗時該怎麼辦？
大多數第三方角色平台都採用這種做法。它行得通，但限制是真實存在的。
2. 工具呼叫（Agent 模式）
這是最「聰明」的做法。由 AI 決定下一個該由哪個角色發言，呼叫工具來指定，再產生該角色的回應。如此反覆，直到場景感覺完整為止。
AI 思考：「華生應該對這個發現有所反應」
→ 呼叫工具：next_speaker("華生")
→ 產生華生的回應
→ AI 思考：「現在夏洛克會插話」
→ 呼叫工具：next_speaker("夏洛克")
→ 產生夏洛克的回應
...
吸引人之處：
- 對話流程最自然
- AI 能完全掌控場景節奏
- 每個角色的回應都能獲得專屬的生成品質
- 自然而然地讓每個角色各有一則訊息
實際情況：
- 多次 API 呼叫＝多次點數扣除
- 延遲不斷累加：N 個角色＝N 次往返
- 只有高階模型（Claude、GPT-4）能穩定處理工具呼叫——較便宜的模型常常失敗，或產生幻覺般的工具呼叫
- 跨多次呼叫的狀態管理很複雜
- 有陷入無限迴圈或意外中止的風險
- 除錯是一場惡夢：問題很難重現
這是一種在紙上看起來很美好的「夢幻架構」，但規模一大，就會在營運上帶來各種頭痛問題。
3. 自由格式文字輸出（我們目前的選擇）
這是最簡單的做法。請 AI 自然地寫出場景，讓它自行決定如何在流暢的文字中呈現多個角色：
夏洛克身體前傾，目光銳利。「真有意思。這泥巴的
痕跡顯示，我們的嫌犯是從東邊過來的。」
華生皺起眉頭。「福爾摩斯，你這是什麼意思？那不過是泥巴而已。」
「不過是泥巴？」夏洛克微微一笑。「親愛的華生，這世上
沒有什麼東西是『不過是』而已的。」
吸引人之處：
- 適用於所有 AI 模型，不需要任何特殊功能
- 創作自由度最大——AI 能自然地寫作
- 上下文乾淨：對話紀錄讀起來就像小說
- 串流體驗極佳
- 只需一次呼叫，成本可預期
- 實作和維護都最簡單
實際情況：
- 所有角色都在同一個訊息區塊裡
- 無法輕易只重新生成單一角色的回應
- 介面的彈性有限
- 期待聊天式泡泡的使用者可能會感到困惑
我們是吃過苦頭才學到的
有件事我們之前從未公開分享過：我們第一版的群組聊天，用的就是工具呼叫。
我們曾經相信那個「夢幻架構」。由 AI 決定誰下一個發言，每個角色都有專屬的生成，還有漂亮的獨立訊息泡泡。它很優雅，也很聰明。但它在正式環境中也是一場災難。
使用者遇到難以預期的費用——同樣的對話，有時會花到預期的 3 倍。回應時間也會隨著 AI 決定讓多少角色參與而大幅波動。較便宜的模型會產生幻覺般的工具呼叫，或是陷入迴圈。我們的錯誤記錄裡塞滿了從沒預料到的特殊狀況。
經過好幾個月的修補和變通後，我們做出了艱難的決定：改用自由格式文字輸出，從頭重新打造。這感覺像是在倒退。但有時候，「沒那麼聰明」的解法反而是更明智的選擇。
我們為什麼做出這個選擇
在大量測試這三種做法——並把其中一種推上正式環境——之後，我們為群組聊天選擇了自由格式文字。原因如下：
穩定比功能重要——結構化輸出會在無法預期的時候失敗。當群組聊天在對話中途壞掉時，使用者早就不在乎有沒有獨立泡泡了——他們只希望它能正常運作。自由格式文字永遠不會因為格式問題而失敗。
品質比數量重要——受限的格式會在不知不覺中削弱 AI 的創造力。比較輸出結果時，自由格式總是能產生更生動、更自然的角色互動。AI 可以專心說故事，而不是專心處理 JSON 語法。
成本可預期——Agent 模式是按每個角色、每次回應計費。一個有五個角色的場景，花費可能比預期多出 5 到 10 倍。使用者應該享有可預期的價格。
全面相容——我們支援多種 AI 模型，但並不是每個模型都同樣擅長結構化輸出或工具呼叫。自由格式文字在哪裡都能用，讓使用者有更多模型可以選擇。
我們接受的取捨
沒錯，我們犧牲了「每個角色一個泡泡」的體驗。但我們換來了：
- 堅若磐石的可靠性
- 更好的創作品質
- 可預期的成本
- 更廣泛的模型支援
- 更乾淨的對話紀錄
在最重視沉浸感的群組角色扮演中，我們相信這個取捨是值得的。
即將推出：故事模式
還有個令人興奮的消息：我們正在打造一個採用結構化輸出的全新故事模式。
為什麼採取不同的做法？因為故事模式的優先順序不同：
- 精準的場景控制比自由發揮的創意更重要
- 豐富的中繼資料（鏡頭角度、音樂提示、章節分隔）能增添價值
- 格式更容易預期（清楚的章節／場景結構）
- 使用者期待更有「製作感」的體驗
不同的使用情境，適合不同的架構。我們不會死守任何單一做法——我們選擇最能服務使用者的那一種。
老實說
多角色 AI 對話沒有完美的解法。每一種做法，都是用某樣有價值的東西去換取另一樣東西。
那些顯示獨立泡泡的平台？它們很可能使用結構化輸出，並接受了它的限制。那些場景控制更「聰明」的平台？大概是使用工具呼叫，並承擔更高的成本和延遲。
我們選擇了最能優先滿足使用者在意之事的道路：可靠、有創意、划算的群組角色扮演。
獨立泡泡的體驗確實不錯。但不值得為它犧牲其他一切。
我們正在探索的方向
我們正在實驗混合式的做法：
- 後處理解析：在生成後使用輕量模型，把自由格式文字拆分成各個角色的段落
- 可選的結構化模式：讓進階使用者在需要精準控制時選擇結構化輸出
- 智慧場景偵測：自動找出自然的分段點，讓介面呈現得更好
我們的目標不是找到「正確」答案，而是在保留有效做法的同時，持續改善體驗。
對群組聊天該怎麼運作有什麼想法嗎？我們很樂意聽聽你的意見。