你有没有想过，为什么我们和 AI 聊了这么久，它还是只能"说"，不能"做"？
刚刚，Anthropic 发布了 Claude Cowork，这个产品让我眼前一亮。它不是又一个聊天机器人，而是一个真正能帮你干活的数字同事。
今天我们来拆解一下 Cowork 背后的底层架构：它如何把“会说的模型”变成“能做的系统”。
如果你更关心“怎么用、怎么管、怎么试点”（任务模板、护栏、指标），我把落地部分单独写成了另一篇：Claude Cowork 落地指南：任务模板、安全护栏与成果物交付
太长不看版
- •范式转移：AI 从"Oracle 模式"（被动问答）进化到"Agentic 模式"（主动协作），思维与行动的断裂被弥合
- •虚拟化隔离：Cowork 在本机 VM 隔离环境中执行任务，对文件和网络访问进行严格控制；据第三方分析，macOS 版本疑似通过 Apple Virtualization Framework (AVF) 实现
- •MCP 协议：Model Context Protocol 是 AI 时代的"USB-C 接口"，通过 Resources/Tools/Prompts 三种原语，让 Agent 能标准化地连接各种数据源和工具
- •Agentic 循环：感知-规划-行动-反思的闭环设计，让 AI 能自主完成复杂任务并从错误中学习
- •共享架构：Cowork 与 Claude Code 共享同类 agentic 架构与工作流模式，GUI 更像是"控制面/可视化外壳"，把同类能力下沉给更多人
1. 范式转移：从 Oracle 模式到 Agentic 协作
在软件工程与人机交互的漫长演进史中，我们正处于一个决定性的转折点。
过去二十年，我们经历了从命令行接口（CLI）的精确控制到图形用户界面（GUI）的直观操作，再到近年来自然语言界面（LUI）的初步尝试。然而，直到 LLM 具备了工具使用（Tool Use）和长期规划能力之前，AI 在开发与办公场景中的角色主要停留在"Oracle（神谕）"模式：
用户提出问题，AI 给出一个基于概率预测的文本答案，但最终的决策、验证与执行仍需人类手动完成。
这种模式存在一个根本性的断裂——思维与行动的分离。
Claude Cowork 的出现，以及其底层的 Claude Code 架构，标志着我们正式跨越了这一断裂，进入了"Agentic（代理原生）"时代。在这个新时代，AI 不再仅仅是生成文本的引擎，而是被赋予了手脚（工具）、眼睛（视觉感知）和环境感知能力的数字实体。它不仅能"说"，更能"做"。
1.1 认知的外部化与执行的闭环
在传统的软件开发生命周期（SDLC）或复杂知识工作中，最大的瓶颈往往不在于"知道怎么做"，而在于繁琐的上下文切换和执行细节。
例如，重构一个遗留模块，开发者需要：理解代码 → 查找引用 → 修改文件 → 运行测试 → 修复错误 → 提交代码。这是一个典型的OODA 循环（观察-调整-决策-行动）。
Claude Cowork 的核心价值在于它接管了这个循环的中间环节。通过深度集成到用户的桌面环境，它将认知的外部化（Reasoning）与执行的闭环（Execution）统一在同一个上下文中。
这并非简单的自动化脚本，因为脚本无法处理非确定性错误，而 Cowork 依靠 LLM 的推理能力，能够在遇到错误（如编译失败、文件未找到）时进行自我反思与修正。
1.2 "计算机使用"（Computer Use）的民主化
虽然 Claude Code 为开发者提供了强大的终端交互能力，但它的 CLI 形态天然地将非技术用户拒之门外。
Cowork 的架构意义在于，它将这种通过代码和工具操作计算机的能力，封装进了一个用户友好的 GUI 外壳中。这不仅是界面的改变，更是底层能力的泛化。
从技术角度看，Cowork 实现了一种"人机协作"的理想形态：
- •人类负责高阶的意图定义和关键节点的审批（Human-in-the-Loop）
这种分工极大地释放了人类的认知带宽，让我们能够专注于最具创造性的部分。
2. 架构解剖学：Claude Cowork 的深层构造
要理解 Cowork 的强大与局限，我们必须剥开其 Electron 应用的表层，深入其操作系统层面的实现。
根据公开资料与技术分析，Cowork 并非简单的 API 包装器，而是一个运行在用户本地的复杂分布式系统缩影。
2.1 虚拟化与安全边界：VM 隔离的实现
在企业级环境或个人设备上运行 Agent，核心风险在于"不可控的副作用"。
一个拥有文件读写权限和 Shell 执行能力的 AI，如果缺乏严格的约束，可能因幻觉或提示注入（Prompt Injection）导致灾难性的后果（如误删关键文件、泄露敏感数据）。
根据 Anthropic 官方文档，Cowork 在本机 VM 隔离环境中执行任务，并对文件/网络访问进行控制。据第三方观察与逆向分析（特别是 Simon Willison 的深度拆解），macOS 版本疑似采用了一种硬核的隔离方案：基于 Apple Virtualization Framework (AVF) 的轻量级虚拟机。
2.1.1 架构拓扑图
为了直观展示 Cowork 的安全隔离机制，我们构建了如下架构拓扑图：
2.1.2 为什么可能选择 AVF + Linux VM？（第三方推断）
传统的沙盒技术（如 macOS 的 App Sandbox 或 Docker 容器）在隔离性和性能之间往往难以两全。Docker 在 macOS 上依赖 Linux VM，开销较大且文件系统性能一直是瓶颈。
而AVF 是 Apple Silicon 芯片原生的虚拟化框架，能够以极低的开销启动虚拟机。
据第三方观察与逆向分析（主要来自 Simon Willison 等技术人员的拆解），Cowork 在 macOS 上疑似采用以下实现方式：
计算隔离：Agent 的执行环境疑似运行在独立的 Linux 虚拟机内（配套定制 rootfs），而非直接在宿主用户空间。这样即便出现恶意指令（例如试图执行rm -rf /），其破坏范围也被限制在临时的 Guest 环境中，无法触及宿主系统。
环境一致性：这解决了"在我的机器上能运行"的经典难题。无论用户的宿主机安装了何种版本的 Python、Node.js 或系统库，Agent 在一个标准化的、预装了必要工具链（git, grep, curl 等）的 Linux 环境中运行。这极大地提高了任务执行的成功率和可预测性。
注意：以上为基于公开观察的技术推断，官方公开口径仅确认"在本机 VM 隔离环境中执行，并对文件/网络访问进行控制"，具体实现细节可能随版本更新而变化。
2.1.3 文件共享：穿越边界的受控访问
仅仅隔离是不够的，Cowork 的任务是处理用户的文件。这就涉及到了虚拟机与宿主机之间的高性能文件共享。
根据官方文档和第三方观察，Cowork 疑似采用以下文件共享机制：
按需挂载（On-Demand Mounting）：Cowork 并不拥有对宿主机文件系统的完全访问权限。在 UI 层面，用户必须显式地选择一个文件夹（Project Folder）授权给 Cowork。在底层，通过 VM 文件共享/挂载机制（可能包括 VirtioFS 等技术）将宿主机的特定目录映射到执行环境中。
权限投影：这种架构实现了物理级别的权限控制。Agent 无法读取未被授权挂载的目录（如~/.ssh或~/Documents），因为它所在的隔离环境中根本不存在这些路径。这比任何软件层面的权限检查（如系统提示词中的"请不要读取敏感文件"）都要安全可靠得多。
注意：具体的文件共享实现（如是否使用 VirtioFS、挂载点路径等细节）未被官方公开，第三方分析中也出现了 mount/bindfs 等多种线索，具体机制可能因平台和版本而异。
2.1.4 补充：公开资料中常被提及的实现细节（仅供参考）
下面这些点来自公开讨论与二次整理，可能随预览版迭代而变化；我们把它们放在“补充”里，避免被误读成官方承诺：
- •平台门槛：有分析认为 macOS 13+ 且 Apple Silicon 是关键前提。
- •镜像交付：有分析提到会下载签名的 Linux VM bundle（例如
rootfs.img一类产物）。 - •资源配额：有分析提到 VM 资源配置相对克制（CPU/内存配额），以平衡性能与宿主占用。
- •“VM 内再套沙箱”：有分析提到 VM 内部可能使用
bubblewrap/seccomp等机制进一步收敛执行进程的权限与系统调用面。 - •统一网络出口：有分析提到执行环境可能默认不直连外网，网络请求通过宿主侧代理/转发组件收口，便于策略与审计。
2.2 Claude Code 与 Cowork 的架构关系
许多用户和分析师最初误以为 Cowork 是一个全新的独立产品。根据 Anthropic 官方文档，Cowork"使用与 Claude Code 相同的 agentic 架构"（uses the same agentic architecture that powers Claude Code）。这意味着两者共享同类 agentic 架构与工作流模式，GUI 更像是控制面/可视化外壳，把同类能力下沉给更广泛的人群。
| | | |
|---|
| 运行环境 | | 嵌入式 Linux VM (Guest Shell) | |
| 交互模式 | | | 核心推理循环（Reasoning Loop）是相同的 |
| 上下文管理 | | | |
| 主要受众 | | | |
| 安全模型 | | | |
这种同构性意味着，Anthropic 在 Claude Code 上积累的关于代码理解、文件操作、测试修复等强大的 Agent 能力，被无缝迁移到了 Cowork 中。
反过来，Cowork 在虚拟化安全方面的探索，未来也极有可能反哺给 CLI 版本的工具。
2.3 核心循环：感知-规划-行动-反思
无论是 CLI 还是 GUI，驱动 Agent 运行的是一个核心控制循环。根据第三方技术拆解（如 PromptLayer 等对 Claude Code 的分析），这个循环被称为"Master Agent Loop"，采用单线程 while-loop 形式运行。
这个循环是 Agent 智能的体现：
- 1.感知 (Observation)：Agent 获取当前环境状态。在 Cowork 中，这包括读取当前挂载目录的文件列表、Git 状态、以及上一轮工具执行的 stdout/stderr 输出。
- 2.规划 (Planning/Reasoning)：基于当前状态和用户目标，模型生成思维链（CoT）。根据官方文档，Cowork 会在任务开始时创建计划，用户可以在执行过程中查看并引导（steer）计划的执行。这种 "Human-in-the-Loop" 的设计是解决 AI 幻觉的关键机制。
- 3.行动 (Action)：模型输出结构化的工具调用指令（Tool Calls）。例如
edit_file、run_command。 - 4.执行 (Execution)：系统执行工具。在 Cowork 中，这通常意味着通过 MCP 协议或直接在 Linux VM 中运行 Bash 命令。
- 5.反思 (Reflection)：Agent 接收执行结果。如果成功，进入下一步；如果失败（如文件不存在、API 报错），Agent 会进入自我修正流程，分析错误原因并尝试替代方案。
3. 神经系统：Model Context Protocol (MCP) 深度解析
如果说 LLM 是大脑，虚拟化环境是躯体，那么Model Context Protocol (MCP)就是连接 Agent 与外部世界的神经系统。
作为解决 AI 应用互联 "N×M" 难题的通用标准，MCP 的提出具有划时代的架构意义。
3.1 解决碎片化集成的 "N×M" 困境
在 MCP 出现之前，AI 开发者面临着巨大的集成成本：
- • 要让 Claude 访问 Google Drive，需要开发专用插件
- • 要让 ChatGPT 访问 Postgres，又要开发另一套
随着模型数量 (N) 和数据源数量 (M) 的增加，集成工作的复杂度呈N × M指数级增长。
MCP 旨在成为 AI 时代的USB-C 接口。它定义了一套标准化的 JSON-RPC 协议，使得数据源只需实现一次 MCP Server，就能被所有支持 MCP Client 的 AI 应用（如 Claude Desktop, Cursor, IDEs）所连接。
3.2 协议架构：Host, Client 与 Server
MCP 采用经典的客户端-服务器架构，但在 AI 上下文中赋予了新的角色定义：
MCP Host (宿主)：这是用户直接交互的终端，如 Claude Desktop 应用。它负责管理整个会话的生命周期、用户界面的渲染以及与 LLM 的核心交互。Host 充当了编排者，决定何时连接哪些 Server，以及如何将 Server 的能力暴露给 LLM。
MCP Client (客户端)：嵌入在 Host 内部的协议实现层。它负责与 MCP Server 建立 1:1 的连接，处理协议握手、能力协商（Capability Negotiation），并将 LLM 生成的工具调用请求序列化为 JSON-RPC 消息发送给 Server。
MCP Server (服务端)：这是真正干活的组件。它可以是一个本地的 Python 脚本，也可以是一个远程的 Web 服务。它通过标准化的接口暴露三种核心原语：Resources, Tools 和 Prompts。
3.3 核心原语的三位一体：Resources, Tools, Prompts
理解 MCP 的核心在于理解其定义的三种原语（Primitives），它们分别对应了 Agent 获取信息、执行操作和复用知识的三种模式。
3.3.1 Resources（资源）：被动的上下文
定义：Resources 是数据源，类似于 REST API 的 GET 端点或文件系统的文件。它们是只读的、被动的。
交互模式：Application-Driven（应用驱动）。用户或 Host 决定何时将某个 Resource "Attach"（附加）到对话上下文中。
架构意义：Resources 的设计体现了对 LLM 上下文窗口（Context Window）的精细管理。不是将所有数据一股脑塞给模型，而是通过 URI（如postgres://db/table/schema）引用资源，模型可以"看到"资源的存在，但只有在需要时才读取其内容。
典型案例：数据库 Schema、API 文档、日志文件的尾部、系统的实时监控指标。
3.3.2 Tools（工具）：主动的能力
定义：Tools 是可执行的函数，能够产生副作用或进行计算。
交互模式：Model-Controlled（模型控制）。LLM 根据用户的意图和当前上下文，自主决定是否调用某个工具，以及使用什么参数。
架构意义：Tools 是 Agent 改变世界的手段。MCP 协议强制要求 Server 定义清晰的 JSON Schema 来描述工具的参数结构，这使得 LLM 能够准确地生成调用指令。
典型案例：execute_sql_query（执行 SQL）、send_slack_message（发送消息）、git_commit（提交代码）、resize_image（处理图片）。
3.3.3 Prompts（提示）：预置的工作流
定义：Prompts 是预定义的模板，包含了特定的 System Prompt 和用户输入的占位符。
交互模式：User-Initiated（用户发起）。用户在界面上选择一个 Prompt 来启动特定的任务流程。
架构意义：Prompts 使得最佳实践（Best Practices）得以复用。一个资深的运维工程师可以编写一个名为 "Incident Analysis" 的 Prompt，固化了排查故障的标准步骤，分发给团队中的初级成员或直接供 Agent 使用。
3.4 传输层深度对比：Stdio vs Streamable HTTP
MCP 协议在传输层提供了两种标准实现，分别对应了本地和远程两种截然不同的应用场景。
| | |
|---|
| 通信机制 | 父子进程间通过 stdin/stdout 管道通信 | 独立的 HTTP 请求，可选 SSE 实现流式与通知 |
| 延迟 | 极低 (<1ms) | |
| 安全性 | 极高 | 需自行处理 TLS、Auth、CORS 等网络安全问题 |
| 部署复杂度 | | |
| 并发性 | | |
| 典型场景 | | 共享知识库、企业级 API 网关、远程昂贵计算资源 |
重要说明：MCP 规范已将传输层更新为stdio与Streamable HTTP两种标准传输。Streamable HTTP 可选用 SSE（Server-Sent Events）实现流式能力和通知机制。旧的 "HTTP+SSE transport" 已被替代，但保持了向后兼容。
架构决策分析：
在桌面端的常见部署形态中，Stdio 模式往往是更自然的选择：本地进程、低延迟、数据不出机、攻击面更小。
例如，如果在隔离环境（VM/容器）内启动 Git 类 MCP Server 子进程，这种设计既能保证操作的原子性和速度（直接在隔离环境内操作文件），又能利用边界提供安全性。反之，若采用 Streamable HTTP 网络传输形态，会引入网络与认证等额外复杂度，也扩大攻击面（Attack Surface）。
然而，随着企业级应用的需求增加，Streamable HTTP 模式的重要性将日益凸显。想象一个场景：企业部署了一个中心化的 "Oracle ERP MCP Server"，全公司的分析师通过各自的 Claude Desktop 连接到这个 Server 查询财务数据。这时，Streamable HTTP 的多租户支持和远程访问能力就变得不可或缺。
3.5 协议生命周期与能力协商
MCP 协议是一个有状态的协议，这与无状态的 REST API 有本质区别。一个典型的 MCP 会话包含以下阶段：
- 1.初始化 (Initialization)：Client 发送
initialize请求，携带协议版本和自身能力（Capabilities）。 - 2.能力协商 (Capability Negotiation)：Server 响应其支持的协议版本和能力（如是否支持资源订阅、是否支持工具列表动态刷新）。这一步确保了 Client 和 Server 能够在最低共同特性集上协作。
- 3.列表发现 (Listing)：Client 请求获取可用的 Tools, Resources 和 Prompts 列表。
- • Server 可以主动发送
notifications/resources/updated通知，告知 Client 某个资源发生了变化（如日志文件有了新内容），Client 可能会据此重新读取资源
- 5.采样 (Sampling)：这是一个高级特性，允许 Server 请求 Client（即 Host）代表它调用 LLM 进行推理。这允许 Server 自身具备一定的智能，实现更复杂的逻辑。
4. 智能核心：Claude 的 "Computer Use" 能力
支撑 Cowork 运转的大脑，是Claude 系列模型。公开资料中常以 Sonnet 等型号举例说明其“Computer Use”（计算机使用）能力，但具体型号与能力开关可能会随产品阶段与平台而调整。
4.1 视觉感知与像素级定位
传统的 Agent 主要依赖文本接口（如 HTML DOM 树或 Accessibility API）来理解屏幕内容。然而，许多现代应用（如游戏、远程桌面、复杂的 Canvas 绘图应用）并不提供结构化的 DOM。
Claude 系列模型（例如 Sonnet）引入了更强的视觉感知能力。它可以直接分析屏幕截图：
- •语义理解：它能识别出屏幕上的 "Submit" 按钮，即使它只是一个没有标签的蓝色矩形图标
- •像素级坐标计算：模型能够输出精确的 (x, y) 坐标，指导鼠标移动和点击。这需要模型具备极强的空间推理能力，通过计算像素距离来定位元素
- •多模态融合：它能结合 OCR（光学字符识别）结果和视觉布局信息，理解复杂的 UI 结构，如表格、层叠菜单和弹窗
4.2 动态规划与错误恢复
在 Cowork 的工作流中，Agent 经常会遇到意料之外的阻碍：网页加载慢、弹出了广告、文件被锁定等。
Claude 系列模型（例如 Sonnet）通常展现出更强的动态规划能力：
- •观察-判断：当点击一个按钮后没有预期反应，模型会对比前后两帧截图，判断操作是否失败
- •策略调整：如果 CSS Selector 此时失效，模型可能会自动切换到基于视觉坐标的点击，或者尝试使用键盘快捷键（Tab 切换焦点）
- •自我修正：在编码任务中，如果生成的代码报错，模型能够阅读错误堆栈，定位到具体行数，并提出修复方案。这种 Evaluator-Optimizer 循环是 Agent 能够独立完成长程任务的关键
4.3 长上下文能力的战略意义
Claude Cowork 利用了 Claude 系列模型的长上下文能力（例如 200k Token 标准上下文；部分模型/计划在特定条件下可达 1M Token，具体取决于所用模型与订阅档位）。这在 Agentic Workflow 中具有巨大的架构价值：
- •全量上下文：Agent 可以将整个项目的目录结构、核心代码文件、甚至相关的 API 文档一次性读入上下文。这避免了 RAG（检索增强生成）系统中常见的检索丢失问题
- •长期记忆：在长达数小时的协作中，Agent 能够"记住"用户在开始时设定的约束条件（如"不要使用 jQuery"），并贯穿始终。虽然超长上下文存在 "Lost in the Middle"（中间迷失）现象，但 Anthropic 通过优化的注意力机制显著缓解了这一问题
5. 从架构到落地：你需要额外关心的三件事
本文聚焦“底层怎么做成的”。但如果你真的要把它用进团队/企业流程里，下面三件事比“模型更聪明”更决定成败：
- 1.权限边界要小：以“授权文件夹/项目”为最小上下文半径，默认只读，写入必须显式开启。
- 2.关键动作要可阻止：删除/覆盖/发送/支付等不可逆动作，必须有明确的确认点（Human-in-the-Loop）。
- 3.结果要可追溯可回滚：变更摘要、来源列表、执行日志、回滚策略，缺一不可。
更完整的落地清单与治理框架，我放在这篇:Claude Cowork 落地指南：任务模板、安全护栏与成果物交付
如果你更关注“安全如何产品化落地”（威胁模型、纵深防御、最小权限、人类在环），建议配合阅读：Cowork 安全架构深度解析：从 Claude Code 到 Cowork，Anthropic 如何把“可控”做成产品
结语
Claude Cowork 不仅仅是一个新功能的发布，它代表了软件架构设计的一次深刻变革。
通过AVF 虚拟化确立安全边界，通过MCP 协议标准化“工具/数据源”的接入方式，再通过主代理循环（Master Loop）把“计划—行动—反馈—修正”做成可运行的系统，Anthropic 向我们展示了一张通往“数字同事”时代的工程蓝图。
对于技术领导者而言，现在的任务不再是观望，而是行动。我们需要开始思考：
- • 现有的业务系统如何通过 MCP 暴露给 Agent？
- • 我们的数据管道是否为 Agent 做好了准备？
- • 我们团队的技能栈是否包含了 Agent 工程学？
在这个新的时代，代码（Code）依然重要，但协作（Cowork）才是核心。
我们正在编写的，不再是给机器执行的指令，而是给数字同事阅读的剧本。
