OpenAI Dots深度解析：常驻智能体为何需要控制平面

从对话工具到常驻工作智能体

OpenAI Dots 的出现，标志着 ChatGPT 正在从一个响应式的对话工具，向一个能够长期运行、持续执行任务的工作智能体（work agent）转变。这是一次角色定位的根本性变化：过去我们向 ChatGPT 提问、它给出答案，交互随之结束；而现在，一个「always-on」的智能体会持续在后台运行、跟踪任务、执行多步骤操作。

对于开发者和企业用户来说，真正值得关注的问题并不是这个功能「看起来是否新奇」，而是一个更严肃的工程与安全命题：当一个 AI 智能体可以长期运行并代表你采取行动时，审批（approvals）、权限（permissions）和沙箱（sandboxes）究竟落在哪里？

常驻智能体带来的核心挑战

权限边界从哪里划定

一个只会回答问题的模型，它的「破坏半径」几乎为零——最坏的情况也不过是给出一个错误答案。但一个能够连续运行、调用工具、访问外部系统的智能体，其风险模型完全不同。它可能读取敏感数据、修改文件、发起 API 调用，甚至代表用户做出带有实际后果的决策。

这就要求一套清晰的权限体系：智能体能访问什么、不能访问什么，必须在架构层面被明确定义，而不是依赖模型「自觉」行事。原文一针见血地指出，关键在于「approvals, permissions, and sandboxes sit where」——这三者的落点，决定了整个系统的安全底座。

「破坏半径」（blast radius）是安全工程中用于量化故障或攻击影响范围的概念，最初来自爆炸物工程，后被引入云原生与零信任安全体系。在 IAM（身份与访问管理）设计中，最小权限原则（Principle of Least Privilege）的核心目标正是压缩任意单一实体的破坏半径：一个只能读取特定 S3 存储桶的服务账号，即便被攻陷，攻击者能造成的损失也严格受限于该账号的授权范围。对 AI 智能体而言，破坏半径的计算更为复杂，因为智能体往往需要跨系统、跨工具协作，其潜在的「操作链」可能将多个低权限动作组合成高危后果——例如读取日历信息、查询联系人、再自动发送邮件，每一步单独看都无害，链式执行却可能造成隐私泄露。这也是为什么单纯依赖事后的访问控制列表（ACL）不足以应对智能体场景，而需要在执行链路中插入运行时审批与意图验证机制。

审批环节不能缺席

常驻智能体的价值在于自动化，但完全无人监督的自动化恰恰是风险的来源。合理的设计应当在关键动作点插入审批机制：哪些操作可以自动执行，哪些必须经过人类确认。这本质上是在「效率」与「可控」之间寻找平衡——放得太开会失控，卡得太死则失去了智能体的意义。

为什么需要一个「控制平面」

原文标题给出了核心观点：常驻智能体需要一个控制平面（control plane）。这个概念借鉴自网络与云计算架构——数据平面负责实际的执行流量，而控制平面负责策略、路由、权限和管理。

把这一思路映射到 AI 智能体上，意味着我们不能只关注模型本身有多强，还必须构建一层独立于模型执行逻辑之上的治理层。这一层负责：

• 统一管理权限策略：定义智能体在不同场景下的访问范围；
• 执行审批流程：拦截高风险操作，交由人类或规则引擎裁决；
• 提供沙箱隔离：让智能体的行为被限制在受控环境中，避免对生产系统造成不可逆影响；
• 审计与可观测性：记录智能体的每一步动作，便于追溯和问责。

没有这样一个控制平面，「always-on」的智能体就像一个拥有钥匙却无人监督的员工——能力越强，潜在风险越大。

「控制平面」这一术语源于网络工程，最早用于区分路由器/交换机中两类不同性质的工作：数据平面（data plane）负责按既定规则高速转发数据包，控制平面（control plane）则负责计算路由策略、维护拓扑状态、下发转发表。两者物理或逻辑上的分离，是现代软件定义网络（SDN）的基础设计原则。在云计算语境中，这一思想被进一步延伸：Kubernetes 的 API Server、etcd 等组件构成控制平面，负责集群状态管理与调度决策；而实际跑在节点上的容器工作负载属于数据平面。控制平面的核心价值在于「关注点分离」——执行逻辑无需理解策略的来源，策略层也不必关心底层执行细节，二者通过标准接口解耦。将这一架构模式引入 AI 智能体领域，意味着模型的推理与工具调用能力（数据平面）应与权限管理、审批流程、审计记录（控制平面）严格分层，从而在不牺牲模型能力上限的前提下，为整个系统提供可独立演进、可独立审计的治理基础。

对开发者的实际意义

对于正在评估或集成此类智能体能力的开发者，OpenAI Dots 提出的问题值得提前思考。与其被功能的新鲜感吸引，不如把工程重心放在治理架构上：

第一，明确职责分层。将智能体的「执行能力」与「授权决策」解耦，不要让模型自身成为最终的权限裁定者。

第二，默认最小权限。任何常驻智能体都应从最小可用权限起步，按需授予，而非默认开放。

第三，把沙箱作为一等公民。在设计之初就为智能体划定隔离的运行环境，而不是事后打补丁。

这些原则并非 AI 独有，而是长期以来软件安全工程的基本功。Dots 的意义在于，它把这些老问题以一种更紧迫的方式重新摆到了台面上。

结语

OpenAI Dots 代表了 AI 助手演进的一个方向：从被动应答走向主动、长期地承担工作。但能力的跃迁必然伴随治理复杂度的上升。常驻智能体的成败，很大程度上不取决于模型能做多少事，而取决于我们能否为它建立起可靠的控制平面——让审批、权限和沙箱各就各位。谁先把治理层做扎实，谁才有资格谈规模化的智能体应用。