最近调一个 AI 编程任务时，我在同一件事上反复卡了很久。模型确实聪明，知道该改哪个文件，也能写出看起来对的代码。但它不知道什么时候该停下来，不知道改完之后还要验证，失败之后更不会换个思路重试。这个场景让我想起最近经常被提到的“OpenAI 产品负责人谈 AI 第三时代”。说实话，比起新模型榜单，我更关注另一个信号：AI 和人的协作方式正在换挡。
第三时代这个词听起来很宏大，但拆到一次具体任务里，其实就三个字：能办事。第一代 AI 帮你找信息，第二代 AI 帮你生成内容，第三代 AI 开始尝试替你执行任务。可一旦进入执行环节，问题就不再是模型会不会生成，而是它能不能按边界做事，出了错能不能被发现。我不会去复述新闻稿，而是想从真实使用和工程落地角度聊聊：第三时代到底意味着什么，像 Codex 这类 AI 编程工具会带来哪些变化，以及我们怎么在项目里真正把它用起来。
1. 第三时代的分水岭：从“生成内容”到“承担任务”
1.1 前两个时代，解决的问题都是“信息获取和生成”
第一阶段，典型代表是搜索引擎和早期的知识系统。它们解决的问题是“我不知道”。用户输入关键词，系统返回相关内容，生成能力很弱，但信息检索效率很高。那时候说“AI 辅助”，更多是帮你缩小查找范围，把需要人工阅读的材料变少。
第二阶段，以大型语言模型为代表。核心能力是生成：给定一段上下文，模型能写文案、写代码、做摘要、翻译、分析。到这里，信息的边际生成成本大幅下降，一个普通人也能够通过自然语言拿到一份初稿。但这个阶段有明显局限：模型输出的是“建议”，不是“结果”。你拿到一段代码，仍然需要自己复制、粘贴、保存、运行、调试、部署。模型本身不接触真实环境，也不知道这段代码在项目里会不会和其他模块冲突。
第三阶段真正不同的地方，是模型开始具备“执行链条”。它不仅能说“我建议你创建这个函数”，还能调用工具、读取文件、执行命令、修改代码、查看运行结果，并根据结果调整下一步。这个变化看起来只是把几个步骤连起来，但本质上是 AI 从“建议者”变成了“执行者”。
这也是为什么“OpenAI 产品负责人谈 AI 第三时代”这类话题会在开发者圈子里引发讨论。模型能力固然重要，但真正改变工作流的，是 Agent 能不能把一个任务从头到尾执行完，并且执行得可验证、可回滚。
1.2 为什么“能干活”比“能生成”更值得关注
第一个原因：任务闭环让 AI 的价值可以直接检验。生成一段代码，好不好看还要靠人判断；但 Agent 跑完一个任务，会留下 diff、测试结果、执行日志。这些东西看得见、测得出、能验收，价值立刻变得具体。
第二个原因：出错的方式变了。过去模型输出不好，你重新生成一次就行；现在 Agent 可能改错文件、执行危险命令、产生不可控变更。这意味着人必须学会控制边界、检查变更、及时回滚。这也是为什么第三时代听起来高级，实际落地却更考验使用者的工程素养。
第三个原因：人和 AI 的分工被重新划分。前两个时代，人的主要工作是“把 AI 的结果接回现实”；第三时代，模型把执行环节接过去了，人的工作变成定义任务、设定边界、验收结果、处理异常。这个分工变化，比模型指标的变化更影响日常开发。公开讨论里的“第三时代”具体表述可能有不同版本，但核心方向基本都指向 Agent 和任务自动化。从技术演进路径看，这个方向是合理的。
1.3 这个判断的适用边界
不能把“AI 第三时代”理解成所有 AI 产品都已经完成了进化。更准确的说法是：技术演进已经具备进入第三时代的条件，但产品落地还分阶段。很多聊天机器人仍然停留在“生成”层面，只是更会生成。真正的 Agent 类产品，需要工具调用、环境访问、验证机制、权限控制、可回滚执行，缺一环都容易出问题。
所以我们应该关注的不是“现在是不是已经进入第三时代”，而是“我要做的任务，适不适合用 Agent 流程来完成”。适合，就把它当作一个工程问题去设计；不适合，就没必要硬套概念。
2. AI 编程为什么是第三时代最典型的试验场
2.1 编程任务天然适合 Agent 化
AI 编程不是唯一适合 Agent 的场景，但一定是最早被大规模验证的场景之一。原因很直接：
- 编程任务有明确目标，比如“给函数增加错误处理”“补充单元测试”。
- 代码仓库是结构化环境，文件路径、语法、依赖关系都很清晰。
- 执行结果可以客观验证，代码能不能跑、测试过不过，结果一目了然。
- 变更可以控制，git 提供了天然的版本管理和回滚机制。
相比之下，文字创作、客服、市场分析这些任务验收标准更模糊，Agent 化难度更大。所以像 Codex 这类工具一出现，就会在开发者圈子里快速传播。它把一个抽象概念变成了看得见摸得着的开发流程。
2.2 Codex 本地安装：一条最小路径
这里用常见的本地 CLI 版本举例。如果你准备试一下，流程大致是这样的：
- 确认环境：本地安装 Node.js 和 npm，建议版本不要太旧。用
node -v和npm -v检查。 - 安装命令行工具：
npm install -g @openai/codex。 - 配置 API 密钥：把密钥写入环境变量，例如
export OPENAI_API_KEY=你的密钥。注意不要把密钥写进项目仓库。 - 准备一个最小仓库：建一个只有一两个文件的测试目录，不要直接在大型项目里试。
- 跑一个非常小的任务，比如“给现有的工具函数添加一行日志输出”，观察它读取文件、修改文件、执行命令的过程。
node -v npm -v npm install -g @openai/codexexport OPENAI_API_KEY="your-api-key"这里的命令只是常见的安装方式，具体以你使用时的官方说明为准。API 密钥属于敏感信息，生产环境更应该放进密钥管理服务，而不是直接写进 shell 历史或代码仓库。
2.3 安装和使用中最常见的三个坑
安装阶段经常遇到一类报错：
error: missing optional dependency @openai/codex-win32-x64. reinstall codex:这类问题大多是平台相关的可选依赖没有下载完整，不一定是你命令写错了。常见排查顺序是：
- 先检查网络。如果是特殊网络环境，确认 npm 能正常下载二进制依赖。
- 清 npm 缓存后重装：
npm cache clean --force，再执行npm install -g @openai/codex。 - 如果还不行，看一下 node 和 npm 版本。某些 CI 容器或精简系统里，缺少平台依赖也会报这个错。
- 最后确认当前系统架构和工具包声明是否匹配。比如报错里的
win32-x64只是一个平台包，不一定代表你系统本身有问题。
真正开始用之后，最大的坑不是安装失败，而是权限和上下文。很多人为了省事直接用管理员身份运行，或者让 Agent 在根目录下自由操作。这类工具的定位是辅助开发，不是无边界自动运维。我给自己的规矩是：
- 只在测试项目目录里跑。
- 首次运行先看它准备读哪些文件、改哪些文件。
- 不要直接让它操作数据库、生产环境、敏感配置。
- 任务执行前尽量新建 git 分支，方便回滚。
注意：不要一上来就把批量数和并发数拉满，先用一条样例确认输入、输出和日志都正常。
3. 从“代码生成”到“任务执行”，真正的难点是边界
3.1 Agent 时代，调试对象变了
过去我们调试程序，核心是代码逻辑：变量、函数、调用链。现在调试 Agent 任务，你要同时看模型 prompt、工具调用历史、文件变更、命令执行结果。程序跑挂了，最后要改的可能是你的任务描述，而不是代码本身。
下表是我自己常用的对比：
| 维度 | 传统开发调试 | Agent 开发调试 |
|---|---|---|
| 输入 | 代码逻辑 | 任务描述 + 仓库上下文 + 权限边界 |
| 错误信息 | 编译器/运行时报错 | 多阶段执行日志、部分失败 |
| 验证方式 | 单元测试、人工检查 | diff 检查、测试、日志回溯 |
| 恢复方式 | 改代码重新运行 | 裁剪上下文、回滚变更、重新规划 |
| 最常出错的环节 | 业务逻辑 | 对任务目标的理解和执行顺序 |
这个表格说明：当 Agent 的每一个步骤都可能出错，我们就不能只靠“再生成一次”来解决问题。更有效的方式是让它把计划先列出来，确认后再执行。这也是我在真实项目中最常用的一步，效果比任何提示词技巧都明显。
3.2 成本、配额和上下文：三个容易被忽略的工程参数
很多人用 Agent 时会忽略一些工程参数，等任务跑到一半才发现问题。
- credits 或配额：很多平台用 credits 来计费。这个数字代表你的可用额度，不代表模型能力。如果任务跑到一半提示额度不足，先检查用量，再考虑优化 prompt 或改用更轻量的模型。
- API key 管理：用环境变量或密钥管理服务，不要硬编码在代码里。不要把自己的 key 分享给他人，也不要用不明来源的 key。
- 上下文长度：Agent 一次能“记住”的内容有限。仓库太大时，它会漏掉文件，甚至重复读取。常见的处理方式是“先给目录，再按需展开章节”，让 Agent 先了解项目结构，再针对具体模块深入。
- 并发和重试：多个任务并发执行确实能提升吞吐，但一旦某个任务跑偏，错误也会被放大。我更建议从一次一条任务开始，确认稳定之后再慢慢增加并发数。
这些参数单独看都不复杂，但它们共同决定了 Agent 能不能从“跑通一次”走到“稳定使用”。如果你只是尝鲜，默认配置通常够用；如果要长期使用，就必须额外考虑日志、失败重试、输出目录和权限控制。
3.3 给 Agent 任务设计一个最小闭环
把一次 Agent 任务当成一个小型工程来管理，我通常按四步走：
- 写清目标：一句话说清楚要做什么，再加一条可验收的结果要求。
- 限定上下文：告诉它仓库路径、要关注的文件、不允许触碰的目录。
- 先让 Agent 输出计划：不要让它立刻执行，先请它列出准备读哪些文件、修改哪些文件、执行哪些命令。
- 验收和记录：用 git diff 或文件对比看变更，检查测试结果，最后把这次任务的输入输出和失败点记下来，形成模板。
这样做的价值是：即使 Agent 这次做错了，你也能知道它是在哪一步错的，是理解错了任务，还是执行错了文件，还是验证环节没做。有了这一步，Agent 才能从“碰运气”变成“可管理”。
3.4 一个更实用的任务描述写法
很多人在提示词环节就容易翻车，因为写得太“像人话”。Agent 任务描述和聊天 prompt 不一样，更像是给新同事写的工单。一个比较稳的写法是：
请在当前仓库中完成以下任务： 目标：为 src/utils.js 增加一个日志清理函数，只删除 logs 目录下超过 7 天的 .log 文件。 边界：不要修改其他文件，不要删除非日志文件。 验收：执行 npm test 后所有测试通过，并提供 git diff。 先输出你的执行计划，确认后再开始修改。这个示例的重点在于：目标、边界、验收、执行顺序都写清楚了。Agent 不再是“自由发挥”，而是先拿计划来和你对齐。这一步做得好，很多执行阶段的偏差都可以提前拦截。
4. 第三时代最该练的，不是“提问”，而是“验收”
4.1 提示词技巧仍然有用，但权重在下降
这里可能要打破一些人的预期：AI 第三时代，最稀缺的能力不是更会写提示词，而是更会做验收。原因很简单：模型的能力已经足够生成看起来很合理的内容，Agent 也已经具备执行动作的能力，这时候真正的风险不是“它不会做”，而是“它会自信地做错”。
提示词写得好，可以减少一部分理解偏差，但无法保证执行过程不出错。你需要一套验收机制，把执行结果拉回来。提示词的价值并没有消失。Agent 任务描述里，目标、边界、验收标准，本质上还是提示词工程。只是关注点从“措辞技巧”转向了“任务设计”和“流程控制”。
4.2 五个验收习惯，建议尽早养成
- 先看计划再允许执行。让 Agent 先列出要读的文件、要改的文件、要跑的命令。
- 所有变更走 git diff。不要只看它说“完成”，要看具体改了哪几行。
- 高风险操作单独开环境。不要在正式分支里直接跑不熟悉的 Agent 任务。
- 为每个任务设定范围。明确告诉它不能碰哪些目录、哪些命令不能执行。
- 失败之后先看日志和调用链，不要立刻重试。很多时候，重试只会重复同样错误。
关键判断：让 Agent 先列计划，确认后再执行，是控制风险最有效的一步。
4.3 适合 Agent 与暂时不适合 Agent 的任务
| 适合 Agent 的场景 | 暂时不建议 Agent 直接处理的场景 |
|---|---|
| 代码重构、仓库内小改动 | 复杂系统架构设计 |
| 生成单元测试和文档 | 需要多方业务判断的决策 |
| 批量文件处理、格式转换 | 数据权限极敏感的操作 |
| 数据清洗、日志分析 | 没有可验证结果的任务 |
| 按明确规则执行的流水线 | 高危环境下的直接变更 |
判断标准其实就三条：目标是否明确，结果是否可验证，出错是否可控。只要三条都满足，可以考虑用 Agent 来跑；只要有一条不满足，就要先把它补上。
5. 面对第三时代，别急着造平台，先跑通一个小任务
5.1 我见过最普遍的误区：还没跑通，就开始搭“平台”
每次新概念火了，都会出现一波“大而全”的布局：Agent 平台、工作流编排、可视化编排器。平台本身没有错，但如果连一个小任务都没稳定跑通过，搭平台只会让问题更复杂。很多团队纠结要不要引入 Agent，真正应该先做的是：从手头一个重复性较强的任务开始，让 Agent 跑一遍，记录它哪里可靠、哪里不可靠，再决定要不要扩大范围。
我更建议的路径是：单任务跑通 -> 固定成模板 -> 增加任务批量 -> 再考虑平台和团队协作。这也是普通开发者和团队最容易上手的方式。
5.2 建立自己的“AI 工作流”而不是“AI 工具集”
第三时代真正沉淀下来，不应该是收藏了一堆 AI 工具，而是一套你自己的工作流。比如我自己有一个很简单的模板：
- 任务输入模板：目标、边界、验收标准、禁止事项。
- 执行前检查清单：这个任务是不是可验证？会不会影响其他文件？需不需要备份分支？
- 执行后验收清单：diff 是否合理？测试是否通过？有没有越界操作？
- 复盘记录：这次任务消耗多少、失败在哪里、下一次怎么改进。
这套东西不需要复杂系统，一个 Markdown 文件或代码仓库里的模板就能承载。真正重要的是，你必须让每一次 Agent 使用都留下记录，下次才能迭代。
5.3 不要把 Agent 当成不需要管理的自动工人
回到开头说的 AI 第三时代。产品负责人在谈第三时代时，行业里往往更关注“AI 能做更多事了”，但我认为更重要的部分是：当 AI 开始承担任务，人的职责就变成了“确保任务被正确理解和执行”。这不是一个纯自动化的问题，而是一个管理问题。
你在项目里使用 Codex 或者任何 Agent 工具时，也要保持这个心态：它不是不需要管理，而是需要一种新的管理方式。你既是任务发起者，也是验收员，还是回滚负责人。工具能替你省掉机械执行的时间，但替你省不掉对结果的判断。
那次调试最后是怎么解决的？我没有继续改提示词，而是给任务加了一步：让它先输出计划，我再决定要不要执行。这个改变很小，但整件事突然从“摸黑赶路”变成了“拿着地图走路”。AI 第三时代之所以值得关注，不是因为它让工具更像人，而是因为它逼着我们重新把任务说清楚、把边界定清楚、把结果看清楚。在一个智能体开始执行任务的世界里，最需要升级的不是模型，而是我们自己的工作方式。
