你有没有想过，为什么我们和 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） • AI负责底层的任务分解、工具调用和状态管理
这种分工极大地释放了人类的认知带宽，让我们能够专注于最具创造性的部分。
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 更像是控制面/可视化外壳，把同类能力下沉给更广泛的人群。
| 运行环境 | |||
| 交互模式 | |||
| 上下文管理 | |||
| 主要受众 | |||
| 安全模型 |
这种同构性意味着，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 协议在传输层提供了两种标准实现，分别对应了本地和远程两种截然不同的应用场景。
| 通信机制 | ||
| 延迟 | 极低 (<1ms) | |
| 安全性 | 极高 | |
| 部署复杂度 | ||
| 并发性 | ||
| 典型场景 |
重要说明：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 列表。 4. 运行循环 (Runtime Loop)：
• Client 发送 tools/call请求• Server 执行逻辑并返回结果 • Server 可以主动发送 notifications/resources/updated通知，告知 Client 某个资源发生了变化（如日志文件有了新内容），Client 可能会据此重新读取资源
5. 采样 (Sampling)：这是一个高级特性，允许 Server 请求 Client（即 Host）代表它调用 LLM 进行推理。这允许 Server 自身具备一定的智能，实现更复杂的逻辑。 • 语义理解：它能识别出屏幕上的 "Submit" 按钮，即使它只是一个没有标签的蓝色矩形图标 • 像素级坐标计算：模型能够输出精确的 (x, y) 坐标，指导鼠标移动和点击。这需要模型具备极强的空间推理能力，通过计算像素距离来定位元素 • 多模态融合：它能结合 OCR（光学字符识别）结果和视觉布局信息，理解复杂的 UI 结构，如表格、层叠菜单和弹窗 • 观察-判断：当点击一个按钮后没有预期反应，模型会对比前后两帧截图，判断操作是否失败 • 策略调整：如果 CSS Selector 此时失效，模型可能会自动切换到基于视觉坐标的点击，或者尝试使用键盘快捷键（Tab 切换焦点） • 自我修正：在编码任务中，如果生成的代码报错，模型能够阅读错误堆栈，定位到具体行数，并提出修复方案。这种 Evaluator-Optimizer 循环是 Agent 能够独立完成长程任务的关键 • 全量上下文：Agent 可以将整个项目的目录结构、核心代码文件、甚至相关的 API 文档一次性读入上下文。这避免了 RAG（检索增强生成）系统中常见的检索丢失问题 • 长期记忆：在长达数小时的协作中，Agent 能够"记住"用户在开始时设定的约束条件（如"不要使用 jQuery"），并贯穿始终。虽然超长上下文存在 "Lost in the Middle"（中间迷失）现象，但 Anthropic 通过优化的注意力机制显著缓解了这一问题 1. 权限边界要小：以“授权文件夹/项目”为最小上下文半径，默认只读，写入必须显式开启。 2. 关键动作要可阻止：删除/覆盖/发送/支付等不可逆动作，必须有明确的确认点（Human-in-the-Loop）。 3. 结果要可追溯可回滚：变更摘要、来源列表、执行日志、回滚策略，缺一不可。 • 现有的业务系统如何通过 MCP 暴露给 Agent？ • 我们的数据管道是否为 Agent 做好了准备？ • 我们团队的技能栈是否包含了 Agent 工程学？
4. 智能核心：Claude 的 "Computer Use" 能力
支撑 Cowork 运转的大脑，是 Claude 系列模型。公开资料中常以 Sonnet 等型号举例说明其“Computer Use”（计算机使用）能力，但具体型号与能力开关可能会随产品阶段与平台而调整。
4.1 视觉感知与像素级定位
传统的 Agent 主要依赖文本接口（如 HTML DOM 树或 Accessibility API）来理解屏幕内容。然而，许多现代应用（如游戏、远程桌面、复杂的 Canvas 绘图应用）并不提供结构化的 DOM。
Claude 系列模型（例如 Sonnet）引入了更强的视觉感知能力。它可以直接分析屏幕截图：
4.2 动态规划与错误恢复
在 Cowork 的工作流中，Agent 经常会遇到意料之外的阻碍：网页加载慢、弹出了广告、文件被锁定等。
Claude 系列模型（例如 Sonnet）通常展现出更强的动态规划能力：
4.3 长上下文能力的战略意义
Claude Cowork 利用了 Claude 系列模型的长上下文能力（例如 200k Token 标准上下文；部分模型/计划在特定条件下可达 1M Token，具体取决于所用模型与订阅档位）。这在 Agentic Workflow 中具有巨大的架构价值：
5. 从架构到落地：你需要额外关心的三件事
本文聚焦“底层怎么做成的”。但如果你真的要把它用进团队/企业流程里，下面三件事比“模型更聪明”更决定成败：
更完整的落地清单与治理框架，我放在这篇:Claude Cowork 落地指南：任务模板、安全护栏与成果物交付
如果你更关注“安全如何产品化落地”（威胁模型、纵深防御、最小权限、人类在环），建议配合阅读：Cowork 安全架构深度解析：从 Claude Code 到 Cowork，Anthropic 如何把“可控”做成产品
结语
Claude Cowork 不仅仅是一个新功能的发布，它代表了软件架构设计的一次深刻变革。
通过 AVF 虚拟化 确立安全边界，通过 MCP 协议 标准化“工具/数据源”的接入方式，再通过 主代理循环（Master Loop） 把“计划—行动—反馈—修正”做成可运行的系统，Anthropic 向我们展示了一张通往“数字同事”时代的工程蓝图。
对于技术领导者而言，现在的任务不再是观望，而是行动。我们需要开始思考：
在这个新的时代，代码（Code）依然重要，但协作（Cowork）才是核心。
我们正在编写的，不再是给机器执行的指令，而是给数字同事阅读的剧本。
