Codex 不只是写代码工具，而是正在变成电脑工作流 Agent

大家好，我是唐斩。

今天看到一篇关于怎么用好 Codex 的文章。

https://x.com/jxnlco/status/2057153744630890620

原文讲了很多 Codex App 里的能力，比如持久线程、语音输入、任务转向、排队、浏览器、Computer Use、MCP、连接器、自动化、Goals、侧边栏、共享记忆等等。

如果只看功能，会觉得这是一个产品功能介绍。

但我觉得真正重要的点不是某个功能，而是 Codex 的定位正在变化。

Codex 不再只是一个 AI 编程助手，而是在往通用电脑工作流 Agent 发展。

从写代码到做电脑上的工作

从写代码到做电脑上的工作

大多数人第一次用 Codex，肯定还是拿来写代码。

看仓库、改代码、跑测试、开 PR。

这当然还是 Codex 的核心场景，但现在的问题是，电脑上很多工作本来就是被代码和工具串起来的。

比如：

• 执行 shell 命令
• 浏览网页
• 调 API
• 导出文档
• 查 Slack 和 Gmail
• 处理日程
• 生成 PDF、表格、PPT
• 等待反馈后继续修改

过去这些事情分散在不同软件里，人是中间的胶水。

现在 Codex 可以用 thread 保留上下文，可以通过 browser、computer-use、MCP 和 connector 接触外部系统，还可以用 automation 和 goals 让任务持续运行。

这就不只是“帮我写一段代码”了，而是“帮我把一件电脑上的工作做完”。

持久线程，是 Agent 工作空间

我之前一直强调，AI 编程最重要的不是单次问答，而是上下文工程。

文中提到的 durable threads，也就是持久线程，我觉得就是 Codex 里的工作空间。

不是每次开一个新聊天，让 AI 重新理解你是谁、项目是什么、上次决策是什么。

而是把线程按长期工作流固定下来。这和我们做软件系统很像。

临时脚本能解决一次问题，但长期系统一定要有状态、有上下文、有边界。

Codex 的 thread 就是在给 Agent 提供这个状态。

引导 和 排队 很有用

Steering 和 Queuing 文章里有两个概念我觉得很值得单独拎出来。

一个是 Steering，在Codex中文里叫引导。

也就是 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 的本质是验证器

文章里还有一个点我很认同：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 当成“帮我改代码”的工具，可能有点低估它了。更好的用法是，给它线程，给它工具，给它记忆，给它验证器。让它从写代码开始，逐步接管你电脑上的重复工作流。