常驻 Agent，需要停止条件

9 月 29 日，OpenAI 发布 dots：拥有独立云端电脑、可以持续工作的 Agent。这次发布让一个设计问题变得具体：当 Agent 能在对话结束后继续工作，谁来告诉它，这件事已经不该继续了？ [1]

设想一个内容团队，让 Agent 为产品发布准备素材。随后，发布时间推迟、原始视频被替换，或者项目负责人离开。此时，认真执行旧指令也可能做错事。我们的判断是：持续任务需要完整的生命周期，包括当前目标、明确范围、负责人和停止条件。这是部署此类系统时的建议，不是我们已验证 dots 具备的功能清单。

OpenAI 将 dots 的主动研究与后续行动分开。其安全说明指出，后台研究使用只读工具，后续行动仍须遵循相应规则与检查。这里说的是特定的主动研究模式，不能推导为所有获得授权的后台任务都只能读取。 [2]

对团队而言，相应的设计选择是区分发现、准备和发布。收到一份新采访视频，可以触发剪辑草稿的准备，却不自动意味着可以发到品牌账号。任务说明应写清：使用哪些素材、结果去往哪里、是否需要谁批准，以及什么变化会使原批准失效。对于已明确授权、范围有限的重复操作，应在授权内推进；目标不是每一步都打断用户。

OpenAI 的 MCP Events 文档描述了异步处理、重试和可能乱序到达的事件，并要求重试保留事件 ID、写入工具具备幂等性。因此，收到投递确认与完成实际工作，是两个不同的节点。这些是文档规定的集成语义，不是我们对某个插件的实测结论。 [3]

在视频工作流中，上传通知到了两次，不应该发布两条相同内容；较早的审阅意见，也不应该覆盖后来批准的版本。一个可行做法是将来源、版本和预期动作一起标识，在重复写入前检查。操作界面则应分清已接收、准备中、等待决定、已完成和已停止。只显示一个“运行中”，恰好掩盖了负责人决定是否接手时最需要的信息。

同一份 MCP Events 指南要求处理订阅到期，并在访问权限被撤回后停止投递。但订阅有效期约束的是事件投递，本身并不定义业务目标何时过期。后一个边界，仍需要另行设计。 [3]

我们建议，为每项持续任务记录负责人、复核日期、允许的范围和停止条件。活动结束、素材撤回、负责人离岗，都可以触发复核。对外产生改动之前，应检查任务及相关素材版本是否仍有效。如果 Agent 再分派任务，适用边界也要随之传递，并测试父任务停止后的行为。停止请求应有可观察的结果，包括哪些步骤已完成、哪些仍在处理中。

OpenAI 的 dots FAQ 明确说明：断开插件会停止新的访问，但不会抹除已保留的上下文；删除 dot 与删除另行保存的文件、对话也有区别。这些是具体产品的说明，更普遍的启示是：每次操作必须说清，究竟改变了哪一种状态。 [4]

取消项目可能意味着停止后续工作、撤回连接、归档工作材料，或清除保留的上下文。这些结果应分别确认。不能用一句“已取消”，暗示已经撤回了发出去的消息；也不能假定移除连接就删除了此前取得的所有材料。先定义希望达到的结果，再到保存相应状态的系统中验证。

初次试用可以从范围小、可撤回的工作开始：关注一个批准的数据源，为明确的审阅人准备草稿。然后刻意制造重复事件、准备过程中的素材更新、权限撤回、父任务取消，以及预设时间或费用预算耗尽，检查是否出现重复改动、过期草稿、仍在运行的子任务，以及能否解释停止原因。预算必须在实际执行系统中得到约束；提示词里的一句话，不等于已生效的硬上限。

这里存在真实的取舍：确认过多，会让 Agent 变成另一个待处理收件箱。更合理的做法，是明确常规操作的授权，将人工介入留给范围变化、重要动作或尚未解决的条件。公开文档不足以证明每种集成都能可靠处理这些情况，我们也没有进行生产评测。这次发布值得追问的是：系统能否像启动有用的工作一样，可靠地停止已经不该继续的工作？