代理介面的未來

簡短回答#

介面未來是分層的，不是贏者全拿。

MCP 在外部軟體能暴露結構化能力時勝出。App protocols 在編排器需要直接驅動代理執行環境時勝出。Native interaction models 在人機協作層勝出——那裡輪流、VAD 與對話管理是錯誤的抽象。Computer use 則作為通用相容層，服務仍只為人類打造的軟體。

乾淨的堆疊：

層級	未來介面	連接什麼	為何勝出
人機協作	Interaction Models / Full-Duplex Interaction	人類感官、語音、螢幕、時序 → 模型	移除回合邊界，讓互動性隨模型智慧擴展
外部軟體	MCP / APIs	模型 → 業務系統、檔案、SaaS、垂直工具	結構化、便宜、快速、可跨介面重用
代理執行編排	App Server-style protocols	編排器 → 代理工作階段、工具、回合、憑證	穩定的生命週期、延續、可觀測性、憑證中介
舊版軟體	Computer use	模型 → 人類 GUI	沒有結構化介面時的通用兜底
長期終點	Agent-Native Infrastructure	代理 → 透過可讀感測器與致動器的世界	系統先為代理描述，而非事後透過人類文件與 GUI 硬接

錯誤在於問哪一個會取代其他。它們處於不同邊界。

主要分界：互動 vs 行動#

有兩種不同的「介面」被混在一起。

互動介面管人與模型如何協作。Interaction Models 認為今天的聊天表面有缺陷，因為模型在單一執行緒中體驗現實：使用者行動時模型等待，模型回應時感知被凍結。Full-Duplex Interaction 是提議的替代：在音訊、影像與文字上同時感知與回應。

行動介面管模型如何改變外部系統。MCP and Computer Use 談的是這一層：Salesforce、Google Drive、Gmail、Slack、Figma、行事曆、利基產業系統，或桌面 GUI。問題不是「人如何與模型協作？」而是「模型能讀寫什麼？」

原生互動模型不會取代 MCP。它們讓人類迴圈更豐富，同時模型仍可呼叫工具、搜尋、瀏覽、生成 UI，或委派給背景模型。MCP 也不會取代互動模型。它在人與模型決定要做什麼之後，給模型結構化的行動表面。

MCP 是預設的行動介面#

MCP 的持久價值很簡單：它讓外部系統對代理可讀（agent-legible）。伺服器暴露型別化能力；Claude Code、Cowork、Claude AI 或第三方代理等客戶端表面消費它們。連接器邏輯寫一次，跨表面重用。

這很重要，因為代理未來不是單一 app。Cowork 使用 Google Calendar、Slack、Gmail、Google Drive、Figma、Salesforce 與其他知識工作系統。Cat Wu 的投影片工作流程使用 Figma MCP、Slack MCP 與 Drive MCP，因為隔夜工作負擔不起每個動作都走截圖點擊迴圈。The Founder's Playbook 把同一模式延伸到客戶外展、排程、回饋 intake、錯誤分類、CRM 維護與垂直利基系統。

當目標系統能暴露下列項目時，MCP 勝出：

型別化操作
範圍化憑證
結構化結果
可重用連接器
比 GUI 驅動更低的延遲執行
足夠的領域特異性以形成護城河

這也是 MCP 不會像提示腳手架那樣縮小的原因。工具選擇周圍的 harness 可能縮小；連接器表面會擴大。更好的模型能更聰明地選工具，但仍需要工具。

Computer use 是相容層，不是理想解#

Computer use 的權衡相反。它慢、耗 token、且通用。模型讀螢幕，透過面向人類的 GUI 驅動滑鼠/鍵盤。其優勢是覆蓋率：沒有 API、沒有 MCP 伺服器、沒有函式庫、也沒有其他對代理可讀介面時仍可用。

所以 computer use 不是乾淨的未來。它是跨過人類打造軟體長尾的橋。

這座橋仍重要。Cowork 正是長尾很重要的產品類型：知識工作者活在往往缺乏乾淨程式化介面的工具裡。MCP and Computer Use 中 Boris Cherny 的論點是：對模型而言，MCP、API 與 computer use 都是 token 層級的行動基底。但對系統設計者，營運差異仍重要：

屬性	MCP / API	Computer use
延遲	低	高
成本	較低的 token/動作成本	截圖/動作迴圈燒 token
覆蓋	僅已整合系統	幾乎任何 GUI
可靠性	結構化合約	視覺狀態與 UI 漂移
最佳用途	高頻、高價值工作流程	舊版、利基、缺介面工作流程

實務規則：在工作流程重複、量大或業務關鍵時建 MCP。在軟體尚未 agent-native 時用 computer use。

App protocol 不是 MCP#

Codex App Server Protocol 看起來像 MCP，因為它也暴露工具呼叫，但處於不同邊界。MCP 連接模型表面與外部系統。App Server protocol 連接外部編排器與 Codex 代理工作階段。

其核心工作是生命週期控制：

啟動無頭代理工作階段
初始化執行緒
開始回合
在延續回合中重用 thread_id
串流回合事件
強制逾時與停滯偵測
處理核准與需要使用者輸入的事件
注入動態工具，同時把憑證留在子代理容器外

最後一點是與 MCP 的架構平行。Symphony 可向代理廣告 linear_graphql 工具，而編排器保留 Linear token。但這屬於 app protocol 而非通用 MCP 伺服器的原因，是編排器在治理代理執行環境：cwd、沙箱、核准政策、回合生命週期、重試與終止。

因此分界是：

需求	介面
讓代理使用 Salesforce/Gmail/Figma/利基 SaaS	MCP 或 API 連接器
讓 daemon 以程式化方式驅動 Codex 工作階段	App Server-style protocol
讓子代理存取帶憑證的 tracker 而不暴露 token	透過編排器的動態工具呼叫
讓代理在舊桌面軟體上點來點去	Computer use

未來很可能有多種 app protocol，因為執行環境不同：程式碼代理、知識工作代理、本機桌面代理、行動代理與團隊 daemon 需要 MCP 不提供的生命週期語意。

原生互動模型吸收面向人類的 harness#

Interaction Models 是涵蓋頁面中最強的主張。它認為互動性應成為模型本身的一部分。VAD、回合偵測、對話管理器與單執行緒聊天，是圍繞更聰明核心的手工 harness。這違反該頁援引的 bitter lesson 模式：較不聰明的腳手架會被通用能力超越。

原生互動模型的未來是：

連續的音訊/影像/文字輸入
約 200ms 尺度的交錯 micro-turn
沒有人為回合邊界
主動插話
對視覺線索的反應
同時說話
具時間感知的行為
並行的工具呼叫、搜尋、瀏覽與生成 UI
把較深工作委派給背景模型

這不是「更好的聊天」。它改變協作意味著什麼。Full-Duplex Interaction 讓模型在人類仍在行動時就「在場」。模型可在使用者說錯時打斷、在螢幕變化時反應、邊聽邊譯，或在正確時機把工具結果織回語音。

這解決的是與 MCP 不同的問題。MCP 讓世界更容易被模型行動；原生互動模型讓模型更容易與人類協作。

Agent-native infrastructure 是終點#

Agent-Native Infrastructure 點名長期方向：數位世界仍為人類而建，必須為代理重寫。文件應回答「我要複製貼上什麼給我的代理？」系統應暴露感測器與致動器。資料結構應對 LLM 可讀。MenuGen 部署摩擦測試是實務檢驗：代理應能在無需人類點擊 Vercel、DNS 與服務設定的情況下建置與部署。

在那個世界裡：

MCP 是服務變得對代理可讀的一種方式。
App protocol 讓代理執行環境可被編排。
Computer use 是仍只面向人類的服務的轉譯層。
原生互動模型讓人類留在迴圈內，而不被困在回合制聊天裡。
一旦代理代表人與組織，代理對代理協議就變得必要。

這才是真正的「介面未來」：不是單一介面，而是從機器工作中移除人類形狀的摩擦，同時為人類判斷增加更豐富的通道。

Cowork 是當前的實證#

Cowork 是最好的具體例子，因為它橫跨所有邊界。

它是非程式碼代理產品：簡報、收件匣分類、上線文件、客戶檔案、會議準備。它依賴行動介面，因為工作活在 Gmail、Slack、Google Calendar、Drive、Salesforce、Gong、Figma 與內部文件中。它對高價值整合用 MCP，而沒有 MCP 的軟體則以 computer use 兜底。

但 Cowork 也說明行動介面不夠。非程式碼產出的機械驗證比程式碼弱。簡報可以很精緻卻在策略上錯誤。收件匣分類可以很流暢卻在問責上失手。這把介面問題推回人類迴圈：審閱表面、升級閾值，以及最終比批次提示後交付成品更豐富的互動。

因此 Cowork 指向分層未來：

MCP 用於重複的紀錄系統。
Computer use 用於缺失的連接器。
Skills/memory/context 用於重複工作流程。
人類審閱，因為非程式碼工作缺乏編譯器式驗證。
最終以原生互動模型做即時引導，而非隔夜批次後審閱。

決策規則#

使用與邊界相符的介面：

若問題是……	使用……
「模型需要反覆使用這個 SaaS 或內部系統」	MCP / 結構化 API
「模型需要操作沒有對代理可讀介面的軟體」	Computer use
「daemon 需要執行、恢復、觀察與治理代理工作階段」	App Server-style runtime protocol
「人與模型需要持續協作」	原生互動模型 / full-duplex 表面
「系統從頭為代理重新設計」	Agent-native 感測器、致動器與 copy-paste-to-agent 文件
「代理需要互相代表人或組織」	未來的代理對代理協議層；現有頁面只點出需求，尚未定案設計

持久的工程工作是避免混淆這些層。不要為值得 MCP 的工作流程建 GUI 點擊機器人。不要假裝 MCP 解決輪流。不要把 app-server 執行協議當業務系統整合層。不要讓原生互動模型負責憑證邊界與外部合約。

結論#

未來的介面堆疊是：

原生互動模型 —— 人機協作。
MCP / APIs —— 在外部系統中的結構化行動。
App protocols —— 編排代理執行環境。
Computer use —— 舊版 GUI 相容。
Agent-native infrastructure —— 長期重新設計目標。

MCP 是預設的行動基底。Computer use 是兜底。App protocol 是代理工作階段的控制邊界。原生互動模型是面向人類、取代回合制聊天的方案。Agent-native infrastructure 是軟體停止假裝主要操作者永遠是人類之後會發生的事。