SeedRealtime 全雙工手機 Agent：Seeduplex 語音互動與 Android 執行層架構指南

SeedRealtime 與 Seeduplex 對手機 Agent 改變了什麼

SeedRealtime 全雙工手機 Agent 這個搜尋意圖，真正關心的是一件事：當語音模型可以更自然地聽、說、被打斷，手機上的 AI Agent 是否就能更可靠地替使用者完成任務？答案要拆成兩層。SeedRealtime 和 Seeduplex 對語音互動層很重要；但 Android 手機任務仍需要另一個受治理的執行層，負責權限、核准、工具調用、結果驗證與復原。

ByteDance Seed 在 2026 年 4 月 9 日發布的Seed full-duplex speech LLM 介紹中，把 Seeduplex 描述為原生邊說邊聽的語音框架，並提到干擾抑制、端點判斷、打斷處理等改善，以及在 Doubao 中推出。Seed 目前也在SeedRealtime 模型頁列出 SeedRealtime 模型家族，讓這個方向成為即時語音 Agent 討論中的重要參考。

從我們打造 FoneClaw 的角度看，全雙工語音 AI 的價值，是把手機 Agent 的入口變得更接近人類對話。使用者可以更自然地說「等一下，不要送出」、「改成比較客氣」、「先幫我看這個畫面」；模型也能在說話時聽到補充、修正或環境干擾。更廣的語音優先手機互動，可以延伸到語音優先 AI 手機：第三代手機互動為什麼不是取消螢幕；本篇聚焦在全雙工語音如何接到可信任的 Android 手機執行架構。

全雙工語音 AI 如何處理停頓、噪音與打斷

傳統半雙工語音互動比較像輪流講話：使用者說完，模型聽；模型說完，使用者再補充。這種模式適合簡短指令，但手機任務常常在中途變更。你可能一邊聽代理朗讀簡訊草稿，一邊說「等一下，把時間改成三點半」；也可能在代理準備開啟導航時補一句「改走高速公路」。全雙工語音 AI 的核心，就是讓模型在生成語音時仍能處理使用者新輸入。

這背後有幾個技術問題。第一是端點判斷：模型要知道使用者是真的說完，還是只是停頓。第二是打斷處理：使用者插話時，模型要能停下、改寫或重新規劃。第三是干擾抑制：旁人的話、背景音、車內噪音、音樂或另一個裝置的聲音，都可能讓模型誤判。Seed 在 Seeduplex 介紹中把干擾抑制、端點判斷與打斷處理列為改善重點；這些成效屬於 Seed 的官方發布描述，實際產品體驗仍要看使用場景、裝置收音與系統整合。

研究上，問題也不是只有「有沒有全雙工」這麼簡單。How Should LLMs Listen While Speaking?討論了 LLM 在說話時如何接收使用者音訊，包含通道融合與 cross-attention routing 等設計取捨。簡單說，系統要決定哪些新聲音應該進入當前回應，哪些只是背景，哪些應該觸發重規劃。手機 Agent 對低延遲尤其敏感，更多推理速度與手機代理的關係可看1000 TPS 大模型與手機 AI Agent：MiMo UltraSpeed 代表什麼。

因此，全雙工讓對話更順，但也把錯誤路徑變得更即時。模型更容易被打斷，也更需要知道何時該停止說話、何時該要求確認、何時該把任務交給執行層。這正是手機 Agent 架構要把對話和執行分開設計的原因。

為什麼對話層和 Android 執行層要分開

我們在 FoneClaw 的工程設計裡，把手機 Agent 分成兩個平面：互動平面和執行平面。互動平面負責聽、說、理解語氣、處理打斷、補充上下文；執行平面負責 Android 權限、工具、任務狀態、核准、結果驗證與復原。全雙工語音 AI 讓互動平面更自然，但它本身不會自動取得 Android 權限，也不會替每個手機動作建立安全合約。

舉例來說，使用者說「幫我回覆他，我晚十分鐘到」，全雙工模型可以很快理解這句話，也能在使用者補一句「語氣客氣一點」時即時改寫。接下來的手機動作卻需要執行平面處理：收件人是否唯一、訊息本文是否完整、預設簡訊 App 是否可用、送出控制是否穩定、是否涉及雙卡選擇、是否要停在草稿給使用者確認。這些都不是語音模型的「對話流暢度」能獨自解決的問題。

把兩個平面混在一起，最容易產生兩種失敗。第一，模型把口頭同意理解成執行授權，導致使用者還沒看到目標與結果就產生外部效果。第二，模型在 Android 權限不足或畫面不穩時繼續嘗試，讓任務狀態變得模糊。FoneClaw 的做法，是讓互動平面把意圖交給受治理執行層，再由執行層依工具合約與 Android 權限完成支援動作。完整的手機執行基礎，可延伸閱讀手機 AI Agent 控制是什麼？Android 手機自動化代理的能力、邊界與安全檢查。

從語音意圖到可驗證結果的七階段合約

實用的 Android 手機 Agent 架構，需要把一句話拆成可管理的任務合約。我們在 FoneClaw 內部思考這類流程時，會用七個階段檢查：擷取、釐清、規劃、核准、執行、驗證、復原。全雙工語音 AI 可以改善第一階段和第二階段，讓使用者更自然地補充、打斷、修正；但後面五個階段決定任務是否真的可信。

1. 擷取：由語音、文字、目前畫面或使用者主動提供的脈絡取得意圖。全雙工模型在這裡要處理停頓、噪音和打斷。
2. 釐清：確認收件人、時間、地點、App、資料範圍和目標結果。模糊時先問清楚，而不是直接猜。
3. 規劃：把任務拆成 Android 可支援動作，例如調整勿擾模式、準備 SMS 草稿、開啟導航、準備撥號或進入設定頁。
4. 核准：把會產生外部效果的動作停在使用者可理解的位置，顯示目標、理由、資料與結果。
5. 執行：由受治理工具依 Android 權限與工具合約完成支援步驟。
6. 驗證：確認狀態是否真的改變、草稿是否可見、導航是否交給指定 App、設定是否到達預期。
7. 復原：遇到權限缺少、畫面變化、工具失敗或使用者改變主意時，回到可處理狀態。

這七階段裡，狀態和核准必須一路保存。使用者打斷語音、切到另一個 App、回到懸浮助手或處理權限，都應該回到同一個任務脈絡。若你想深入看手機核准介面如何呈現理由、信心與接管設計，AI Agent 操作核准介面指南：建議、信心分級、理由與手機接管設計會補上更完整的 UX 層。

我們正在打造的 FoneClaw Android 執行層

FoneClaw 目前採用的是使用者觸發式語音與畫面脈絡。語音輸入由使用者開始；目前畫面脈絡也由使用者主動附加，而不是讓手機長時間持續聽或看。這個設計來自我們做手機 Agent 的經驗：越靠近個人裝置，越要讓入口、資料範圍和外部效果都具體可見。SeedRealtime 和 Seeduplex 在本文作為全雙工語音互動的重要參考；FoneClaw 的現行產品則以公開的 Android 執行層能力為準。

截至目前可取得的最新產品資訊，FoneClaw 提供懸浮助手、同手機任務延續、權限復原與快速動作。這些能力讓對話產生的意圖能留在可接回的任務流程中。例如使用者在訊息 App、行事曆或地圖頁面看到資訊後，可以叫出懸浮助手，主動附加目前畫面，要求 FoneClaw 準備下一步。若過程中需要授權，權限復原會把使用者帶回可處理位置，而不是讓任務消失。

目前 FoneClaw 的受治理 Android 動作，包含勿擾模式、可見訊息流程、撥號準備、導航交給選定地圖 App，以及部分設定工作。這些例子很適合說明執行層的價值：對話模型產生意圖，FoneClaw 負責把意圖轉成可核准、可驗證、可復原的手機結果。讀者可以從FoneClaw 功能介紹查看目前能力，並從FoneClaw 下載頁取得現行版本。

若你想理解目前畫面脈絡如何被使用者主動附加、如何避開覆蓋層干擾，以及懸浮助手如何承接核准與復原，Android 懸浮 AI 助手與目前畫面：提問、核准、執行與復原指南會提供更直接的操作視角。

需要執行保護的全雙工手機 Agent 情境

第一個情境是會議前的勿擾模式。使用者說「幫我開勿擾到會議結束」，全雙工模型可以邊聽邊處理補充，例如「只允許家人來電」。執行層則要確認 Android 權限、設定目標、例外規則與完成狀態。真正可靠的結果，不是模型說「好的」，而是手機狀態被驗證並可回顧。

第二個情境是語音簡訊。使用者開始口述：「傳給 Alex，我會晚十分鐘到。」代理朗讀草稿時，使用者打斷：「改成十五分鐘，語氣客氣一點。」全雙工語音 AI 可以讓這個修正非常自然；FoneClaw 這類執行層則要檢查收件人、完整本文、預設 App、送出控制、雙卡或附件狀態。敏感外部效果在可見核准後發生，讓語音便利和傳送責任對齊。

第三個情境是通話與導航。使用者說「幫我打給餐廳，然後導航過去」，中途又補一句「先不要打，改成查路線」。全雙工互動可以快速接受修改；執行層要知道目前任務已從撥號改成導航，並把路線交給選定地圖 App。這種多步驟任務需要狀態，而不是單次語音指令。

第四個情境是被打斷的設定任務。使用者正在要求代理調整某個 Android 設定，突然改口或切到別的 App。FoneClaw 的任務延續與權限復原，目的就是把這種中斷變成可接續流程。更多 Android 手機 Agent 執行範例，可回到手機 AI Agent 控制是什麼？Android 手機自動化代理的能力、邊界與安全檢查。

隱私、電量、聲音與視覺限制，以及下一步

全雙工語音 AI 放到手機上，第一個約束是隱私。麥克風何時啟動、哪些音訊進入模型、使用者如何停止、任務何時需要核准，都要有明確設計。FoneClaw 目前採用使用者觸發式語音輸入和使用者主動附加的目前畫面脈絡，讓入口和資料範圍回到具體任務。未來若更強的即時模型進入手機 Agent，這個原則仍會保留：自然互動服務使用者，外部效果回到可見核准。

第二個約束是電量與延遲。全雙工模型需要更持續的音訊處理、打斷偵測、噪音判斷和即時回應；手機上還要同時保留畫面、網路、通知與工具執行。低延遲能讓語音互動更自然，但電量、發熱與連線品質會決定真實體驗。這也是我們把執行層做成明確任務流程的原因：模型速度越快，越需要穩定的停止、核准與復原。

第三個約束是視覺 grounding。Seed 在 Seeduplex 發布中把 visual input 和 proactive interaction 列為展望方向；這代表已發布重點是語音全雙工，而不是完整的連續視覺感知。研究上，VideoFDB full-duplex audio-visual benchmark也顯示串流音訊與視覺 grounding 仍是獨立挑戰，很多系統在非明確視覺問題上仍未充分利用視覺訊號。對手機 Agent 來說，真正可靠的 listen-see-speak-act 需要視覺脈絡、使用者授權、工具執行和結果驗證一起設計。

我們的 builder checklist 很簡單：先讓語音入口可打斷，再把意圖交給任務狀態；先要求資料範圍，再調用工具；先顯示核准，再產生外部效果；先驗證結果，再回報完成；遇到失敗時，回到可處理位置。這是 FoneClaw 正在打造的方向，也是全雙工語音 AI 真正進入 Android 手機 Agent 架構時需要補上的執行層。