Dots: Always-on agents（Dots：常驻在线的智能体）

📅 2026-09-29 | 🏷️ 工程 & Agent | ⭐ HN 466分/353评论
🔗 原文：https://openai.com/index/introducing-dots/
💬 讨论：https://news.ycombinator.com/item?id=49896604

是什么

OpenAI 在官网发布新产品 Dots，核心卖点是「Always-on agents（常驻智能体）」：智能体不再是你发问才响应的一次性会话，而是持续在场、持续观察并主动推进任务的存在。发布当天即在 HN 引发 466 分、353 条评论的大规模讨论。

🔍 小白解读

先说几个词

• Agent（智能体）：能自己拆解任务、调用工具、连续干活的 AI，不只是回答问题。好比从「只会答话的客服」升级为「能替你跑腿办事的助理」。
• Always-on（常驻在线）：程序不随会话结束而停止，一直在后台运行、持续工作。打个比方：以前是「招手才停的出租车」，现在是「住在家里的全职保姆」——不用每次都重新交代家规。
• 主动触发：智能体自己判断时机发起行动或提醒，而不是等人下指令。类似从「你叫它才动」变成「它发现有事就动」。
• 会话（Session）：一次「你问 AI 答」的完整过程；常驻智能体的世界里，「会话」这个概念本身被弱化了。

这篇到底在说什么

到目前为止，绝大多数 AI 助手的工作方式像「点餐」：你打开窗口、下单、拿到结果、窗口关闭，下次再来一切从零开始。OpenAI 这次发布的 Dots 用标题讲清了方向——让智能体 Always-on，也就是让它长期「住」在你的工作环境里：任务不用一次性交代完，它可以分很多次慢慢做；有进展或异常时主动来找你；上下文也不必每次重述。HN 上 466 分、353 条评论的讨论热度说明，大家关心的不只是产品本身，而是这种形态背后的架构含义：计费按什么算？一直跑着的智能体会不会闯祸？权限怎么管？这些正是产品页面之外、工程师们真正焦虑的部分（具体功能细节以官方发布页为准）。

这跟普通人有什么关系

如果常驻智能体成为主流，普通人使用 AI 的方式会从「想到才问」变成「交代一次、长期跟进」：比如让它持续盯着某个项目进度、每天汇总邮件里的待办、发现异常主动提醒。对依赖 AI 工具的岗位，它更像是多了一位不用睡觉的实习助理——但同时也意味着你的工作习惯要适应「有个 AI 一直在场」的新状态。

为什么值得架构师关注

• 请求-响应假设被打破：现有 LLM 应用的计费、限流、并发模型几乎都建立在「请求-响应」之上；常驻智能体意味着长连接、持续 token 消耗与事件驱动架构，成本模型需要重做。
• 状态管理升级：一次性会话可以无状态横向扩容，常驻智能体必须维护长期记忆与任务状态，存储、故障恢复、幂等性都要重新设计。
• 权限与审计面扩大：持续在场的 agent 意味着持续持有凭证与工具权限，「最小权限 + 全程审计」从建议变成硬需求；这与本日 Nvidia 看门狗芯片、MCP 审计工具的新闻同属一条安全主线。
• 生态卡位：OpenAI 直接在产品层定义 agent 形态，自建 agent 平台的团队需要重新评估「自研 vs 接入」的边界。

核心内容

• OpenAI 官方发布页：openai.com/index/introducing-dots/，标题即定位「Dots: Always-on agents」。
• 核心概念为常驻智能体：区别于按需应答的一次性会话，强调持续在场、持续工作。
• 发布当天 HN 讨论 466 分/353 评论，评论数接近点赞数，争议与关注并存。
• 与同日发布的 GPT 6.1 Sol 同属 OpenAI 本窗口期的连续动作（见本刊另一篇报道）。

行动建议

• 有自建 agent 平台的团队：精读官方发布页与定价文档，重点测算「常驻模式」下的单位任务成本与传统请求-响应模式的差异，再决定是否接入。
• 做内部工具的团队：即使不接入 Dots，「常驻 agent」的交互范式（任务分期执行、主动汇报、异常上报）值得借鉴到现有工作流设计中。
• 安全团队：把「长期持有的 agent 凭证与权限」列入下一轮安全评审范围。
• 短期选型影响有限、以观察为主：细节与稳定性待更多一手实测后再评估，建议订阅官方 changelog 跟进。