TanStack是广受欢迎的 TypeScript 库（如TanStack Query和TanStack Table）背后的团队，该团队最近发布了TanStack AI的 alpha 版本。这是一个与框架无关的 AI 工具包，旨在消除供应商锁定，让开发者完全掌控自己的 AI 技术栈。

TanStack AI 引入了跨多个 AI 供应商的统一接口、多语言服务器支持以及开放式协议架构。该 alpha 版本提供了对 JavaScript/TypeScript、React 和 Solid 的支持，并内置了OpenAI、Anthropic、Gemini和Ollama的适配器。此次发布代表了一种全新的 AI 工具理念，即将自身定位为中立于供应商的基础设施，而非平台服务。

TanStack AI 的突出特性之一就是其同构（isomorphic）工具系统，允许开发者通过toolDefinition()一次性地定义工具，并通过.server()或.client()方法提供特定环境的实现。这种架构在整个应用中提供类型安全性，同时支持工具在服务器和客户端上下文中执行。

工具模式有两种定义方式：推荐使用Zod Schemas，或者使用JSON Schema（适用于已有 JSON Schema 定义的项目）。该工具包还提供了模型粒度的类型安全性，使开发者能够针对每个模型获得完整的、针对特定供应商选项的类型提示。

客户端库包括原生 JavaScript、React 和 Solid，未来还将支持更多框架。alpha 版本还附带了同构的开发工具，可洞察大语言模型（LLM）在服务器端和客户端的行为，使开发者能使用熟悉的模式调试 AI 工作流。

该版本在开发者社区中获得了积极反响。开发者 Stanley Ulili 在 Better Stack 的一篇详细指南中这样写到：

虽然仍处于 alpha 阶段，但是它已经展现出了巨大的潜力。它注重清晰的架构、强大的 TypeScript 支持，并强调融入现有技术栈的自由，而非强制绑定特定框架或供应商。

在Reddit上，一些评论者对 SDK 的使用场景以及这个新库试图解决的问题提出了疑问，这促使 TanStack 生态系统的创始人 Tanner Linsley 作出了回应：

最近，我和 TanStack 的所有其他维护者都在深入探索 AI，我们发现 Vercel 的解决方案仍有足够的改进空间，因此决定自己打造一个更贴近我们产品原则的方案。

 

到目前为止，这带来了更好的类型安全性、更优的同构模式，坦白说，这也能够让我们自由地朝着自己想要的方向发展，而不必受制于其他团队。

 

竞争是好事，它能推动整体进步。

TanStack AI 将自己定位为 Vercel AI SDK 的直接替代品，后者目前是 JavaScript AI 工具领域的主导者。与 Vercel 的做法不同，TanStack AI 作为纯粹的开源基础设施，不包含服务层、不收取平台费用，也不存在供应商锁定。团队强调，开发者直接连接到自己选择的 AI 提供商，无需通过中间商。

由于这是新库的 alpha 版本，因此不存在从早期版本迁移的路径。开发者可通过 npm 安装核心包并开始使用：npm install @tanstack/ai @tanstack/ai-react @tanstack/ai-openai。快速入门指南提供了创建聊天应用的分步说明，而工具指南则深入讲解了同构的工具系统。

TanStack AI 是由 TanStack 团队开发和维护的开源项目。它延续了该团队在构建框架无关的开发者工具方面的良好声誉，目标是提供真正开放的工具，兼容任何技术栈，而非将开发者捆绑进专有的生态系统。

TanStack Releases Framework Agnostic AI Toolkit

今天凌晨，喜欢闷声做大事的 DeepSeek 再次发布重大技术成果，在其 GitHub 官方仓库开源了新论文与模块Engram，论文题为“Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models”，梁文锋再次出现在合著者名单中。

与传统的大模型架构相比，该方法提出了一种新的“查—算分离”机制，通过引入可扩展的查找记忆结构，在等参数、等算力条件下显著提升模型在知识调用、推理、代码、数学等任务上的表现。代码与论文全文均已开源。

论文地址：https://github.com/deepseek-ai/Engram/blob/main/Engram_paper.pdf

代码地址：https://github.com/deepseek-ai/Engram

这种查和算分离的 Engram 新方法的整体架构如下图所示：

为什么需要 Engram？

那么，我们为什么需要 Engram ？

目前主流的大语言模型架构依然基于 Transformer 和Mixture-of-Experts（MoE）结构。MoE 是目前推进参数规模和能力扩展的关键技术之一，通过动态路由机制，只激活部分参数以降低计算成本，同时在任务容量方面实现大规模扩展。DeepSeek 自家系列模型（如 DeepSeek V2、DeepSeek V3 等）也采用了先进的 MoE 方法进行扩展训练。

但在这些传统的 Transformer 架构（无论是 Dense 还是 MoE）中，模型的参数实际上承担着两种截然不同的角色：

事实性记忆（Memorization）：存储海量的知识事实。例如，“法国的首都是哪里？”、“世界最高的山脉是哪座”等。这类信息相对死板，更多依赖于“查表”式的检索。

逻辑推理与计算（Calculation）：负责复杂的逻辑链条、多步推理和情境理解。例如，“根据这段代码的逻辑推导可能的 Bug”、“解析一段复杂的哲学论证”。

目前的大语言模型倾向于将这两者混在一起。当你试图让模型记住更多知识时，你不得不增加参数量。而在传统的 Dense 模型中，参数量增加意味着前向传播时的计算量（FLOPs）也会同步激增。MoE 架构虽然通过稀疏激活解决了“算力随参数同步爆炸”的问题，但 DeepSeek 研究发现，MoE 专家在处理“死记硬背”的任务时依然不够高效。

神经网络本质上是连续的数学变换，用高昂的矩阵运算去模拟简单的“查表检索”，本身就是一种极大的浪费。DeepSeek 的 Engram 正是为了打破这一困境——“该查表的查表，该算的算”。

Engram 的核心思想与架构

聚焦到问题本身，Engram 方法为什么能解决上述问题？

“Engram”一词源自神经科学，意为“记忆痕迹”，它是一个可扩展、可查找的记忆模块，用于语言模型在推理过程中过去可能已经见过的模式或片段。

Engram 的核心技术之一是现代化的哈希 N-Gram 嵌入（Modernized Hashed N-gram Embeddings）。

• 传统方式：模型通过多层自注意力（Self-Attention）和 MLP 层的非线性变换，反复提取输入文本中的特征。

• Engram 方式：它对输入的 Token 序列进行 N-Gram（连续 N 个词）切片，并利用哈希算法将这些片段映射到一个巨大的、可学习的查找表（Lookup Table）中。

由于采用哈希索引，这种查找是确定性且 O(1) 时间复杂度的。这意味着无论模型存储了多少万亿个记忆片段，检索的速度几乎是恒定的，且算力消耗极低。

O (1) 的含义是： 一次查找的耗时是常数级的，与 N-gram 表的规模无关。

也就是说，这种设计本质上将一部分“记忆职责”从深度神经计算中卸载出来（例如序列模式、固定知识段的识别与回填），使得模型既拥有活跃神经通道（例如 Transformer + MoE）处理复杂计算，也有静态记忆通道高效处理固定模式，这就是所谓的“稀疏性的新轴”（a new axis of sparsity）。

简单来说就是 MoE 负责：“计算密集”神经推理与复杂组合功能、Engram 负责：“记忆查找”固定模式以及模式重建，两者协同构成一个更高效的整体架构。

此外，它还具备条件记忆（Conditional Memory）。与简单的静态查找表不同，Engram 是“条件化”的。它会根据当前上下文的隐向量（Hidden States）来决定提取哪些记忆。

在架构设计上，Engram 模块位于 Transformer 层的早期阶段。它负责“模式重构（Pattern Reconstruction）”，即在计算层（MoE 或 Dense）开始干活之前，先把相关的背景事实和历史模式检索出来，作为“素材”喂给后续的逻辑层。

它与 MoE（Mixture of Experts）的关系是怎样的？

论文特别指出：Engram 提供了一个新的稀疏性轴，与 MoE 的条件计算不同，它通过条件查找提供静态记忆容量。下面图表中从目标、计算方式、优化方向和作用位置四个维度解释了 Engram 和 MoE 的区别。

最后，DeepSeek 将 Engram 与 MoE 结合，形成了一个双系统：

• Engram 模块：负责海量知识点的“存储与快速检索”。

• MoE 专家：摆脱了沉重的记忆负担，全身心投入到“逻辑推理与合成”中。

这种分工极大地优化了参数效率。在 27B 的实验模型中，Engram 模块可以占用大量的参数用于记忆，但在实际推理时，它只消耗极少的计算量（FLOPs）。

网友：V4 将采用这种架构

在 Reddit、X 和其他平台的相关帖子中，Engram 的技术核心受到了不少用户的肯定和技术肯定。众多网友认为这个模块的特点在于让模型架构处理“记忆模式查找”和“神经计算推理”两块职责分离，从而开启了新的稀疏性方向。

在 Reddit 平台有用户评论说：

 “Engram 嵌入方法很有意思。大多数模型仅通过 MoE 进行扩展，但 Engram 增加了静态记忆作为补充的稀疏性轴，查找复杂度为 O(1)。他们发现 MoE 和 Engram 之间存在 U 形缩放规律，这指导着如何在两者之间分配容量。分析表明，这减轻了早期层级静态模式重建的压力，从而保留了用于复杂推理的深度。确定性寻址意味着它们可以将嵌入表卸载到主机内存中，而不会增加太多推理开销。”

同时，有用户对这种基于 n-gram lookup 的机制表达了直观兴趣，他评论道：

“即便是在不依赖 GPU 的环境下也能实现这种 O(1) 查找方式，让不少开发者对本地部署这样的大模型功能有了更实际的期待。”

在部分技术性评论中，有人指出：

即从已有技术逻辑来看，在 LLM 中加入静态记忆查找似乎是“顺理成章”的发展方向。

这类观点反映了一个重要观点：专家群体开始从纯参数扩张思维转向更“智能”的架构设计，包括查表式模块和神经网络的协同。

不少高级开发者在讨论中进一步提到，这种设计在理念上类似于对传统 NLP 技术（如 n-gram embedding）的现代化转换，结合了高效寻址机制（deterministic addressing）和神经推理模块，这种组合在纸面上看具有较高的可行性和实用性（这一点正是 Engram 的核心贡献）。 

另一条社区评论指出，Engram 很可能是DeepSeek 即将发布的 V4 模型的核心技术基础：

业内观察者认为 Engram 模块可能会成为 DeepSeek V4 的重要组成部分，并预示 DeepSeek 下一代模型会在记忆和推理协同上实现架构级提升。

在 X 平台，也有网友表达了同样的猜测，认为 V4 也将采用这种架构。

还有网友调侃，原本想抄袭下谷歌的技术，但现在要抄袭 DeepSeek 了，因为它比谷歌更好！

还有网友表示，其实 Meta 之前也有过类似想法，但用到的技术不同。

参考链接：

https://www.reddit.com/r/LocalLLaMA/comments/1qb034t/github_deepseekaiengram_conditional_memory_via/?utm_source=chatgpt.com

https://x.com/scaling01/status/2010748516788777445

https://github.com/deepseek-ai/Engram/blob/main/Engram_paper.pdf

程序员中的超级“保守派”、Linux 之父Linus Torvalds，现在也用起了 AI 编程。

图源：GitHub

最近，Linus 在 GitHub 上悄悄上传了一个小项目。项目本身不大，但特别的是，它是他用一款谷歌系 AI 编程助手 进行 Vibe Coding 完成的。

这个仓库很快就被眼尖的网友挖了出来，目前已经收获了 1600+ 颗 Star。

Linus 缔造的 Linux，与 Windows、macOS 一起，构成了当今计算世界的三大通用操作系统阵营之一。

不过他曾直言：“在过去将近 20 年里，我并没有从事编程工作。”这并不是他远离技术，而是早就从亲手写代码的人，转变成了为整个系统长期演进负责的人。

在这种角色下，这位老哥过去对“AI 帮你写代码”这套叙事，一直保持高度警惕甚至是嗤之以鼻——他关注重点的不是代码写得快不快，而是代码在多年之后是否还能被理解、维护和演进。

而现在，Linus 对 AI 编程的态度可谓是“大转弯”：不仅开始亲自尝试 Vibe Coding，还公开表示自己对这种方式“相当积极”。

这些事情的冲击力并不在于“AI 又进步了”，而在于连最不吃 AI 编程这一套的人，也开始松动了。

反 AI 编程的“顽固派”们，也开始接受 Vibe Coding 了

在生成式 AI 席卷软件行业的当下，有这么一群特殊的 “顽固派”， 他们定义了现代计算机的技术基石，却曾长期对 AI 编程嗤之以鼻，甚至公开泼冷水。

比如 Linux 之父 Linus Torvalds、Java 之父 James Gosling、Redis 之父 antirez（Salvatore Sanfilippo），个个都是编程界的殿堂级人物。

但有意思的是，随着 AI 工具能力的突飞猛进，这群昔日的 “反 AI 先锋”，正以各自的方式重新划定 AI 的边界：有人有限度拥抱，有人批判中认可，还有人干脆彻底转身。

比如 Linus 老哥，之前对生成式 AI 一直保持观望的态度。

他并不否认 AI 的潜力，但极度厌恶围绕 AI 的过度炒作。在一次开源峰会上，他直言当前关于生成式 AI 的讨论“90% 是行销炒作，只有 10% 是现实”，并毫不掩饰自己的反感。正因为讨厌炒作，他选择在相当长一段时间内 主动忽略 AI 热潮。

Linus 之前一直没有使用各种 AI 编程工具。不过，这并不代表他对新范式抱有敌意。相反，他对 Vibe Coding 总体持正面态度，只是并未急于亲自下场。

而现在，随着工具逐渐成熟、噪音开始下降，Linus 也终于对 Vibe Coding 上手了。

他用上了谷歌的智能体优先开发平台 Antigravity，靠 Vibe Coding 搞定了项目里的 Python 音频采样可视化工具。

从最初的 “搜索 + 照猫画虎”，到后来直接让 AI 写代码，甚至自定义组件，最终效果比他手写的还要好。

面对内核社区里 AI 生成补丁泛滥的争议，他的立场很清醒：问题不在于 AI 本身，而在于维护者是否真正理解代码、承担责任。在他眼里，AI 可以当帮手，但不能当甩手掌柜。

而 Redis 创始人 Salvatore Sanfilippo（网名：antirez） 的转变更具戏剧性。

这位以 “简洁、可预测” 为信仰的系统级程序员，曾固执地坚持一行行手写代码，对自动化工具保持高度警惕。

但最近，他公开抛出了一句颠覆自己过往理念的话：

“对于大多数项目而言，除非是为了娱乐，现在自己写代码已经不再明智了。”

让他改口的，是实打实的体验。

在使用 Claude Code 的过程中，他发现 AI 在极少人工干预的情况下，就能完成原本需要数周的系统级任务：修复 Redis 测试中的并发与时序问题、重写核心库、复现复杂的数据结构改动。

更夸张的是，他只提出需求，Claude Code 5 分钟就生成了一个 700 行的纯 C 库，用于 BERT 类嵌入模型推理，性能仅比 PyTorch 慢约 15%；而他耗时数周完成的 Redis Streams 内部改动，AI 根据设计文档，20 分钟便复刻完成。

他坦言，对抗浪潮没什么意义，不如主动拥抱：

“忽略人工智能对你或你的职业生涯都没有好处。花几周时间仔细研究，而不是五分钟浅尝辄止。”

但 antirez 强调，这不是编程乐趣的终结，而是转移：“真正有趣的事情，已经从‘如何写代码’，变成了‘要做什么、为什么这样做’。”

当然，这位技术极客也没丢掉警惕性。他担忧 AI 技术的集中化风险。少数公司掌握核心能力，可能引发程序员失业、技术权力失衡等问题。

相比前两位，Java 之父 James Gosling 的态度要尖锐得多。他多次炮轰，当前的 AI 热潮 “基本上是一场骗局”，AI 已经沦为“自带误导属性的营销术语”。

在他看来，生成式 AI 编程的本质，不过是对已有代码和模式的重组，根本谈不上真正的创造力。那些看起来惊艳的演示，一旦碰上复杂项目就露馅：“刚开始接触氛围编程，会觉得它特别酷炫。可一旦项目变得稍微复杂一点，氛围编程就会很快耗尽开发者的脑力。”

Gosling 的核心质疑点很明确：AI 只能复刻见过的代码，但专业软件开发的精髓，在于开拓性的创新 —— 这些内容从来不在现成的代码库里。

不过，他也没把话说死。他承认 AI 技术背后的数学与统计原理很复杂，也认可它的实用价值，不是取代程序员，而是 “生成没人愿意去写的文档”，或者解释现有代码的功能。说到底，AI 更像一个智能搜索引擎，而非编程大神。

他还不忘吐槽一把资本：“科技行业里骗子和炒作者的数量之多，令人难以置信。风险投资者只关心成功获利，而不是开发出真正有用的技术。” 他甚至预言，“绝大多数 AI 投资都会被烧个精光。”

说到底，这三位大佬的转变，都不是向 AI “投降”。

他们认可的，是 AI 在重复劳动上的效率；他们坚守的，是人类程序员不可替代的核心价值，对复杂系统的理解、对工程架构的判断、对长期维护的责任，以及开拓性的创新能力。

对 Linux 内核开发，Vibe Coding 还欠火候

需要说明的是，虽然 Linus 现在对 Vibe Coding 的态度很积极，但他也直言称，这种方式 并不适用于 Linux 内核开发。

一个重要原因在于，今天的计算机系统早已比他学习编程的年代复杂得多。Linus 曾回忆，当年他接触的一些输入程序，甚至是从计算机杂志上照着敲下来的。

虽然他已经很久没有深度参与具体功能编程，长期为整个内核的演进负责。在他的“系统维护者”视角下，稳定性、安全性和可维护性，远比“写得快不快”更重要。

这一点，其实在他最近上传到 GitHub 的那个项目里有所体现：AI 主要写的只是对 Python 可视化工具部分，核心 C 语言部分（音频效果的数字信号处理等）还是他亲自写的。

在 Linus 看来，Vibe Coding 在小项目和探索性场景中确实优势明显：进入门槛低、反馈速度快，能迅速把模糊的想法变成可运行的程序，用来生成样板代码、辅助脚本，或者“先跑起来看看”，都非常合适。

但这种方式的短板同样明显——生成代码往往风格不稳定、抽象边界模糊、依赖隐性假设，短期能用，长期却很难维护。

而 Linux 内核，恰恰是一个对“可维护性”极端苛刻的系统：代码需要被不同年代、不同背景的维护者反复阅读、修改和重构，任何一次“看起来省事”的生成式决策，都可能变成未来十年的技术债。

不过话说回来，即便不能“全靠 AI 写代码”，“部分交给 AI”本身，就已经在重塑程序员的工作方式。

在另一条时间线上，有些工程师甚至已经开始用 AI 来开发 AI 本身。

比如 Boris Cherny。作为 Anthropic 工程师、也是 Claude Code 的创造者，他已经几乎不再以传统方式写代码了，而是把自己打造的 AI 编程工具玩儿出了花：

他让 Claude Code 自己参与开发自己，然后竟在一年内完成了 1096 提交。

这个工具已成为全球最受欢迎的 AI 编程工具之一，去年还给 Boris 带来了超过 10 亿美元（约合人民币 70 亿元） 的收入。

参考链接：

https://github.com/torvalds/AudioNoise

https://www.theregister.com/2025/11/18/linus\_torvalds\_vibe\_coding/

https://antirez.com/news/158

https://www.bnext.com.tw/article/81200/linus-torvalds-gen-ai-bubble

https://x.com/bcherny/status/2009072293826453669

在开发者工具 Claude Code 推出之后，Anthropic 团队很快意识到一个出乎预料的现象：开发者并没有把它局限在“写代码”这件事上。相反，Claude Code 被迅速用于整理资料、撰写文档、生成报告、分析数据，甚至承担起类似“数字同事”的角色。

这种使用方式的外溢，最终促使 Anthropic 做出一个更激进的产品判断——如果大模型已经被当作工作伙伴使用，那么是否应该为“所有人”，而不仅仅是开发者，提供一种真正面向日常工作的智能协作形态？

于是今天，Anthropic 正式推出了 Cowork。

Anthropic 工程师、Claude Code 创建者 Boris Cherny 在 X 上发帖宣布了该消息。他写道：

自 Claude Code 发布以来，我们发现用户将其用于各种非编码工作：例如进行度假研究、制作幻灯片、清理电子邮件、取消订阅、从硬盘恢复婚礼照片、监测植物生长、控制烤箱等等。这些应用场景丰富多样，令人惊喜——原因在于底层 Claude Agent 是最佳代理，而 Opus 4.5 是最佳模型。

今天，我们非常激动地推出 Cowork，这是我们让 Claude Code 服务于所有非编码工作的第一步。该产品目前仍处于早期阶段，功能尚不完善，与 Claude Code 最初发布时的状态类似。Cowork 包含许多我们认为使其真正与众不同的创新用户体验和安全功能：内置虚拟机用于隔离、开箱即用的浏览器自动化支持、以及对所有非编码工作的支持。

据介绍，Cowork 是一款基于 Claude Code 底层架构构建的全新产品，目前以“研究预览版”的形式，率先面向 macOS 平台上的 Claude Max 订阅用户开放。与传统对话式 AI 不同，Cowork 的核心定位并非“聊天”，而是“协作”：它试图让 Claude 从一个被动响应指令的助手，转变为能够理解任务、制定计划、持续执行，并与用户保持协同关系的智能工作体。

从“对话助手”到“数字同事”

长期以来，大模型产品的主流交互形态仍然是对话。用户输入问题，模型生成回答；用户提出修改，模型再次响应。这种模式在信息查询、文本生成等场景下行之有效，但在真实工作流中却暴露出明显局限——上下文需要反复提供，文件需要人工整理，输出结果往往还要用户自行转换为可用格式。

Cowork 试图解决的，正是这一断裂问题。

在 Cowork 模式下，用户可以直接授予 Claude 对本地指定文件夹的访问权限。需要强调的是，这种访问并非“全盘授权”，而是由用户明确选择、逐一控制的结果。Claude 只能看到、读取、编辑或创建那些被允许的文件和目录，而无法触及任何未授权内容。

一旦获得权限，Claude 的能力边界就发生了质变。它不再只是基于文本上下文“想象”文件内容，而是可以直接操作真实存在的工作材料。例如，它可以扫描一个杂乱无章的下载文件夹，按照文件类型、时间或用途进行分类和重命名；可以从大量截图中提取关键信息，自动生成一份结构化的费用清单；也可以将零散的会议笔记、草稿和片段，整理成一份逻辑清晰的报告初稿。

这种能力的本质，并不是简单的“更聪明”，而是 Claude 被嵌入进了用户的实际工作环境之中。

Anthropic 在产品说明中多次强调，Cowork 的体验更接近“给同事布置任务”，而不是与机器人来回对话。一旦任务被下达，Claude 会自行拆解步骤、规划执行路径，并在执行过程中持续向用户同步进展。用户无需等待任务完成即可插入新的反馈或补充想法，这些指令会被自动排队、并行处理。

这也是 Cowork 与普通对话模式最根本的差异之一：它默认假设用户的工作是多线程的，而不是线性的。

当然，“更自主”的能力，意味着更高的风险。

让 AI 进入文件系统，甚至具备修改、创建和删除文件的能力，无疑是一种能力跃迁，同时也是风险跃迁。Anthropic 并未回避这一点，反而在产品介绍中反复提醒用户保持警惕。

首先是操作层面的风险。如果收到明确指令，Claude 确实可以执行具有破坏性的操作，例如删除本地文件或批量修改内容。一旦指令本身存在歧义，或者模型误解了用户意图，后果可能是不可逆的。

因此，在 Cowork 中，Claude 在执行任何“重要操作”之前，都会主动征求用户确认。这种设计并非形式上的“弹窗提示”，而是希望用户在关键节点重新审视任务目标，必要时进行纠正或细化指令。Anthropic 也明确建议，在涉及高风险操作时，用户应提供尽可能清晰、具体的指示，而不是依赖模糊的自然语言。

另一类更复杂、也更具行业共性的风险，是“提示注入”（Prompt Injection）。

在 Cowork 的工作过程中，Claude 可能会接触来自互联网的内容，例如网页、文档或第三方信息源。如果这些内容中被恶意嵌入了指令，试图诱导模型偏离原本的任务计划，就可能引发安全问题。Anthropic 表示，他们已经构建了针对提示注入的多层防御机制，但也坦言，“代理安全”——即确保 AI 在现实世界中执行操作时的可控性——仍然是整个行业正在积极探索的前沿问题。

从这个角度看，Cowork 并不是一个“已经完全成熟”的产品，而更像是一次对未来工作方式的现实实验。

Anthropic 也明确指出，这些风险并非 Cowork 独有，而是所有具备“行动能力”的 AI 工具都会面临的问题。只是对许多用户来说，Cowork 可能是第一次接触到一个超越简单对话、真正能够影响本地环境的 AI，因此更需要建立正确的使用习惯和风险意识。

研究预览版背后的产品逻辑

Cowork 目前被定义为“研究预览版”，这一定位本身就释放了明确信号：Anthropic 并不认为自己已经找到了最终形态，而是希望通过真实用户的使用反馈，加速产品迭代。

根据官方披露，Anthropic 计划在后续版本中引入多项重要改进。其中包括跨设备同步能力，使 Cowork 不再局限于单一终端；以及将其移植到 Windows 平台，从而覆盖更广泛的办公人群。同时，安全机制也将持续强化，尤其是在代理行为可解释性和可控性方面。

从产品路径上看，Cowork 与 Claude Code 之间存在清晰的继承关系。两者共享相同的底层架构，这意味着 Cowork 在能力上，理论上可以完成 Claude Code 已经证明可行的许多复杂任务。不同之处在于，Cowork 将这些能力重新封装为更偏向非技术用户的交互方式，降低了使用门槛。

如果说 Claude Code 面向的是“愿意为效率付出学习成本”的开发者群体，那么 Cowork 的目标人群显然更加广泛：内容创作者、产品经理、运营人员、行政人员，乃至任何需要与文件、资料和信息打交道的知识工作者。

在掌握 Cowork 的基本使用方式后，用户还可以进一步扩展 Claude 的能力边界。

首先是连接器。Claude 可以通过用户已有的连接器，访问外部信息源，从而将本地任务与外部数据打通。这使得 Cowork 不再只是一个“本地整理工具”，而是可以承担跨系统的信息整合角色。

其次是新增的一系列技能。这些技能专门用于提升 Claude 在创建文档、演示文稿以及其他常见办公文件时的表现，使其输出更加贴近真实工作场景的格式和标准。

此外，如果用户在 Chrome 浏览器中将 Cowork 与 Claude 配对使用，Claude 还可以完成需要访问浏览器的任务。这一步，实际上进一步模糊了“对话 AI”“自动化工具”和“数字员工”之间的界限。

从整体设计来看，Cowork 试图减少用户在“提供上下文”和“整理结果”上的认知负担。用户无需手动拼接背景信息，也无需将 Claude 的输出再加工成可用成果。更重要的是，用户不必为了等待 AI 完成某个任务而中断自己的工作节奏——任务可以被连续布置、并行执行。

Anthropic 在描述这种体验时，用了一个耐人寻味的比喻：这更像是给同事留言，而不是来回沟通。

用户：没有 Linux 版本，差评！

在 Cowork 发布之后，迅速在开发者社区、AI 产品圈以及更广泛的知识工作者群体中引发讨论。与以往单纯围绕模型能力、跑分或价格的争论不同，这一次的焦点明显转向了一个更现实的问题：“AI 是否真的开始成为一个可以被信任、被授权的工作参与者？”

在 Reddit 上的最新讨论串里，有用户评论指出他们“很期待尝试这个功能”，认为 Anthropic 近来在产品和用户信任构建上做得不错。

**因为仅限 macOS 和订阅计划，部分用户感到遗憾。**在另一个 Reddit 讨论串中，有用户对 Cowork 的平台限制表达了不满或遗憾，评论集中在“只支持 macOS”这一点上。

此外，值得注意的是，有些评论虽然不是专门针对 Cowork，但有一些用户还是对 Anthropic 近期产品策略与沟通的不满，对 Cowork 的发布背景和用户关系具有间接关联语境。

在 Reddit 平台，有长期用户表示，自己已经从忠实支持者变成对 Anthropic 的信任下降甚至不满。该用户指出：

“作为很早一批用户，我原本极力推荐 Claude，但最近几个月感觉 Anthropic 的产品质量沟通都变差了。”

参考链接：

https://claude.com/blog/cowork-research-preview

https://x.com/bcherny/status/2010809450844831752

https://www.reddit.com/r/singularity/comments/1qb6qv1/introducing_cowork_claude_claude/?utm_source=chatgpt.com