个人智能体正在从回答问题，转向持续推进一件事。Claude Duet 把 Agent 放进云端虚拟机和专属浏览器长期运行，定期巡查已连接的服务，发现问题主动提醒，涉及外部影响再把操作交回用户批准。它目前仍是研究预览，候补名单只对美国用户开放。

个人智能体正在从“回答一个问题”的聊天产品，转向“持续推进一件事”的执行系统。Grok Bot、Muse、Dots 相继出现后，Anthropic 推出 Claude Duet，给出的答案是：让 Agent 在云端虚拟机和专属浏览器中长期运行，定期巡查已连接的服务，发现问题后主动提醒，并在涉及外部影响时将操作交回给用户批准。

Claude Duet 的核心底座是 Claude Opus 5.5。目前它处于研究预览阶段，候补名单仅对美国地区 Pro 和 Max 用户开放，并提供独立 iOS、Android 客户端和网页端。产品能力、权限范围和开放节奏仍可能变化，不能把早期体验当作生产 SLA。

真正值得开发者关注的不是“AI 会不会自动干活”，而是它如何在长期任务中管理状态、连接器凭据、预算、外部副作用和用户授权。

Duet 试图解决的，是任务中断后的上下文问题

普通聊天式 Agent 的工作模式往往是同步的：用户提出需求，模型执行若干步骤，输出结果并结束。现实工作却很少一次完成。会议时间需要等参与者回复，未付账单需要隔天核对，客户邮件需要根据新信息再起草，数据看板也可能等到某个系统更新后才有意义。

Duet 的设计是把这种等待与继续执行放到云端。每天早晨，它汇总已绑定软件中的重要动态；工作时间每隔数小时巡查一次连接应用；遇到突发事项时主动发送提醒。用户不必保持手机或电脑开机，也不需要把每个任务的历史背景反复复制回对话框。

这类能力背后至少需要三份状态：

1. 任务状态：当前在等什么、已经完成什么、下一步要做什么。
2. 业务状态：日历、收件箱、账单、客户记录或项目文件的最新变化。
3. 授权状态：哪些动作可自动执行，哪些只能准备草稿，哪些必须等人确认。

如果缺少第三层，持续运行很容易演变成持续越权。真正可用的 Personal Agent 不仅要记住任务，还要记住每项任务的权限边界。

云端虚拟机和专属浏览器，解决的是执行连续性

Claude Duet 在后台运行一台带专属浏览器的虚拟机。用户通过文字或语音交代任务，Agent 在云端调用对应应用；完成后或遇到确认节点时再推送通知。

它会继承 Claude 中已有的记忆、技能和已连接应用，不必从头配置。为避免后台巡查迅速占满账号用量，用户可以设置多久接收一次报告、希望接收哪些内容。

云端执行有明显好处：任务不依赖本机是否在线，浏览器环境更容易隔离，连接器调用也可以统一在托管环境中审计。但它并不会自动解决安全问题。团队仍需确认：

• 云端浏览器保存哪些会话、Cookie 和登录状态；
• 任务完成、失败或长时间等待后如何通知与恢复；
• 多个连接器之间是否能横向读取数据；
• 用户撤销授权后，后台任务和缓存凭据是否立即失效；
• 能否导出操作日志、任务记录与最终产物。

没有这些能力的虚拟机，只是把本机自动化搬到另一台机器上；有了这些能力，才接近可治理的 Agent 运行时。

自主不等于任意执行：分级确认才是关键产品能力

Duet 可以自主阅读信息、起草内容、准备方案，但发送消息、付款、签署文件和删除数据之前，需要展示具体步骤，等待用户手动批准。即使获得同意，证券交易和跨账户转账等高风险行为仍被排除在外。

这是主动 Agent 最重要的边界：

低风险：读取、分类、总结、草拟

中风险：创建草稿、整理待办、准备表单

高风险：发送、支付、签署、删除

禁止项：高风险金融交易、跨账户资金转移

实际产品还需要将“确认”做得足够具体。一个好确认框不能只写“是否继续”，而应展示收件人、支付金额、商品或服务、数据字段、最终文件、操作范围和不可逆后果。让用户确认一个抽象动作，本质上仍是在让用户盲签。

6000 多个连接器，带来的是能力密度，也是攻击面密度

Claude Duet 通过官方市场中 6000 多个连接器接入工作软件。可见的使用场景涵盖 Gmail、Slack、QuickBooks、Stripe、Gusto、HubSpot、Canva、Shopify、LinkedIn 和 Docusign：它可以整理遗漏信息、起草邮件、核对账单、处理报销、管理客户跟进、制作宣传物料、搭建店铺页面和整理合同流转。

当 Agent 接入的系统从一个增加到几十个，风险不再只来自模型幻觉，还来自连接器的组合。一个看似无害的读取权限，可能通过其他工具成为数据外流入口；一封草拟邮件，可能在获得发送权限后影响客户关系；一个支付连接器，可能把“采购建议”变成真实消费。

因此，连接器治理应至少满足：

Agent 接入越多工具，越不能把权限当作一次性设置。权限应随任务、环境和风险等级动态收缩。

虚拟卡可以隐藏卡号，但不能替代支付策略

Duet 接入 Stripe Link 数字钱包和 Shop Pay。采购场景下，它可以使用虚拟卡结算，不直接暴露用户真实卡号；后续还计划通过 1Password 完成站点登录。

虚拟卡确实能降低真实卡号泄露风险，但不能自动消除支付风险。支付策略还必须包含额度、商家、类别、频次和异常行为控制。例如，办公耗材可以在固定供应商和月度预算内自动采购，第一次向陌生商家付款、超出单笔阈值、修改收货地址或购买订阅服务，则必须要求用户复核。

支付权限应遵循“能准备，未必能执行”的原则。Agent 可以完成比价、生成购物车、汇总税费和交付周期，但最终扣款是否发生，要取决于用户配置的规则与逐项确认。

从内部试用到企业任务，最关键的是结果可复查

早期使用案例展示了不同的节奏：有人散步时通过语音交代待办，晚上查看整理后的报告；有人用它安排访谈、做原型；小企业主用它统一检查财务、客服和营销；还有用户从早报中发现了日程错误，或收到客户电话与航班冲突的提醒。

这类例子体现了 Agent 的实际价值：不是替代某一项技能，而是减少碎片任务在不同系统之间跳转的成本。但企业落地不能只看“它省了多少个标签页”，还要看结果是否可复查。

一个可靠的长任务应保留：

1. 输入来源和读取时间；
2. 模型的中间判断与调用工具；
3. 需要人工确认的分叉点；
4. 最终修改、发送、支付或提交的完整记录；
5. 失败、重试和回滚的原因。

只有这样，用户才能在 Agent 做错时定位问题：是数据源错误、权限过宽、任务理解偏差、工具执行失败，还是确认规则没有覆盖特殊情况。

安全架构：模型不应直接看到原始密码和 Token

Duet 的安全设计强调专用安全分类器、系统提示词和凭据保护。信用卡号、政府身份证件等极高敏感信息会被直接拦截；健康记录和个人财务类信息则需要明确授权才能流转。外部操作还要通过自动化分类器审核。

一个值得借鉴的原则是：模型负责计划和推理，凭据代理负责认证和执行。模型不应该接触原始密码或登录 Token，而是向受控代理发出经过策略校验的操作请求。这样即使模型受到提示词注入影响，攻击者也难以直接获得可复用的长期凭据。

浏览器型 Agent 还要防范提示词注入。网页、邮件、文档中的第三方文本可能诱导 Agent 忽略用户目标、导出敏感数据或调用高风险工具。除了模型侧防护，还需要执行层验证：禁止网页内容改变系统指令，限制跨域数据读取，为敏感操作绑定显式授权，并在外部工具调用前再次检查参数。

研究预览阶段，先把成本和误判纳入设计

Duet 目前仍是研究预览。它可能误读上下文，也可能判断错事件紧急程度；工作场景是当前重点，订票等私人生活事务的表现相对有限。用户暂时也不能直接查看其虚拟机浏览器画面。

用量方面，后台巡查、财务模型、演示文稿和其他长流程任务都会消耗 Claude 账号共享额度。长期运行的 Agent 如果没有预算和频率控制，可能在用户不关注时持续消耗 Token。

建议将用量控制做成任务策略，而不是仅设置一个全局额度：

• 定期巡查任务限制检查频率、数据源数量和最大上下文；
• 深度分析任务设置预算上限、最长运行时间和检查点；
• 外部动作必须单独计数并保留通知；
• 失败重试需要退避、上限和人工介入条件；
• 任何定时任务都应支持暂停、查看历史与一键撤销授权。

在国内开发环境中，若需要用兼容 API 将 Claude Code 接入现有工作流，可通过 Code80 配置 endpoint。无论使用什么模型渠道，连接器权限、密钥隔离、预算限制和关键动作审批都应由项目侧负责。

常见问题

Claude Duet 已经对所有用户开放了吗？

没有。当前处于研究预览阶段，候补名单面向美国地区的 Pro 和 Max 用户，后续会分批开放。

Duet 在后台运行时，电脑必须保持开机吗？

不必。它使用云端虚拟机和专属浏览器执行已授权任务，因此手机或电脑关闭后任务仍可继续。但连接器权限、任务范围和通知规则需要事先配置。

Agent 可以直接付款、发消息和签合同吗？

它可以准备相关操作，但发送消息、付款、签署文件和删除数据都需要用户手动批准。证券交易和跨账户转账等高风险行为被排除在外。

虚拟卡是否意味着支付绝对安全？

不是。虚拟卡可以降低真实卡号暴露风险，但仍需设置金额上限、商家白名单、支付类别、频次限制和异常确认规则。

为什么 Agent 不能直接读取密码和登录 Token？

将原始凭据交给模型会显著扩大提示词注入和数据泄露风险。更合理的设计是由受控凭据代理完成认证，模型只能请求经过策略审核的具体动作。