StreamVibe 解析：AI 何時該開口，使用者改口後又該記住什麼？（2026）

2026 年 10 月 26 日，Chengzhi Liu 等研究者在 arXiv 發布了〈StreamVibe: Proactive Video Agents for Evolving User Intent〉。StreamVibe 想處理的情境很熟悉：你正做一件事，希望助手適時提醒；但你中途換了目標，它還在按舊要求熱心回答。這篇研究把「看懂影片」往前推一步，問助手能否追蹤現在仍然有效的需求。

下面先整理論文的三個零件，再檢查評測與數字，最後談它對日常助手的啟發。這是研究預印本的解讀；本文核對了論文 HTML、PDF 與專案頁，未執行模型重現。有價值的設計與已獲證實的產品效果，應分開判斷。

StreamVibe 的問題：看見同一個畫面，為什麼答案要改？

想像你在整理試算表，先說「每做完一階段就告訴我」，之後改成「只有出錯才提醒」。檔案可能還是同一份，但助手應該停止報進度。若只把兩句話都放進長對話，模型仍得在每次開口前重新判斷：哪一句取代哪一句？什麼已做完？先前提醒過什麼？

論文把這件事拆成三層。明確意圖像「水沸騰時告訴我」，條件由使用者說出；隱含意圖像「幫我留意這道菜」，助手要從目標、畫面與進度判斷何時幫忙；動態意圖則加入中途改口。隱含不等於讀心，它仍以使用者給出的目標及已見到的資訊為依據。

動態變化	論文的意思	用試算表理解
Revision／修訂	替換既有意圖	從「報進度」改成「只報錯誤」
Composition／組合	保留原要求，再增加要求或限制	仍報進度，再加上金額使用同一單位
Interruption／插入	加入即時問題，持續任務仍有效	先問目前在哪個分頁，之後繼續監看

這三者的差別會改變後續行為。把「增加一項」誤當「替換全部」，會漏工作；把「替換」誤當「全部保留」，就會繼續提供過期協助。原文的重要性在於，把需求變化列成可測的問題，而不是只要求模型記得更多文字。

三個零件：考題、會決定開口的模型、會更新狀態的 Harness

StreamVibe-Bench 是考題；StreamVibe-VL 是根據串流畫面決定沉默或回答的模型；StreamVibe-Harness 是維護需求、進度與歷史的執行層。專案頁將基礎模型標為 Qwen3.5-9B。要先分清這三者，才能知道改善來自訓練、外部記憶，還是測試條件。

Harness 記三種東西：目前有效的需求、任務與環境進度、已提供過的回應。它讓每個需求有自己的狀態：有的提醒完成一次便結束，有的監看要持續。舊資訊逐步摘要，近期資訊保留較細，再依當下任務取回相關歷史。取回記憶是提供證據，不能直接等同於把舊要求重新啟用。

An intent remains active until all its evidence points are covered.

中文：一項意圖會維持有效，直到對應的所有證據點都已被涵蓋。

StreamVibe 論文第 3.1 節

這句話描述的是評測任務的定義：一項需求可能對應多個該協助的時點，不能回答一次就算整件事完成。實際 Harness 還要依新輸入修訂或終止需求。第 4.1 節也明確把職責分開：生命週期管理決定哪些需求仍有效，何時回答、回答什麼，仍由模型策略決定。想先理解模型與執行層的關係，可接著看 Agent Harness 白話解說。

訓練則分兩步：先用監督式微調，同時教等待／開口及回應內容，調整兩類決策的權重；再用協助時點附近的短軌跡做強化學習，把時機、內容及整段互動的一致性列入獎勵。這是訓練與系統設計的組合，不宜把結果解讀成換一句提示詞就能得到。

StreamVibe 怎麼考？單次答對與一路做對是兩張成績單

依論文第 3.4 節，作者將評測配置為 4,100 筆：明確 600、隱含 2,000、動態 1,500。文中「85K」由 70K 任務導向微調樣本與 15K 強化學習任務組成；微調另外混入 768K 一般串流影片樣本。所以，85K 不能當作全部訓練量，也不宜自行補成三種意圖平均分配的資料集。

考試沿時間播放影片，每一步只看當時以前的畫面與使用者輸入。作者以模型提出候選協助時點與參考回應，再由四位審閱者核對，保留全體同意的樣本。這讓時點能被評分；但「哪一刻值得打擾」仍是這套標註規則下的判斷。

評測方式	它隔離了什麼問題	讀者應追問
Pointwise／逐點	在指定歷史下，獨立判斷某時點要不要回答	給的是正確歷史，還是模型自己生成的歷史？
Trajectory／整段軌跡	沿完整影片持續決策，把自己的先前回應帶到後面	早先誤答會不會導致重複、漏答或追錯需求？

兩者都需要，但意義不同。單次判斷像在乾淨桌面完成一道題；整段軌跡則要帶著自己留下的紀錄繼續做。若把前者高分直接當成長時間可用，就跳過了錯誤累積。論文希望呈現的核心，正是把需求追蹤與持續互動放回評測。

時機以 Precision、Recall、F1 與誤觸發率觀察；內容另有 Answer Score 和 Content F1。依附錄 B.5，Answer Score 主要看成功配對回應的品質，Content F1 則把配對內容分數與輸出、參考事件數量一起計算。因此，一個少開口的系統可能答得漂亮，卻漏掉許多該幫忙的時刻；只看答案品質不夠。

增益數字先停一下：v1 的主表與附錄需要對帳

摘要提出回應時機與品質改善 10.7%，加入 Harness 的主動互動增益為 12.3%。這兩個數字是作者自報。本次核對 v1 正文、附錄與專案頁，仍未找到能唯一還原它們的指標、比較基準與彙總算式，因此本文不把它們換成「整體能力提升多少」，也不自行改稱百分點。

更具體的問題是，主文表 2與附錄表 3，對部分相同數值的意圖類別標示不一致。例如 Gemini-3.1-Pro 的逐點、正確歷史評測，Content F1 在表 2 的明確／隱含欄為 29.52／52.32，表 3 則為 52.32／29.52。這個差異同時出現在本次取得的 HTML 與 PDF；本文無法替作者決定哪組標示應採用。

這不等於證明方法無效，卻足以要求分類排名與總增益先保留。若一張表的類別或是否包含 Harness 尚待釐清，就不適合把不同表的最好數字拼成一個「全面領先」的故事。讀者真正需要的是同一版資料、相同協定與清楚的系統配置。

即使只讀附錄表 13 的同表消融，取捨也很明顯：作者列出的 RL 模型加入 Harness 後，動態意圖的 Timing F1 由 13.28 到 19.96，Recall 卻由 52.58 到 30.65；明確與隱含兩類的 Timing F1 也未同步上升。這些是指定表格、指定配置的自報分數，且仍受上述整體一致性問題限制。較少誤觸發和較少漏答，必須一起驗收。

資料規模也要讀註解：作者列出 20,546 個協助點與 183.4 小時，但表 15註明，明確意圖部分的協助點與時長是從合格樣本池按比例估計。本文因此保留它們為作者報告的配置統計，不將每項都當作已獨立盤點的精確總數，也不採用存在口徑疑問的平均片長做推論。

其他研究提供什麼校正？需求改動與保持沉默都已有前例

StreamVibe 把三類意圖、持續影片、模型訓練和狀態管理接在一起，值得研究；但需求會改變這件事，已有其他團隊提出考題。IPIBench 原始論文的互動設計包含新增、編輯與取消請求，以及被動問答與主動提醒交錯。這份前例讓我們把焦點放回 StreamVibe 的組合設計，而非宣稱它發明了動態需求評測。

ProactiveBench 原始論文則把需要回答與應保持沉默的情境一起計分，討論過早回答與錯過回答。這支持了一個評估方向：主動助手的品質包含「不該說的時候能否停住」。這些研究提供背景與比較方法，並不是對 StreamVibe 分數的獨立重現。

AlphaLab 的判讀：該記住的是有效需求，不只是整段對話

一、記得更多，不等於知道哪一句已失效

對話歷史可以同時保留「報進度」與「只報錯誤」，但行動需要的是一份當下有效的要求。把原文永久留存，與把它從有效清單移除，可以同時成立。StreamVibe 的設計提醒我們，記憶除了查得到，也要能標示何時生效、何時被取代、是否已完成。若常碰到「找到了舊資料，卻用錯在今天」的問題，RAW-RAG 記憶診斷能補上證據交接的另一面。

二、懂得閉嘴，需要一個把漏答也算進去的標準

讓助手全部保持安靜，當然能減少打擾，卻也失去主動協助的目的。合理決策是把誤提醒造成的中斷、漏提醒造成的損失，以及使用者偏好一起考慮。低風險的操作建議可以容許先問一句；涉及重大後果的情境，應保留清楚的使用者確認與控制。單一平均分數很難替不同任務決定這個比例。

三、看影片回放，與真正改變工作流程，還隔著一個回饋迴圈

在標註影片裡，助手說話後，原先錄好的畫面仍沿既定時間前進；真實世界裡，一次提醒可能改變使用者下一步，也可能改變目標本身。因此，時點配對成績能支持對該影片評測的判讀，不能直接換成「人工作得更快、更安全」。原文結論也把意圖與環境共同演化，列為後續研究方向。

同樣地，1 FPS 的輸入取樣與主表 ±2 秒的配對容忍範圍，是評測設定；使用者實際等待多久，還包含擷取、狀態更新、檢索、推論和輸出。這兩種時間應分開量。若要把設計接入自己的系統，可先看 Agent Harness 實作流程，並用 Agent Observability留下每次狀態變動及觸發原因。

四、我同意這個拆法，對突破幅度保留判斷

我同意：把需求生命週期、任務進度與開口策略分開，能讓「為什麼又說了這句」變成可追查的問題，也比把全部責任交給長對話更適合設計測試。我存疑：目前 v1 的數據呈現，足以支持多大的普遍改善。主表與附錄的差異應先修正，再由外部用固定版本重跑，最後才談真實使用者的效益。

下一步：先寫一段會改口的小劇本，再看助手是否跟得上

要把這篇研究用在選工具或做系統，可以先用公開、非敏感的畫面設計一段小測試：第一階段請助手報進度，第二階段改為只報錯誤，第三階段插入即時問題。事先寫下每個階段應保留、應替換與應暫停的要求，再記下所有回答與沉默。這是建議的驗收劇本，不是本文新增的模型成績。

看四件事：舊要求是否仍觸發；新要求是否漏掉；同一提醒是否重複；插入問題後能否回到仍有效的任務。每次都保留當下可見證據、有效需求清單、實際回應與完整等待時間。AI Evals 入門能幫你先寫出合格條件，再比較模型。

截至 2026 年 10 月 28 日本次查閱，官方專案頁將程式，以及模型權重與評測資料的 Hugging Face 發布入口標為「soon」，並寫明仍在內部核准流程。這是當次頁面狀態，七日發布字樣應當作團隊計畫。追蹤下一版時，最有價值的補件是可對帳的結果表、固定版本的評測與系統配置，以及使用者真的改變行為之後的互動證據。