[控场AI]
· 5 分钟阅读· 2,707 字

OpenAI推出dots常驻智能体:ChatGPT要替你处理一切

OpenAI推出dots常驻智能体:ChatGPT要替你处理一切

OpenAI推出常驻智能体dots,主打「主动执行+关键审批」,试图将ChatGPT从问答工具升级为全天候数字管家。

OpenAI发布了名为「dots」的常驻智能体演示,宿主平台为ChatGPT。与传统聊天机器人的被动响应模式不同,dots定位为全天候主动执行任务的数字管家,能够在无需用户逐步指令的情况下自主推进网站上线、整理董事会材料、完成代码迁移、处理婚礼筹备等横跨工作与生活的复杂任务。其核心设计亮点是保留了明确的「人在环路」审批机制——低风险步骤由智能体自主处理,代码发布、日程改期等高风险操作则须用户确认。不过,目前公开的仅为官方演示视频,真实产品的可靠性、第三方系统集成方式以及持续在线所涉及的隐私边界,均有待独立验证。

从对话工具到常驻助理:dots想要什么

OpenAI放出的这段演示视频里,一个名为「dots」的常驻智能体(always-on agents)正式亮相,宿主平台仍是ChatGPT。它一开场就自报家门:「我是你的Dot,随时准备接手你手头的一切。」用户随口给它起了个名字叫「Alfred」——这个致敬蝙蝠侠管家的命名并非偶然,dots的定位就是一个全天候待命、主动推进任务、只在关键节点找你确认的数字管家。

这与我们熟悉的ChatGPT有本质区别。传统聊天机器人是被动响应式的——你问一句,它答一句。而dots呈现出的是持续在线、主动执行的工作模式:它会自己推进网站上线、更新董事会演示文稿、处理产品迁移,甚至在你没开口时就已经开始做事。视频中Alfred的一句话很有代表性:「我会保持事情推进,遇到需要你批准的重要事项时来找你。」

dots正在根据已批准的设计准备网站上线

演示里它到底做了哪些事

从这段演示的密度来看,OpenAI刻意展示了dots横跨工作与生活的能力边界。梳理一下Alfred在短短几分钟内处理的任务:

工作场景

  • 网站上线:根据用户已批准的设计准备秋季新品页面,用户口头要求「把第一张和第三张照片对调」后,它立即完成并发布。
  • 董事会材料:整理演示文稿,汇报了「营收同比增长51%」等数据,并在用户要求调整叙述顺序(先讲消费者体验、再讲增长数字)后重排内容。
  • 应用迁移:从Google Meet会议记录中提取任务,规划代码改动,重建后「测试未发现回归问题」,并把预览和结果放进PR,最后要求用户审批分阶段上线。
  • 团队协作:把结果同步到Slack,准备好上线流程等待批准。

用户要求它先逐条核对每个流程再提交审查

生活场景

  • 婚礼筹备:蛋糕供应商临时取消,dots已经找好备用方案,并直接排出「周六上午11点双方都有空」的试吃时间。
  • 孩子课程:在报名开放的第一时间抢到了孩子的课后课程名额。
  • 日程冲突处理:发现明天的财务评审与女儿的演出撞了时间,主动提出改期并开始准备会议笔记。

这种任务清单的呈现方式,透露出OpenAI对智能体的核心叙事:它不是某个垂直工具,而是要成为跨越所有生活维度的统一执行层。

更新后的网站展示秋季新品设计

「人在环路」的审批机制是关键设计

值得关注的是,演示里反复出现「批准」「审查」「等待我确认」这类措辞。dots并非完全放权自动执行,而是保留了明确的人类审批节点(human-in-the-loop)。

用户在应用迁移任务上明确指示:「先启动,但在我审查前,你必须逐条核对每个流程和当前产品的差异。」dots的回应是完成重建后主动交付PR、请求分阶段上线的批准,并承诺「任何变动都会标记出来」。这种设计回应了当前智能体落地的最大顾虑——当AI能自主写代码、发网站、改财务材料时,如何保证不失控。

把审批权保留在关键节点(发布、上线、改期),既让智能体能连续推进多步任务,又给了用户对高风险操作的最终控制权。这可能是这类常驻智能体能否被企业和个人真正信任的分水岭。

重建后的应用预览与测试结果

「人在环路」(Human-in-the-Loop,HITL)是AI系统设计中的一种核心安全范式,指在自动化流程的关键决策节点强制引入人类判断,而非让系统完全自主运行。这一概念最早来自控制论与自动化工程领域,近年随着大模型能力跃升而在AI落地讨论中被频繁提及。

HITL的设计难点在于如何划定「关键节点」的边界:介入过多会抵消自动化的效率收益,介入过少又会让用户失去对系统行为的感知和控制。dots的方案是按操作后果的不可逆程度来分级——推进草稿、整理材料这类低风险步骤由智能体自主完成,而代码上线、日程改期、正式发布等一旦执行便难以撤回的操作则必须等待用户明确批准。这种分级授权思路与当前企业级AI部署中的「渐进式信任」理念一致,也是监管机构在讨论AI问责框架时反复强调的设计要求。

一个值得冷静看待的演示

必须指出,目前公开的仅是OpenAI的官方演示视频,并非独立评测。视频呈现的是理想状态下的流畅体验:任务一次成功、时间自动匹配、代码零回归。真实产品能否达到这种可靠性,尤其是在处理代码迁移、财务数据、多方日程这类容错率极低的场景时,仍有待第三方验证。

演示中未披露的细节也不少:dots如何接入Slack、Google Meet、Teams等第三方系统?数据权限和隐私边界如何界定?「常驻在线」意味着它需要持续访问用户的邮箱、日历、代码库和通讯工具,这背后的授权与安全机制尚不明确。

从行业方向看,dots代表的是AI从「对话助手」向「自主执行代理」的又一次跃迁。它想解决的不是「回答问题」,而是「替你把事做完」。这个愿景足够诱人,但演示的光鲜与落地的复杂之间,还隔着不小的距离。

「常驻在线」(always-on)智能体在技术实现层面面临的挑战远比演示所呈现的复杂。要让智能体在后台持续感知用户的邮件、日历、代码库和即时通讯,需要建立长期的OAuth授权连接,并处理令牌刷新、权限撤销、跨平台API限速等一系列工程问题。更深层的挑战在于「上下文窗口的持久化」:当智能体需要记住数周前的决策背景时,如何在成本可控的前提下维护足够长的记忆链,目前业界尚无成熟的通用方案。

隐私层面,持续访问用户通讯工具意味着智能体会接触大量敏感数据——合同草稿、薪酬信息、个人医疗预约等内容可能同时出现在它的「视野」中。欧盟《通用数据保护条例》(GDPR)和美国各州隐私法对此类持续性数据访问有明确的知情同意与数据最小化要求,OpenAI如何在产品层面落地合规机制,将是监管机构重点审视的对象。

总结

dots把ChatGPT的角色从问答工具推向了全天候管家,用「主动执行+关键审批」的组合试图在自动化与可控性之间找到平衡。演示覆盖了从产品上线、代码迁移到婚礼筹备的广泛场景,展现了统一智能体的野心。不过,作为官方宣传物料,其真实可靠性、系统集成方式和隐私边界都还需要实际使用和独立测试来检验。

#dots#OpenAI#常驻智能体#always-on agents#ChatGPT#AI智能体#自主AI助手#人在环路
分享:

相关推荐