Agent 介面的未來

簡短回答#

介面的未來會是分層架構，而不是只能擇一的勝者全拿。

MCP 適用於能提供結構化功能的外部軟體。應用程式協定適用於協調器需要直接驅動代理程式執行環境的情況。原生互動模型適用於人類協作層；在這一層，輪流發言、VAD 和對話管理都是不合適的抽象概念。對於仍只為人類打造的軟體，電腦操作則會以通用相容層的形式繼續存在。

清晰的分層如下：

層級	未來介面	連接對象	勝出的原因
人類協作	Interaction Models / Full-Duplex Interaction	人類的感官、語音、畫面、時間 -> 模型	移除輪次邊界，讓互動性隨模型智慧提升而擴展
外部軟體	MCP / APIs	模型 -> 業務系統、檔案、SaaS、垂直領域工具	結構化、成本低、速度快，且可在不同介面重複使用
代理程式執行環境協調	App Server-style protocols	協調器 -> 代理程式工作階段、工具、輪次、憑證	穩定的生命週期、延續能力、可觀測性、憑證中介
舊版軟體	電腦操作	模型 -> 人類 GUI	沒有結構化介面時的通用備援方案
長期終點	Agent-Native Infrastructure	代理程式透過易於理解的感測器與致動器 -> 世界	系統從一開始就以代理程式為對象描述，而不是事後透過人類文件和 GUI 改造

錯誤之處在於追問哪一種會取代其他方式。它們各自位於不同的界線上。

主要區別：互動與操作#

這裡混淆了兩種不同的「介面」。

互動介面決定人類與模型如何協作。Interaction Models 指出，現今的聊天介面有缺陷，因為模型只能在單一對話串中體驗現實：使用者行動時模型等待，接著模型回應時，感知又被凍結。Full-Duplex Interaction 提出替代方案：在音訊、影片和文字中，同時進行感知與回應。

操作介面決定模型如何變更外部系統。MCP and Computer Use 討論的正是這一層：Salesforce、Google Drive、Gmail、Slack、Figma、行事曆、利基產業系統，或桌面 GUI。問題不是「人類如何與模型協作？」，而是「模型能讀取和修改什麼？」

原生互動模型不會取代 MCP。它們讓人類互動循環更豐富，同時模型仍然可以呼叫工具、搜尋、瀏覽、產生 UI，或委派工作給背景模型。MCP 也不會取代互動模型。它在人類與模型決定要做什麼之後，提供結構化的操作介面。

MCP 是預設的操作介面#

MCP 的持久價值很簡單：它讓外部系統變得易於代理程式理解。伺服器提供具型別的功能；Claude Code、Cowork、Claude AI 等用戶端介面，或第三方代理程式都能使用這些功能。連接器邏輯只需撰寫一次，就能在不同介面重複使用。

這很重要，因為代理程式的未來不會只有一個應用程式。Cowork 會使用 Google Calendar、Slack、Gmail、Google Drive、Figma、Salesforce 及其他知識工作系統。Cat Wu 的簡報工作流程會使用 Figma MCP、Slack MCP 和 Drive MCP，因為隔夜工作無法承受每個操作都透過螢幕截圖與點擊循環完成。Founder's Playbook 則將同樣的模式延伸至客戶聯繫、排程、意見回饋收集、錯誤分類、CRM 資料維護，以及垂直領域的利基系統。

當目標系統能提供以下項目時，MCP 就具有優勢：

具型別的操作
有範圍限制的憑證
結構化結果
可重複使用的連接器
比 GUI 操作更低延遲的執行方式
足夠的領域專屬性，足以形成護城河

這也解釋了為什麼 MCP 不會像提示詞鷹架那樣縮減。工具選擇周邊的 harness 可能會縮小；連接器介面則會擴大。更好的模型能更聰明地選擇工具，但仍然需要工具。

電腦操作是相容層，而非理想方案#

電腦操作的取捨正好相反。它速度慢、耗用大量 token，而且通用性高。模型讀取畫面，再透過面向人類的 GUI 操作滑鼠與鍵盤。它的優勢在於涵蓋範圍：沒有 API、MCP 伺服器、函式庫或其他易於代理程式理解的介面時，它仍然能運作。

因此，電腦操作不是理想的未來形態，而是跨越大量人類打造軟體的橋梁。

這座橋仍然很重要。Cowork 正是長尾需求重要的產品類型：知識工作者使用的工具往往缺少乾淨的程式化介面。Boris Cherny 在 MCP and Computer Use 中指出，對模型而言，MCP、API 和電腦操作都是 token 層級的操作基底。但對系統設計者來說，操作層面的差異仍然重要：

特性	MCP / API	電腦操作
延遲	低	高
成本	token／操作成本較低	螢幕截圖／操作循環會消耗 token
涵蓋範圍	僅限已整合的系統	幾乎任何 GUI
可靠性	結構化契約	視覺狀態與 UI 漂移
最適用途	頻繁、高價值的工作流程	舊版、利基或缺少介面的工作流程

實務原則：若工作流程會重複執行、量大或攸關業務，就建置 MCP。若軟體尚未成為 agent-native，就使用電腦操作。

應用程式協定不是 MCP#

Codex App Server Protocol 看起來像 MCP，因為它提供工具呼叫，但它位於不同的界線。MCP 將模型介面連接至外部系統；App Server 協定則將外部協調器連接到 Codex 代理程式工作階段。

它的核心任務是控制生命週期：

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

最後一點在架構上與 MCP 相似。Symphony 可以向代理程式提供 linear_graphql 工具，同時由協調器保管 Linear token。但這應該屬於應用程式協定，而非通用 MCP 伺服器，原因在於協調器負責管理代理程式執行環境：cwd、沙箱、核准政策、輪次生命週期、重試和終止。

因此，區分如下：

需求	介面
讓代理程式使用 Salesforce/Gmail/Figma／利基 SaaS	MCP 或 API 連接器
讓背景服務以程式方式驅動 Codex 工作階段	App Server-style 協定
讓子代理程式使用具憑證的追蹤系統，又不暴露 token	透過協調器進行動態工具呼叫
讓代理程式在舊版桌面軟體中點選操作	電腦操作

未來可能會有許多應用程式協定，因為不同執行環境各有差異：程式碼代理程式、知識工作代理程式、本機桌面代理程式、行動代理程式和團隊背景服務，都需要 MCP 無意提供的生命週期語義。

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

Interaction Models 是這些文章中最有力的主張。它認為互動性應該成為模型本身的一部分。VAD、輪次偵測、對話管理器和單一執行緒聊天，都是圍繞更聰明核心手工打造的 harness。這違反了文章引用的苦澀教訓模式：能力較弱的鷹架終將被通用能力超越。

原生互動模型的未來會有：

持續的音訊／影片／文字輸入
以 200ms 為尺度交錯進行的微型輪次
沒有人為設定的輪次邊界
主動插話
對視覺線索做出反應
同時說話
感知時間的行為
並行呼叫工具、搜尋、瀏覽和產生 UI
委派深入工作給背景模型

這不只是「更好的聊天」，而是改變協作的意義。Full-Duplex Interaction 讓模型在人類仍在行動時就能參與。使用者說錯話時，模型可以打斷；畫面變化時，模型可以回應；模型可以一邊聆聽一邊翻譯，也可以在適當時機把工具結果融入語音。

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

Agent-native 基礎設施是終點#

Agent-Native Infrastructure 指出長期發展方向：數位世界仍是為人類打造，因此必須為代理程式重新設計。文件應該回答「我要複製貼上什麼給我的代理程式？」系統應該提供感測器和致動器。資料結構應該易於 LLM 理解。MenuGen 的部署摩擦測試是實務檢查：代理程式應該能自行建置和部署，不必由人類逐一點選 Vercel、DNS 和服務設定。

在這個世界裡：

MCP 是服務變得易於代理程式理解的一種方式。
應用程式協定讓代理程式執行環境可以被協調。
電腦操作是仍然只面向人類服務的轉譯層。
原生互動模型讓人類可以留在迴圈中，而不受限於輪流對話。
一旦代理程式開始代表個人和組織行事，代理程式對代理程式協定就會成為必要。

這才是真正的「介面未來」：不是只有一種介面，而是在減少機器工作中以人類為中心的阻力時，同時增加更豐富的人類判斷管道。

Cowork 是目前的實證#

Cowork 是最具體的例子，因為它跨越了所有這些界線。

它是一款非程式碼代理程式產品：簡報、收件匣分類、發布文件、客戶資料檔、會議準備。它依賴操作介面，因為工作內容位於 Gmail、Slack、Calendar、Drive、Salesforce、Gong、Figma 和內部文件中。它使用 MCP 進行結構化、高價值整合，並以電腦操作作為缺少 MCP 軟體的備援方案。

但 Cowork 也顯示，光有操作介面並不足夠。非程式碼產出的機械式驗證能力較弱。一份簡報可能看起來很精緻，策略卻仍然錯誤。收件匣分類可能表達流暢，卻仍然錯誤處理責任歸屬。這讓介面問題回到人類互動循環：審查介面、升級處理門檻，以及最終超越批次提示後交付成品的模式，採用更豐富的互動方式。

因此，Cowork 展現出分層的未來：

MCP 用於反覆使用的核心記錄系統。
電腦操作用於缺少連接器的情況。
Skills／記憶／脈絡用於重複發生的工作流程。
人類審查用於缺少類似編譯器驗證機制的非程式碼工作。
最終採用原生互動模型，即時引導工作，而非隔夜批次處理後再審查。

判斷原則#

依照界線選擇介面：

如果問題是……	使用……
「模型需要反覆使用這項 SaaS 或內部系統」	MCP／結構化 API
「模型需要操作沒有易於代理程式理解介面的軟體」	電腦操作
「背景服務需要執行、恢復、觀察和管理代理程式工作階段」	App Server-style 執行環境協定
「人類與模型需要持續協作」	原生互動模型／全雙工介面
「系統正從零開始為代理程式重新設計」	面向代理程式的感測器、致動器，以及可複製貼上給代理程式的文件
「代理程式需要代表個人或組織彼此互動」	未來的代理程式對代理程式協定層；目前的文章指出了需求，但設計尚未定案

持久的工程工作在於避免混淆這些層級。不要為值得採用 MCP 的工作流程打造 GUI 點擊機器人。不要假裝 MCP 解決了輪流發言問題。不要把應用程式伺服器執行環境協定當成業務系統整合層。不要讓原生互動模型負責憑證界線和外部契約。

摘要#

未來的介面堆疊如下：

原生互動模型用於人類協作。
MCP / APIs用於外部系統中的結構化操作。
應用程式協定用於協調代理程式執行環境。
電腦操作用於舊版 GUI 相容性。
Agent-native 基礎設施是長期重新設計的目標。

MCP 是預設的操作基底；電腦操作是備援方案；應用程式協定是代理程式工作階段的控制界線；原生互動模型則是輪流對話的面向人類替代方案。當軟體不再假設主要操作者必定是人類時，就會形成 Agent-native 基礎設施。