OpenAI这次发布的常驻智能体Dots，初看名字像个小工具，细看产品形态却值得重视。它不再是那种“你发一句、它回一句”的聊天窗口，而是你可以把整个任务丢给它，它自己泡在云端执行多步骤流程，跑完才来跟你汇报。换句话说，AI交互的基本单位正在从“一轮对话”变成“一个任务的完整生命周期”。

这东西出来以后，我做Agent开发的朋友群里讨论最多的不是某个模型参数，而是“常驻”这两个字到底怎么落地。这篇文章就围绕常驻、云端、多步骤这三个关键词展开，拆一拆Dots背后的工程逻辑，也聊聊它对研发团队、产品经理和自动化工作流的实际影响。无论你是准备上手用，还是想理解这个产品方向为什么重要，应该都能从中看到点有价值的东西。

1. 常驻这个词，才是Dots真正的关键

1.1 从“AI问答”到“AI干活”的交互模型切换

回看过去两年大部分人的AI使用方式，核心还是“会话模型”。无论是网页端聊天，还是API调用，本质上都是：你输入一段Prompt，模型生成一段回复，交互结束。这种模型的优点显而易见，即时、轻量、门槛低；缺点也同样明显——它默认AI每次只能完成一个动作，做完就得等下一次指令。一旦任务需要几十步，人就不得不变成“提示词投喂员”，每一步都盯着，每一步都要重新组织上下文。

Dots这类常驻智能体的思路完全不一样。你把一个目标交给它，它自己拆分任务、安排步骤、调用工具、检查中间结果，遇到问题自己尝试解决，实在搞不定再回头问你。任务周期可能从几秒钟拉长到几小时甚至几天，在这个周期里你不需要持续在场。这个变化用一句话概括就是：AI从“计算器”变成了“执行者”。按一次出一个数的计算器，和接了任务就自己去完成的执行者，是两种完全不同的产品逻辑。

这个差别的分量，只有真正做过自动化的人才能体会。过去想让AI持续维护一个代码仓库，我得反复开几百次对话、手动把每次输出粘来粘去，再告诉它下一步做什么，本质上我依然是那个承担责任的操作员。而Dots这种模式一旦跑通，交互的单位就从“一轮对话”变成了“一个任务的完整生命周期”，我只需要在开头把目标描述清楚，剩下的推进、纠偏、收尾都由Agent持续跟进。

这里还藏着一个容易被忽略的产品细节：任务生命周期。Dots把任务当成一个可以长期存在、跨多次执行持续更新的对象，任务状态、上下文、中间产物都是持久化的，而不是一股脑塞进上下文窗口里。这恰恰是它区别于“用大模型反复对话”的根本工程差异——AI应用从“无状态”走向了“有状态”。

1.2 为什么常驻必须发生在云端，而不是本地

很多人会问：常驻就常驻，为什么非得在云端？我自己弄台电脑放着，让Agent跑在本地不行吗？

这个问题的答案，取决于你对“常驻”二字的理解。如果你只是希望Agent在某个固定时段帮你跑一批脚本，本地完全够用；但如果要的是“随时待命、持续在线”的效果，本地设备的物理边界就成了天花板。理论可行，实操却很脆弱，本地环境至少有三个绕不开的问题。

第一是进程生命周期。本地Agent进程跟操作系统和物理设备强耦合。合上笔记本盖子、系统休眠、断网、重启，进程说没就没。你不可能为了一个Agent任务，让电脑24小时开着不睡。云端天然为“7x24小时在线”设计，进程不绑定某台具体设备，可以经受住设备离线、网络抖动等各种意外。

第二是资源弹性。多步骤复杂任务在某个阶段可能突然需要大量算力，可能同时处理几百个文件，也可能要并行跑几十次测试。本地的算力固定，达到瓶颈就只能排队甚至卡死。云端可以按需扩容，任务结束后释放资源，这就让“长期在线”在成本上也说得过去了。

第三是权限与协作。常驻在云端的Agent可以拥有独立身份、独立凭证，不依赖任何个人的账号。团队成员能共同查看它的任务进度、执行日志和最终产出。这个“独立身份”对企业协作意义极大，它意味着Agent不再是某个人电脑里跑着的私人程序，而是一个团队共享的虚拟角色。

我常跟团队用这个类比：本地跑Agent，相当于雇了个员工，但只允许他待在自家客厅里干活，你出门他就只能停工；云端跑Agent，相当于给他办了工牌和工位，他可以在公司办公室独立运转、按节点汇报。哪种模式更接近“真正的同事”，不言自明。

1.3 从Codex CLI到Dots：一条完整的Agent演进线

把Dots放回OpenAI的Agent路线图里看，会发现它和之前的Codex CLI是同一脉络的产物。Codex是一个跑在命令行里的编码Agent，你在终端里给它一个任务，它能自己读代码、改代码、跑测试、提PR。Codex用实际运行证明了一件事：让AI自己动手写代码，不是概念，而是可交付的能力。

但Codex形态有个天然边界：它活在命令行会话里，一旦会话关闭，它的“工作状态”就随之消散。Dots补的正是这一环，把Agent从短期会话中解放出来，让它常驻后台、跨会话持续运行。如果说Codex像一个坐在你终端里、你随时可以开口问的程序员，那Dots更像一个拥有独立工位、按任务单干活的驻场工程师，工作节奏不再被你的会话打断。

从产品演进看，这条线特别清晰：先通过Codex这类工具解决“AI会做”，再通过Function Calling和MCP这类工具协议解决“AI会用工具”，最后通过Dots解决“AI能持续做”。三层能力叠在一起，才构成完整意义的常驻智能体。Dots不是凭空冒出来的单品，它是Agent从“会话式助手”走向“作业系统”的关键一步。

2. “持续工作”是怎么被工程化的

2.1 任务队列与断点续跑：常驻的基础设施

要让一个Agent真正“持续工作”，最先要回答的工程问题是：任务中途断了怎么办？跑着跑着API超时怎么办？某个步骤连续失败，是重试还是放弃还是绕路？

这些问题单看都不复杂，组合起来就是一套任务调度系统的全部关键。我推测Dots的云端底层至少包括三层：任务队列、执行引擎、状态存储。你下发的任务进入队列，执行引擎从队列中取出任务、拆解步骤、逐项执行，执行结果和中间状态写回状态存储。任意一步失败，引擎都能依据已保存的状态决定重试、跳过还是回滚。

这个过程很像现代下载工具的“断点续传”。传到一半断了，重新连上不是从头开始，而是接着已下载的部分继续。常驻Agent同理，它每完成一个步骤，就把该步骤结果和下一步计划持久化下来。这样不管进程怎么重启、网络怎么波动，任务都能从断点继续推进，而不是原地返工。

我特意写这一段，是因为太多Agent项目都死在同一个地方：Demo里跑得行云流水，一到真实环境就翻车，根因几乎都是没有任务持久化和断点恢复。一次偶发的网络抖动，就能让长任务前功尽弃。Dots敢把“持续工作”当核心卖点，说明任务调度这部分是有真实工程投入的。如果你打算自建一套类似的常驻Agent，我的建议也是先从这层基础设施做起，而不是急着调Prompt——任务调度稳定了，长任务才有资格谈效果。

2.2 权限边界与沙箱隔离：常驻Agent的安全底线

一个能自主执行多步骤任务的Agent，在云端必然握有一定权限。它能读文件、写文件、调API、访问数据库，甚至操作代码仓库。权限越大，风险越大。一个不受管控的常驻Agent，和一名不受管理的内部人员没什么两样。

所以Dots这类产品安全设计必须要覆盖三件事：最小权限、沙箱隔离、操作审计。

如果你是自建常驻Agent，我建议把这三条当硬约束，不是可选项。尤其是操作审计。Agent自主性越高，审计就越是刚需。这不仅是技术问题，更是信任问题：一个每天都在自主干活的主体，只有行为能被完整记录和回溯，团队才敢把更多任务交给它。

行业层面，OWASP已经发布了专门针对智能体应用的安全风险清单，里面列出的“过度授权”“不安全的插件机制”“Agent身份认证缺失”等问题，在常驻Agent场景下会格外突出。动手做相关功能之前，建议先把这些风险清单过一遍，能少踩很多坑。

2.3 状态管理：不只是“上下文变长”

多步骤复杂任务的另一个硬骨头是状态管理。任务走到后半程，经常需要前面的中间结果。是不是把之前的对话历史一股脑塞给模型就行？

远不够。上下文窗口再长也有上限，而且海量中间信息全塞进去会导致“注意力稀释”——关键信息容易被淹没，模型容易在无关细节上空转。工业级的做法是维护独立的状态层：任务目标、当前阶段、已完成步骤的输出、待办优先级、关键决策记录，都作为结构化数据单独存储。模型执行每一步时，从状态层按需读取信息，而不是对着干巴巴的历史文本盲猜。

这有点像Web开发里的Session机制。客户端不会把每次请求的全部历史都重放给服务器，而是服务器自己维护会话状态，按需读取。状态外置，长周期系统才能保持稳定高效。Dots这类常驻Agent成熟的标志之一，就是状态层设计得足够扎实——用户随时能看清“任务到了哪一步”“这一步在干什么”，而不是面对一个“正在执行中”的黑盒干等。

我判断Agent产品是否靠谱有个实用标准：任务进度是否可理解。只告诉你“正在执行中”，说明状态管理多半没做好；能明确告诉你“已完成第3步/共8步，正在调用xx工具，上一步生成了xx文件”，背后一定有一套完善的状态机制。这个标准，大家拿到Dots之后可以第一时间验证。

3. 多步骤复杂任务：Dots能接住什么活

3.1 任务拆解：从“目标”到“步骤清单”

“多步骤复杂任务”的关键词是复杂，而复杂任务的第一道门槛，就是把目标拆成可执行的步骤清单。人类接到“优化官网转化率”这种任务，会先想：分析数据、定位瓶颈、提出方案、执行改动、验证效果。Agent也必须具备同样的拆解能力，否则多步骤就是一句空口号。

理想状态下，Dots接到一个任务后要做三件事：目标分解、依赖排序、执行调度。目标分解把大任务拆成若干子任务；依赖排序确定哪些必须先做、哪些可以并行；执行调度在具体子任务上分配资源、选择合适工具。

这里最容易踩的坑是依赖关系判断。有些任务看起来能并行，实际存在隐性依赖；有些看起来必须串行，内部却藏着一批可并行的子任务。Agent如果缺少这种推理能力，要么把任务排成低效的串行队列，要么因为执行顺序错乱导致中间结果不可用。这也是为什么“支持多步骤复杂任务”绝不只是“多几轮工具调用”而已，它背后考验的是Agent的规划能力。

3.2 典型场景：常驻Agent真正能落地的方向

结合Dots“云端常驻、持续工作”的定位，我梳理了几个可以预期的落地场景。

这四类任务的共同点是：流程清晰、量大、不依赖临场主观判断。用规则加模型组合就能驱动，正是常驻Agent的甜区。Dots这类工具真正吃下的是这些场景，而不是去抢“需要灵感、需要战略拍板”的岗位。

当然，每个团队任务形态不同，落地时要做适配。以代码仓库维护为例，真正跑起来之前，往往先要把团队自己的代码规范、测试流程、分支策略整理成Agent可读的说明，否则Agent只会按通用逻辑干活，未必符合你们项目的实际约定。这个适配过程才是Agent落地的真实工作量所在。

3.3 当前边界：哪些任务还不适合交给常驻Agent

聊完能干什么，也得诚实说说什么不适合。就当前Agent能力边界来看，有三类任务我不建议急着交给常驻Agent。

第一类是需要强交互决策的任务。商务谈判、客户需求澄清、情绪化投诉处理，这些场景对语境感知、情绪识别、实时应变要求极高。Agent可以辅助整理资料，但全程主持很容易翻车。

第二类是高风险的写操作。直接改生产数据库、执行不可逆的部署，这些操作不是不能自动化，而是必须加“人在环上”的审批机制。Agent把方案、影响范围、风险清单完整写清楚，等人确认后再执行。负责任的Agent产品都该在类似节点设置人工闸门。

第三类是需要长期审美或隐性经验的任务。品牌调性定义、产品视觉改版这类高度主观的工作，Agent给出的结果可能“逻辑正确但毫无灵气”。更适合让人类主导，Agent做竞品调研、数据收集等辅助工作。

判断任务是否适合交给常驻Agent，我有一个简单标准：验收标准能不能被清晰描述。如果“做得对”可以写成一套明确规则，就适合Agent执行；如果“做得对”只有老员工一眼能看出来、用语言讲不清，那就别难为Agent了。

4. 一个Agent长期跑在云端，对团队和产品意味着什么

4.1 从“工具”到“虚拟同事”：工作流变了

Dots这类常驻智能体一旦普及，团队工作流最早变化的会是任务下达方式。过去用AI，核心动作是“提问”；以后用常驻Agent，核心动作是“派活”。提问是即时的、无状态的；派活是目标导向的，要把背景、约束、交付标准、验收方式一次交代清楚。

由此带来的连带变化是协作流程本身。Agent执行的每个任务都需要有状态，派给谁、做到哪一步、卡在哪个环节、有什么风险，这套逻辑和项目管理里跟踪人力工单完全一致。未来Agent平台很可能演化为“任务管理系统 + 人工智能执行层”的组合形态，上层是任务分配与进度监控，下层是Agent在云端批量干活。

我私下里有个判断：真正把常驻Agent用好的团队，未来一年最需要的不是更多模型知识，也不是更多提示词技巧，而是把工作职责拆解成清晰任务书的能力。这种能力和写需求文档高度同源，本质上都是把目标、边界、质量标准说清楚。谁能先掌握，谁就能先吃到Agent带来的效率红利。

4.2 对工具链生态的冲击与承接

常驻Agent要真正干活，离不开工具。这正是MCP这类工具协议和Function Calling机制的战略意义所在——它们让Agent的“手脚”能伸进外部系统。GitHub、数据库、邮件系统、监控平台、内部OA，全部可以变成Agent可调用的能力。

在常驻Agent时代，工具链生态的重要性会进一步放大。Agent不是为了对话而对话，它执行每一步都要落到具体操作上。哪个系统能被Agent顺畅调用、哪个产品API规范、哪个安全模型适配沙箱环境，哪个就能在这一轮生态重构中占住位置。反过来，那些只给用户一个聊天入口、却拒绝开放API的产品，会日益边缘化。

对企业来说，这意味着一个容易被忽略的前置条件：底层系统的API化程度，直接决定Agent能帮你干多少活。内部系统有可靠API，Agent就能无缝接入业务流程；只有人工操作界面，Agent再聪明也插不进手。很多Agent项目最后卡住，瓶颈往往不在模型，而在“没有接口给Agent用”。

4.3 成本模型与验收机制：常驻Agent的三本账

常驻Agent还有一个常被人忽视的问题：成本。一个Agent长时间在线、反复调用模型、持续执行任务，token消耗量和日常聊聊天完全不是一个量级。这就像雇全职员工和请临时工的区别，工作节奏和成本结构完全不同。

所以团队要上常驻Agent，一定要先建好三本账。第一本是预算账：单个任务平均成本、每月任务总量、总预算上限、超支熔断机制。第二本是质量账：交付结果准确率、人工抽检通过率、返工率。第三本是产出账：投入成本换来了多少实际产出，比如修了多少issue、稳定产出多少报告、节省多少人工小时。

缺了任何一本账，Agent项目都可能沦为“看起来很酷但算不清回报”的黑洞。我一向反对“先上再说”的Agent项目，因为AI系统的真实成本往往被调试过程无限放大。靠谱的路径是，先在低风险任务上跑一个季度，把成本、质量、产出基线摸清楚，再逐步扩大授权范围。

5. 想上手Dots之前，建议先想清楚的几件事

5.1 任务描述方式：从一句Prompt到一份SOP

如果你准备开始用Dots，最先要改的就是任务描述习惯。常驻Agent不是聊天机器人，不会跟你来回追问十轮才搞明白要什么。下发任务时，目标、背景、限制条件、交付物、质量标准，最好一次性说清楚。

我实际工作中用的任务书模板大致是这样：

这个模板第一次看会觉得啰嗦，但用几次就会发现，任务书写得越清楚，Agent执行返工率就越低。Agent没有读心术，只能基于现有信息推理。你给模糊指令，它只能返回模糊结果，这跟模型聪明不聪明无关，而是信息量本身就不够。

5.2 监控与审计：不能只有“下发-等待-惊喜”

常驻Agent的自主性决定了你没法事无巨细盯着它。所以一套可靠的监控与审计机制必须有。具体来说，至少覆盖四块：执行日志、进度看板、异常告警、结果留档。

执行日志记录Agent每一步行为：调用了什么工具、读了什么文件、产出了什么。进度看板展示每个任务的运行状态，避免任务跑了一整天你都不知道卡在哪。异常告警在任务重复失败、资源消耗异常时通知你，防止白白烧钱。结果留档保存每次任务的产出、版本和决策链路，为后期质量评估提供依据。

我见过很多Agent项目翻车，根因往往不是模型能力，而是过程中没人盯，等发现时已经跑偏很久。常驻Agent就像无人驾驶汽车，驾驶座上的人可以离开，但仪表盘、导航、报警器一个都不能省。这点在Dots这类产品上，比任何单点功能都重要。

5.3 从Dots看智能体的行业风向

最后讲一点偏宏观的判断。Dots的发布，某种程度上标记着Agent产品形态步入新阶段：从“对话式助手”走向“任务式执行者”。常驻、云端、多步骤这三个词，分别对应在线时长、运行环境、任务复杂度三个维度的跃迁。

对开发者而言，这个方向提前布局的有两件事。第一，把能API化的业务流程尽量API化，给Agent留好接口。第二，把团队知识和操作流程整理成结构化SOP，作为Agent的执行知识底座。这两件事都不绑定具体厂商或产品，属于“先做永远不会吃亏”的沉淀。

对做产品的人而言，常驻Agent带来的新机会在“场景编排”：把散落的AI能力、工具API、数据源，编排成完整、可持续运转的任务流。这个能力会越来越值钱，因为行业缺的已经不是单个模型的能力，而是如何让模型在真实业务场景里持续可靠地干活。

就我个人而言，看到Dots出来，最欣慰的倒不是哪个具体功能多惊艳，而是“智能体”这个词终于从演示走向工程化。接下来我准备把手上的几个固定流程任务，改造成常驻Agent的任务单先跑一段时间，用实际成本和收益来验证这个方向。等有了真实的实测数据，再写一篇复盘分享出来。