Claude Duet 主动运行后，企业 Agent 需把四个治理边界写进 Runtime

Agent 从等你敲门变成主动巡逻：查应用、按间隔检查账户、发现事项就提醒，关掉应用也能在云端继续跑。难点因此从能不能调用工具，变成什么时候启动、凭什么授权、信息流向哪、中断后能不能安全继续。

过去的 Agent 很像一个“等你敲门的工具”：用户发出指令，它调用工具，任务结束后返回结果。Claude Duet 把模式往前推了一步，它会查看用户连接的应用，按设定间隔检查账户，生成晨间简报，发现需要处理的事项时再提醒用户；复杂任务即使用户关闭应用，也能在云端继续运行。

Anthropic 在 2026 年 10 月 21 日开放了 Claude Duet 研究预览，同时明确提醒，当前版本仍可能误读邮件线程或误判事项紧急程度。主动式 Agent 的难点因此不再只是“能不能调用工具”，而是“什么时候应该启动、启动前凭什么授权、信息能流向哪里、任务中断后能否安全继续”。

这四个问题，决定了企业是否真的能把主动式 Agent 放进日常流程。

第一条边界：主动触发必须单独治理

工具权限和触发策略不是一回事。前者回答“Agent 能不能读邮件、日历或账户”，后者回答“某次变化是否值得创建任务并提醒用户”。如果把两者混在一起，Agent 可能拥有读取权限，却在低价值事件上不断启动任务，消耗额度并制造噪音。

Duet 的公开运行方式是每隔数小时检查一次连接账户，而不是持续监控。检查越频繁，发现延迟可能越低，但套餐消耗也会更快；两次检查之间出现的紧急事项，则可能要等到下一轮才被发现。这不是产品缺陷清单，而是主动运行必然要面对的资源和时效权衡。

企业落地时，可以先为一类高价值事件定义清晰阈值，例如临近会议的时间冲突、即将到期的合同或异常账单，再观察四项指标：

指标	要回答的问题
发现延迟	事件发生后多久被 Agent 识别
漏报率	重要事件是否被跳过
无效提醒率	有多少提醒并不值得用户处理
单项消耗	一次检查和后续处理用了多少资源

同一事项连续更新时还要去重，否则一封邮件的多次修改可能触发多条提醒。主动性真正的第一步不是尽可能多地启动任务，而是让每次启动都有可解释的理由。

第二条边界：批准必须绑定执行时的上下文

Duet 的公开说明是：发送消息、付款、签署文件或删除内容前，会展示准备执行的动作并等待用户批准；证券交易、账户间转账、访问他人账户等操作，即使用户批准也属于禁止范围。

这说明系统至少区分了“需要确认”和“永远禁止”两类动作。但“执行前询问”本身并不能解决长任务授权的时效问题。批准只有在执行对象、内容和范围仍与批准时一致，才有资格继续执行。

举个典型例子：用户批准发送合同 V1，任务排队期间协作者把附件换成 V2。如果系统沿用旧批准，Agent 就可能发送未经确认的内容。这是 TOCTOU，也就是检查时和实际使用时之间状态发生变化的问题。

企业的审批记录至少应绑定：

操作对象和版本标识；
收件方、附件和关键字段摘要；
允许执行的动作范围；
失效条件和最终提交前的校验结果。

最终提交入口应该再次做确定性检查。对象、接收方、金额或附件发生关键变化，就暂停并展示差异；内容和对象都没有变化的低风险操作，则不必机械地反复弹窗。审批系统需要的是基于风险的失效策略，而不是一个对所有动作都生效的统一倒计时。

第三条边界：跨应用协作要限制信息流向

单次工具调用合法，并不代表组合后的信息外发合理。Duet 的公开资料称，它使用专门的分类器和安全系统提示词检查每条消息：信用卡号、政府身份证件等最严格类别的信息被设计为拒绝分享；健康或个人财务等其他敏感信息，则只有在用户明确指示发送时才放行。

这项披露针对的是消息内容的外发边界，不能直接扩展为完整的数据血缘追踪。企业还要同时判断四个维度：信息来自哪里、内容是什么、要发给谁、用于什么目的。

例如，Agent 可以获准读取客户邮件、汇总财务记录并向外部顾问发送报告，但这三项权限不能自动组合成任意共享客户信息的许可。更棘手的是，敏感性可能在摘要和聚合后发生变化：单条邮件不敏感，跨应用合并后却可能暴露客户身份或经营状况。

因此，输出检查不能只看原始消息，也要检查 Agent 生成的摘要、报告和表格等派生内容。比较稳妥的起步方式是先定义少量硬规则，例如客户明细只能进入内部报告，外部报告只能使用通过检查的汇总数据，并在审计日志中保留触发了哪条规则、拦截了哪一段内容。

第四条边界：技术恢复不等于业务可以继续

主动式 Agent 往往运行很久，用户可能关闭应用、断开设备，或者任务本身因为网络和工具故障中断。恢复执行位置与确认任务仍然可以继续，是两件不同的事。

Duet 的公开描述是运行在云端虚拟机中，用户离开设备后任务仍可继续。Claude Cowork 的 Dispatch 则是把手机发来的任务交给用户桌面执行，电脑需要保持唤醒且 Claude Desktop 保持打开。两者都支持用户不守在当前界面，但运行位置和本地环境依赖完全不同。

Anthropic 在 Managed Agents 工程文章中还公开过一种长周期 Agent 架构：把 Claude、Harness、Sandbox 和 Session 拆开。Session 记录运行事件，Harness 出现故障后可以启动新实例，读取事件日志并从最近事件恢复。这个工程实践不能直接当作 Duet 内部架构披露，却说明了一个重要原则：系统日志只记录“已经发生了什么”，不能代替外部业务系统回答“现在真实发生了什么”。

以批量处理发票为例，任务中断期间，人工可能已经完成部分付款。恢复时直接重放未确认步骤，可能造成重复提交；如果只相信本地“尚未成功”的标记，也无法排除请求已经被外部系统接受、但响应丢失的情况。

比较项	技术恢复	业务验证
确认对象	日志、执行位置、运行环境	任务目标、外部状态、授权条件
核心问题	从哪里接着运行	下一步是否仍有必要且被允许
核验依据	持久化事件与工具记录	外部查询、对象版本、操作回执
通过条件	历史可读、环境可重建	无重复副作用、关键条件仍成立
失败处理	重建环境或恢复实例	暂停核对、重新授权或重新规划

恢复后的提交入口应先查询外部结果，再决定是否重试。支持幂等键的接口要复用同一次业务操作的标识；结果不明时先核对；任务目标、关键对象或授权条件变化时，必须重新规划或请求确认。

企业 Runtime 该先改哪一层

主动式 Agent 不是在现有聊天机器人上多加一个定时器。它需要把触发策略、审批上下文、信息流控制和恢复验证纳入同一条执行链。对 Runtime 团队而言，最小可行的改造可以从一个跨应用任务开始：记录为什么启动、批准了什么、哪些信息可以外发、恢复后核对了哪个外部状态。

只要任一关键条件变化，任务就应该能够暂停、重新确认或安全结束。这样做的目标不是让 Agent 永远不出错，而是让每一次继续运行都有可解释、可审计、可撤销的依据。

Claude Code、Cowork 或其他 Agent 工具都可以作为执行层，但国内团队若需要通过 API 统一接入多种模型，可以了解 Code80(https://code.ai80.vip/home) 这类渠道。接入方式可以变化，授权、审计和恢复规则不能省略。

常见问题

主动式 Agent 和定时任务有什么区别？

定时任务按固定时间执行预设动作，主动式 Agent 还要理解变化、判断是否值得启动、选择工具并决定何时提醒用户。因此它需要独立的触发策略和风险评估。

为什么批准后还要在最终提交前重新检查？

因为任务排队、重试或等待期间，对象、附件、接收方和业务状态可能已经变化。最终检查用于防止旧批准被套用到新内容上。

只检查原始邮件，能防止敏感信息泄露吗？

不能。Agent 生成的摘要、报表和跨应用聚合结果可能比单条原文包含更多敏感信息，输出层和派生内容同样需要审计。

Agent 恢复执行时，为什么不能直接重放上一步？

因为外部系统可能已经完成了操作，只是回执没有返回。恢复流程应先查询真实业务状态，再依据幂等键决定是否重试。

企业接入 Claude 类 Agent，第一步该做什么？

先选一个低风险、可回滚的跨应用任务，建立触发原因、审批对象、外发规则和恢复核验的完整日志，再逐步扩大权限范围。国内团队也可以通过 Code80 接入模型，但治理规则仍需自行维护。

本文由人人都是产品经理作者【易安说AI】，微信公众号：【易安说AI】，原创/授权发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议