Claude Duet将主动式Agent模式推进至新阶段，其核心在于规范企业Agent需明确四类边界：主动触发需单独治理、审批执行需绑定上下文、跨应用协作需限制信息流向、技术恢复需保障业务持续。从资源与时效权衡看，主动触发需通过阈值定义与四项指标评估，避免低价值事件消耗额度与制造噪音；从流程合规看，审批需绑定操作对象与版本、收件方及执行范围等上下文，通过最终提交复检防范状态变更风险；从数据安全看，跨应用协作需限制敏感信息外发，输出需覆盖原始与派生内容并进行多维度审计；从业务保障看，技术恢复需明确恢复位置与验证逻辑，通过跨外部状态核验避免重复操作或信息丢失。企业接入此类Agent，需将触发策略、审批上下文、信息流控制和恢复验证纳入统一执行链，从低风险跨应用任务切入，逐步完善可解释、可审计、可撤销的治理体系，方能真正落地主动式Agent的长期应用价值。
--91likeyou---
企业落地时，可以先为一类高价值事件定义清晰阈值，例如临近会议的时间冲突、即将到期的合同或异常账单，再观察四项指标：
指标 要回答的问题 发现延迟 事件发生后多久被 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 永远不出错，而是让每一次继续运行都有可解释、可审计、可撤销的依据。
常见问题
主动式 Agent 和定时任务有什么区别？
定时任务按固定时间执行预设动作，主动式 Agent 还要理解变化、判断是否值得启动、选择工具并决定何时提醒用户。因此它需要独立的触发策略和风险评估。
为什么批准后还要在最终提交前重新检查？
因为任务排队、重试或等待期间，对象、附件、接收方和业务状态可能已经变化。最终检查用于防止旧批准被套用到新内容上。
只检查原始邮件，能防止敏感信息泄露吗？
不能。Agent 生成的摘要、报表和跨应用聚合结果可能比单条原文包含更多敏感信息，输出层和派生内容同样需要审计。
Agent 恢复执行时，为什么不能直接重放上一步？
因为外部系统可能已经完成了操作，只是回执没有返回。恢复流程应先查询真实业务状态，再依据幂等键决定是否重试。
企业接入 Claude 类 Agent，第一步该做什么？
先选一个低风险、可回滚的跨应用任务，建立触发原因、审批对象、外发规则和恢复核验的完整日志，再逐步扩大权限范围。国内团队也可以通过 Code80 接入模型，但治理规则仍需自行维护。
题图来自 Unsplash，基于 CC0 协议
🔥 热词：#claude code一共有多少个agent · #claude 显然这里有一个更弱的agent工作过 · #Claude多agent协同框架 · #claude code算agent吗 · #claude code的agent的安全策略屏蔽 · #claude的agent有哪些 · #claude code agent 二次开发 · #claude的agent