DevDay 2026 最让我提神的不是又发布了一个刷榜模型而是那句“把持续工作的 AI 装进 ChatGPT”。如果你跟我一样过去两年一直在手动把 AI 生成的草稿复制来复制去、隔几个小时就去问一句“上次那个任务到底做完没”那这个方向的杀伤力比参数数量大得多。这个概念其实不复杂持续工作的 AI就是让 AI 从一个“你问它答”的对话工具变成一个能自己排期、自己拉数据、自己干活干完活还会回来跟你交差的数字助理。它被直接嵌进 ChatGPT 之后你不需要一直开着对话框等它回复而是像开了一个常驻后台服务它会定时醒来处理任务处理完再睡回去。这篇文章我不想复述发布会上的 PPT 愿景主要讲我自己对这件事的理解、背后的技术点拆解以及真正把这种 Agent 跑起来之后踩过的坑。有的东西听起来很简单但落地时全在细节里。1. 持续工作的 AI 是什么从“聊天机器人”到“数字员工”1.1 过去两年我们其实一直卡在“一次性对话”先说说之前的痛点。早期的 ChatGPT 使用体验是打开对话框输入问题得到回答对话结束。哪怕后来有了多轮记忆这种记忆也基本限制在“当前会话”里——换一个会话它对你上周做过的事情一无所知。放到真实工作流里这个断层问题非常明显。拿写周报举例你让 AI 帮你写周报它写得很好但下周你再想让它写就得把几十段聊天记录、邮件、项目文档重新喂一遍。要是中间数据源更新了AI 根本不知道任务中途被打断AI 也不会主动提醒你“上次整理到一半的资料还没收尾”。这就是一次性对话的局限。所谓“持续工作的 AI”并不是简单地加一个定时器而是让 AI 拥有一个长期运行的任务上下文。它需要知道自己现在做到哪一步、还差什么、什么时候该继续甚至判断当前信息是否已经过期。这个长期上下文是过去那些“对话式 AI 自动化”没有解决的底层问题。我在这个项目上最深的体会是很多人嘴上说“AI 自动化”做出来的东西其实只是把 Prompt 模板化再加一个脚本定时调用接口。AI 没有状态、没有记忆、没有目标。真正的持续 AI得从“模型调用”升级成“任务运行环境”。1.2 DevDay 2026 给出的答案常驻 Agent ChatGPT这次 DevDay 上OpenAI 把“持续工作的 AI”做成了 ChatGPT 的内置能力。它不是说再单独开一个 App 让你去装而是直接在 ChatGPT 里加了一层“任务运行环境”。在这个环境里Agent 可以挂载配置、读取工作目录、按调度被唤醒并且把执行结果写回一个持久化的状态文件。我用一个类比来理解这事以前用 AI 像在路边招手打出租车挥手即停到了目的地就散伙你还要重新跟司机解释路线。持续工作 AI 更像地铁系统只要列车没到终点站它就会沿着轨道一直跑你不需要每一站都喊一声“下一站记住停”。你作为乘客只需要在控制中心看状态、处理异常。这套体系适合谁先说结论它绝对不只是给程序员用的。开发者可以把它绑到代码仓库上让 Codex 挂着修 issue、跑测试、提 PR运营可以设置每天早上自动抓取数据、生成日报内容创作者可以把它当资料整理员持续监控某个选题方向的相关信息数据分析师可以用它定时跑 SQL、整理异常指标、输出归因清单。换句话说只要愿意写一点配置文件普通用户也能搭起一条属于自己的AI流水线。它不是某个垂直工具而是一个“AI 运行容器”。2. 核心细节拆解要把“持续”二字做实靠这几件事2.1 长程记忆与上下文管理“持续”最大的工程难点不是模型而是记忆。一个 Agent 连续跑上一周原始对话记录可能超过百万 token。你不可能每次都把全部内容塞进模型上下文那样成本和延迟都不可接受。我实际跑下来靠谱的做法是分层记忆滚动摘要每处理完一批子任务就要求模型把结果压缩成一段结构化摘要存进短期记忆区。旧的完整细节全部转存到向量库需要时按相关性检索。关键状态表任务进度、目标、已完成项、当前阻塞项要单独存成一个结构化文件不要跟自然语言聊天记录混在一起。状态表是机器的“输入输出”聊天记录是机器的“思考草稿”。工作目录持久化每个 Agent 都要有一个专属工作目录用来放中间产物、临时脚本、下载的数据文件。哪怕 Agent 进程重启也能通过目录恢复现场。ChatGPT 里的持续 AI本质上就是一个带记忆文件系统的小型任务引擎。我在配置任务时习惯把所有记忆相关参数单独放在一个文件里例如[agent] name weekly-report # 每个任务开始前让模型先读两份文件 state_file ./state.json summary_file ./memory.md [context] mode rolling-summary summary_every 8 # 每8轮更新一次摘要 retrieve_limit 5 # 每次最多检索5条历史记录这里的summary_every很关键。太频繁会额外消耗 token太少则摘要信息失真。我试过 3 和 20 两个极端最后觉得 4 到 10 轮之间比较稳。摘要本身也要有固定模板目标、当前进度、遗留事项、下一步动作。没有模板的摘要跟流水账没区别。2.2 任务调度与触发方式持续不等于“24 小时不间断跑大模型”。真正合理的持续是事件驱动平时处于挂起状态有信号到达再唤醒。信号一般有三种来源。第一种是定时触发。适合日报、周报、定期巡检这一类固定节奏的任务。配置里可以写[timer] schedule 0 9 * * 1-5 # 每个工作日早上9点 timezone Asia/Shanghai第二种是事件触发。比如收到新邮件、提交了新 issue、某个 webhook 回调、数据库出现了新记录。事件触发的好处是响应及时不用空转。第三种是手动触发也就是你在 ChatGPT 里直接发一句“继续昨天的任务”Agent 会读取状态文件接着往下做。这里要特别强调如果任务没有新的输入信号就不要唤醒模型。否则账单一上来就会把人吓住。我自己跑过一个失败的例子把轮询间隔设成 5 分钟结果一天下来光检查“有没有新消息”就消耗了几百万 token实际产出的有效结果却几乎为零。后来改成 30 分钟一次并在检查前先做一层纯规则的变更检测没有变化就直接跳过成本立刻降了一个数量级。2.3 工具调用与权限边界一个能持续工作的 AI必须能调用外部工具查邮件、发请求、跑代码、写文件。这次 DevDay 上我很关注的一点是内置的“工具注册中心”。也就是说Agent 不像以前那样只能靠模型瞎猜函数名而是有一个清晰的工具清单每个工具都声明了入参、出参和权限级别。权限级别设计上建议至少分成三档权限级别可操作范围典型示例只读读文件、查数据库、请求公开接口拉取数据、检查仓库状态可写修改工作区或仓库内文件生成文档、创建分支审批对外部系统产生不可逆副作用发邮件、合并 PR、删除资源我实际落地时会把大型 Agent 默认设为“只读 少量审批”。这不是限制效率而是给 AI 划一条安全跑道。Agent 跑得再快也不能让它一脚油门冲进生产环境。注意持续工作的 AI 不是僵尸进程也不是一个“无人值守的万能工具”。它更像一个实习生你可以给它权限但关键操作必须留一道人为关卡。3. 实操把持续工作的 AI 用起来3.1 场景一自动汇总信息并生成周报先说一个最容易上手的场景让 Agent 每周自动整理信息生成一份周报。这个场景几乎零风险一旦配好能省掉大量重复劳动。操作步骤大致是在 ChatGPT 里新建一个“持续任务”类型选“报告助手”。配置数据源。最开始我只接了邮件收件箱的某个文件夹而不是整个邮箱。设置调度时间。我选周五下午五点触发这样周报内容能覆盖整周。定义输出模板。包含本周进展、风险项、待办事项、下周计划。配置送达方式。让 Agent 把最终报告写进共享文档并给相关人发一条通知。一个最简配置可以参考[source] type mailbox folder INBOX filter is:unread AND from:project-team [output] type doc target team_notes:weekly_report这里最值得提醒的是数据源过滤。我第一次做这个任务时偷懒直接把整个收件箱喂进去结果 Agent 被营销邮件和系统通知刷屏生成的周报里全是打折信息和登录提醒完全没法用。后来加了发件人白名单和主题关键字过滤输出质量才稳定下来。另外模板最好固定下来。我一开始让 Agent“随便写”结果它每周风格都不一样后来干脆做了一个 Markdown 模板里面留好字段Agent 只负责填内容。稳定性和可读性都好了很多。3.2 场景二让 Codex 进入“持续修 bug”模式Codex 本身就是代码 Agent把它嵌入 ChatGPT 之后修 bug 这件事可以变成一个后台任务。这个场景适合团队里已经有一定测试覆盖率的仓库因为我需要让 Agent 自己验证结果而不是纯靠猜。我这里跑的流程是持续监控某个仓库的 issue只看带bug标签的任务。当新 issue 出现时Agent 自动拉取代码、尝试复现、定位可疑模块、修改代码、跑相关测试。测试通过后Agent 提交一个 PR并自动打上agent-generated标签。PR 进入人工 review 队列不允许 Agent 自己合并到主分支。权限配置在这里是最关键的。代码写入分支可以放开但 push 主分支必须审批。我还在系统里加了“禁止 Agent 修改依赖锁定文件”的规则因为 Codex 有时候为了修一个测试会把依赖版本一改把整个环境搞乱。这个场景跑通之后最大的收益不是“bug 被修了多少”而是把维护者从“查看重复 issue、筛选无效反馈”里解放出来。Agent 负责把繁琐的前置工作做完人只需要在后端做决策。3.3 场景三多 AI 协作编排复杂任务如果只靠一个 Agent 硬扛上下文会非常拥挤而且容易“精神分裂”——一会儿思考数据一会儿又要写文案结果两边都做不深入。所以当任务复杂度上来之后我会拆成多个子 Agent让它们各管一段再有一个主 Agent 做聚合。举个例子做一个竞品监控系统Agent A 负责定时抓取竞品官网和更新公告Agent B 负责翻译和摘要把非结构化的页面文本整理成结构化条目Agent C 负责对比历史趋势判断哪些变化值得关注主 Agent 每天汇总这三个子 Agent 的结果生成一份简报。子 Agent 之间不直接改对方的状态而是通过一个消息队列传递结果。A 把原始内容丢进队列B 从队列取走处理处理完再丢给 C。这样做的好处是如果 B 因为网络问题挂了C 还能继续跑之前已经入队的数据只是输出会缺一块不会全线崩溃。这和微服务非常像。用多个小 Agent 并行远比一个大 Agent 包打天下要稳定。同时每个子 Agent 的记忆文件都小检索快也不容易产生上下文污染。4. 踩坑实录连续工作 72 小时后我遇到的那些怪问题4.1 你大概率会碰到的启动和配置错误持续 Agent 刚上手的时候报错率真的不低。我把自己和几个朋友踩过的典型问题整理成了速查表方便直接对照。错误信息大概率原因处理方式missing optional dependency openai/codex-win32-x64. reinstall codexnpm 包在 Windows 平台缺少对应的二进制依赖按提示重装 codex或核对 Node 版本、平台架构unable to load config.toml配置文件语法写错、编码带 BOM、路径不对用 UTF-8 无 BOM 格式重存逐字段核对the gpt-x model is not supported when using codex with a chatgpt acc当前账号权限不支持该模型走 Codex 通道换 API Key或改用当前账号支持的标准模型failed to start. 该进程没有程序包标识符Windows 桌面客户端启动逻辑异常用命令行方式启动或重新安装客户端这里面我特别想说一下config.toml。很多 Agent 工具都把配置放在这个文件里它相当于启动开关。TOML 格式对空白符号非常敏感一个字段拼错就会被忽略但工具不一定给红线报错而是会在之后某个很奇怪的环节悄悄失败。更隐蔽的是部分编辑器默认在文件头加一个 BOM 标记这让 Agent 每次启动都报“无法加载配置文件”排查了半天。我的习惯是任何配置文件改动之后先跑一遍“解析检查”命令而不是直接跑 Agent。确认配置能被读到再启动任务。4.2 资源失控持续运行真的会烧钱持续 Agent 最隐蔽的坑是 token 账单。如果一个 Agent 每隔 5 分钟就唤醒一次全量扫描一天就是 288 次。假设平均每次任务消耗 2 万 token一天就是 576 万 token。再按目前 API 的定价算一天烧掉几十甚至上百美元是非常正常的。控制资源的第一件事是设置冷却时间。我常用的配置是这样[agent] cooldown_minutes 15 daily_budget 5daily_budget的意思是当天累计消耗达到一定量就自动停止等第二天重置。这个功能相当于给 Agent 上了个预算保险丝。第二个办法是“先检后算”。只读检查类任务先跑一个轻量脚本判断数据源有没有变化比如哈希值变了没有、有没有新文件、接口返回的版本号是否一致。只有确定发生变化才唤醒大模型去处理。没变化就直接睡觉一个 token 都不消耗。把持续 Agent 当成真实员工来看就很容易理解你不会让员工每 5 分钟看一次邮箱而是让他每小时看一次看完没新邮件就继续做别的事。4.3 数据污染Agent 把自己带沟里持续运行的 Agent还会遇到一个非常隐蔽的经典问题数据污染。它会把自己上一次的输出当成新的输入错误结论被反复叠加最后越滚越歪。我做过一个指标对账任务让 Agent 每天生成一组数据核对结果。最开始它看起来很聪明后来我发现它连续三天都在重复一个错误结论而且错误数字越来越离谱。原因就是它每次任务开始前先去读了昨天自己生成的报告把报告里的错误判断当成了新事实来源。解决思路是“锚定外部事实”。让 Agent 任务开始前先读取外部系统快照比如直接从数据库查原始数据而不是读昨天的输出文件。关键字段加上一致性校验如果某个指标与外部系统差异超过阈值自动终止任务并标记为“需要人工确认”。工作目录定期清理避免旧文件干扰新任务。这个教训让我意识到持续 AI 的“记忆”必须分清楚哪些是事实、哪些是观点。事实来自外部系统观点才是模型自己的判断。两者一旦混在一起长期运行必然出乱子。5. 写在最后没人愿意做的工作才是持续AI的第一站5.1 落地建议从小任务开始保留人工关卡如果你想在自己团队里引入持续工作的 AI我的建议是千万不要一上来就做“全自动大项目”。先找一个非关键、可回滚、低副作用的场景比如整理资料、生成草稿、采集状态让它跑一周。跑通了再逐步扩大权限和范围。我有一个很具体的判断标准这个任务如果做坏了会不会对生产环境或核心业务造成不可逆影响如果答案是有可能那就必须保留人工审批环节。Agent 可以自动跑完整个流程的前 80%最后 20% 的确认动作必须由人来做。这不仅是为了安全还能作为反馈信号不断告诉 Agent 什么才是合格的结果。5.2 我的一点个人体会在这个项目里折腾了三个月我最大的感受是真正的持续 AI不是流程编排工具也不是定时任务脚本。它最有价值的地方是拥有一个长期上下文可以为了同一个目标分阶段执行。它记得住上一次做到哪也知道下一步该做什么。我现在的工作习惯已经变了每天收工前把第二天要 Agent 处理的事项写在一个任务面板上第二天它自己读、自己做、自己回报。那种感觉比用任何自动化脚本都更接近“多了一个同事”。如果你正准备上手我的建议只有一句话从一件你讨厌做但规则清晰的小事开始把它完全交给 Agent 去跑。等你能放心让它连续工作一周再回头看就回不去了。