Heartbeat Thinking 讓語音代理邊聽邊查：等待少 36.4%，為何不保證每題更準？
Heartbeat Thinking 在使用者說話時保留推理與工具結果，指定語音評測的回答等待減少36.4%。本文拆解半秒排程、結果重用、正確率取捨與重複呼叫成本。
Heartbeat Thinking 想把聆聽時間用來準備答案。你還沒說完一段語音要求，前半句可能已足夠讓助理先查資料，減少說完後的等待。
但使用者會停頓、改口或補條件，提前工作可能誤讀要求。另一個問題是，新逐字稿到來時若系統重啟推理，尚未完成的推理或工具參數就可能被切斷。
Ant International 的研究在 2026 年 10 月提出 Heartbeat Thinking，定時讀取最新的部分逐字稿，同時讓已開始的推理和工具有機會完成。
作者在一組語音評測中把最終回答的平均等待從 6.90 秒降到 4.39 秒，其他評測的最終正確率卻沒有一致上升。
我認為它適合改善可重用的查詢準備，採用時仍要核對最後說出的完整要求，並計算那些猜錯或重複工作的成本。
先看一般語音代理為什麼會把可利用的聆聽時間浪費掉，才能理解這次排程改了哪一段。
Heartbeat Thinking 要解決語音代理的哪一段等待？
研究把語音結束前已能開始的查詢和推理提前做，減少完整要求確定後才開始的工作。它改的是語音代理的處理流程，並非另行發布一個會聽聲音的新模型。
一般語音工具流程會先完成辨識，再讓模型理解，接著呼叫工具，最後才產生語音回答。每一步都可能花時間，如果全部串在說完之後，使用者就得一起等待。
但要求不會在最後一個字才突然出現。使用者前面可能已說出訂單編號，後面才補充配送問題。代理若先查到訂單，就有機會把部分準備藏在聆聽時間裡。
這和隨便猜下一句不同。能否提早工作，取決於當時已聽到的內容是否足夠形成有效要求，以及提早取得的結果最後有沒有被採用，不能只看系統是否一直在運算。
語音還有停頓和修正。使用者可能先提一個日期，再說改成另一個，前半句足以開始查詢，卻不代表它已經是最終條件，早做的工作因此可能失效。
研究的目標是增加能留下來的準備。它沒有要求最終回答等待全部預先推理完成，而是盡可能在完整要求到達時，手邊已有可核對的材料。
因此，效益應看說完以後還剩多少必要工作，而不是單看推理開始得多早。啟動時間提前，若結果沒完成或參數錯誤，未必能替最終回答省下時間。
提前準備有價值，但如果每次新文字都中止舊工作，準備也可能永遠做不完。
半秒讀一次逐字稿，為什麼不取消上一個推理？
新排程定時啟動推理讀取最新輸入，已執行的推理和工具則繼續，把完成結果寫進共享紀錄。部分逐字稿是使用者還在說話時，語音辨識已經提供的文字。
Heartbeat 的預設安排是每五百毫秒檢查一次，最多同時保留兩個推理工作。這是限制並行量的排程，沒有表示每半秒一定能完成推理，也不是不受限制地增加模型呼叫。
相比之下，按語音視窗切斷的做法，可能在新文字到達時丟掉尚未完成的輸出。若模型正在組合工具名稱和必要參數，這次工具呼叫就可能連送出都還來不及。
Heartbeat Thinking 讓已開始的工作繼續完成，再由後來的推理讀取最新文字。這把更新輸入和完成運算分開，減少新內容一到，原本準備就被截斷的情況。
完成的推理與工具結果會進共享紀錄，下一個工作就不必永遠從空白開始。如果第一個查詢已找到可用資料，後來的工作可以利用它，進一步補足依賴前項結果的查詢。
但共享紀錄不是所有內容都會自動變成正確答案。它也可能留下較早的解讀，後來要求若改變，就需要確認哪些內容還有用，否則保存更多反而增加混淆。
這種設計的重點，是讓工作有機會走到完成，同時讓新輸入持續進來。它沒有改變語音辨識本身的錯誤，也不保證每次分段文字都準確反映說話者意思。
保留結果之後，最終回覆者仍要決定哪些結果符合完整要求。
使用者改口時，最終回答怎麼挑可重用的結果？
回覆者讀完整逐字稿與已完成準備的快照，捨棄矛盾解讀，需要的工具結果若缺少就自行補做。快照是某個時間點已完成內容的固定集合，不會因工具稍後回來就自動改變。
這份快照在最終回答組裝上下文時建立。上下文是模型這次作答能看到的資訊，包含完整要求、先前對話、工具規格，以及當時已完成的準備。
還沒完成的工作不會讓回覆者一直等下去。研究採取的做法，是先開始處理完整要求，缺少必要查詢時由回覆者自己呼叫，避免慢工具把整個答案拖住。
同時，後來才回來的準備結果會被排除。這是一個清楚的可用邊界，能讓流程較容易管理，但也表示早期工作就算最後成功，仍可能因為太晚而無法幫到這次回答。
若使用者改口，回覆者應依最後條件挑選。例如先查過某個日期的資料，最後要求卻換成另一日，舊查詢內容即使完整，也不能因此直接拿來作答。
這也要求系統分清工具要求和工具結果。送出的參數符合最後要求，是一項條件。最後回答是否真正使用對應結果，又是另一項條件，兩者可能分離。
因此，研究沒有只看模型是否會叫工具，而是繼續追蹤哪些準備被帶進最終回答，以及是否需要重做，這才更接近提早工作的實際收益。
這個設計先增加可重用的準備，接著才看它是否真的提高任務品質。
工具覆蓋率增加十六個百分點，和回答更準有何不同？
覆蓋率衡量最終流程用了多少已完成的正確工具結果，不等於整份答案的正確率。Heartbeat 研究把這項量測稱為預先工具覆蓋率，目的是看準備是否真的被重用。
在工具任務裡，呼叫需要和參考要求匹配，結果也得在回覆者開始時可用，而且後面沒有再重複呼叫，才算成功覆蓋。單純在說話期間送出很多要求，不能全部算進去。
AudioCRAG 的定義又略有不同，量的是多少樣本重用了已完成的檢索結果，而沒有再查一次。因此，不同資料集上的百分比，不能全部當成相同數量工具被提早完成。
作者在三組測試都觀察到，Heartbeat 比視窗式準備留下更多可重用結果。FDBench v3 增加十六個百分點，支持保留進行中工作的設計，確實改變了準備完成程度。
但最終品質並沒有一致上升。在 FDBench，品質分數和一次成功率比視窗式基準提高。換到 SpeechFCEval 和 AudioCRAG，指定設定的最終表現卻略降。
這表示提早取得資訊和正確使用資訊不是同一件事。模型可能查對工具，卻在完整回答時混入舊條件。也可能多拿到一些材料，仍沒有正確判斷任務需要什麼。
研究也測試不同最終回覆模型，結果各有變化。因此，採用者需要把準備量和答案品質分開量，不宜只追求工具覆蓋率越高，就假設使用者結果一定越好。
準備較多未必更準，但仍可能降低說完後的等待，所以速度需要另外量測。
6.90 秒降到 4.39 秒，計時從哪裡開始？
數字是 FDBench v3 中相對於使用者說完後，最終語音回答開始的平均時間，不是整段對話長度。較早出現的簡短確認聲音，也不算這個最終回答的開始。
在 Heartbeat 的指定模型搭配下，視窗式準備的平均值為六點九零秒，Heartbeat 為四點三九秒，相對減少約百分之三十六點四。這是流程等待改善，沒有表示底層模型每一步計算都變快。
研究使用 Qwen3.6-35B-A3B 做預先推理，並以 DeepSeek-V4-Flash 的指定版本作最終回覆。模型搭配和工具工作負載是條件的一部分，換成別的服務仍要重新量測。
作者還檢查正確工具呼叫何時開始。Heartbeat 的平均開始時間落在說完前四點三七秒，表示部分工作確實利用了聆聽時間。但這項數字只看有匹配呼叫的情況。
因此，負的開始時間不是系統預知未來，也不代表每段要求都能提早四秒完成。使用者越早提供足夠條件，系統越可能先做出符合最後要求的查詢。
論文對早到、晚到資訊也另外分析。條件晚到時，可提前開始的機會會變少，這符合流程本身的限制：排程再積極，也不能可靠填出使用者還沒提供的必要參數。
在作者的分組分析裡，資訊較早到齊時，有七成多錄音能在說完前啟動符合最終條件的呼叫。資訊較晚到齊時，這個比例不到一半。它衡量的是啟動，不是完成結果已進入最終回答，不能拿來代替前面的覆蓋率。
等待減少後還有一筆成本：猜錯與重複的準備仍然消耗推理資源。
更多並行推理和晚到結果，會付出哪些代價？
固定排程可能在資訊沒變時重算，快照建立之後才回來的工具結果也不會再補進這次回答。Heartbeat 作者把依輸入變化調整的排程列為後續方向，這次沒有把它當成已解決的能力。
如果使用者長時間停頓，模型仍可能在相近文字上再次推理。並行上限可以限制同時負擔，卻不等於消除所有重複計算，實際費用仍要看呼叫次數、長度與工具成本。
晚到結果也可能造成重做。最終回覆者沒有拿到某個結果時，可能自行查詢。原本的準備稍後才完成，就會出現兩次相似工作，但不一定都能被使用。
更嚴重的問題是新舊結果混用。作者指出，FDBench 有百分之四的錄音，即使正確參數的工具要求已發出，最後回答仍使用錯誤或過時的準備資訊。
論文舉例，代理先依不完整條件把較貴商品加入購物車，後來聽到預算後找到便宜選項，回答卻混用了前一次購物車總額。新的查詢沒有自動撤回先前動作，最後敘述也未必一致。
這個例子說明，改對後面的參數，不等於前面的狀態已恢復。對會改變外部狀態的工具，系統需要另行處理確認與補救，不能只憑最後一句看起來符合要求。
這些成本與限制決定它適合哪些查詢，而不是所有語音動作都應提早執行。
什麼工作值得先準備，部署前應驗證哪個條件？
我會先用能安全重用的讀取查詢比較等待、錯誤與呼叫量，再確認改口時不會沿用錯誤參數。這讓研究裡的排程收益，對應到實際產品能接受的工作。
像先讀資料、準備檢索候選，通常比直接修改帳號或送出交易更容易核對。這是依工具後果作出的產品設計判斷，不是論文已替所有工具驗證安全的結論。
驗收也應保留停頓、晚補條件和明確改口的錄音。若只挑最前面就把資訊說完的例子，可能高估能提前工作的比例，也看不到新舊結果混用的問題。
延遲證據目前集中在 FDBench，其他工作負載的工具速度和資料需求不同。能在更短等待中維持完整要求與執行結果的一致，才是這項排程真正值得保留的改善。
延伸閱讀：語音 AI 代理只看逐字稿夠嗎？Tazo 的音訊決策層主張與論文證據怎麼讀
延伸閱讀：Dessa 只聽人聲學會對話：Block 全雙工語音模型的展示與開放界線
Heartbeat Thinking 常見問題
Heartbeat Thinking 是新的語音模型嗎？
它是讓語音代理在聆聽時安排推理與工具準備的流程，使用既有模型，不是新的聲學模型。
平均少等 36.4% 適用所有語音工作嗎？
這份延遲結果集中在指定 FDBench v3 模型與工具條件，其他工作需要另行量測。
工具覆蓋率提高，就代表回答一定更準嗎？
覆蓋率衡量準備是否被重用，最終答案還可能混用過時資訊，品質必須分開檢查。
