Claude Cowork新功能Dispatch上线：手机远程指挥电脑Agent，开启本地工作流自动化新篇章

Claude Cowork 是这一波本地 AI 智能体（Agent）热潮的先行者。当外界还在讨论哪款产品“最好用”时，一部分用户已经利用 Cowork 实现了整个工作流程的自动化。

近期，Cowork 上线了一项名为“Dispatch”的新功能，将这类 Agent 产品的生产力推向了新的高度：用户可以通过手机，远程指挥自己电脑上的 Cowork 执行任务。

Dispatch 功能调用了 Cowork 完整的底层能力。这意味着，用户在电脑端能够访问和操作的一切——本地文件、浏览器、连接的邮箱、网盘或 Slack 等工具——现在都可以通过手机端进行指挥和调用。

Anthropic 的产品负责人 Felix Rieseberg 在一次访谈中提出了一个引人深思的观点：

如果你雇佣了一名开发者，却规定他只能通过邮件来收发代码，这有多荒谬？然而，我们目前对待 AI 的方式正是如此。

Cowork 的解决方案是赋予 Claude 一个虚拟机（VM）。通过这个安全隔离的虚拟环境，Claude 能够像真人一样自由地安装软件、执行各类任务，而不仅仅是被困在一个只能回答问题的输入框里。

在加入 Anthropic 之前，Felix 曾参与 Slack 桌面应用的构建，并且是 Electron 框架的核心维护者。VS Code、Slack 等知名应用都构建在 Electron 之上。

在近期的一次深度访谈中，Felix 分享了 Claude Cowork 从原型到上线的完整历程、虚拟机背后的设计思考、Skills 功能的意外诞生，以及在他看来，Agent 要真正融入日常知识工作还需要哪些条件。

以下是访谈的精华内容。

01 Cowork 本质是运行在虚拟机中的 Claude Code

主持人：首先，请向大家介绍一下 Claude Cowork 是什么？

Felix： 简单来说，Claude Cowork 是 Claude Code 的一个用户友好版本。它的基本工作原理是：我们拥有一个相当强大的 Agent 框架——Claude Code。去年 12 月，我们注意到越来越多的人开始使用 Claude Code，即使他们并非技术人员，不熟悉终端操作。甚至一些熟悉终端的人，也开始用它来处理非编程类工作，比如管理开支、整理收据或组织知识库。用它来管理 Obsidian 的用户反馈尤其好。

我们想把握这个机会，将这种能力带给那些不熟悉终端、可能不知道如何使用 brew install 命令的用户。因此，Cowork 本质上是在虚拟机中运行的 Claude Code，它增加了一些安全保护和便利功能，让那些不想一上来就打开终端的人也能轻松使用。

主持人：但你说它是“更用户友好”，我的实际体验却感觉 Cowork 功能更强大，集成了更多东西。这是我的个人错觉吗？

Felix： 说实话，我认为你的感觉没错。这让我想起了最近一直在思考的一个问题。当我们说“用户友好”时，人们往往会联想到“简化版”。但实际上，Cowork 是一个“功能超集”。

这让我想起 10 到 12 年前在微软的经历，当时我们开始研究 Electron 和基于浏览器的跨平台技术。最早的用例之一是 Visual Studio Code，它最初就是一个网站。当时的说法是，VS Code 是更用户友好的 Visual Studio。同样，也有声音质疑它不适合严肃的开发者。

但最终的结果是——关于 VS Code 为何如此成功，每个人都有自己的解读——但我个人认为，其强大的可扩展性和可定制性起到了关键作用。你可以将 VS Code 接入几乎任何工作流程，它非常易于修改和扩展。我觉得 Cowork 可能正在经历类似的情况：它很容易扩展，很容易融入用户的工作流。

主持人：Claude Code 在非技术场景的使用量激增。是什么促使你们决定开发一个独立的产品 Cowork？而且听说你们只用了 10 天就完成了？

Felix： 在 Anthropic，我们一直在思考，如何让那些习惯用 Claude 进行问答的用户，也能利用 Claude 来执行任务、解决问题甚至构建东西。如何将这种“执行能力”带给目前主要处于“问答模式”的用户？

我们在这方面已经有很多产品原型，可以追溯到一年半以前，很多同事都在研究这个问题。Anthropic 的内部文化非常强调原型驱动和演示优先。我们有很多未公开发布的内部原型。Cowork 实际上是我们从众多原型中挑选合适部分组合而成的产物。

这也是为什么每当有人提到“10天”这个数字时，我觉得有必要澄清：我们并非从零开始。已经有很多基础组件和工作在进行中。这就像构建网站时会使用 React 等现成框架一样，我们也有很多可重用的组件。

02 当执行变得“廉价”，平台基础设施的价值反而上升

主持人：说到执行成本变得廉价，这个转变确实很惊人。

Felix： 是的。我们通常认为“想法廉价，执行才是难点”。但现在情况不同了。

过去，产品经理需要寻找潜在客户，通过低带宽的方式（如访谈）了解他们的问题和付费意愿，然后构思解决方案、起草规格、设计，最后才执行。

现在 Anthropic 内部的做法是：不要写长篇备忘录了，直接把所有候选方案都快速构建出来。 把它们都造出来，然后选择最好的那个。

主持人： 你提到重用某些组件，这让我联想到，即使是 Claude Code，虽然编写代码的成本趋近于零，但拥有某种平台基础设施的价值似乎在增加，因为你在构建新东西时可以像搭积木一样组合它们。所以，当有人说许多软件的价值会因为能够轻易重建而“归零”时，我认为恰恰相反——拥有现成平台可供构建的价值实际上更高了。

Felix： 我认为你说得对。整体平台确实非常有用。这可能是一个在 AI 领域有些反主流的观点，但我实际上并不认为未来会是超个性化软件的时代，即每个人都运行自己独有的版本。那样会带来协作的困难。例如，如果我想和你交流，我们使用各自不同的内部工具，该怎么办？

在构建 Cowork 的背景下，这是两种思路的结合。变得“廉价”的执行，并不意味着要重建所有基础设施。我认为许多基础设施本身也没有太多重造的先验价值。例如，我的团队从未考虑过重建 Claude Code。我们非常明确地从核心论点出发：这应该基于 Claude Code，然后在它之上进行构建。

真正变得“廉价”的执行部分是：如何将所有这些“乐高积木”组合成对用户有意义的产品。 这才是创造价值的关键。现在，你有如此多不同的方法来决定哪些部分应该抽象为通用模块（原语），哪些应该保持完整。

对我个人而言，我可能不会再试图在没有用户测试的情况下，仅凭设想就确定一个产品方案。这虽然不是新概念，但在过去，你必须在技术选型 A 或 B、这种或那种构建方式之间做出昂贵且不可逆的决策。我现在坚信，你应该把它们都构建出来，在小型焦点小组中进行测试，然后选择更好的那个。这与我们一年前的工作方式有很大不同，确实是最近才发生的变化。

03 给 AI 一台完整的电脑，至关重要

主持人：请详细介绍一下 Cowork 及其核心组成部分。

Felix： 基本上你已经掌握了要点。其中的“规划”功能目前可以暂时忽略。Cowork 真正有价值的几个方面包括：虚拟机可能是其中最强大的功能。

我们目前运行一个轻量级虚拟机，并将 Claude Code 置于其中。这样做有几个重要原因：安全性是其一。但即使暂时抛开安全性不谈，如果你只是想让它“做任何事情”，那么给 Claude 一台完整的电脑是相当强大的。这通常都是一个好主意。

在 Anthropic 的架构和用户体验设计中，积极地采用拟人化视角是很有用的——你可以把 Claude 视为一位人类同事。你会如何与一位人类同事协作？

今早我给我父亲打了个比方：如果你是一名开发者，而你的雇主告诉你不需要电脑，他们只会通过邮件发送代码给你，你再通过邮件把代码发回去。这种方式对几英里外的人或许可行，但效率极低。

通过虚拟机（VM），因为它是 Linux 系统，Claude Code 几乎可以自由安装它所需的任何工具，例如 Python、Node.js。当然，我们实施了严格的网络出入控制。作为用户，你仍然可以用简单的自然语言来明确告知整个系统，哪些操作是被允许的，哪些是不被允许的。

关键在于，我们永远不需要像询问一个真人（比如市场部或法务部的同事）那样去获得许可。我不需要去问律师：“你同意我安装 Homebrew 吗？”因为这类问题的含义复杂而微妙，难以推理。这为我们提供了巨大空间，让 Claude 变得非常强大。

主持人：你之前提到过“审批疲劳”这个概念。如果每一步都需要审批，那就不是自动化；但不审批又存在风险。沙箱环境是否正好提供了一个折中方案？

Felix： 我认为，作为 AI 行业的一员，我们需要构想出比现有方案更好的方法。不能只是“什么都不做就绝对安全”，而“想让它有用就必须批准每一步”。

计算机使用就是一个很好的例子。要让主机上的计算机使用真正安全，唯一的方法可能是批准每一个操作。模型说“我想输入这个词”，你说“好的，看起来没问题，我知道光标焦点在哪里”。但如果你不授权，那就不是自动化。你需要能够授权，然后离开，并相信它不会造成严重破坏。

我之前提到过一个观点，引发了一些讨论：我通常认为硅谷整体上低估了本地计算机的价值。 我常反问：为什么你们都在用 MacBook，而不是 iPad 或 Chromebook？本地机器仍然有其不可替代的价值。

现在，当我思考 Claude 时，我认为它应该是一个对你极其有用的实体。这个实体需要能够访问你所能访问的所有相同工具，否则它会以各种复杂的方式受到限制。

实现路径有两种：一种是说，好吧，我们将把你电脑上的所有东西一个个搬到云端。这是一条路，我认为其他一些产品选择了这种方式。但就我个人而言，对于我使用的工具数量，我真的没有耐心去给另一个工具逐一授予权限，并持续维护这些权限的更新。

主持人：我一直在想，一键把整台电脑克隆到云端会是什么感觉，但每个人真的都想要这个吗？我觉得不一定。

Felix： 这引出了所有技术问题的上游考量。总的来说，我认为世界还没有为这种东西做好准备。举个简单的例子：作为桌面应用，理论上在你的许可下，我们可以在你的电脑上做很多事情，包括读取你的 Chrome cookies（如果我们真的想这么做）。我们可以获取你的 cookies，虽然你不需要为我们解密，但如果我们想，可以把它们传到云端。这是一个相当直接的解决方案，听起来很酷。我们可以说：看，现在你的所有任务都能在云端完成了。

但很多网站，包括银行，如果它们发现相同的身份验证来自两个不同的地理位置，就会锁定你的账户。然后你就得带着护照去银行分行解封。

虽然我们都对“智能体化未来”这个词有些厌倦了，但我认为许多基础设施需要慢慢跟上。在那之前，让 Claude 发挥最大效能的方式，就是让它就在你工作的地方运行。

主持人：你们如何评估 Claude Cowork？它与评估 Claude Code 的方式有何不同？

Felix： Claude Code 主要针对编码任务进行优化，我们主要根据它在典型软件工程工作中的表现来评估其改进或退步。而 Claude Cowork 则针对典型的知识工作进行评估，例如你在金融或法律办公室中会遇到的那种工作。我个人的用例总是管理我的事务，比如处理个人抵押贷款等。

你可能会注意到我们对系统提示词的细微调整，我们放入什么内容，以及如何用我们提供的工具引导 Claude。因此，它可能在一个方向上表现得更好，而在另一个方向上有所权衡。Claude Code 在代码方面会更好，Claude Cowork 在非编码任务方面会更好。

这些差距在下一代模型中是否还会存在？对我来说尚不清楚。因为目前我们进行的这些超级优化，我不确定它们还能保持多久的相关性。

Skills 的优势：极易创作、高度个性化

主持人： 我展示一下我是如何使用 Claude Cowork 的。我让 Cowork 自己从 Zoom 下载录音、压缩，然后自动上传到 YouTube，它居然全做到了。然后，我让它把自己的工作流程打包成一个 Skill，这样以后就可以直接复用了。

Felix： 这太美妙了，也很有趣。因为 Skills 的一个非常有趣之处在于它们太容易制作了。任何人都可以制作 Skill，甚至一条短信都可以是一个 Skill，而且可以做到高度个性化。

主持人： 基本上，我觉得人们熟悉 Cowork 的方式是：找一个你通常需要手动点击操作的知识工作任务，尝试将其自动化。然后你会想，如果能再进一步呢？如果再进一步呢？于是你不断扩大 Cowork 的自动化范围，随着对它的信任增加，也教会它如何逐步接管你的部分工作。

Felix： 这有点像玩《Factorio》（一款自动化工厂建设游戏），但是为了你自己的生活。你从很小的地方开始，自动化一些小事，一旦成功，就不断添加到这个自动化“帝国”中，让你的生活越来越轻松。

我最喜欢的 Skill 是每天早上 Cowork 会查看我的日历，确保没有日程冲突。因为人们倾向于安排很多会议，有时是最后一刻的，有时会错过。我在自定义提示词中写了相当明确的说明，比如“如果 Dario 安排了会议，就不要试图重新安排 Dario 的会议”。

主持人： Skills 这个想法是怎么来的？能详细讲讲吗？

Felix： Barry 最初开发的原型就很像今天的 Cowork，他思考的是为不想编写代码的人设计一个协作工具。他也是在桌面应用内做的原型。

我们想到的第一个用例是：什么样的非编码用例能真正受益于图形界面，并且能与底层代码分离？每个人都会想到相同的答案——数据分析。比如“我们今天有多少用户？”总是这类问题。

最终促使 Skills 诞生的是，我们想把这个小原型连接到我们的数据仓库。团队很快发现，与其为这个东西构建一个自定义工具来连接数据仓库，他们只是写了一个 Markdown 文件：“亲爱的 Claude，如果你想获取数据，这是端点，这是 API 的样子，你自己搞定。”

这最终非常有效，以至于他们开始尝试同样的模式——只给模型一个描述它需要做什么的 Markdown 文件。整个东西最终演变成了 Skill。我们想：我们应该把这个模式打包起来，这是个好主意。

高度专业化的 AI 应用短期有效，但不会存在太久

主持人：关于产品设计，我发现你们一直保持比较“通用”的方向。未来会不会推出针对特定技术栈的版本，比如专门针对 React + Node.js 的版本？

Felix： 不会。我们不会发布一个只适用于使用 React 和特定技术栈 X 的 Node.js 应用的 Claude Code。如果是其他技术栈就不行——我知道有几家创业公司在做这种事。

我不是 VC，也不是投资者，很难预测市场走向。但就我感兴趣的构建模块而言，Electron 可能是我构建过的最受欢迎的东西。Electron 本身是高度可抽象和可泛化的，对吧？有海量的应用都在使用它。

主持人： 对，很难预测最终会有多少应用使用 Electron。

Felix： 更难预测的是这些应用会做什么。我记得 Bloom 应用出来的时候——你的摄像头画面在角落的一个小圆圈里，很巧妙。那是个 Electron 应用。或者至少曾经是，我不确定现在还是不是。1Password 也做了很多有趣的东西。

这是我很熟悉的抽象层级。每当我给其他工程师建议时，我都说这一层是最值得投资的，因为这一层的工具虽然不是最完美的，但这是你为未来获得最大杠杆效应的位置。

主持人： 这引出了一个关于“脚手架”的问题。你现在投入精力构建的任何“脚手架”，都可能随时被下一代模型淘汰，这本质上是一种下注，对吗？

Felix： 是的。作为 Anthropic 的工程师，我对即将到来的模型有更多了解：下一个模型是什么，它擅长什么，不擅长什么。

因此，我越来越倾向于一个想法：与其过度投资于修正模型的“脚手架”——模型可能并非表现不当，只是没有按你期望的方式行事——不如赋予它尽可能多的能力，并努力确保安全，这样即使最坏的情况也不会太糟。然后，等待下一个模型的发布。

主持人： 这是否意味着，高度专业化的 AI 产品，其生命周期可能不会太长？

Felix： 我认为我们会看到很多应用和公司利用 AI 做出令人印象深刻的事情，短期内它们可能看起来非常有效，因为它们高度专门化于个别用例。但我认为，一旦模型在泛化能力上变得更强，能够在没有大量专门指导的情况下更好地处理这些特定任务，我不确定这些高度专门化的方案能持续多久。

你已经在 Skills 和 MCP 服务器中看到了这种转变的苗头。Barry 最初制作 Skills 时做的东西，看起来就很像今天的 Cowork。他也在桌面应用中进行原型开发。

最终促使 Skills 诞生的契机是，我们想把这个小原型连接到数据仓库。团队很快发现，与其为这个东西构建自定义工具，他们只是做了一个 Markdown 文件，上面写着：“亲爱的 Claude，如果你想获取数据，这是端点，这是 API 的样子，你自己搞定吧。”

06 无需完美：模型对齐与分层防护

主持人： 在安全方面，你们是如何实施分层防护的？

Felix： 我们不需要构建完美的系统，也不需要等待模型达到 100% 的对齐。 我们可以依赖行业长期使用的“瑞士奶酪模型”，采用多层防护。每一层都可能有一些漏洞，但组合起来就能提供足够的安全性。

作为开发者，我们可能对风险有更高的容忍度，但同时也抱有一种信任——如果真的发生了不好的事情，我们或许能够修复它。想想那些简单的事情，比如 npm install。我们都在用完整的用户权限运行它。如果它想读取 .ssh 目录，它就能做到。这就是默认行为。

主持人： 是的，作为工程师，我们一直都对风险有更高的容忍度。

Felix： 如果你进行一些内省，问自己“这应该是我们做事的方式吗？”，你未必总能得出正确的答案。

对于模型也是如此。我不想问你“你对这个脚本没问题吗？”，因为我相信一旦它成为你工作流程的一部分，你要么没有足够的技能去理解这个 Python 脚本是否安全，要么你根本不会去读它。

通过虚拟机（VM）和严格的网络出入控制，用户仍然可以用简单的人类语言明确告诉整个系统，什么是允许的，什么是不允许的。但我们永远不需要去问一个真人——可能是市场部或法务部的人。我不需要去问律师：“你同意我安装 Homebrew 吗？”因为这个问题及其答案的含义是复杂而微妙的。

07 未来展望：协作与自动化演进

主持人： Cowork 接下来的发展方向是什么？会支持 Claude Code Remote 吗？

Felix： 目前还没有，但即将到来。

我们还处于非常早期的阶段。每周都会有新功能发布，如果不是重大功能，至少也是小的改进。我会继续加倍投入，让 Claude 在你的电脑上变得更高效。

我们正在处理的三个主要方向是：
* 在你的电脑上做更多事情。
* 独立完成更长时间的任务。
* Remote（远程）功能即将到来。

主持人： 多人协作会如何实现？例如，我需要同事机器上的文件，或者想了解他们的任务进展来配合自己的工作，这种场景如何处理？

Felix： 这对我来说非常有趣。这又回到了“脚手架”的问题——我们是否会构建最终会消失的脚手架？

我的疑问是：我们什么时候会直接给这些 AI 分配它们自己的 Gmail 账号？给它们自己的 Slack 账号，然后它们就像人类一样，使用相同的工具进行交流。

我们的金融团队一直在努力做好办公软件的集成。有一段时间，我们构建了很多技术让 Claude 在 Google Doc 中留下有用的评论，现在它就是通过这种方式工作的——在你的 Google Doc 中留下评论，这就是你与它交互的方式。

主持人： 所以最终，不同的 Cowork Agent 会通过 Slack 相互交流？

Felix： 可能是这样。我对于最佳的交互模式仍然持开放态度。是为 Cowork Agent 之间的交流构建超级定制化的工具？还是直接跳到终点线，说“如果你在工作中使用 Slack，我们就给它一个 Slack 账号，这就是它的多人协作能力”？

主持人： 还有一个想法，就是观察我一整天在做什么，然后告诉我哪些部分可以“Cowork 化”（自动化）。

Felix： 是的，这有点像为你的生活玩《异星工厂》（Factorio）。你从很小的地方开始，自动化一些很小的事情，一旦成功，你就不断向这个自动化帝国添加东西，让你的生活越来越轻松。

还有一个可能有点“令人不安”的想法：我们有蓝牙低功耗（BLE）技术，这台电脑可以检测到它就在另一台电脑旁边，所以你们可能在做同一件事。你会在 Cowork 中看到这个功能吗？可能不会。但我认为，还有很多真正具有创造性的解决方案我们尚未尝试。

关注“鲸栖”小程序，掌握最新AI资讯