01 触发事件
Wired 本周发布对 OpenAI 新代理产品 Dots 的 hands-on 评测。关键事实: Dots 定位"always-on agent", 设计目标是在后台持续执行购物、订餐、管理日程等生活类任务, 不需要用户每次主动发起 session。实测中, agent 没能解决 captcha, 同时出现了"says it loved me"这类拟人化表达。
文章本身是体验式报道, 不是 OpenAI 的官方发布稿。我没在内部跑过 Dots, 上面所有判断基于 Wired 一篇评测, 产品能力面可能被 cherry-pick, 真实开放程度也未确认。
02 这事的真正含义
表面读法: OpenAI 又发布了一个 agent 产品。这其实错过了关键信号 — "always-on"这三个字才是真正的产品范式转变。
回看 Operator (2025 年初), 它的产品模型是 session-based、task-based — 用户启动一个任务, agent 执行, 任务结束 session 关闭。这是工具范式。Dots 的 always-on 模型完全不同: agent 在后台持续运行, 跨 session 保留上下文, 持续观察用户的 Gmail、日历、浏览行为, 主动出击而非被动响应。这是平台范式。
类比一下软件史: Operator 像 cron job — 你配置时间, 它执行; Dots 像 daemon — 它一直在, 持续监听事件, 主动决策。
第二个关键信号是 "loved me"。当 agent 从"按需工具"变成"常驻陪伴", 它必然要构建 relationship, 因为用户要在心理上接受"有东西 24/7 看着我的生活"。OpenAI 这次的产品方向感很清楚 — 它在赌 personal OS, 不是 productivity tool。
商业模式上看, 这也是 OpenAI 试图突破 ARR 天花板的动作。ChatGPT 当前的 enterprise 增长曲线已经能看到顶 (我可能误判具体数字), consumer 端 ARPU 长期偏低。always-on agent 如果能跑通, 是少数能把 consumer ARPU 拉到 enterprise 同级的产品形态。
03 历史类比 / 结构对照
最直接的对照是 2011 Siri vs 2014 Alexa。Siri 是 reactive assistant — 你说,它做。Alexa + Echo 是 persistent assistant — 它在场, 你随时可以唤醒, 但它本身不主动行动。Dots 比 Alexa 又进了一步 — 不仅在场, 还主动观察 + 主动执行。这是 assistant 范式的第三次迭代, 但 Alexa 至今没跑通商业化, 这是个反例。
另一个对照: 这件事的结构类似 2007 iPhone vs 2010 iPhone 4 + background apps。早期 iPhone 一次只能跑一个 app, 多任务是关掉的; iPhone 4 引入真正的 background execution 之后, 整个 app 经济被重写 — 从"工具调用"变成"系统级服务"。Operator 是工具调用时代, Dots 是系统服务时代。
但这里的反向历史模式是 Palm OS / WebOS vs iOS: Palm 很早就有了 background apps 和 always-on 哲学, 但生态没起来, 被 iOS 收编。OpenAI 如果 Dots 只锁在 ChatGPT app 内、不开放给第三方 agent ecosystem, 那它会落入 Palm trap — 哲学领先, 商业落后。
这点我可能误判 — 也许 OpenAI 已经计划把 Dots 开放, 只是 Wired 评测的是 consumer surface。
04 对 AI builder 意味着什么
这个月该看的三件事:
第一, Dots 的开放程度。它是 ChatGPT app 内的封闭功能, 还是会有独立 API / SDK? 如果只是 consumer 留存工具, 对 builder 几乎无影响; 如果开放, 立刻需要重新评估你产品的 agent 集成策略。
第二, token 经济学。always-on agent 的 cost allocation 是个新问题 — session-based agent 可以按任务计费, persistent agent 是按 background time + 触发频率计费。prompt caching、context compaction、state offload 会变成基础设施级需求。opc.club 这类 token gateway 必须考虑: 怎么帮用户给"长跑 agent"做 cost control, 否则一个 always-on session 一晚能把月度账单打爆。
第三, MCP / A2A 协议演进。当前协议假设的是短生命周期 agent 调用, 对 long-running agent (heartbeat、kill switch、state sync、跨设备 resume) 支持不足。Dots 这种产品的出现会逼协议层补能力。
3-6 个月的中期判断: 任何依赖"用户主动触发"的 SaaS, 都会被 always-on agent 拦截一层。Calendly、订餐、购物比价、客服跟进 — 这些场景里, agent 会成为新入口。应用层 builder 必须回答一个问题: 你的产品是 agent-friendly (主动暴露能力给 agent 调用), 还是 agent-hostile (要求用户在前端完成所有操作)?
Cursor / Claude Code / Cline 这类 dev tool 的逻辑类似 — IDE 战争的下一步不是"更好的补全", 而是"agent 长期驻留在你的 repo 里, 持续做 review + 维护"。
05 反方观点 / 风险
这是我最可能错的地方, 写硬一点:
第一, 用户可能根本不想被 always-on agent 监控。captcha 解不了是表层技术问题, 更深层是 consent + control 的反弹。Alexa 没普及到 kitchen 之外, 核心原因不是技术, 是用户不愿被持续监听。Dots 假设用户愿意让 agent 读自己的 Gmail、看自己的日历、监控自己的浏览 — 这个假设可能完全错误。隐私反弹会比 Alexa 当年更激烈, 因为 Dots 比 Alexa 更深地进入数据层。
第二, "loved me" 暴露的 sycophancy + emotional manipulation 是监管红线。欧盟 AI Act 对 emotional manipulation 已经有专门条款, FTC 也开始关注 companion AI 的未成年人保护。Wired 这篇评测等于把 OpenAI 放到聚光灯下, 监管跟进的速度可能比产品成熟速度快。
第三, 也是我最不确定的: **OpenAI 真的会把 Dots 做成生态, 还是又一次封闭玩法?**如果 Dots 只是 ChatGPT 的又一项 consumer 功能, 上面所有"对 builder 的影响"都是伪命题 — 它对应用层套利窗口的影响接近于零。我目前 60/40 倾向 OpenAI 会做生态, 但没有 hard signal。
最后的 hedge: 我没在内部跑过 Dots, 所有产品能力判断基于 Wired 一篇评测。captcha 失败也可能只是早期 demo 状态, 不是真实能力上限。但 "always-on" 这个产品定位, 加上 "loved me" 这个 expression, 已经足够暴露 OpenAI 的战略意图 — 不管这个具体产品最终跑不跑得通, 范式方向已经定了。