导读很多人第一次用 Codex还是把它当成「更会写代码的 ChatGPT」看仓库、改 diff、跑测试、提 PR。真正有意思的变化是 Codex 的边界正在往外推当浏览器、邮件、日程、MCP、桌面 GUI、自动化都接进来之后Codex 就不再只是 coding agent而是在变成一个「电脑工作系统」。先别急着把 Codex 理解成 IDE 插件很多开发者最早接触 coding agent通常是从代码任务开始的。比如让它读一个 repo理解架构改一段实现跑一遍测试再帮你准备 PR。这当然还是 Codex 的主场。但如果只停在这里就会低估它真正的变化。因为电脑上的很多工作本来就已经被代码、命令、网页、API 和文件系统包了一层。只要这些表面能被 Codex 操作它就自然会从「写代码」扩展到「把电脑上的工作往前推」。这就是这篇长文的核心判断Codex 的重心仍然是代码但它的工作边界已经不是代码。说白了以前我们问的是「它能不能把这个函数写对」。现在更值得问的是「它能不能在一个真实工作流里把上下文、工具、产物和人的判断串起来」。长线程比单次回答更重要这篇文章反复强调一个词durable threads长线程。它不是简单的聊天记录保存而是让一个工作流有自己的长期上下文。比如你可以有一个专门处理发布的线程一个做文档审查的线程一个负责外部监控的线程甚至一个类似 Chief of Staff 的线程。这些线程的价值不在于「记得你上次说过什么」这么浅。更重要的是它能保留一整套工作习惯哪些来源可信、哪些步骤要先跑、哪些人需要被提醒、哪些检查不能漏。这也是我觉得很多人会低估的一点AI agent 的生产力不只来自模型变聪明也来自上下文不再每次清零。一个短聊天里的 AI 很像临时工。你每次都要重新交代背景、规则、口味和禁忌。长线程更像一个持续工作的项目房间里面的材料、半成品、决策记录都还在。语音、转向、排队人还在回路里这里有几个看起来小但实际很关键的控制方式voice、steering、queuing。语音输入的意义不是「懒得打字」。它更适合捕捉还没整理好的想法。很多真实任务一开始都不是一个漂亮 prompt而是一段含糊的描述我记得 Slack 里好像有人提过这个名字可能叫 Ben但细节我忘了。你去找一下。对传统工具来说这句话信息太脏。但对能搜索、整理、追问、汇报的 agent 来说这反而是很自然的入口。Steering 是另一种控制任务跑到一半时用户可以打断它立刻纠偏。Queuing 则是不打断当前任务只把下一步排到队列里。比如「做完后把预览链接发给审核人」这就是排队。这套控制模型背后的重点是人没有被踢出回路。很多 agent 产品容易把「自动化」讲成「你不用管了」。但真实工作不是这样。越是复杂任务越需要用户在关键节点做判断。好的 agent 不是替你拍板而是把决策点提前暴露出来让你用最少的介入改变方向。工具接入之后Codex 开始离开 repo长线程解决的是「上下文能不能留下来」。工具解决的是「它到底能碰到什么」。Codex 的触达范围大概可以分成几层层级适合做什么browser在侧边栏里查看网页、标注、调试页面Chrome处理依赖登录态的真实网页流程computer use操作只能通过桌面 GUI 完成的任务MCP / connectors接入 Slack、Gmail、Calendar 等工作入口Skills把重复工作流封装成可复用能力这个方向很关键。因为很多重要工作并不是从代码仓库开始的。它可能从一条 Slack 消息开始从一封客户邮件开始从日历里的会议开始从一个 Google Docs 评论开始。过去这些入口彼此割裂最后还是人来做搬运工。现在 Codex 有机会把它们接到同一个工作线程里。这里也有一个现实提醒工具越多风险越大。能读 Slack、能看 Gmail、能操作浏览器意味着权限边界、确认机制、日志记录都会变得更重要。真正成熟的 agent 工作流不是「尽可能自动执行」而是「把可自动化的部分自动化把需要人负责的部分清楚地停下来」。自动化和 Goals从陪聊变成追结果文章里还有两个概念值得单独拿出来Automations 和 Goals。Automations 是让 Codex 按计划启动工作。比如每天生成报告定期检查 repo或者让一个活跃线程每隔一段时间醒来看看 Slack、Gmail、PR 评论有没有新东西需要处理。Goals 则更像长跑任务你给它一个明确终点和验证器让它持续往那个结果推进。弱目标是按这个 Markdown 里的计划实现一下。强目标是把这个内部工具从 Python 迁到 Rust。目录要建好功能要对齐单元测试全部通过才算完成。差别就在验证器。没有验证器的目标只是愿望。测试、benchmark、复现脚本、端到端流程这些东西把「继续努力」变成了「有没有更接近完成」。这也是未来 agent 工作流最实用的一条分界线不是任务越大越适合交给 agent而是越能被验证的任务越适合让 agent 长时间推进。侧边栏和移动端产物就在对话旁边Codex app 的 side panel 也在这套叙事里占了很大位置。它解决的是另一个老问题AI 产出一个东西之后人到底在哪里审。如果输出是代码可以看 diff。如果输出是网页就应该直接打开页面。如果输出是文档、表格、PDF、deck就应该在同一个工作上下文旁边审阅、标注、修改而不是导出以后切到另一个地方重新沟通。OpenAI 最近把 Codex 接进 ChatGPT 移动端也是同一个逻辑长任务不应该把人绑死在电脑前。你可以在 Mac 上启动一个任务让本地文件、权限、依赖都留在那台机器上人离开桌面后手机继续看进度、回答问题、批准下一步、改变方向。这不是简单的「远程控制电脑」。更像是让工作线程跟着人走而执行环境还留在最合适的地方。真正的变化上下文、工具、验证器这篇长文最值得记住的不是某一个功能而是一个框架。Codex 正在从三个方向变重1上下文长线程、共享记忆、项目文件让工作不用每次重来。2工具浏览器、Chrome、MCP、连接器、桌面 GUI让它能碰到真实工作表面。3验证器测试、检查矩阵、端到端流程让长任务知道什么叫完成。如果说早期 coding agent 的问题是「能不能写对代码」下一阶段的问题会变成「能不能在真实工作流里带着上下文和验证器把事情推到完成」。我觉得这才是 Codex 这波变化的重点。它不是要把程序员变成甩手掌柜。相反它把人的角色往上抬了一层少做搬运、检索、重复执行多做目标定义、判断和验收。总结一下Codex 仍然从代码出发但它的产品形态已经在往「工作系统」移动。长线程解决上下文工具连接真实工作表面Goals 和验证器让任务有终点。真正能用起来的 agent不是全自动替你决定而是在正确的节点让你介入。