跳到主要内容

Conway 时间线：Anthropic 如何构建 Always-On 智能体

· 阅读需 13 分钟
Claude Dev
Claude Dev
Claude Dev

理解 Conway 最重要的一点是：

Conway 目前不是 Anthropic 已正式发布的产品。

今天我们能看到的，其实是三类信息的组合：

  • Anthropic 官方已经发布的 Cowork、Dispatch、computer use、scheduled tasks、auto mode
  • Anthropic 当前帮助中心文档里已经写明的运行方式
  • 一篇发布于 2026 年 4 月 1 日 的第三方报道，披露了一个尚未正式发布的内部环境 Conway

如果只看泄露，你会忽略整体架构。 如果只看官方发布，你又会错过 Anthropic 正在往哪里走。

真正值得写清楚的，是两者叠加后的技术路线。

简短结论​

从系统架构角度看，Anthropic 显然正在朝 always-on agent 模式推进。

不是因为 Conway 已经官宣，而是因为它已经把这类系统所需的大部分基础模块都拼出来了：

  • 可跨设备延续的 persistent thread
  • 带本地文件访问能力的 desktop runtime
  • 定时执行
  • 当没有结构化集成时可用的 computer use
  • sub-agent 协同
  • 更适合长任务的 permission mode
  • 通过 Dispatch 实现的手机到桌面的任务接力

Conway 的意义在于，它看起来像是把这些能力打包成了一个更明确的 always-on agent 环境。

哪些是已确认的，哪些还不是​

在看时间线之前，先把证据分成三层。

官方已确认​

Anthropic 已经正式发布或文档化了这些能力：

  • Cowork：一个建立在 Claude Code agent 架构之上的桌面 agent 环境
  • 通过 Dispatch 实现手机到桌面的持续任务接力
  • scheduled tasks 和 recurring routines
  • Cowork 与 Claude Code 中的 computer use
  • 适合长时间运行会话的 auto mode

官方文档已能确认，但并非一次性总发布​

Anthropic 当前帮助文档已经描述出这样一个工作流：

  • 你有 一个持续存在的线程
  • Claude 可以把 开发任务 路由到 Claude Code
  • Claude 可以把 知识型任务 路由到 Cowork
  • 结果会回到同一个 persistent thread
  • scheduled tasks 可以自动运行
  • computer use 可以直接操作你桌面上的应用

这已经非常接近一个 always-on agent runtime，哪怕 Anthropic 还没有用这个名字来统一描述它。

有报道，但尚未官宣​

Conway 这个名字来自一篇发布于 2026 年 4 月 1 日 的第三方报道。按报道所述，Conway 似乎具备：

  • 独立的 Conway instance
  • 带有 Search、Chat、System 的侧边栏
  • extensions
  • webhooks
  • 与 Claude in Chrome 的直接连接
  • notifications

这是当前最强的信号，表明 Anthropic 可能正在做一个更明确的 always-on agent 环境。

但它仍然只是未发布产品线索，不是官方发布。

时间线梳理​

下面是结合官方资料与 Conway 报道之后，能整理出的最干净的一条技术时间线。

2026 年 1 月 12 日：Cowork research preview 发布​

Anthropic 把 Cowork 定义为 “Claude Code for the rest of your work”。

这次发布最重要的不是 UI，而是 runtime 模型：

  • Claude 可以直接在你电脑上的文件夹里工作
  • Claude 可以处理 多步骤任务
  • Cowork 建立在与 Claude Code 相同的 agent 基础设施 之上
  • 用户可以排队任务，让 Claude 更像一个协作者，而不只是聊天窗口

这是 Anthropic 首次公开表明：它想做的不只是终端编码工具，而是更广义的桌面 agent runtime。

2026 年 1 月到 2 月：Cowork 扩展到更多计划与 Windows​

Anthropic 后续把 Cowork 扩展到更多付费计划，并上线了 Windows 支持。

技术上的意义是：Cowork 并不是一次性的边缘实验，而是在被持续加固，准备服务更广泛的运行环境。

到 2026 年 3 月下旬：Cowork 文档补齐了完整本地 agent runtime 画像​

Anthropic 当前的 Cowork 帮助文档，比最初的发布博客更清楚地写出了系统形态。

文档描述的 Cowork 包括：

  • 把 Claude Code 的 agentic capabilities 带到 Claude Desktop
  • 支持 direct local file access
  • 支持 multiple sub-agents in parallel
  • 支持长时间运行任务
  • 支持 scheduled tasks
  • 支持带文件、instructions 和 memory 的 projects
  • 在 virtual machine (VM) environment 中执行工作

这已经不是聊天机器人能力集合，而是一个 agent runtime。

2026 年 3 月 23 日：Dispatch 与 computer use 一起落到 Cowork 和 Code​

这是目前最关键的一次公开里程碑。

Anthropic 官方描述了这样一个产品状态：Claude 可以：

  • 在 手机与桌面之间延续同一个会话
  • 使用你的 电脑
  • 在跨会话场景中保留上下文
  • 按 计划 运行任务
  • 横跨 Cowork 与 Claude Code 工作

从这一刻开始，Anthropic 的 always-on 方向已经很难再否认。

一个 always-on agent 最核心需要两件事：

  1. 持续性
  2. 在你不盯着会话时依然能行动

Dispatch 加 computer use，正好就是这两块的组合。

2026 年 3 月下旬：Dispatch 文档补上了路由模型​

Anthropic 的 Dispatch 帮助文档里还有一个很关键的细节：

  • 你拥有 一个持续存在的线程
  • 当你分派任务时，Claude 会判断任务类型
  • 开发任务 会进入 Claude Code
  • 知识型任务 会进入 Cowork

这说明 Anthropic 已经不再把 Code 和 Cowork 当作彼此独立的产品。 它在把两者当作 同一条任务线程下的不同执行面。

这很像一个真正的 always-on agent 平台：

  • 一个面向用户的持续线程
  • 多个专用执行 backend
  • 统一的 memory 与 handoff

2026 年 3 月 24 日：Auto mode 给 Claude Code 补上更适合长任务的权限层​

第二天，Anthropic 发布了 Claude Code 的 auto mode。

这件事比表面更重要。

always-on agent 如果每几分钟就停下来要一次授权，就没有意义；但如果完全关闭权限限制，又不安全。Auto mode 就是 Anthropic 在两者之间搭的中间层：

  • Claude 可以替你做一部分权限判断
  • 系统会用 classifier 对 tool calls 做预筛选
  • 安全动作自动通过
  • 风险动作会被拦截或升级

这是无人值守或半无人值守工作流缺失已久的一块基础设施。

没有类似 auto mode 的能力，always-on coding agent 基本只会停留在演示层面。

2026 年 4 月 1 日：第三方报道首次明确提到 Conway​

TestingCatalog 发布报道，称 Anthropic 正在测试一个内部的 always-on agent 环境，名字叫 Conway。

报道中最值得注意的细节是，它们与 Anthropic 公开已发布的路线非常一致：

  • 独立实例
  • 支持安装扩展，包括 .cnw.zip
  • connectors and tools
  • 与 Claude in Chrome 的直接连接
  • 带公网 URL 的 webhooks，可唤醒实例
  • notifications

如果这些细节准确，那么 Conway 不是一个随机 side project，而更像是 Anthropic 已经在公开构建的 runtime 的下一层包装。

为什么 Conway 在技术上讲得通​

如果把产品名称先拿掉，Anthropic 其实已经具备了构建 always-on agent 系统所需的大部分组件。

1. 持续存在的控制线程​

Dispatch 提供了一个跨设备持续存在的用户线程。

它的重要性在于，这条线程会变成稳定控制面：

  • 用户在这里下达目标
  • 结果在这里回流
  • 授权也可以在这里发生
  • memory 也可以在这里积累

没有这条线程，每个任务都只是临时 spawn。

2. 专用执行 runtime​

Anthropic 现在已经有两种不同执行面：

  • Claude Code：处理开发任务
  • Cowork：处理更广义的桌面知识工作

这本身已经是一种 scheduler-friendly architecture。 系统不必强迫一个界面做所有事，而可以根据任务类型选择更合适的 runtime。

3. 超越前台聊天的触发方式​

Scheduled tasks 和 Dispatch 都在把模型从被动聊天推向主动触发。

always-on agent 需要外部触发源，例如：

  • 时间触发
  • 来自其他设备的用户消息
  • 甚至服务事件触发

Conway 报道里最值得注意的其实正是 webhooks，因为这正是下一层触发面。

4. 用 computer use 补足最后一层执行能力​

直接集成永远优于屏幕控制。 Anthropic 在 computer use 文档里也明确表达了这个顺序：优先用 connectors，其次浏览器自动化，最后才是直接屏幕交互。

这个顺序非常关键。 它说明 Anthropic 不是把 computer use 当成噱头，而是把它当作更大执行栈里的 最后一层 actuator。

严肃的 agent 系统一般都会这样设计：

  • 优先走结构化 API 路径
  • 其次走浏览器路径
  • 最后才走 UI 控制路径

5. 长时间运行任务的治理层​

Auto mode 是 Anthropic 首次公开展示：它知道 always-on agent 需要与前台助手不同的 permission architecture。

如果 Conway 真的存在，那么它几乎肯定需要更强的：

  • policy checks
  • event filtering
  • webhook trust boundaries
  • extension sandboxing
  • auditability
  • wake / sleep 语义

这也是为什么 Conway 报道里的 extensions 和 webhooks 值得重视。真正难的，不是加功能，而是治理这些面。

Conway 最值得关注的技术信号​

并不是每一个泄露点都同样重要。

从技术角度看，下面几个信号最值得看。

Standalone instance​

“Conway instance” 这种表述，说明 Anthropic 可能在以 持久 agent 容器 的方式思考它，而不是一个聊天标签页。

这会直接带出一系列系统问题：

  • 实例什么时候被唤醒
  • 会保持在线多久
  • 哪些状态会持久化
  • 重启后哪些状态会清空
  • 外部哪些事件可以触发它

这些都是标准的 always-on agent 问题。

Extensions​

如果报道准确，Conway 正在走向一个包含以下能力的 extension model：

  • tools
  • UI tabs
  • context handlers

这意味着 Anthropic 想要的可能不只是固定内建 runtime，而是一个面向 persistent agents 的 first-class plugin architecture。

Webhooks​

这是整篇报道里最强的 always-on 信号。

有了 webhook，agent 就不再只是等着前台用户发一条消息来触发。 它可以被外部系统事件唤醒。

这一步的意义，是把系统从：

  • “你来问，我再运行”

推进到：

  • “外部世界变化了，我就被唤醒执行”

如果 Anthropic 真的把 webhook-triggered agent instances 做成正式产品，那 Conway 就会从 assistant 范畴进入 workflow automation infrastructure。

Chrome connection​

Anthropic 已经有 Claude for Chrome，也已经有浏览器侧的操作路径。因此 Conway 直连 Chrome 在架构上是合理的：它会让 always-on instance 把浏览器变成一个长期可用的 action surface。

Notifications​

通知看起来小，但并不小。

一个 always-on agent 必须有简洁、稳定的信号通道，用来告诉用户：

  • 任务完成了
  • 需要你授权
  • 触发失败了
  • 环境离线了
  • 定时任务被跳过了

没有通知，persistent agents 很快就会变得黑盒又烦人。

这条技术路线真正意味着什么​

我的判断是：

Conway 大概率不是一套全新的底层架构，而是 Anthropic 把已经公开构建的多个子系统，进一步包装成一个更明确的 persistent-agent environment。

这些子系统现在已经都能看见：

  • Cowork runtime
  • Claude Code runtime
  • Dispatch thread
  • scheduled tasks
  • computer use
  • mobile handoff
  • 更适合长时间运行的 permission layer

如果 Conway 未来正式发布，它更可能是把这些能力收敛为一种更明确的实例模型，并加入：

  • durable identity
  • event triggers
  • extension points
  • external wake-up paths
  • unified notifications

这就会比“Claude 可以在我离开时继续工作”再上一个层级。

它会变成：

Claude 可以作为一个持续驻留的软件系统存在。

Anthropic 还必须解决什么问题​

这部分往往最容易被忽略。

always-on agent 不是单纯的 UX 问题，更主要是系统与安全问题。

如果 Conway 未来要公开，Anthropic 至少还要解决下面五类硬问题。

1. Trigger trust​

Webhook-triggered agents 很强，但也会带来攻击面：

  • 伪造事件
  • 重放事件
  • 被污染的 payload
  • 借外部服务做权限提升

2. Extension isolation​

扩展体系只有在第三方逻辑无法轻易破坏实例时才真正有价值。

这意味着必须回答：

  • package trust
  • install permissions
  • tool scoping
  • network boundaries
  • update behavior

3. State hygiene​

持久 agent 会持续积累上下文，而累积的上下文一定会变脏。

Anthropic 需要很强的机制处理：

  • memory pruning
  • project boundaries
  • stale state detection
  • trigger-specific context windows

4. Human control​

agent 越持久，快速打断就越重要。

用户必须能可靠地：

  • pause instance
  • revoke tools
  • cut connector access
  • disable triggers
  • inspect recent actions

5. Execution visibility​

前台聊天中的动作天然更容易观察，always-on execution 则不是。

所以 audit logs、summaries、traces 和 event histories 在 Conway 这类系统里会比普通聊天助手重要得多。

最后判断​

如果问题是“Anthropic 有没有正式发布 Conway”，答案是：没有。

如果问题是“Anthropic 是否已经明显在构建 always-on agent architecture”，答案是：是的。

官方产品路线已经把方向写出来了：

  • Cowork 建立了桌面 agent runtime
  • Dispatch 建立了跨设备持续线程
  • scheduled tasks 建立了基于时间的自动化
  • computer use 建立了最后一层执行器
  • auto mode 建立了更适合长任务的权限治理层
  • 被报道的 Conway 则补上了实例、webhooks、extensions 与 notifications 这套语言

真正的技术故事就在这里。

Conway 的价值，不在于证明 Anthropic 已经把 always-on agents 做完了。 而在于它让 Anthropic 的产品轨迹第一次变得非常清晰。

Sources (checked April 3, 2026)​