Codex 工作流 Agent 深度评测：不止是代码工具
最近读到一篇拆解 Codex 深度用法的文章，内容很扎实，把 Codex 应用里的各项能力都梳理了一遍——持久线程、语音输入、任务转向、排队、浏览器、Computer Use、MCP、连接器、自动化、Goals、侧边栏、共享记忆等等。如果只盯着这些功能看，很容易把它当成一份产品功能清单。但真正值得关注的，不是某个具体能力，而是 Codex 的定位正在发生根本性转变：它不再只是一个 AI 编程助手，而是在朝着通用电脑工作流 Agent 的方向演进。
从写代码到接管电脑上的工作
大多数人第一次接触 Codex，肯定还是冲着写代码来的：看仓库、改代码、跑测试、开 PR。这依然是它的核心场景。但关键在于，电脑上很多工作本来就是用代码和工具串联起来的。比如：执行 shell 命令、浏览网页、调 API、导出文档、查 Slack 和 Gmail、处理日程、生成 PDF/表格/PPT、等待反馈后再修改。过去这些事情分散在不同的软件里，人是中间的胶水。现在，Codex 可以用 thread 保留上下文，通过 browser、computer-use、MCP 和 connector 触达外部系统，还能用 automation 和 goals 让任务持续运行。这就不再只是“帮我写一段代码”，而是“帮我把一件电脑上的工作做完”。
持久线程，就是 Agent 的工作空间
之前一直强调，AI 编程最重要的不是单次问答，而是上下文工程。文中提到的 durable threads（持久线程），本质上就是 Codex 里的工作空间。不是每次开一个新聊天，让 AI 重新理解你是谁、项目是什么、上次的决策是什么；而是把线程按长期工作流固定下来。这和我们做软件系统很像——临时脚本能解决一次问题，但长期系统一定要有状态、有上下文、有边界。Codex 的 thread 正好在给 Agent 提供这个状态。
引导和排队：真正像 Agent 的关键
文章里有两个概念值得单独拎出来。一个是 Steering（引导）：Codex 正在执行任务时，你发现它方向不对，可以打断它，告诉它往另一个方向走。比如它正在改页面，你可以直接说“这个间距不对”“这个文案错了”“这个地方缩小一点”。另一个是 Queuing（排队）：不打断当前任务，而是告诉它做完以后继续做下一件事。比如：改完以后把预览链接发给 reviewer；测试通过以后整理一版 release note；文档更新后再检查一次链接。这两个能力组合起来，才真的像一个 Agent——因为真实工作不是一次性输入然后等最终答案，而是边看边改、边改边补充，做完一件接下一件。
工具触达决定 Agent 能做多远
Codex 能不能成为通用 Agent，关键看它能接触到什么。文章里把工具分了几层：$browser 适合在侧边栏里看网页、测页面、做 UI review；@chrome 适合需要用户登录态的浏览器任务；@computer 适合只能通过桌面 GUI 操作的任务；MCP 和 connectors 则适合连接 Slack、Gmail、Calendar 等系统。这一点很重要——Agent 的能力不只由模型决定，也由它能操作的世界决定。一个能读仓库、开浏览器、查 Slack、写文档、操作桌面、跑测试的 Agent，才可能把工作闭环。所以 MCP、Skill、Connector、Computer Use 这些东西，是 Agent 工程的基础设施。
Goals 的本质是验证器
文章里还有一个点很认同：Goals 必须有明确终点。弱目标是“帮我实现这个 Markdown 里的计划”，强目标是“把这个 Python 工具迁移到 Rust，直到单元测试全部通过”。区别在于有没有 verifier（验证器），有没有明确的终点可以让 Agent 知道目标方向和结束的时机。AI 长时间执行任务，最怕的就是看起来一直在努力，但不知道有没有接近目标。所以一个好的 Goal 必须包含：目标是什么、什么时候算完成、用什么信号验证、失败后怎么继续迭代。验证器可以是测试集、benchmark、bug 复现、校验矩阵，也可以是一个完整的端到端流程。没有验证器的自动化，本质上就是许愿，看命看运气。这也是 AI 编程从玩具到生产力工具的分界线。
共享记忆要落到文件里
文中还提到一个很实用的做法：用 Obsidian vault 这类文件夹作为长期记忆。对话记录不是最好的长期记忆，文件才是。比如一个 vault 里可以有：TODO.md、people/、projects/、agent/notes/AGENTS.md。仓库保存代码，vault 保存滚动上下文——谁参与了项目，做过什么决策，当前卡点是什么，下一步要跟进谁，哪些信息以后还会用。这些都不应该只躺在某次对话里，因为对话是过程，文件才是资产。
对程序员的启发
总结一下，这篇文章真正的价值在于提醒我们：AI 编程的下一阶段，不是让 AI 写更多代码，而是让 AI 接管更多工作流。程序员的能力也会跟着变化。以前比的是谁写代码快、谁熟悉框架、谁 debug 强；现在还要加上：谁能定义清楚目标，谁能设计可验证的工作流，谁能把重复流程沉淀成 Skill，谁能维护长期上下文，谁能调度多个 Agent 和工具完成闭环。从代码的开发者转型成 Agent 的调度和环境提供者——这已经是一个新职业了。古法程序员这个职业正在终结。
Codex 仍然从代码出发，但它已经开始往代码之外扩展。从 repo 到浏览器，从浏览器到桌面，从桌面到 Slack/Gmail/Calendar，从一次任务到长期线程和自动化。这条路走下去，Codex 会越来越像一个通用电脑工作系统。所以，如果现在还只是把 Codex 当成“帮我改代码”的工具，可能有点低估它了。更好的用法是：给它线程，给它工具，给它记忆，给它验证器。让它从写代码开始，逐步接管你电脑上的重复工作流。