AI第三时代：从生成内容到执行任务，智能体编程的落地实践与边界控制

最近调一个 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_KEYyour-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 第三时代之所以值得关注不是因为它让工具更像人而是因为它逼着我们重新把任务说清楚、把边界定清楚、把结果看清楚。在一个智能体开始执行任务的世界里最需要升级的不是模型而是我们自己的工作方式。