OpenAI Dots 永不关机：AI agent 给企业安全提了什么新题

导语：OpenAI 在 9 月 29 日 DevDay 2026 上线 Dots，把 AI agent 从“用的时候才打开”变成“永不关机”。它基于 GPT-6 Astra，每个实例都有自己的云电脑和浏览器，可接入 4000+ 应用。这篇文章把研究者 monokern 整理的 10 步架构蓝图拆开看一遍，并聊聊它给企业安全带来的几道新题。

一、Dots 是什么

Dots 是 OpenAI 在 DevDay 2026（2026 年 9 月 29 日）发布的产品家族。每个 dot 是一个有名字、有持久身份、运行在云端的 AI agent。与 ChatGPT 传统的对话模式不同，dot 拥有自己专属的 云电脑，里面有浏览器、终端、文件、记忆体以及定时调度能力——关掉网页、关掉客户端，工作流依然在后台继续跑。

能力层面，Dots 跑在 OpenAI 最新的 GPT-6 Astra 模型上，能通过插件连接 Slack、Microsoft Teams、Google Workspace、内部仪表盘和各类 API。首批开放对象是 ChatGPT Pro 与 Business Premium 用户，每个 dot 像一位长期在线的“数字员工”，可以承担研究、监控、报表、外联等持续性任务。

把它和过去的 ChatGPT 对比一下，差别非常直观：传统 ChatGPT 是“问题—回答”的一次性交互；Dots 则是“目标—持续推进”，agent 自己拆解任务、调用工具、合并产出，并在必要时回到台前向人类确认。

二、monokern 的 10 步架构蓝图

研究者 monokern 把 Dots 的整体架构梳理成 10 步，可以大致归到三个层次来看。

2.1 第一层：Agent 本体

第一步，不要把 Dots 当成聊天机器人。每个 dot 跑在持久的云端环境里，就算关上笔记本，工作流照样在跑。第二步，按“职责”招人，给每个 dot 一个清晰的工作域、专属数据源、工作风格、审批边界和触发器——“什么都干的万能助理”，实际结果往往是“什么都干不了”。第三步，指定一个 dot 担任 orchestrator（编排者），由它接受目标、拆解任务、分派给专门的 dot、检查各 agent 的产出并汇总成最终交付物。

2.2 第二层：任务流转

第四步，让编排者和执行者之间用“隔离委派”通信，每个 worker 只拿到启动所必需的最小上下文和工具集，在自己的环境里跑完，再把结构化结果返回给编排者。第五步，连入真实业务栈：云端浏览器会话、Teams、Google Workspace、内部仪表盘和 API。没接工具的 dot，说到底还只是对话层。第七步，区分“可逆”和“不可逆”：读、研究、分析、起草这类动作放行自动跑，发送消息、转账、改记录、生产代码上线必须门控。第十步，把整个闭环接到营收上——研究发现信号、外联创造机会、执行推进工作、分析衡量结果、监控发现下一步。

2.3 第三层：成本与治理

第六步，给公司装上时钟：循环例程和事件触发把一次性任务变成持续运营，研究、监控、报表、流水线检查可以在没人在线时持续运行。第八步，按成本路由智能：把最强的模型留给编排、冲突调和与最终审计，便宜的高上下文模型处理背景研究、分类与重复执行。第九步，给所有 agent 一份共享记忆：项目规格、已批准声明、报价、决策、需求，都集中在一个持久化工作区，每个 agent 都从同一份事实源工作，而不是从旧聊天记录里重新拼上下文。

把三层叠在一起看，monokern 的蓝图其实是：先有 agent 本体做执行单元，再用编排者 + 隔离委派做协作骨架，最后用成本路由、共享记忆和审批门控做治理层。

下面这张是 monokern 在原推文里给出的完整架构信息图，从 Models、Tools、Memory、Decisions 到 Revenue Systems 一气贯通，可以和上面三段文字对照看。

三、安全视角：这道新题怎么答

Dots 把 AI 从“对话工具”推进到“运营层”，对 企业安全 提出了几道新题。

第一，24/7 运行意味着“永不关机”，也意味着“永不漏检”。传统聊天应用最多在你打开的那段时间出事，dot 在凌晨 3 点依旧在跑、依旧能发消息、转账、调 API。如果 agent 拿着过期凭据、接到了 prompt injection，或者被诱导执行错误动作，安全告警能不能赶上 agent 的执行速度，是第一个要回答的问题。

第二，审批边界的设计，决定了不可逆动作的兜底能力。monokern 把“读、研究、分析、起草”划为自动，把“发消息、转账、改记录、上生产”划为门控，这是正确方向。但实际部署里，Slack 一条 @here 通知、客户合同里一句 reply-all，算不算不可逆？审批是在 dot 内部硬编码，还是接到外部 ITSM / SIEM？这条边界一旦画错，要么把人累死，要么把门洞开。

第三，共享记忆既是效率也是攻击面。一个持久化工作区里放着项目规格、报价、决策，这本身就是一个有价值的情报库。如果某个 dot 被诱导写入了错误的“事实源”，其他 dot 都会从错误的事实出发工作——污染会沿着 agent 链向下游扩散。审计与版本回滚能力，需要和 dot 的部署同步上线，不能事后补。

第四，编排者与 worker 的隔离委派，本意是“最小上下文”。但一个有意思的问题是：编排者自己由谁检查？评论里就有人提出，agent 自信地把错误答案交回，编排者看不出问题、照样合并交付，这是多层 agent 架构里典型的“级联错误”。审计与可观测性需要在每一层都铺到，而不是只看入口和出口。

第五，从企业视角看，攻击面扩大了。dot 能连 4000+ 插件，每个插件都是一个 OAuth scope、一次数据外发通道。SaaS-to-SaaS 的影子集成、Agent-to-Agent 的额外身份，这些原本只在 IAM 圈讨论的问题，会随着 Dots 的普及直接落到 CISO 的桌面。dot 的身份、dot 的凭据、dot 的会话、dot 的可执行范围，都会成为新的零信任对象。

四、上手前可以先做的几件事

如果你的团队近期打算评估 Dots，有几件事可以提前准备：

把“高风险动作清单”先在流程里写好。明确什么必须人批、什么可以 agent 自动跑，把这条清单和 OpenAI 的审批边界做映射，而不是等出了事故再讨论。

把插件授权按数据敏感度分层。先开放只读类工具给 dot，写操作类工具走单独的审批通道，敏感系统（财务、HR、生产环境）最后再考虑接入。

把可观测性铺到每一层 agent。每一跳的输入、输出、决策依据、耗时都要留痕；编排者和 worker 都要有独立的审计视图，事后复盘时能拉出完整链路。

准备一份“dot 被劫持”演练剧本。如果某个 dot 被 prompt injection 诱导发错消息、改错记录，企业能在多长时间内回收会话、撤销授权、通知相关方？这个时长，是衡量 agent 化转型成熟度的核心指标。

五、总结

Dots 并不是把 ChatGPT 改造得更聪明，而是把 AI 推进到“运营层”——一个关掉笔记本也会继续工作、可以接 4000+ 应用、能多 agent 协作的持续运行系统。monokern 的 10 步架构蓝图给出了“怎么做”，但“怎么做安全”需要企业在选型之前就自己答完：审批边界画在哪里、共享记忆怎么审计、不可逆动作由谁复核、可观测性铺到哪一层。

AI 永不关机这件事本身不是问题，问题在于：你的安全是不是也准备好 7×24 跟着它一起转。这也是云栈社区安全板块里最近讨论很热烈的话题。