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 codex | npm 包在 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 去跑。等你能放心让它连续工作一周，再回头看，就回不去了。
