3月18日，Anthropic Claude Cowork 项目核心技术人员 Felix Rieseberg 接受了海外播客 Latent Space 主持人 Alessio 与 swyx 的深度访谈。本次对话围绕 Anthropic 近期发布的Claude Cowork 展开，深入探讨了其从 10 天快速原型到正式产品的诞生历程、虚拟机的底层逻辑、本地计算与云端的权衡、硅谷对本地计算机的认知误区、AI 渐进式起飞背景下的 Agent 协作范式转移以及skill如何重塑人类工作流等话题。
Felix Rieseberg指出，Claude Cowork 的核心价值在于为 AI 提供了一台运行 Linux 系统、具备高度自由度的虚拟机，他认为，硅谷当前严重低估了本地计算机的价值，在基础设施完全适配当前的AI 浪潮前，将电脑克隆到云端存在巨大的认知与技术挑战，而让 AI 贴近用户的本地环境、直接访问工具与浏览器 Cookie，才是现阶段实现长程任务委派的高效路径。
此外，Felix 认为模型实际能力远超目前的使用方式，这源于开发者未能提供充足的工具。他预测，未来个人的核心生产力资产将从标准化的产品转向私有的skills库，通过符号链接实现skill在不同 Agent 框架间的无缝映射。
对于 AGI，Felix 认为当 AI 能够自主处理如 Google Cloud 注册等高度复杂的流程时，变革实则已经发生。未来，AI Agent 将不再局限于单人模式，而是通过人类现有的社交工具或专用通讯协议，实现 Agent 之间的直接对话与任务交接 。
01
Claude Cowork 的诞生与定位
作为 Cowork 的核心技术人员，能否请你从宏观层面为那些还没有尝试过的人介绍一下，究竟什么是 Claude Cowork？我最近对这个产品非常痴迷，它能帮我处理视频命名、编辑等所有琐事，甚至让我感觉 AGI 已经实现了。虽然你把它定位成一个更易用的版本，但它能与 Chrome 及其他工具集成，它是否更像是一个功能上的“超集”权力用户工具？
Felix Rieseberg: 官方头衔是技术核心人员，这个职衔可能会一直伴随着我。我很想看看那个演示。我工作中最大的乐趣之一，就是观察用户如何以各种奇特的方式使用 Cowork。显然，我们很难针对所有特定的使用场景进行设计，但那些对产品感到最惊艳的用户，通常是因为 Cowork 完成了一些我从未预料到它能胜任的任务。
我们有一位新设计师，他接手的首批小任务之一是为内部 Slack 频道设计一个新的 Cowork 表情符号。他画了一个 SVG 文件并直接交给 Cowork，问它能否为这个表情做个动画。现在这个表情拥有了一个非常漂亮的循环动画效果。这证明了你可以利用代码实现比预期多得多的功能，这种探索对我来说非常有趣，我也很期待看到你们的使用案例。
简单来说，Claude Cowork 是 Claude Code 的用户友好版本。我们的核心逻辑是，我们拥有 Claude Code 这一性能强劲的 AI Agent 框架。在去年 12 月，我们注意到越来越多的人开始使用它，即便他们并非技术人员，不习惯使用终端命令行。甚至是一些技术人员，也开始将 Claude Code 用于非编程任务，比如管理开支、整理收据或组织知识库。
当时很多人对 Obsidian 的联动感到兴奋，我们希望把握住这个趋势，将这种能力带给那些非终端原生、不知道如何通过命令行安装软件的用户。因此，Cowork 的本质是在虚拟机中运行的 Claude Code，我们增加了一些缓冲设计和安全护栏，使其对于那些不想一上班就打开终端的用户来说更加安全、便捷。
（关于权力用户工具定位）坦白说，我不认为你这种看法有错，这也是我过去两周一直在思考的问题。这让我想起大约 10 到 12 年前我在 Microsoft 的经历。当时我们开始研发 Electron 以及跨平台技术，Visual Studio Code 最初其实是一个网站。当时的叙事是 Visual Studio Code 是 Visual Studio 的轻量易用版，甚至有声音认为严肃的开发者不会使用它。但最终，Visual Studio Code 取得了巨大的成功。
我个人的看法是，可定制性和扩展性起到了决定性作用。你可以将 Visual Studio Code 接入几乎任何工作流，针对它进行二次开发极其容易。我觉得 Cowork 也在经历类似的过程，它极易扩展且能轻松融入现有工作流。这种便利性虽然是开发者追求的目标，但用户发现其价值的方式，通常是将其映射到他们日常工作的具体任务中。
02
执行成本趋于零，但底层平台的可扩展性价值正在增加
去年年底你看到了 Claude Code 出现大量非技术用途，那么决定开发独立产品 Claude Cowork 而非修改原有程序的触发点是什么？你们只用了 10 天就把它做出来了，这种设计过程是怎样的？另外，当人们说软件的价值将归零，因为它可以被轻易重造时，你是否觉得拥有一个现成的、可扩展的平台反而更有价值？人们应该在底层原语上投入更多吗？
Felix Rieseberg: 在 Anthropic，我们一直在思考如何让习惯于问答模式的用户能够利用 AI 的力量去执行任务。它能为你解决问题，为你构建东西，我们希望将这种能力带给那些目前只习惯于聊天对话的用户。其实我们在这个方向上已经做了很多原型，甚至可以追溯到一年半以前，公司内部有很多工程师在研究这个方向。
Anthropic 内部有一种非常推崇原型演示优先的文化，我们有许多未公开的内部原型。Cowork 实际上是从这些已有的原型中挑选出最合适的组件组合而成的。关于 10 天完成开发这个说法，我想加一个重要的限定条件，在项目正式启动前，内部已经打好了很多基础。就像你用 React 开发网站一样，你是在利用现有的工具栈，这与我们当时的情况类似。
在决策路径上，我们正处在一个执行成本变得极其低廉的新世界。过去我们可能需要产品经理去接触潜在客户，低效率地调研他们的痛点，然后起草说明书、做设计、最后执行。但在 Anthropic，我们现在的做法是直接构建，不写备忘录，快速把所有可能的方案都做出来，然后从中选出最好的。目前最有影响力的决定，是我们如何在用户的本地计算机上交付价值。这是一个核心决策点，这个工具最终应该运行在本地还是云端，这其中涉及巨大的权衡。
（关于平台原语的价值）没错。我认为你是对的，整体性的平台非常有用。这在 AI 领域可能是一个有点反直觉的观点，我不认为未来会是那种每个人都运行自己专属定制化软件的世界。如果每个人都用自己的内部聊天工具，那我们要怎么互相沟通？
在构建 Cowork 的过程中，执行变得廉价并不意味着要重造所有原语（AI 系统提供的最基础能力），从先验的角度看，那样做的价值也不大。我的团队从一开始就认定核心必须是 Claude Code，然后在此基础上构建。执行变便宜体现在你如何像玩乐高积木一样，将这些现有组件以对用户有意义且有价值的方式组合起来。现在的问题是，你会把哪些功能定义为底层的原语？你是坚持只用公开可用的原语来构建产品，还是保留一些内部核心技术？
我认为模式仍在演化，但我以后可能再也不会在没有经过用户测试的情况下，就试图凭空构思一个产品。这虽然不是新概念，但过去在技术选型或架构路径上做决定成本很高，而现在我坚信你应该把所有方案都做出来，找一小部分核心用户试用，看哪个效果好就选哪个。这种工作方式与一年前相比已经发生了巨大变化。
（关于语言实现的灵活性）重点不在于编写 Electron 的绑定代码，而在于应用程序内部发生的逻辑。至于用什么语言实现，AI 可以帮我轻松搞定。
03
在 AI Agent 的未来真正到来前，基础设施需要慢慢追赶
我们能否为 Claude Cowork 建立一个清晰的心智模型？它本质上是 Claude Code，此外还有云端应用和 Chrome 插件。我想澄清一下 Cowork 的主要组成部分，特别是关于规划功能。此外，既然已经开始在本地机器上深度使用 AI 了，这引发了一个思考：难道不应该一切都以云端优先吗？
Felix Rieseberg: 你理解得很到位。实际上你可以把规划这个概念先放一边。Cowork 中最有价值的部分是虚拟机。我们运行一个轻量级的虚拟机，并将 Claude Code 放入其中。这样做有很多原因，安全和保密是重中之重。但即使抛开这些不谈，给 AI 一台属于它自己的计算机也是极其强大的。在架构和交互设计中，将 AI 深度拟人化通常是很有用的。如果是一个真人为你工作，你会给他什么？
我今天早上给我也在用 AI 编程的父亲举了个例子。如果你是一名开发者，雇主却说不需要给你配电脑，只让你通过邮件接收和发送代码，那工作效率会极其低下。而在虚拟机环境下，因为它是一个 Linux 系统，Claude Code 拥有极大的自由度来安装所需的工具，比如 Python 或 Node.js。虽然我们有严格的网络访问控制，但用户可以用自然语言明确系统可以做什么。我们不再需要去咨询法务或市场部门，询问是否可以安装 Homebrew 这种琐事。
问题与答案的深层影响非常复杂且微妙，并不容易推导，这种复杂性给 AI 带来了很多干扰，但也让 Claude 变得非常强大。我们几乎每周都在增加新功能，你可能已经注意到，这些改进使得 Claude Cowork 在处理某些任务时比基础版 Claude 更为出色。实际上，大部分优化都体现在系统提示词中。这些优化的核心在于 AI 如何推导你的工作内容，以及我们如何在系统提示词中包含特定信息来提升效率。当然，这也离不开 Claude 与 Chrome 的深度集成。随着模型能力的提升，很多人在面对 MCP 连接器时感到无从下手。我不愿意翻遍几十个连接器去到处点击，结果发现有一半功能还无法正常使用。因此，Claude 与 Chrome 的结合非常高效，我们可以直接通过 Chrome 子智能体下达指令，它就会自动完成任务。
在开发 Claude Cowork 的第一周，我发现自己开始用它处理编码任务，虽然这并非它的初衷。我在内部工具中挑选那些容易修复的 Bug，过滤掉涉及内核损坏或操作系统的复杂问题。我告诉 Claude Cowork，去所有崩溃分析工具中找到可修复的 Bug，然后指派另一个 Claude 实例去修复它们。
swyx： 指派另一个 Claude 是指启动一个新实例吗？
Felix Rieseberg: 目前我的做法是让它通过 Claude Code 远程访问目标网站。这相当于一个循环，针对每个 Bug 生成带提示词的 Markdown 文件，并为每个文件启动一个 Claude 会话。虽然 Claude Code 本身有子智能体的概念，但我当时是采用远程任务的方式运行。这样我发完任务就能去开会，而远程端的工作会持续进行。
（关于云端优先的权衡）我认为硅谷整体低估了本地计算机的价值。为什么我们还在用 MacBook 而不是 iPad 或 Chromebook？ 因为 AI 作为助手，需要拥有和你一样的工具访问权限，否则它在处理复杂任务时会处处受限。我们可以采取两种路径，一种是逐一将工具移入云端，但我没耐心管理所有权限并保持更新。
另一种路径是全盘接收并上传你的所有工作内容到云端。如果点击一个按钮就能把整台电脑克隆到云端，我不确定用户是否真的想要。这在技术挑战之前，首先是认知挑战。在授权下，理论上我们可以读取你的 Chrome Cookie 并传到云端，这在技术上很简单，能让你在云端完成所有任务。但很多网站一旦检测到异地登录身份就会锁定账户，届时你可能需要带着护照去银行柜台解锁。尽管大家对 Agent 这个词已经听厌了，但在 AI Agent 的未来真正到来前，基础设施需要慢慢追赶。在此之前，提升效率最好的办法就是让 AI 贴近你的工作环境。
04
模型能力没有完全释放的原因是没能给 AI 提供足够的工具
从定性感觉上，Claude Cowork 的长程能力似乎比 Claude Code 更强。关于评估，你们是进行感性测试还是自动化的程序评估？此外，在失败模式中，有多少是由于模型智能限制，有多少是由于将智能投入工具的工程化水平导致的？
Felix Rieseberg: 我们会根据评估结果每周调整技巧。Claude Code 和 Claude Cowork 的评估用例完全不同。Claude Code 侧重编码任务，主要通过它在处理软件工程任务时的表现来衡量。而 Claude Cowork 更多针对金融或法律办公等知识工作。我个人的用例通常是管理私人事务，比如房贷规划或家庭财富管理。你感受到的差异其实源于我们对系统提示词的微调，以及我们通过工具赋予 AI 的引导方向。由于性能权衡客观存在，Claude Code 会更擅长代码，而 Claude Cowork 更擅长非编码任务。这种差距在未来几代模型中是否还会存在，目前还不确定。因为现在的这些超强优化，我不确定长期来看是否还有必要。
（关于长程任务的处理）实际上，用户倾向于交给 Claude Cowork 那些时间跨度更长、任务量更大的工作。当工作变长，目标就会变得模糊，所以我们要求 Claude Cowork 大量使用规划工具和询问工具。我们希望它先厘清用户真正想要什么，而不是埋头干四个小时最后交回一个错误的结果。
（关于评估流程）我们所谓的评估是分析整个对话记录，包括 AI 调用的所有工具，然后根据调整的参数来测量输出。这个流程贯穿在训练和开发中。如果把后训练与外围的脚手架（Scaffolding）分开看，Claude Cowork 更多存在于脚手架空间，但我们也针对它进行了训练。评估意味着分析在给定对话记录下的输出结果，包括文件输出和 Token 输出。
（关于模型能力与工具工程化）我一直在思考的是模型能力冗余问题。模型的实际能力往往远超用户的使用方式。部分原因是我们没能给 AI 提供足够的工具。但在构建脚手架时，我也会考虑这些复杂的脚手架在未来是否会消失。作为前沿实验室的工程师，我能更早洞察下一代模型的能力。
我在想，我们是应该投入大量精力去修补脚手架，还是应该尽可能赋予它更多能力，并在确保安全的前提下等待下一代模型发布。我目前更倾向于后者。很多公司在做非常专业的 AI 定制化应用，短期看很有效，但一旦模型的泛化能力进一步提升，这些过度引导的特定用例可能就不再有必要了。这种趋势在skills功能和 MCP 服务器的演变中已经初见端倪。比如 Barry 最初开发的skills原型，看起来和现在的 Claude Cowork 非常像。他最初是想为非开发者提供类似功能，最典型的用例是数据分析。团队发现与其为连接数据仓库构建自定义工具，不如直接告诉 AI 接口端点和 API 的样子，让它自己搞定。
随后 AI 将接管控制权。这就像是在抽象层级上又往上提升了一步。以前你必须明确指令 AI 这是一个 CLI 并要求其调用，或者提供一个符合 MCP 规范的 API 结构，现在你只需要定义终点。如果你想了解某些信息，只需在此发布需求，甚至可以直接发送 SQL 语句，这都能正常运行。这种模式非常有效，开发团队开始尝试只给大模型提供一个描述任务需求的 Markdown 文件。这套体系最终演变成了skills系统，我们意识到应该将其封装成产品，这套方案非常出色。
我想展示一下我使用 Claude Cowork 的方式。起初我并不信任它，但它直接帮我完成了从 Zoom 下载录音、重命名并上传至 YouTube 的繁琐流程，这简直取代了视频博主的工作。我甚至让它自主创建skills，将大任务拆分成子skills并由父级skills统一编排，现在我每周都会运行这些skills。人们上手的路径通常是先找繁琐任务替代，随着信任增加再扩大范围。你在 Cowork 上有做任何专属的特殊功能吗？
Felix Rieseberg: 看到这些应用场景非常有启发。skills系统最吸引人的一点在于其极低的门槛。任何人都能像发短消息一样创建一个skills，并且实现高度的个人定制化。这本质上是一个抽象层，我猜你在设置时一定给过它不少指导。这种模式非常优雅。
（关于自动化逻辑）这就像是在现实生活中玩《异星工厂》，你从微小的自动化环节切入，逐渐建立起一个庞大的自动化帝国，让生活变得越来越轻松。我个人最常用的skills是日历冲突管理。人们总是在最后一刻塞进来各种会议，处理起来很痛苦。虽然我还没把它正式发布成skills，但在自定义提示词里已经写明了规则。我设定了明确的优先级，比如 Dario 安排的会议绝对不能推掉。它会根据我关心的程度、工作时间偏好来自动协调日历。这种细微的体验最能让用户产生共鸣。
我们发布 Cowork 时，在 X 平台上最火的一个案例是清理桌面。你其实并不真的需要一个大模型来整理文件夹，但这种体验真的很聪明。没错，需要给它访问权限。很高兴你喜欢。我们是 Claude Cowork 团队的，如果你希望这些功能也出现在 Claude Code 里，尽管告诉我们。
05
视觉能力与 Computer Use 的进化
我现在还在尝试用它做数据分析和设计转代码，比如直接丢给它一个 Figma 文件。虽然我写代码习惯用终端里的 Claude Code，但 Cowork 的 Chrome 集成在网页开发和调试方面表现更出色。既然功能相通，为什么它不能同步我之前的 Claude Code 会话呢 ？另外，万物皆可视觉化是 Computer Use 的核心超能力，刚发布时我觉得它慢且不可靠，但短短一年间的进步确实惊人。
Felix Rieseberg: 我很想听听你对桌面版应用中内置 Code 功能的看法，虽然我和他们是同一个大团队，但我自己从不使用桌面版。我们的内置浏览器功能其实是为了给 AI 提供一双眼睛。当它能实时看到你的工作界面、调试 DOM 树时，效率会产生质的飞跃。这就是你在 Cowork 中体验到的强大功能。无论它是调用你的 Chrome 还是使用内置浏览器，核心逻辑是一样的。只要 AI 能看见它正在处理的对象，它就不再需要你反复去跑测试或运行 QA，因为它自己就能实时纠错。
（关于会话同步）问得好，目前还没实现，但我们正在努力。这就是 OpenAI 团队一直在做的那类集成工作。我们的思路是与其重新造一个浏览器，不如去集成那些已经足够优秀的既有工具。我们的目标不是取代你电脑里的应用程序，而是完美地融入你现有的工作流，创造一种全新的协作方式。我们希望在用户已经在用的地方提供服务，而不是强迫用户为了使用 AI 而切换浏览器。我只想为那些有一堆繁琐任务、希望通过 Claude 释放生产力的人构建工具。
（关于操作能力进化）初期它确实几乎不可用，但这一年来的提升非常显著。确实，直接编写执行脚本更具定制化特征，我们正在向架构上层演进。Computer Use 是一个极具潜力的领域。我不认为我们离“AI 高效操作你的个人电脑”还有多远，它将不再局限于操作一个虚拟的云端环境。
06
让skills成为跨 Agent 的核心资产
你怎么看skills的可移植性？比如我在其他工具里处理办公室访客登记的skills，目前没法直接在 Cowork 里用。我不希望记忆是通用的，但我希望skills能跨 AI Agent 使用。目前在 MCP 领域，人们也在尝试做网关或注册表，我不确定这是否能成为一门生意。
Felix Rieseberg: 对我来说，这又回到了最基础的原语。我们的skills本质上是基于文件的，而不是锁死在某个封闭平台里的私有格式。这种设计天生就具备极强的可移植性。这些skills作为容器格式的一部分，以前统称为插件。插件在 Claude Code 中的应用非常广泛，其采用统一的格式，用户可以方便地安装。在当前的 cowork 协作环境中，你只需简单地将整个 GitHub 仓库添加进去即可实现。
这种模式类似于skills市场或插件市场，是实现便携性的核心手段。我认为这个领域仍有巨大的增长潜力。目前的挑战在于如何提高用户对可编写skills的认知，并简化skills的分享流程。如果过于强调连接 GitHub 仓库等技术细节，往往会令普通的知识工作者感到困惑，因为这不符合通用办公场景的操作习惯。目前行业内尚未解决的一个关键问题是，如何界定skills中哪些部分是通用的便携组件，哪些部分是与个人强绑定的私有组件。
关于skills的结构化，可以尝试将公共skills与私人skills进行配对。最直接的实现方式是采用字符串插值（String Interpolation），自动填入用户名、电话或特定文件路径。虽然目前的方案还略显笨重，但未来必然会出现一种既能保留skills便携性，又极易上手的模式。skills本质上是基于 Markdown 的纯文本文件，理想的编写体验不应依赖繁琐的教程，而应像指导新员工订机票一样，通过自然语言描述流程，让 Claude 能够快速理解并执行。
（关于个性化订票场景）当然，我们需要将通用流程与个人偏好深度结合。以订机票为例，我不认为 AI 应该完全接管订票动作，因为这涉及复杂的个人选择。订机票是目前最常见的 Demo，但这其实并不是一个理想的展示场景。我更倾向于自己掌控订票过程。之所以人们反复提起这个例子，是因为它典型地包含了普适性与个性化两个维度。普适性体现在追求性价比，个性化则体现在对时间、座位和机场的偏好。如果能将这些需求整合进一种便携、兼容且易懂的skills格式中，将极具竞争力。
（关于skills云端同步）从数据存储的角度来看，现在的云端协作环境应该支持符号链接（Simlink），将用户的skills库无缝映射到所有的 AI Agent 框架中。我们在内部维护了一个名为 Valuable Tokens 的仓库，存放了所有的命令和子 Agent，并开发了相应的 TUI 工具来实现快速部署。目前的实现手段还比较原始，基本等同于文件复制。理想的体验应该是，每进入一个新环境，系统就能自动关联云端文件夹并同步所有skills。目前的现状是，如果更换 AI Agent，用户不得不手动寻找并复制这些分散的skills文件。这种寻找成本是目前最大的痛点。未来，个人的核心生产力资产将不再是产品本身，而是这些私有的skills库。毕竟产品是标准化的，真正的差异化在于用户如何通过这些配置文件来定制自己的工作流。
（关于行业未来趋势）我倾向于将 AI Agent 和大语言模型视为协同工作的伙伴。我在 Notion 工作时深知实现信息同步的难度。你所追求的实际上是让所有的 AI Agent 在用户的偏好、skills和执行方式上达成共识。未来可能会出现一种类似于skills版 Dropbox 的独立机构，作为权威的skills托管中心，将链接嵌入到各种产品中。尽管商业闭环尚不明确，但这确实是一个极具前景的方向。随着技术进步，很多传统业务模式正在瓦解。skills应该能够在个人生活与职业场景之间进行插值。虽然底层的逻辑架构是一致的，但具体的执行细节会有所不同。作为工程师，最有效的手段依然是符号链接。将 AI Agent 读取 Markdown 文件的过程视为一种链接行为，虽然当前有效，但我们需要更智能的方案。你可以直接向 cowork 描述需求，让它自动完成这些底层的配置工作。
07
垂直行业应用与劳动力市场冲击
现在正值报税季，我认为用 Claude 处理财务是一件大事。它现在已经支持原生输出 Excel 文件了，这是否意味着你们有专门的工程团队在负责垂直行业方向 ？另外，它通过视觉能力读取视频内容理解得越来越深，这种通过截图识别视频的逻辑虽然没有转录精准，但也足够好用了。
Felix Rieseberg: 我们非常看重垂直行业，因此设有专门的垂直行业团队和企业服务团队。这些工程师每天都在思考如何让 Cowork 在特定行业中发挥最大效能，如何让非技术人员更容易理解并接入 AI，从而获得与软件工程师同等的价值。软件工程师之所以能站在 AI 浪潮的最前沿，是因为我们已经习惯了各种像鲁布·戈德堡机械一样复杂的自动化嵌套系统，自动化本就是我们工作的一部分。Claude 作为模型，其能力与这些数据密集型行业的需求高度契合，因为在这些领域，处理海量数据的准确性至关重要。关于税务处理，我曾发推特提到 Claude 正在帮我报税，这确实不可思议。虽然推特受众可能并不想看我的纳税申报单，但那种体验确实很酷。
（关于视觉识别逻辑）它是具体怎么实现的？我很好奇。明白，它是截取屏幕截图，然后通过视觉能力进行识别。我们已经意识到了图像生成等功能的需求。对我来说，观察 Claude 的创造力以及它解决问题的独特方式是非常有趣的。
（关于劳动力市场冲击）关于行业冲击，目前存在明显的短期压力，即如何将 Token 转化为实际价值。在编码和企业搜索领域，所有的初创公司都在向技术栈的上层迁移。如果第一方平台如 cowork 已经覆盖了大部分工作流，那么单纯的搜索功能将失去议价能力。目前的价值洼地在于规划。AI Agent 的核心优势在于针对特定任务的规划能力和专用工具集。但随着模型能力的进化，这些功能正逐渐被集成到本地设备端。如果初创公司能稳定交付最终的任务结果，而不只是提供中间工具，那么它依然具备竞争优势。
Anthropic 非常关注 AI 对劳动力市场，尤其是初级岗位的冲击。当我们通过自动化消除那些冗余工作时，实际上也消灭了很多初级员工赖以成长的岗位。这是一个严肃的社会问题，我们需要思考如何为职场新人提供新的成长路径。一种可能的方案是创造模拟实战岗位。在软件工程领域，初级员工的成长往往是非线性的。我们可以利用 AI 模拟高密度的实战场景，将原本需要数月的项目经验压缩到一周内的速通训练中。一年内，员工就能积累传统模式下三年的经验。虽然这种模式在缺乏反馈闭环的领域较难落地，但在法律或量化金融领域具有极高的可行性，类似于 Jane Street 模拟器，在其中高强度训练三个月即可具备实战能力。
（关于教育模式对比）资深工程师在 AI 的助力下正变得更加高效，创造了更大的价值。以滑铁卢大学的毕业生为例，其核心竞争力在于强制性的实习制度。他们在毕业前就接触过真实的用户需求和生产环境，这与纯理论的大学教育有本质区别。德国的大学教育往往过于理论化，导致企业必须从头教起。滑铁卢大学的学生通过在大厂轮岗实习，在毕业时已经具备了极强的实战经验。随着初级岗位的缩减，这种实战化教育模型将成为未来的必然选择。年轻人的优势在于神经可塑性更高，偏见更少，更容易成为 AI 原生代。但问题在于，未来可能不需要那么多初级员工了。Anthropic 认为 AI 对市场的冲击将是巨大的，社会各界需要加强对这一议题的讨论。通过频繁发布工具，我们可以让公众在渐进式的起飞过程中逐步适应变化，而不是被技术爆发淘汰。
08
AI 变革已经发生，重点在于让 AI 接手更大规模的任务
刚才提到的清理桌面的计划任务完成了，它是按文件类型组织的，但我更希望它能按主题进行归类。目前我需要赋予它读取视频文件的skills，让它明白我的处理习惯。关于 AGI，有人预测是 10 年，有人觉得只要 1 年，你如何看待这个时间点？另外，我发现我已经可以让它去注册 Google Cloud 这种复杂操作了，这对我来说意味着实现了 AGI，在那之外还有什么？
Felix Rieseberg: 你可以直接跟进要求它那样做。你看，它的提案里确实已经包含了相关的建议。虽然你现在用的是 Opus 4.6，但我给用户的建议是：不必再纠结这些细节，直接告诉 AI 你的需求即可。AI 往往能找到实现路径，即便那个方法未必是你习惯或预想的方式。我非常好奇 Claude 最终会构思出什么样的方案。
关于 AGI 还有多少年能实现，大家可以各抒己见，有人预测是 10 年，有人觉得只要 1 年。我不确定自己倾向于哪个时间点，但最终这是否在四五年内发生可能并没那么重要。如果我们拥有一个性能合格的模型，那变革必然会发生，这是我们必须面对的课题。通过频繁发布工具，我们可以让公众在渐进式的起飞过程中逐步适应变化，而不是被突如其来的技术爆发所淘汰。大家都在期待那个大爆炸时刻，即 AI 的进化形成自我强化循环、 Scaling Law 驱动下的能力加速彻底垂直化的时刻。到那个阶段，竞争就会全面爆发，不再有缓慢追赶的余地，你会发现 Claude 在处理任何任务时都表现得异常出色。
（关于 AGI 后的场景）这基本上涉及到一种观念，你现在仍然必须告诉它去构建你的脚本，你仍然有所参与。虽然这看起来很神奇，但在我看来，这种参与还是太重了。我看到了太多的琐碎流程，我希望能把这些负担从用户身上卸下来。我会继续沿着技术栈向上突破，让你的生活越来越轻松。
（关于观察日常操作的建议）很有趣。在我的职业生涯中，我从不习惯提前预告还在开发中的功能，你应该打好基础并直接发布，然后再谈论它。但令我惊讶的是，你们刚才提到的很多点，在我们看来都是极其显而易见的方向。应该有人在做那些事情。如果你观察 Claude Code，我们将要发布的东西可能不会让你们感到意外。你会说，那显然是有价值的，显然我们正在推进。我们的功能越多地属于那一类，对我们就越好，因为那样我们就不会最终构建出那些过于专业化、难以驾驭的东西。避免过度专业化非常重要，这让你保持通用目的，意味着你没有把眼光局限在某个垂直领域。
09
虚拟机的技术底座与跨平台权衡
有人抱怨 Claude Cowork 创建的虚拟机体积太大，动辄 12 到 15 GB。此外，如果 AI 正在我的电脑上执行任务，我就没法同时使用它了，这里存在一个竞争条件。我想提一下，Felix 是真正的虚拟机专家，之前做过 JavaScript 运行 Windows 95 的项目。现在的虚拟机在开发中存在哪些性能权衡？特别是针对 Windows 平台的支持是如何实现的？
Felix Rieseberg: 这确实是个有趣的话题。在开发 Cowork 初期，我曾构思过让 Claude 拥有自己的独立光标。这听起来很酷，但实际操作中会遇到很多问题，因为无论是 Apple 还是 Microsoft，其操作系统的底层逻辑都是基于单一用户操作设计的。虽然应用层可以实现前后台并行，但在操作系统层面实现双重操作极其困难。我一直在思考 Claude 操作电脑的最佳形态：是为你准备一个独立的虚拟机环境供你偶尔查看，还是让它在你离开电脑时接管操作，亦或是完全在云端运行。这取决于你与电脑、与数据之间的亲密度。
（关于 Windows 95 项目）代码还在我的 GitHub 上，那是你个人主页上最吸睛的项目。那是个非常有趣的项目。我得澄清一下，我并没有编写 Windows 95 的底层系统，也没有编写那个能模拟 x86 处理器并在 JavaScript 中运行的 V86 引擎。那个项目源于公司内部关于 Electron 优缺点以及是否该用 JavaScript 构建软件的辩论。我想证明既然我能在 JavaScript 里跑通整个 Windows 95 甚至运行 Excel，而且速度还比很多 SaaS 应用快，那 JavaScript 的性能上限其实很高。我花了一个晚上就把它做出来了，主要是为了调侃 Slack 的同事。
（关于 Cowork 虚拟机的技术细节）那个虚拟机确实很酷，虽然在开发中存在很多性能权衡。很多人问为什么虚拟机占用了 10 GB 空间，其实那是 macOS 显示的问题，我们通过压缩镜像中的空白空间，实际占用的磁盘空间并没有那么多。但这属于技术细节，对用户来说，他们更在意的是 30 秒的启动时间。无论技术上如何解释，30 秒的体感启动时间确实太长了。无论采用哪种方式，性能都会比直接在本地运行 Claude Ultra 慢一些，这种权衡是客观存在的。
（关于 Windows 平台实现）在 Windows 平台上，我们利用了 Windows 主机计算系统 (Host Compute System, HCS)。这套系统也是 WSL2 的运行基石，很多开发者都非常认可这个子系统。它的精妙之处在于，我们需要明确划分虚拟机的运行空间，并严格控制通信权限，因为你赋予了这个虚拟机相当大的权力。我们不仅要优化两个系统之间的连接，还得确保其他随机应用无法干扰虚拟机内部 Claude。
上周我们开始编写一套全新的网络驱动服务，专门优化 Claude 访问互联网的方式。如果你的公司实施了深度包检测或在内网拆解 SSL 流量，那么简单版本的 Claude Code 很容易在用户电脑上崩溃。但我们现在的方案表现非常出色，能兼容绝大多数用户的环境。我常举的例子是，我希望这个工具在普通用户随手拿起的机器上都能高效运行。而那台机器很可能没有安装 Python 或 Node.js，如果缺少了这两项环境，从本地运行的角度看，Claude 的效能就会大打折扣。
在 Mac 上，我们利用了 Apple 虚拟化框架，它非常稳健且经过深度优化，调用 API 也非常简单。一旦你开始发布生产级别的代码，就必须不断处理各种边缘情况。但不得不说，Apple 在虚拟化框架上确实表现极其出色，既快速又可靠。Windows 也是如此，其主机计算系统和 WSL2 堪称系统中的瑰宝。它是极少数能让开发者一致好评的功能，接入同一个子系统让我们更有底气。无论你的电脑权限被锁得有多死，哪怕是雇主禁止你安装任何插件，我们都能正常运行。
（关于隔离的安全性）在很多办公环境中确实如此。即便在 Anthropic，IT 部门也会严格控制安装权限，这是很多公司的常态。这反而减轻了 IT 部门压力，因为我们可以将 Claude 的计算环境与用户的环境隔离开。对于 Claude 的运行环境，你可能会担心数据丢失、潜在的敌对行为者或数据外泄。一旦你控制了网络和文件系统层，你就不必再担心 Claude 编写的那些 Python 脚本了。真正让人担心的是，如果你直接在本地安装 Python，任何人都能在你的电脑上执行任何操作。而一旦放入虚拟机，这种风险就会大幅降低。
10
Claude Code 的未来是什么？
人们普遍存在审批疲劳，你不可能去核准每一条指令。沙箱化恰恰提供了某种中间地带。我想知道 Claude Code 的未来是什么？远程控制在 Claude Code 上能用了吗？
Felix Rieseberg: 是的。我认为 AI 行业有责任提出更好的方案，而不是简单地说只要它什么都不做就是安全的。如果你想让工具真正有用，却还得让用户步步审批，那就失去了意义。计算机使用功能就是一个典型例子。要在宿主机上实现绝对安全的计算机使用，唯一的办法就是让你批准每一个动作。比如 AI 模型说它想输入某个词，你觉得没问题，但这就不叫自动化了。你需要实现真正的委派，在授权后可以放心走开，并相信系统不会搞出大乱子。我们不必非要等到系统完美无缺或模型 100% 对齐后才行动。我们可以沿用行业内成熟的瑞士奶酪模型，通过多层防御来降低风险。但我们确实需要加大投入，构建那种无需事事审批的系统。
作为开发者，我们对风险的容忍度可能更高，但也带有一种自信，觉得如果真的出了大问题，我们也大概率能修补。不只是 Claude，简单的操作比如 npm install 也是如此。我们都在以全权用户身份运行它，如果它想读取 SSH 密钥，它完全能做到。默认环境竟然如此不安全，这挺疯狂的。最安全的方法是什么都不做，但我们想要的是强大的产品。在可能的范围内，我不想反复问你是否允许运行这个脚本，因为我相信，一旦它成为你工作流的一部分，你可能没有精力去逐行检查 Python 代码是否安全。
（关于 Claude Code 的未来）我们还处于起步阶段。我们会继续保持快速迭代，你可以期待每周都会有新功能发布。我会继续在本地电脑场景下加倍投入，让你和 Claude 在本地都能高效工作。我们开始更多地应对关于“你的电脑”的定义问题，它必须是摆在你面前的这台机器，还是你电脑上的虚拟机，或者是云端的某个环境？ 第三点让我兴奋的是，我们正在进行这种逐步爬升式的尝试，引导那些习惯于提问并获得答案的用户学会放手，让 Claude 接手越来越大的任务，无论在时间跨度还是任务规模上都是如此。
（关于远程控制）极好的问题。即将推出。如果你想继续押注在本地电脑上，那是一件显而易见的事。
11
未来的 AI 将通过人类工具或专用协议进行协作
为什么我们要在一个应用里封装一个完整版本的 Chromium？直接使用操作系统自带的 Web 视图难道不是更容易吗？此外，我看过 Tauri，你对它有什么看法？ 另外关于协作，如果我的 Claude 协作 AI，它的多人模式是什么样的？是 AI 之间构建通讯协议，还是直接让它们使用 Slack 等人类工具？ 最后想聊聊 Anthropic Labs。我一直把实验室分为模型实验室和 AI Agent 实验室。Claude Code 现在就属于这个内部的 AI Agent 实验室吗？
Felix Rieseberg: 答案是肯定的，那样确实更容易。事实上，我早年参与构建 Slack 应用时就尝试过这种方案。我在加入 Slack 时，他们已经有一个基于类似 PhoneGap 技术构建的应用，直接调用操作系统的 Web 视图。但那个方案因为各种原因失败了，于是团队决定动用更强大的技术手段，也就是加强对渲染栈的控制。选择嵌入式渲染引擎的原因在于，直到 2026 年这依然是真理：操作系统的原生渲染引擎做得还不够好。升级这些引擎的唯一途径是升级操作系统。
为什么要选 Chromium？尽管它体积巨大，但它是目前为止最出色的工具。像 Unreal Engine 这样顶级的引擎，如果要渲染文本，底层也会使用 Chromium。Chromium 是工程界的奇迹之一。它能动态渲染 YouTube 视频、协商比特率、处理极其糟糕的硬件驱动程序。你可以访问 Chrome 的 gpu 页面，你会发现密密麻麻的已启用补丁，全是针对你电脑硬件问题的变通方案。所有这些努力，只是为了确保当开发者要求在这里显示一个红色像素时，它能准确无误地发生。Chrome 之所以伟大，是因为它能极其可靠地运行在用户扔给它的任何机器上。Electron 的魔力就在于，它能让你轻松地以最符合业务场景的方式封装并调用 Chromium。
作为工程师，我们往往假设底层的平台层是极其稳定的。但当你真正和底层开发者交流时，他们会说其实我们也是在瞎猜。我在 Slack 工作时有个很深的感触：NVIDIA 是我们的客户。曾有一个 bug，Slack 里的 YouTube 视频会出现奇怪的伪影，最终发现那是 Chromium 的一个 bug。这种事在技术栈的每一层都在发生。
（关于 AI 重写原生应用）这听起来确实有可能，它会变得越来越强。我一直在等待一个 AGI 时刻：什么时候我们可以说不再需要 Electron 了？ 现在的 AI 模型已经非常有能力把 Electron 应用重写为 Swift 代码。但它们能否构建出性能更高、内存占用更少的超优化应用？这需要开发者长期积累的高度优化经验。我们还没到那一步，即使是最强的模型，也无法在处理这种极其复杂的任务时做到完全不出错。现在的 Ultra Think 推理模型在处理这类任务时还有压力，或者说，我们需要让它持续思考好几天。
（关于 AI 协作模式）这非常有趣。这又回到了脚手架的问题：我们是为了过渡而构建临时的协作框架，还是直接给这些 AI 分配 Gmail 账号和 Slack 账号，让它们像人类一样交流？ 我们的财务团队一直在尝试办公软件的集成。以前我们要在 Claude 周围构建很多技术让它在 Google Doc 里留言，而现在它能直接在文档里评论，这就是你与它互动的方式。我还在思考：最好的交互模式是为 AI 之间构建一套定制的通讯协议，还是直接让它们使用现成的人类工具？比如给它一个 Slack 账号，这样它就天然具备了多人协作能力。
而且让你两边的 AI 协作伙伴都能互相交谈。虽然这听起来可能有点令人不安，但技术上是有可能的。我们之前谈过skills转移，如果你的 AI 直接询问其他 AI 是否有处理这个任务的skills，那将非常强大。我们可以利用低功耗蓝牙技术，让电脑感知彼此的物理距离，从而判断大家是否在处理同一件事。
（关于 Anthropic Labs）其实团队成员的流动性很大。实验室团队主要研究那些尚未公开、非常前卫甚至看起来不太可能实现的想法，这就是所谓的疯狂科学。Claude Code 现在已经是一个相当大的团队了。但我们依然保留了一个独立的实验室团队，而且规模更大了。他们研究的东西极其超前，甚至很多是半成品。实验室的宗旨就是：只研究那些对普通团队来说完全没意义、但极具破坏性的想法。大家快去尝试协作模式吧，这是我今年感受到的最接近 AGI 的体验。
粤ICP备14082021号
免费POC，
零成本试错
