MCP 與電腦使用

資料來源#

• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts
• The Founder's Playbook: Building an AI-Native Startup
• Zero Trust for AI Agents

摘要#

兩種將模型連接至外部軟體的互補機制，皆由 Anthropic 建立，並且都是 Claude Code／Cowork／Chat 產品介面中不可或缺的基礎。MCP（Model Context Protocol，模型上下文協定）提供結構化、程式化的存取——「你在 Claude AI 中使用的相同連接器」可以接上 Salesforce、Google Docs、Google Calendar、Slack、Figma、Gmail，以及越來越多的利基產業系統。電腦使用則是沒有 MCP 時軟體的通用方案：模型直接驅動 GUI（滑鼠、鍵盤、螢幕），速度較慢，但在 Opus 4.7 上已越來越有能力。Boris Cherny 的說法是：「對模型而言，一切都只是 tokens」——MCP／API／電腦使用是同一能力的可互換基礎。

MCP 是什麼#

由 Anthropic Labs 於 2024 年底建立，與 Claude Code 和桌面應用程式一同推出，來自 Boris 的創始團隊。這是一種採用伺服器—客戶端架構的結構化工具呼叫協定：

• 伺服器——與外部系統（Salesforce、Slack、Gmail、內部 CRM、利基產業 SaaS）並行執行；以具型別的函式呼叫形式公開可用工具。
• 客戶端——消費這些工具的 Claude 介面（Claude Code、Cowork、Claude AI、第三方代理）。
• 到處都是相同的連接器。「你在 Claude AI 中擁有的相同 MCP 連接器，可以像接上 Salesforce 一樣接上 Google Docs、Google Calendar。Cowork 可以使用它，Claude CLI 可以使用它，Claude Code 到處都可以使用它。」——Boris Cherny

其結構特性是：每個系統只需撰寫一次連接器邏輯，就能由每個 Claude 介面使用。這正是讓 Cowork 能橫跨現有知識工作工具（Salesforce、Docs、Drive、Slack 等）運作的原因，而 Anthropic 不必為每項工具個別建立整合。

電腦使用是什麼#

當沒有 MCP 時，作為備援方案的通用 GUI 驅動。模型查看螢幕截圖，決定要點擊、輸入或捲動什麼，再透過無障礙／自動化 API 執行。它可以操作「你電腦上幾乎任何一套軟體」（Boris Cherny）。

截至 Opus 4.7，其特性如下：

• 品質——「相當不錯……現在做得相當好，尤其是 4.7」（Boris）。Anthropic「在電腦操作方面確實領先不少」。
• 延遲——「非常慢」。對相同任務而言，比 MCP 消耗更多 tokens，因為每次動作都需要一次螢幕截圖往返。
• 涵蓋範圍——通用。當目標軟體沒有 API、沒有 MCP、沒有 Python 函式庫，唯一介面是面向人類的 UI 時，就由電腦使用負責運作。

Cowork 是目前電腦使用最重要的部署介面：許多知識工作應用程式都缺乏程式化介面。

「其實不重要」論點#

Boris 對 MCP、API 與電腦使用之間問題的說法：

「這些事情其實沒有那麼重要。可以是 MCP、API，或某種程式化存取，因為模型不在乎。對模型而言，一切都只是 tokens。」

基礎是可互換的——工作就是「以模型能消費的形式，將能力公開給模型」。MCP 針對結構化／快速／低成本進行最佳化；電腦使用則針對通用／備援／緩慢進行最佳化。兩者最後都可化約為 token 層級的工具呼叫。

這與苦澀教訓相連：隨著模型進步，「使用 MCP」和「使用電腦使用」之間的界線，應該由模型決定，而不是由人類設計的 harness 決定。Boris 對未來幾年的預測：

• 「模型將會負責所有程式碼。它將會啟動代理。它將會建立環境。」——其中當然也包括選擇呼叫工具時合適的基礎。
• 電腦使用被特別點名為「將會大幅變好」的產品領域。

實際的跨介面使用#

介面	MCP 範例	電腦使用範例
Claude Code（CLI）	GitHub、檔案系統、Slack	罕見——工程工具通常都有 CLI／API
Cowork	Salesforce、Google Drive/Docs/Calendar、Gmail、Slack、Figma	沒有 MCP 的軟體；尤其是知識工作應用程式
Claude AI（聊天）	相同的連接器集合	可使用電腦使用
行動版／網頁版	相同的 MCP 基礎設施	瀏覽器端，搭配螢幕分享權限

Cat Wu 的每晚簡報工作流程（Cowork）明確使用 MCP——Figma MCP、Slack MCP、Drive MCP——而不是電腦使用，因為對一個希望在早晨前完成的工作流程來說，延遲成本無法接受。

在創辦人手冊中（AI-Native Startup Lifecycle）#

這份手冊將 MCP 視為每個階段的主要整合機制：

• 構想階段——Cowork 使用 Gmail 和 Google Calendar MCP 管理外展對話串、安排客戶訪談，以及執行第 7 天的後續跟進。
• MVP 階段——「構想階段管理探索流程的相同 MCP 整合，在此適用於」回饋會議排程、錯誤回報分類，以及迭代週期追蹤。
• 規模化階段——與競爭者聞所未聞的利基產業系統整合 MCP，被列為護城河的組成部分（例如，通用型醫療帳單 AI 會在 340B 藥品計畫申報上失效；垂直領域專家的 MCP 串接競爭者則不會）。

手冊中的兩個案例研究，具體呈現了 MCP 作為護城河的觀點：

• Kindora 提供 MCP 連接器，讓非營利組織能夠直接在 Claude 裡使用其潛在客戶開發工具——產品是透過 MCP 使用，而不只是「與」MCP 整合。
• Anthropic Skills 被提及為反覆工作流程的編碼介面（「我如何稽核商業租約」、「我如何分類病患初診表」）——Skills + MCP + 記憶共同構成複利資料護城河概念所描述的專有基礎。

手冊本身較少強調電腦使用，但其中將 Cowork 稱為橫跨「每個階段」的營運層；而 Cowork 正是電腦使用填補 MCP 缺口的地方。

與 harness 縮減的連結#

模型進步時的 Harness 縮減預測，隨著模型進步，提示鷹架、權限與驗證邏輯會向內遷移。MCP 和電腦使用是 harness 的相反面——它們是模型與世界之間的連接器。它們不會縮減，而會變得更廣泛（更多系統、更多介面）且更快速（每次動作的延遲更低）。縮減的是模型工具選擇決策周圍的 harness 邊界，而不是工具集本身。

注意：當模型更擅長判斷何時使用電腦使用、何時要求真正的 MCP 時，今日大量手動撰寫 MCP 伺服器的工作，可能會變成「要求模型建立你需要的連接器」。這仍不是 harness；更像是由模型撰寫的基礎設施。

與 Agentic Misalignment (AM) 和問責的連結#

MCP 和電腦使用正是將 LLM 轉化為能採取後果性行動的代理的基礎。兩者都將模型的觸及範圍延伸至：

• 客戶的 CRM
• 客戶的電子郵件
• 客戶的行事曆
• 最終，客戶的完整桌面

Human-AI Accountability Redesign 的「決策權」子前沿負責治理這一點——代理可以透過 MCP／電腦使用自主執行什麼，哪些事情需要明確的人類核准。Claude Code Auto Mode 是一個具體實例：分類器會自動核准安全的 MCP／工具呼叫，阻擋有風險的呼叫。

MCP 作為安全面#

Zero Trust for AI Agents 將 MCP 視為代理部署中風險最高的工具面之一，並提供先前來源缺少的具體威脅資料：

• 工具中毒——攻擊者入侵 MCP 工具描述、結構描述或中繼資料，讓代理根據偽造的能力呼叫工具；惡意工具可以將指令藏在中繼資料中，在使用者不知情的情況下外洩資料。
• 拉回攻擊——合法工具被靜默替換為惡意版本。第一個有文件記錄的野外惡意 MCP 伺服器，冒充合法電子郵件服務並秘密複製所有寄出的郵件——這具體實現了「攻擊面隨採用率擴大」的疑慮。
• 工具鏈結——將合法工具（內部 CRM + 外部電子郵件）組合成有害序列，而任何單一工具都不會單獨啟用該序列；由於每次呼叫都透過有效憑證下的受信任二進位檔執行，以主機為中心的監控看不到惡意軟體。這正是最小代理權（限制每個工具的能力）和參數驗證要控制的問題。

框架提出的處方是：在驗證並自行簽署程式碼後，於不可變平台上自行執行／託管 MCP 伺服器（代理供應鏈風險）；使用與呼叫代理身分綁定的短期 token驗證工具存取，絕不使用靜態 API 金鑰（代理身分與驗證）；並將高風險呼叫置於升級核准機制之後。Claude Code 對 MCP 連線使用具自動重新整理功能的 OAuth 2.0，以及工作階段範圍的「ask」權限，被列為參考實作。

MCP Tool Poisoning（針對此攻擊類別的專門概念頁）如今以經驗資料進一步明確化了威脅模型。ShareLock（Liu et al.，arXiv 2606.27027）證明，掃描每個 MCP 工具描述——上文及下方開放問題所暗示的直覺式緩解措施——不僅不完整，更是可證明不足：它使用 Shamir 閾值秘密分享，將惡意指令拆分成看似良性的 tool_id／checksum 分享片段，分散在多個工具之間，因此每個描述在資訊理論上都是乾淨的（少於 t 個分享片段時無法揭露任何資訊）；接著，伺服器更新中的拉回攻擊植入觸發器，在執行階段重組 payload——ASR 超過 90%，但每個 LLM 安全分類器和熵偵測器都將工具評為 Safe。偵測必須跨工具且具備狀態性；僅逐一審核伺服器無法解除風險。

現實世界的事件則從另一面封鎖了另一種緩解措施。Agentjacking（Tenet Security，2026 年 6 月，case-study；亦見於 MCP Tool Poisoning）透過完全合法的 MCP 伺服器——Sentry 自身的伺服器——劫持程式設計代理：攻擊者注入偽造錯誤事件（透過公開、刻意設計為只能寫入的 Sentry DSN），伺服器忠實地將其作為受信任診斷轉送給代理；代理讀取偽造的 ## Resolution，並執行攻擊者的 npx 指令。本節的教訓很精確：審核或自行簽署 MCP 伺服器在此並無幫助，因為伺服器從未遭到入侵。 ShareLock 打破了逐一掃描工具描述；Agentjacking 則搭乘合法伺服器的資料進入。兩者共同顯示，MCP 攻擊面有兩條正交分支——遭污染的工具中繼資料，以及透過合法伺服器傳遞的惡意資料——而「自行執行／驗證自己的伺服器」對任何一條都無法完全封閉。（供應商利益衝突：Tenet 販售代理執行階段安全產品，因此其規模宣稱在專頁中以內文歸因；機制本身才是持久的部分。）

工具呼叫點的標準化防禦。 這些攻擊所推動的行動層授權，如今正取得互通性標準。OpenID Foundation 的 AuthZEN Working Group 已核准 COAZ（AuthZEN Profile for MCP Tool Authorization，AuthZEN 的 MCP 工具授權設定檔；Working Group Draft，2026-06-15），將 MCP 工具呼叫映射到 AuthZEN 的 Subject-Action-Resource-Context 決策模型，使 API／AI gateway 或下游 PDP 能根據政策授權每一次工具呼叫——讓 MCP 工具公開呼叫它所需的授權檢查。這是每次呼叫授權閘門（ScopeGate、aiAuthZ）的標準機構版本——見 AIMS。範圍注意事項：COAZ 授權的是呼叫，因此能限制超出政策的重組或注入行動；但如同每個價值閘門，它無法捕捉仍在允許政策內的受污染呼叫（同一種「合法變數資料遭破壞」的殘餘風險，也無法處理能力範圍內、但套件獲准時可執行 npx 的 Agentjacking 案例）。這是提案中的標準，practitioner-opinion——權重低於實證的每次呼叫授權工作；完整討論見 AIMS。

相關連結#

• Claude Code／Cowork／Anthropic——介面與供應商
• Zero Trust for AI Agents——將 MCP 視為最高風險工具面之一；提供工具中毒／拉回攻擊／工具鏈結的威脅模型
• MCP Tool Poisoning——TPA 攻擊類別的專門概念；ShareLock 的閾值秘密分享變體證明，逐一掃描工具描述在資訊理論上是盲目的；其 Agentjacking 案例研究（合法的 Sentry MCP 伺服器轉送攻擊者注入的資料）則證明審核／自行簽署伺服器同樣盲目——兩者從相反方向強化了本頁的 MCP 安全開放問題
• Agent Supply Chain Risk——MCP 伺服器是明確的工具供應鏈向量；自行執行伺服器 + 自行簽署是緩解措施；ShareLock 的重組觸發器是透過伺服器更新植入的拉回攻擊
• Agent Identity and Authentication——短期、綁定身分的 token 取代靜態金鑰，用於 MCP／工具驗證
• Agentic Prompt Injection——MCP 連接的瀏覽／電子郵件／文件工具是間接注入的入口
• Boris Cherny——共同建立 MCP；提出「其實不重要」論點
• Cat Wu——闡述每日 MCP 使用情況與 Cowork 整合故事
• Harness Shrinkage as Models Improve——什麼不會縮減；互補性基礎設施
• The Bitter Lesson——由模型決定基礎，是苦澀教訓的終點
• AI-Native Startup Lifecycle——MCP 橫跨創辦人的四個階段
• Compounding Data Moat——Skills + MCP + memory 作為護城河基礎
• Claude Code Auto Mode——工具使用的決策權閘控
• Claude Code Best Practices——以 MCP 為基礎的擴充，是「擴展模式」的一種機制
• Agentic Misalignment (AM)——MCP／電腦使用作為行動面；風險隨觸及範圍增加
• Human-AI Accountability Redesign——MCP／電腦使用部署的治理層
• Agent Harness Engineering——MCP 作為連接器與 harness 作為鷹架之間的區別
• Hermes Agent——使用 MCP 的第三方代理產品（在 Claude Code Best Practices 的跨工具能力表中提及）
• Symphony——另一種編排方式，MCP 式工具公開改由 codex-app-server-protocol 處理
• Agentic Work Systematization——外掛將 MCP／連接器整合與 skills 一同打包；連接器是系統化中工具觸及的一半（接觸真實工具的迴圈，而不只是檔案系統）
• Agent-Native Infrastructure——MCP 讓服務成為代理可讀的（結構化）；沒有 MCP 時，電腦使用是驅動 GUI 的備援——兩者共同構成 Karpathy 所謂「先為代理描述」的世界所需基礎
• Agent Identity Management System (AIMS)——AIMS 將 MCP 工具視為 OAuth 授權的資源面，並將其人機協作模型與 MCP 的使用者徵詢模式對齊——但堅持本地 MCP 核准不是授權，必須映射到可驗證的授權伺服器授予；現在也承載 OpenID AuthZEN COAZ 草案（授權每次 MCP 工具呼叫的提議標準，MCP→SARC）以及 AARP（前置／核准的「尚未」步驟）
• Loop Engineering——連接器／外掛（MCP）是其五項原語之一：讓迴圈能在你的真實工具中採取行動（開啟 PR、更新工單、在頻道中發訊息），而不只是查看檔案系統

開放問題#

• MCP 生態系的成長速度與電腦使用的品質曲線：電腦使用要到什麼時候才會「夠好」，使建立 MCP 伺服器的邊際價值下降？Boris 暗示還要幾年，但沒有量化。
• 電腦使用是可持續的介面，還是過渡技術？如果大多數知識工作軟體在接下來 24 個月加入 MCP 支援，電腦使用的角色就會縮小到舊式／僅限桌面的系統。
• MCP 安全模型：隨著手冊建議獨立創辦人將 MCP 接上 Salesforce、Gmail、Calendar，攻擊面會隨採用率擴大。現在已由 Zero Trust for AI Agents 處理（工具中毒、拉回攻擊、第一個野外惡意 MCP 伺服器）——見上方「MCP 作為安全面」。尚存問題：既然 MCP 的吸引力在於零整合成本，獨立創辦人如何實際上執行／託管並自行簽署每一個 MCP 伺服器？**ShareLock 進一步銳化了問題：**自行託管的廉價替代方案——使用防護模型掃描工具描述——被閾值分割在資訊理論上擊敗，因此輕量級緩解措施並不成立，負擔又回到自行執行伺服器或下游行動層授權。**而 Agentjacking 顯示自行執行伺服器本身也不足夠：**當伺服器是轉送攻擊者注入資料（偽造 Sentry 錯誤）的合法可觀測性平台時，自行託管／審核伺服器什麼也抓不到——不受信任的輸入搭乘其資料進入，因此殘餘負擔完全落在下游資料／行動層（來源追蹤 + 頻外行動閘門），而不是伺服器衛生上。
• Cowork 的電腦使用防護機制與 Claude Code 的自動模式分類器相比如何？部署情境不同，風險特徵可能也不同。

推導#

• The Future of Agent Interfaces——將 MCP、電腦使用、應用程式協定、原生互動模型，以及代理原生基礎設施置於不同的介面邊界

資料來源#

• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next——Boris 關於 MCP／電腦使用的問答（Sequoia AI Ascent 2026）
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)——Cat 每日的 Cowork+MCP 工作流程
• The Founder's Playbook: Building an AI-Native Startup——MCP 橫跨構想／MVP／Launch／Scale，以及護城河框架
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts——OpenID Foundation，《…advances authorization for the agent era with new AuthZEN Working Group Drafts》，2026 年 6 月 15 日，practitioner-opinion。COAZ（AuthZEN Profile for MCP Tool Authorization——MCP 工具呼叫點上提議中的標準軌授權決策）；提議中的 Working Group Draft，權重低於實證的每次呼叫授權工作