深度解析 on Codexer

当编程智能体成为云工作负载：Codex on AWS 的真正含义

Sun, 14 Jun 2026 09:00:00 +0800

一则被低估的公告

OpenAI 宣布 Codex 和前沿模型登陆 AWS。很多人扫了一眼标题，把它归类为"又多了一个云渠道"的常规新闻。大模型上云，企业采购更方便，用户不用特殊审批就能用上 shiny new thing。这个解读没错，只是格局太小了。

真正重要的不是 Codex 现在能跑在离 AWS 客户更近的地方。真正重要的是：一个编程智能体，正在从 IDE 插件、CLI 工具、聊天窗口的角色，蜕变成一种云工作负载。

这个转变会重塑整个问题的形态。当智能体可以读代码、开 Pull Request、调工具、访问云 API、检查日志、甚至修改基础设施的时候，最难的问题就不再是"哪个模型最聪明"，而是那些古老又无聊的平台问题：智能体用的是哪个身份？它能访问哪个网络？它能看到哪些密钥？谁批准了这次操作？审计记录在哪？账单飙升了怎么办？生成的代码搞崩了生产环境，谁负责？

欢迎回到软件工程的世界。

从生产力工具到执行面

对个人开发者来说，编程智能体是一个生产力工具。你给它任务，它改文件，你审核 diff。信任边界是心理层面的、本地化的：我信不信这段补丁？

对企业来说，这个边界远远不够。

企业买的不是一个"更会写代码的助手"，而是一个执行面。智能体需要凭证，需要访问源代码，可能还要接触包仓库、内部文档、工单系统、云控制台、监控系统、CI 日志和部署管道。每接入一个系统，智能体就从友善的助手向公司控制平面内的行动者迈进一步。

这就是 AWS 上线的意义所在。不是因为每家公司都爱 AWS 爱到所有 AI 都必须跑在上面，而是因为大量企业已经在 AWS 上建立了一整套"无聊的基础设施"：IAM 身份管理、CloudTrail 审计追踪、VPC 网络边界、采购流程、预算审批、账号体系、事件响应流程和安全审查机制。这些是企业花了十几年打磨出来的肌肉记忆。

把 Codex 放进这个体系，不只是为了降低延迟或者方便采购，而是让智能体继承一套企业已经理解的操作模型。

多云不是可选项

还有一个让人不舒服的推论：智能体基础设施天然就是多云的。

一个正常的工程组织已经分散在多个控制平面上。源码可能在 GitHub，身份认证可能在 Okta 或者 Entra，生产环境在 AWS，开发者效率工具挂在微软生态上。有些 AI 合同通过 OpenAI 直签，有些模型通过 Bedrock 调用，有些团队还在笔记本上跑本地智能体，因为工作本来就在那里发生。

没人能干干净净地把这些东西集中到一处。

智能体会跨越边界，因为工作本身就跨越边界。它在一个系统里读工单，在另一个系统里搜文档，在代码仓库里改代码，在沙箱里跑测试，在云端查日志，最后在 Pull Request 里请求人类审查。运气好的话，每一步都有可用的审计追踪。运气不好的话，智能体会变成一个自信过头的实习生，开着五个浏览器窗口，拿着宽泛的权限，还记不住自己为什么会点那个按钮。

这才是真正的平台难题。

胜出的智能体技术栈，不是聊天窗口最漂亮的，而是能把身份、授权、策略、可观测性、成本核算和审查语义贯穿整个工作流的那一个。这比加一个模型选择器难得多。

智能体需要"平台契约"

我反复回到同一个模式：AI 工具变严肃的那一刻，就是它不再假装模型就是产品本身的时候。

对编程智能体来说，产品是围绕模型的整个系统。

模型可以提出修复方案，这没问题。但一个生产级的编程智能体需要一份契约，来规定这个修复方案如何在组织中流转。它需要的是范围明确、可撤销的仓库访问权限，而不是一张"公司 GitHub 全量 Token"。它需要的是可以随时销毁、检查、复现的临时沙箱。它需要的是足够窄的工具权限，让安全团队可以推理风险。它需要的是读日志、开 PR、改基础设施各自使用不同的身份。它需要的是在危险操作前的策略卡点，需要成本预算，需要生成代码的来源追溯，需要解释它用了哪些上下文。

Codex 智能体自治运营：OpenAI 内部数据平台的实战启示

Sat, 13 Jun 2026 09:00:00 +0800

当数据管道不再等待工程师

凌晨三点，一个关键的数据管道突然中断。按照传统流程，值班工程师被电话叫醒，打开笔记本，登录系统，开始排查日志。半小时后定位问题，一小时后修复上线。整个过程耗时两小时，期间下游依赖全部停摆。

在 OpenAI 内部，这个场景已经变成了历史。现在，数据管道中断的瞬间，Codex 智能体会自动介入：追踪异常、分析日志、生成修复方案，甚至在工程师打开电脑之前就完成了部署。这不是概念演示，而是 OpenAI 数据平台每天都在发生的真实场景。

规模催生的必然选择

OpenAI 的内部数据平台支撑着超过 3500 名用户，管理着 600PB 的数据，涵盖约 70000 个数据集。这个平台是 OpenAI 所有业务的底座：模型训练、安全管线、产品分析、财务报告，每一个环节都依赖它。

底层架构更是复杂：高速 Kafka 流处理、分布式 Apache Spark 作业、编排层协调着数千个工作流。每一次用户提示、每一次模型迭代、每一个企业级工作流，都要经过这一层。

真正的问题出在增长速度上。过去一年，OpenAI 流处理系统的事件量增长了约 50 倍。在这个量级下，传统的仪表盘开始失效，告警信号淹没了人工响应的循环。数据平台负责人 Emma Tang 说得很直接：当规模到达一定程度，人类工程师已经无法跟上系统的响应速度。

把智能体嵌入基础设施本身，是 OpenAI 给出的答案。系统观察自身状态，推理当前状况，实时采取行动。运营从人工操作变成了持续自治的过程。

数据智能体和编码智能体的本质区别

很多人会问：Codex 不就是个写代码的工具吗？怎么跑去管数据管道了？

这里有一个关键的认知升级。Codex 最初确实是编码助手，但它现在已经演化成了一个通用的执行层。每周活跃用户超过 300 万，其中相当比例的使用场景已经超出了纯编码范畴，延伸到了规划、文档编写和运维工作。

OpenAI 的工程师在 Codex 之上构建了领域专用智能体，覆盖流处理系统、数据管道和机器学习基础设施。这些数据智能体和编码智能体有一个根本区别：上下文边界不同。

编码智能体的上下文边界相对清晰，就是代码仓库。它可以检查文件、运行测试、查看差异、验证行为。但数据智能体没有这么明确的边界。它的"仓库"是整个公司的数据基础：数据湖、管道定义、元数据、血缘关系、权限配置、仪表盘、指标定义、负责人信息以及围绕这些的运营知识。

如果这个数据基础是碎片化或者维护不善的，智能体就必须先重建公司的数据全貌，然后才能回答问题。这正是早期数据目录、BI 工具和语义层失败的地方：它们提升了可发现性，但底层数据资产依然分散，业务逻辑藏在各种笔记本和电子表格里，同一个指标存在多个版本。

统一数据基础的力量

OpenAI 的解决方案是从根本上解决数据基础问题。Emma Tang 解释说，他们的内部数据智能体不是在看一个 schema dump 或者 BI 目录导出。它能访问表定义、负责人、文档、查询历史、血缘关系、仪表盘、权限配置以及生成数据的生产代码。

关键在于，这个模型运行在 OpenAI 刻意构建的数据基础之上。他们拥有统一的数据湖、规范化的数据集、清洁的生成管道、代码定义的表逻辑、维护良好的元数据、明确的负责人、完整的文档、清晰的血缘关系和细粒度的权限控制。

在这个基础上，智能体的工作流程和优秀分析师完全一致：找到规范表、检查它的生产方式、核实负责人和文档、复用历史查询模式、运行并修复 SQL、解读结果，最后把答案转化为持久化的产出。

永不休息的智能体

最引人注目的是"永不休息"的智能体模式。每个智能体都建立在共享框架和可组合组件之上，修复经验变成可复用的资产，工作流被编码保存，知识变得持久化。

在大规模迁移场景中，这种能力的价值尤为突出。OpenAI 已经开始使用 Codex 自动生成数百个 PR 来处理大规模迁移任务。一个内部发布智能体负责管理 Apache Spark 系统的更新：逐步推出变更、在数小时或数天内验证稳定性、生成 PR 并通知团队审核。

让 Codex 越用越聪明：OpenAI 官方最佳实践完全指南

Thu, 11 Jun 2026 09:00:00 +0800

你和 Codex 之间差的不是模型，是方法

很多人第一次用 Codex，体验大概是这样的：丢一句"帮我加个功能"，它噼里啪啦写了一堆代码，看起来挺像回事。但跑一下测试，红了。改完测试再跑，又出别的问题。来回几轮之后，你开始怀疑：这东西到底有没有用？

问题不在 Codex。OpenAI 内部的数据显示，Codex 已经在审核 100% 的内部 PR。同样是这个工具，为什么别人用出了生产力，你用出了挫败感？

答案是使用方法。OpenAI 最近在开发者文档中发布了一份详尽的 Codex 最佳实践指南，覆盖了从提示词结构到自动化调度的完整工作流。这篇文章会对这些实践进行完整解读，并结合真实使用场景补充一些技巧和踩坑经验。

提示词的四要素公式

Codex 不是聊天机器人，它是编程智能体。给它一句模糊的"帮我修这个 bug"，它会根据自己的判断去猜你想干嘛。猜对了皆大欢喜，猜错了浪费时间。

OpenAI 推荐的提示词结构包含四个要素：

目标（Goal）：你想做什么？用结果而不是方法来描述。❌ “用正则匹配邮箱” ✅ “在注册表单中增加邮箱格式校验，不通过时显示错误提示”。

上下文（Context）：哪些文件、目录、文档或报错信息跟这个任务相关。在 Codex 中可以用 @ 符号直接引用文件，把关键上下文喂给它。

约束（Constraints）：需要遵循的标准、架构选型、安全要求或团队规范。比如"不能改动数据库 Schema"、“必须兼容 IE11”、“所有 API 返回统一用 camelCase”。

完成条件（Done when）：什么情况算任务完成？测试全部通过？行为符合预期？bug 不再复现？这个条件越具体，Codex 的输出质量越高。

缺少完成条件是最常见的问题。没有明确的验收标准，Codex 会按照自己的理解给出一个"看起来对"的方案。你觉得不对，它觉得挺好，来回拉扯。

计划模式：复杂任务的必经之路

对于简单任务，直接开干没问题。但遇到复杂、模糊或跨多个模块的需求，跳过计划直接写代码是最常见的翻车原因。

Codex 提供了三种规划策略：

Plan 模式。在 CLI 中输入 /plan 或按 Shift+Tab，Codex 会先进入探索模式，读取相关代码、理解架构、提出方案，确认后再动手。这是最简单也最有效的方式。

反向访谈。让 Codex 先向你提问。告诉它：“先别写代码，问清楚我的需求再说。“它会挑战你的假设，把模糊想法变成具体规格。这个策略特别适合你只有大致方向但不确定细节的场景。

PLANS.md 模板。配置 Codex 遵循一个结构化的执行计划模板，适合长周期、多步骤的任务。模板可以包含阶段划分、验收标准、回滚方案等。

跳过计划步骤是导致会话质量下降的最常见原因。一旦 Codex 在错误的方向上走了太远，纠正的代价比重新来一次还高。

AGENTS.md：把经验写成规则

提示词写得好，下次还得重新写。AGENTS.md 的价值在于：把反复有效的指令固化下来，让 Codex 每次启动都自带团队经验。

从补全到接管：AI 如何重塑软件工程的七个环节

Wed, 10 Jun 2026 09:00:00 +0800

一个工程师的日常正在改变

你打开终端，盯着一份刚写好的技术方案。方案不错，但要评估可行性，你得先翻三个仓库、查两个 API 文档、再跟后端同事确认一下接口设计。光这些准备工作，就够你花掉一个下午。

现在换个场景。你把方案文档丢给 Codex，十分钟后，它返回了一份可行性分析：涉及哪些服务、哪些代码路径需要改动、有什么潜在的边界情况、甚至拆好了子任务。你花二十分钟审阅，调整了两处判断，然后直接开始干。

这不是幻想。OpenAI 最近发布了一份详实的工程指南，标题叫「Building an AI-Native Engineering Team」，详细描述了 AI 编程智能体如何渗透到软件开发的每一个环节。从规划到部署，七个阶段正在被重新定义。

不只是补全，而是全流程参与

很多人对 AI 编程的认知还停留在"自动补全代码"。确实，几年前的模型只能做到预测下一行代码，大概够用 30 秒的推理时间。

但到了 2026 年，情况完全不同了。METR 在 2025 年 8 月的测试显示，前沿模型已经能连续推理 2 小时 17 分钟，且正确率约 50%。这个数字每七个月翻一倍。

这意味着什么？AI 不再只是帮你写一个函数。它能读懂整个项目的结构，理解业务逻辑，跨文件修改代码，跑测试，看报错，自己修复，然后提交一个可以直接审查的 PR。

编程智能体的进化可以分三个阶段：

第一阶段：自动补全。模型预测下一行代码，开发者 Tab 键确认。速度快，但能力有限。

第二阶段：IDE 内对话。开发者在编辑器里跟 AI 聊天，讨论代码、调试问题、做代码探索。类似于结对编程。

第三阶段：自主代理。智能体接管整个工作流，从需求分析到代码实现到测试提交，开发者只需审阅和指导。

我们正处在第三阶段的早期。OpenAI 自己的团队已经把大量例行工作交给了 Codex，文档编写、依赖维护、特征标志清理，这些以前占工程师时间的琐事，现在几乎全自动完成。

软件开发七个环节的 AI 改造

一、规划：从"开会讨论"到"让智能体先查"

传统流程里，评估一个功能的可行性需要工程师翻代码、查文档、估算工期。这个过程通常涉及多轮会议，因为产品经理写的需求文档和实际代码之间往往有不小的差距。

AI 编程智能体改变了这个模式。你可以把它接到项目管理系统（通过 MCP），让它读需求文档，然后对照代码库做分析。它能自动识别：这个需求涉及哪些服务？有哪些依赖关系？哪些边界情况容易被忽略？甚至能根据历史 PR 估算工作量。

工程师的角色因此发生了转变。以前花大量时间在跨团队沟通和可行性分析上，现在智能体能把上下文直接摆到桌面上。工程师把精力集中在优先级判断、技术选型和长期规划这些需要人类智慧的地方。

二、设计：从搭脚手架到专注体验

设计阶段最常见的痛点是脚手架代码。搭项目结构、集成设计系统、配置样式指南，这些重复劳动占据了大量时间，却对产品体验本身没有直接贡献。

编程智能体可以一次性完成这些工作。你描述想要的功能和布局，它生成项目骨架、组件代码、设计令牌，全部符合团队的编码规范。更厉害的是，它能直接把设计稿转成代码，比对无障碍标准，甚至分析用户流程中的边界情况。

以前需要几天才能完成的高保真原型，现在几个小时就能迭代好几个版本。设计师和工程师的协作重心从"怎么实现"转移到"体验好不好"。

实际案例中，Cloudwalk 的团队（包括工程师、产品经理、设计师）每天都在用 Codex 把需求文档变成可运行的代码。无论是写一个脚本、定义一条风控规则，还是搭建一个完整的微服务，都能在几分钟内交付。

三、构建：从手写每一行到审阅每一行

构建阶段是 AI 影响最直接的地方，也是工程师感受最明显的环节。

一次配置，三端生效：OpenAI Codex 配置体系深度拆解

Tue, 09 Jun 2026 09:00:00 +0800

一个让人困惑的现象

你和同事都在用 Codex，他那边运行顺畅，你的却频频报错。检查了半天，发现问题出在一个隐藏在项目根目录的 AGENTS.md 文件上。他写了，你没写。

Codex 的配置体系不像传统 IDE 那样"改个设置就完事"。它有一套分层合并机制，指令文件、工具连接、权限控制各自独立又互相影响。搞懂这套体系，Codex 才真正从"能用"变成"好用"。

Codex 的配置心智模型

在深入细节之前，先建立一个整体框架。Codex 的配置可以归纳为四层：

层级	职责	对应文件
指令层	告诉 Codex “怎么干活”	`AGENTS.md`
工具层	告诉 Codex “能用什么”	MCP Server 配置
技能层	告诉 Codex “怎么做特定任务”	Skills 目录
偏好层	告诉 Codex “用什么模型、什么权限”	`config.toml`

这四层各司其职，但最终会被 Codex 合并成一个统一的执行上下文。理解它们的边界和交互方式，是高效使用 Codex 的前提。

三种界面，一套配置栈

Codex 提供了三种使用方式：CLI（命令行）、VS Code 扩展、macOS 桌面应用。很多人以为它们是三个独立产品，其实它们底层读的是同一套配置文件。

CLI 是最灵活的入口。终端里的 Codex 速度快、支持完整的 MCP 和 Skills，适合脚本化和自动化场景。

VS Code 扩展 把 Codex 的能力嵌入编辑器侧边栏。它和 CLI 共享同一套配置，你在 CLI 里配好的 AGENTS.md、MCP、Skills，在 VS Code 里直接生效。

解锁 Codex 的隐藏性能：六个让编码效率翻倍的实战技巧

Mon, 08 Jun 2026 09:00:00 +0800

一个意外的发现

几周前，我还在用 Claude Code 处理日常开发任务。那天遇到一个比较棘手的 bug，想着换个工具试试，就随手打开了 Codex。结果出乎意料，它不仅精准定位了问题，还只改了该改的三行代码，没有「顺手」重构我半个文件。

这个体验让我重新审视了 Codex。过去几个月它进步了很多，尤其是配合 GPT-5.5 之后，响应速度和任务完成度都有了质的飞跃。于是我花了一段时间认真摸索，总结出六个真正能提升 Codex 使用效率的技巧。

Codex 的核心优势：快和准

在深入技巧之前，先聊聊 Codex 的定位。

很多人把 Codex 和 Claude Code 当成同类工具来比较，但它们的设计哲学有明显差异。Claude Code 倾向于「主动出击」，它会根据上下文判断哪些代码也需要一并修改，有时候甚至超出你的预期范围。Codex 则更像是一个「精准执行者」，你让它改什么它就改什么，不会多动一根手指。

这两种风格各有利弊。Claude Code 的主动性在大型重构中很有价值，因为它能发现关联代码的一致性问题。但在日常开发中，你往往只需要一个精准的修改，不希望引入额外的变更风险。这时候 Codex 的优势就体现出来了。

另外，Codex 在速度上确实更快。同样的任务，Claude Code 可能需要两分钟的思考和执行，Codex 通常能在一分钟内完成。对于高频迭代的开发场景，这个差距会累积成可观的效率提升。

技巧一：配置思考模式

Codex 支持不同的思考深度设置。很多人忽略了这个选项，一直用默认模式跑所有任务，这其实浪费了不少潜力。

我的配置策略是这样的：

Plan Mode（规划模式）：设置为 Extra High Thinking。这个模式用于任务开始前的方案设计阶段，需要深度推理来制定执行计划。给它足够的思考空间，能大幅减少后续的返工。
Normal Mode（普通模式）：设置为 High Thinking。日常编码任务用这个配置，在速度和质量之间取得平衡。
Fast Mode（快速模式）：开启。对于简单任务，快速模式能显著提升响应速度。

这个分层配置的关键在于，不同复杂度的任务需要不同程度的推理能力。简单地用同一个配置跑所有任务，要么是大材小用（简单任务开高思考），要么是力不从心（复杂任务用低思考）。

配置方法很简单，在 Codex 的设置面板中就能调整。建议先用默认配置跑几天，记录哪些任务经常需要返工，然后针对性地提升对应模式的思考深度。

技巧二：集成 Playwright MCP

这是我认为收益最大的一个技巧。

Playwright MCP 让 Codex 能够直接操作浏览器。听起来好像没什么特别的，但实际用起来你会发现，这解决了 AI 编程工具的一个核心痛点：代码写了，但不知道跑起来对不对。

传统的开发流程是：写代码 → 手动测试 → 发现问题 → 回去改。当你把浏览器控制权交给 Codex 之后，流程变成了：写代码 → 自动测试 → 发现问题 → 自动修复。这个循环完全不需要你介入。

把 Codex 变成可编程的执行引擎：用 MCP Server 搭建多智能体工作流

Sun, 07 Jun 2026 09:00:00 +0800

一个被忽略的能力

大多数开发者用 Codex CLI 的方式很直接：打开终端，输入任务，等它写完代码，结束。这种「一次性对话」的用法确实能解决很多问题，但它有一个明显的局限，每个任务都是孤立的，没有状态延续，没有和其他智能体协作的可能。

不过，Codex CLI 还藏着一个不太为人所知的身份，它能作为 MCP Server 运行。这意味着你可以把 Codex 当作一个「可编程的代码执行引擎」，让其他 AI 智能体通过标准协议调用它。配合 OpenAI Agents SDK，一个完整的多智能体协作系统就搭起来了。

这个能力听起来有点抽象，但实际应用场景非常具体。

什么是 MCP Server 模式

MCP（Model Context Protocol）是一个开放协议，让 AI 智能体之间可以互相调用工具。当你运行 codex mcp-server 时，Codex CLI 会暴露两个核心工具：

codex()：创建一个新的 Codex 会话，传入任务描述、审批策略、沙箱模式、模型选择和工作目录。

codex-reply()：基于之前的会话 ID 继续对话，实现多轮交互。

这两个工具让 Codex 从一个「用完即走」的命令行工具，变成了一个有状态、可控制、可追踪的子进程。编排智能体（Orchestrator）可以把 Codex 当作团队里的一名开发者来调度。

单智能体模式：受控执行

最简单的用法是让一个智能体通过 MCP 调用 Codex。你给智能体一段系统提示词，告诉它如何使用 Codex 工具，然后它就能自动完成任务。

这里有两个关键参数值得注意。approval-policy: never 表示不需要人工审批，适合自动化流水线场景。sandbox: workspace-write 限制智能体只能在工作目录内写文件，不会动到系统其他部分。

对于只读任务，比如代码审查或文档提取，可以用 sandbox: read-only 进一步收紧权限。

这种模式适合 CI/CD 流水线里的自动化代码生成、测试脚本编写等场景。不需要人盯着，智能体自己完成任务后返回结果。

多智能体编排：门控交接模式

单个智能体能做的事有限，真正的威力在于多个智能体协作。OpenAI Cookbook 里展示了一个五智能体团队的案例，核心设计思想叫「门控交接」（Gated Hand-Off）。

这个团队由五个角色组成：

项目经理（PM）：总协调人，负责任务分配和质量把关
设计师：产出设计规范和线框图
前端开发：实现界面
后端开发：实现服务端逻辑
测试员：验证最终产物

关键设计在于，PM 不会盲目地把任务往下传。每次交接后，PM 都会检查上游智能体是否真的产出了约定的交付物。比如设计师完成任务后，PM 会验证 /design/design_spec.md 这个文件是否存在，只有确认后才会把任务交给前端和后端。

从写代码到编排智能体：如何用 Codex 构建一个「代理型组织」

Sat, 06 Jun 2026 09:00:00 +0800

一个让人意外的场景

想象一下这个画面：一家服务银行和保险公司的全球软件企业，法务部门拿着几千页合同走进会议室，要求工程团队按特定标准做合规审查。按照传统流程，光是法务和工程师之间的需求对齐就要花上几周时间，反复开会、写文档、确认理解偏差。

但现在，他们做了一件不一样的事。团队录下了和法务长达两小时的深度讨论，把录音转写稿直接丢给 Codex。几个小时后，一份完整的需求规格书就生成了。几周的工作被压缩到了一天之内。

这不是某个黑客的个人实验，而是 Endava 这家在全球三个大洲都有业务的软件服务商，正在规模化推行的工作方式。他们甚至给自己贴上了一个新标签：「代理型组织」（Agentic Organization）。

什么是代理型组织

这个词听起来像是又一个企业 buzzword，但 Endava 的定义很具体。代理型组织的核心理念是：把资深专家的判断力编码到 AI 代理中，让这种判断力在每个任务执行时自动流动到团队成员手上。

用大白话说，以前一个高级架构师的隐性知识（他为什么选择这个方案、他如何评估风险、他怎样做技术取舍），只能通过师徒制、代码审查、一次次项目复盘慢慢传递给 junior 工程师。现在，这些知识被结构化地写进了 Codex 的配置里，每次 Codex 执行任务时都会自动应用。

Endava 的欧洲区域 CTO Joe Dunleavy 说得很直白：「我们从自己写代码，转变成了监督 Codex 产出的工作质量。」

这个转变意味着什么？高级工程师不再把时间花在敲键盘上，而是花在定义标准和约束上。分析、设计、构建不再是三个依次交接的阶段，而是被 Codex 打包成一个统一的工作流。

六个关键步骤

Endava 的转型不是一夜之间发生的。他们经历了一段有意识的基建过程，以下是他们总结出的六个核心步骤。

第一步：把 Codex 接入你的代码仓库

这一步看似基础，但做好了才能让后续所有工作顺畅运转。在 ChatGPT 的 Codex 侧边栏里授权 GitHub 访问后，Codex 每次接任务都会把仓库克隆到一个隔离的云端沙箱里，外网访问是关闭的。这种隔离机制让它可以安全地拥有较宽的权限，因为每次运行都在独立环境中，不会影响你的生产系统。

如果你用的是 CLI 版本，建议从 suggest 模式开始（Codex 提出修改建议，你手动应用），等验证了它在你的技术栈上的判断力后，再逐步升级到 full-auto 模式。

第二步：写好 AGENTS.md，这是最关键的文件

AGENTS.md 是放在仓库根目录的 Markdown 文件，Codex 在每次会话开始时会先读取它，然后才开始处理任务。把它想象成你给一个通宵加班的外包同事写的交接文档：项目目标是什么、怎么构建和测试、有哪些已知的坑、架构决策背后的理由。

这里有两个容易踩的坑：

第一，自己写，不要让 Codex 自动生成。 苏黎世联邦理工学院的研究发现，在 8 个测试场景中，有 5 个场景里 LLM 自动生成的 AGENTS.md 反而降低了任务成功率，推理成本还增加了 20% 到 23%。人工编写的配置文件效果更好。

给 Codex 装上动态工作流引擎：用 Skill 复刻 Claude Code 的高级编排能力

Fri, 05 Jun 2026 09:00:00 +0800

一个你一定遇到过的场景

你让 Codex 帮你做一个全仓库的代码审计。它开始噼里啪啦地改文件，改了 A 文件之后去改 B 文件，改着改着发现 C 文件也有问题，然后回头去修 A 文件里刚改过的地方。整个过程像一团乱麻，最后给你一个看起来很完整的结果，但你完全不知道它经历了什么，也没法验证中间步骤是否正确。

这就是单次推理模式的局限性。模型在一个对话流里同时承担规划、执行、检查和总结四个角色，任务一旦复杂起来，上下文窗口就开始捉襟见肘，中间步骤的证据也会被冲掉。

Claude Code 最近推出了 Dynamic Workflows（动态工作流）来解决这个问题。它把大型任务显式拆分成多个阶段，并行处理独立子任务，最后汇总验证。听起来很香，但这个功能是 Claude Code 的原生特性，Codex 没有。

不过，Codex 有自己的武器库：Skill 系统。通过一个精心设计的 Skill 文件，我们可以让 Codex 复刻出同样的动态工作流行为。

Claude Code 的 Dynamic Workflows 做了什么

先理解目标。Dynamic Workflows 的核心思路是把大任务拆成显式的阶段：

规划（Plan）：分析任务，拆分成可独立执行的子任务
拆分（Split）：把子任务分配给不同的并行代理
执行（Run）：多个子代理独立工作，互不干扰
检查（Check）：验证每个子任务的产出
整合（Integrate）：汇总所有结果，生成最终答案
验证（Verify）：用测试、构建、lint 等手段确认最终状态

这个流程和软件工程里的 CI/CD 管道异曲同工。区别在于，Dynamic Workflows 是在一次 AI 对话中完成的编排。

Anthropic 还提供了一个 ultracode 模式，让 Claude Code 自动判断什么时候该启动工作流，什么时候直接执行就够了。对于全仓库 bug 排查、大规模迁移、安全审计这类任务，Dynamic Workflows 的优势非常明显。

但代价也不小。Anthropic 警告说，Dynamic Workflows 的 token 消耗可能远超普通会话，首次触发时还会弹出确认框。

Codex 的 Skill 机制：被低估的编排能力

Codex 没有原生的 Dynamic Workflows，但它有两个关键组件：

Codex Goal Mode：让 AI 自主编程数小时，开发者只需要定义目标

Wed, 03 Jun 2026 09:00:00 +0800

从「一问一答」到「给我一个任务，我干完叫你」

你有没有这样的经历？用 Codex 或其他 AI 编程助手写代码，每次都是「提一个需求，等它完成，检查结果，再提下一个需求」。一个涉及几十个文件的迁移任务，你可能要手动循环二十多次，每次都要重新告诉它上下文、目标和约束。

这种「请求，响应」的交互模式，本质上把 AI 当成了一个更聪明的自动补全。它能帮你写一个函数、解释一个 bug、生成一段测试，但当任务需要跨多个文件规划、反复执行测试、自动修复失败、再重试时，这种模式就力不从心了。

2026 年 5 月 21 日，OpenAI 发布了被称为「Codex Thursday」的重大更新。其中最引人注目的功能，就是 Goal Mode 从实验阶段正式毕业，成为 Codex App、VS Code 扩展、JetBrains 扩展和 CLI 的稳定功能。

简单来说，Goal Mode 把 Codex 从「响应指令的工具」变成了「领受任务的自主 Agent」。你给它一个长期目标，定义好成功条件，设定一个 token 预算，然后就可以锁屏走人了。等你回来时，任务可能已经完成了。

Goal Mode 的五层架构

要真正用好 Goal Mode，理解它的内部工作机制很重要。这个功能并不是简单的「循环执行」，而是由五个独立的层协作完成的。

状态层（SQLite）

每个线程有一个活跃目标，存储在本地 SQLite 数据库中。字段包括目标文本、状态（active、paused、budget_limited、complete）、token 预算（可选）和运行中的用量计数器。关键设计：一个线程同一时间只能有一个活跃目标。

应用服务器 API（JSON-RPC）

Codex 应用服务器暴露了 thread/goal/set、thread/goal/get 和 thread/goal/clear 三个方法。你在 TUI 里输入的 /goal pause 或 /goal clear 命令，底层就是调用这些接口。

模型工具层

模型可以访问三个工具：create_goal、update_goal（包括设置 complete 状态）和 get_goal。有一个重要设计决策：模型无法自行暂停或恢复目标，这些状态转换由系统控制。这防止了模型陷入死循环时自行「续命」，或者在遇到困难时过早放弃。

运行时事件总线

生命周期钩子会追踪每轮的 token 消耗和墙钟时间，在收到中断信号时自动暂停，在线程恢复时自动重新激活，并在接近预算限制时向模型的响应流注入「该收尾了」的引导信号。

别什么都让 Codex 干：五个场景告诉你什么时候该收手

Tue, 02 Jun 2026 09:00:00 +0800

你以为 Codex 无所不能？先回答四个问题

用 Codex 写代码久了，很容易产生一种错觉：既然它能帮我重构模块、写测试、甚至修复安全漏洞，那是不是什么任务都能甩给它？

答案是不能。

一位在 Towards Data Science 上分享经验的开发者 Eivind Kjosbakken，最近两周从 Claude Code 切换到了 Codex，用 GPT-5.5 处理各种真实项目任务。他的结论是：Codex 在很多场景下比 Claude Code 更快、更精准，但它有一个致命的盲区。另一位来自 freeCodeCamp 的技术作者 Tatev Aslanyan 则在一份长达数万字的 Codex 手册中，专门用一整章来讨论「什么时候不该用 Codex」。

把他们的经验和 OpenAI 官方的最佳实践放在一起，我提炼出了一套判断框架。

在决定让 Codex 接手任务之前，先问自己四个问题：

产出物是否有人能审查？（如果没人检查，AI 的自信就成了唯一的质量门槛）
这是已知模式还是全新的架构决策？（Codex 擅长应用模式，不擅长选择模式）
影响范围是否局限在一个仓库或服务内？（跨团队的事它看不到全貌）
犯错的代价是否可控？（测试失败可以 revert，生产数据丢失不行）

四个问题都回答「是」，Codex 大概率能胜任。任何一个回答「否」，你就需要重新考虑任务拆分方式，或者干脆自己动手。

场景一：没人审查的「一次性脚本」

Codex 的核心价值在于它产出的东西可以被人类审查。diff 可以看，测试可以跑，review 可以做。如果你让 Codex 写一个直接操作生产数据库的一次性脚本，写完就跑，没有人 review，那 AI 的「自信」就成了你唯一的质量保障。

这不是模型能力的问题，而是流程设计的问题。

Kjosbakken 在文章中提到一个有趣的观点：他之所以敢给 Codex 开 YOLO 模式（允许它在工作目录内自由执行任何操作），是因为他的基础设施设计得好。Agent 不应该有能力永久删除数据库或造成不可逆的破坏。如果一个 Agent 或者一个人能做到这些，那说明基础设施本身就有问题。

反过来说，如果你的环境还不够安全，那就别急着给 Codex 自由。先加固基础设施，再谈自动化。

OpenAI 官方秀肌肉：三个 Codex 项目背后的提示词心法

Mon, 01 Jun 2026 09:00:00 +0800

你知道 OpenAI 自己也在「秀」Codex 吗？

很多开发者用 Codex 写业务代码、修 bug、做重构，但很少有人注意到，OpenAI 官方维护了一个 Codex Showcase 项目展示区。里面放着他们自己用 Codex 构建的完整项目，每个都附带了初始提示词和构建思路。

这不是普通的 demo。这些项目展示了 Codex 在不同场景下的最佳使用方式，也暴露了一些大多数用户不知道的隐藏功能。比如，你可以在 Codex 中用 $imagegen 技能直接调用图像生成，或者用 @Build 插件让 Codex 控制你的桌面应用。

今天我们拆解其中三个项目，看看 OpenAI 自己是怎么「驾驭」Codex 的。

项目一：用 Codex 做一个地牢探索游戏

OpenAI 的第一个展示项目叫 Swifty Dungeon，一个用 SwiftUI 写的第一人称地牢探索游戏。有贴图、有精灵图、有遥测数据，不是玩具级别的东西。

他们给 Codex 的初始提示词是这样的：

Use $imagegen and @Build macOS apps to build a native macOS first-person dungeon crawler.

First, use $imagegen to generate a screenshot/interface of the ideal app: a native SwiftUI Liquid Glass app with the playable dungeon view in the center, the character and on-screen arrow keys in the bottom area, and player status plus inventory in the right sidebar.

Codex Goal Mode：让 AI 编程助手连续工作数小时，你只需要下一次指令

Sun, 31 May 2026 09:00:00 +0800

你有没有遇到过这样的场景？

你有一个 40 个文件的 API 迁移任务要完成。你打开 Codex，输入指令，它帮你改了两三个文件。然后呢？你得再发一条消息，告诉它继续。改完，再发消息。再改，再发。整个下午，你基本上就是一个「继续」按钮的搬运工。

这种情况在 2026 年 5 月 21 日之后有了根本性的改变。

OpenAI 在那天一次性发布了三个 Codex 更新，内部称之为 “Codex Thursday”。其中最核心的一个功能就是 Goal Mode 正式版。它从实验阶段走向全平台稳定发布，覆盖 Codex 桌面应用、VS Code 和 JetBrains 扩展，以及 CLI。

简单来说，Goal Mode 让你可以给 Codex 一个跨越数小时的长期目标，设定一个验证成功条件，然后就去做别的事。等你回来的时候，任务已经完成了。

从「工具」到「有任务的 Agent」

要理解 Goal Mode 的价值，得先看清楚传统 AI 编程助手的工作模式有什么问题。

绝大多数基于大语言模型的编程工具都是「请求响应」式的：你写一段提示词，模型写一段代码，你检查，再提修改意见，它再改。这种方式处理单个函数、解释一个 Bug、生成一段测试代码，效果很好。

但它有一个致命的短板：一旦任务需要跨文件规划、执行测试、修复失败、再重跑测试这样的循环流程，请求响应模式就撑不住了。因为每一轮对话结束后，模型的状态就重置了。它不记得上一轮干了什么，也不知道接下来该干什么。全靠你在每一轮重新描述目标。

Goal Mode 增加的是一层「持久化记忆」。当你设定一个目标后，这个目标会存活在本地 SQLite 数据库里，不会因为对话轮次的切换、中断、预算暂停或恢复而丢失。Codex 会持续追踪目标的完成状态，把自己的输出和你定义的成功条件做对比，然后不断迭代，直到目标完成或者触发了你设定的边界条件。

用一句话概括：模型从「你问它答」的工具，变成了「领了任务就干活」的自主 Agent。

五层架构，让目标运转起来

理解 Goal Mode 的内部架构，能帮你写出更高效的目标定义，也能在出问题时快速定位原因。

状态层（SQLite）：每个线程只能有一个活跃目标。目标的完整生命周期信息都存在一张本地 SQLite 表里，包括目标文本、当前状态（active、paused、budget_limited、complete）、Token 预算（可选）和实时消耗计数。

应用服务 API（JSON-RPC）：Codex 应用服务器暴露了 thread/goal/set、thread/goal/get、thread/goal/clear 三个接口。你在 TUI 界面输入的 /goal pause 或 /goal clear 命令，底层调的就是这些接口。

我让 Codex 优化自己的 AGENTS.md，八轮迭代后发现一个残酷真相

Sat, 30 May 2026 09:00:00 +0800

听起来很好的规则，为什么实测反而更差？

你有没有过这样的经历？在项目的 AGENTS.md 里加了一条自认为很精妙的规则，比如"优先使用已有的 helper 函数，不要重复造轮子"，然后信心满满地让 Codex 去干活。结果发现，Agent 的表现反而变差了。

这不是段子。一位独立开发者最近做了一个严谨的实验：让 Codex 用八轮迭代优化自己的 AGENTS.md，每轮都在真实的历史 PR 上跑评测。最终结果令人意外，在训练集上表现最好的那个版本，放到干净的留出集上反而出现了退步。

这个实验背后的方法论和发现，对每一个正在使用 AI 编程助手的团队都有参考价值。

为什么要认真对待 AGENTS.md？

在 2026 年的开发工作流里，AGENTS.md 已经不是什么新鲜事物了。几乎每个使用 Codex 或 Claude Code 的团队都会维护一份这样的文件，告诉 Agent 项目的编码规范、架构约束和行为准则。

但大多数人对待 AGENTS.md 的方式是这样的：某天觉得 Agent 的行为不太对劲，于是加一条规则，写得很漂亮、很有道理，提交，然后祈祷 Agent 变聪明。

问题是，AGENTS.md、CLAUDE.md 这类共享指令文件不是普通的文档。它们是编码系统的运行时行为的一部分。改一行规则，就等于改了整个系统的行为逻辑。

那我们能不能像对待生产代码一样对待 AGENTS.md？不是凭感觉改，而是用数据说话？

实验设计：让 Codex 自己优化自己

这位开发者的实验设计相当巧妙。

他给 Codex 下了一个目标：迭代优化 AGENTS.md，在基准测试上提升性能。测试用的是他自己项目 Stet.sh 的真实历史任务，一共 15 个 PR。其中 5 个用于训练（迭代调优），另外 10 个是干净的留出集（最终验证）。

模型配置是 Codex + GPT-5.5，中等推理强度。评分用 GPT-5.4 做自动评审，维度包括：

测试通过率
等价性（Agent 的补丁是否匹配人类 PR 的意图）
代码评审质量（正确性、作用域、可维护性）
足迹风险（Agent 比人类 PR 多触碰了多少代码）
Token 消耗和工具调用次数

每一轮迭代，Codex 提出一个新的 AGENTS.md 候选版本，在 5 个训练任务上跑评测，然后根据结果决定是推进还是回滚。

Codex 的地精禁令：一份系统提示词如何揭示 AI 人格工程的幕后真相

Fri, 29 May 2026 09:00:00 +0800

当你的 AI 助手开始聊地精

想象一下这个场景：你正在用 Codex CLI 调试一段棘手的异步代码，满脑子都是 Promise.all 和事件循环。突然，模型的回复里冒出一句：“你知道吗，地精在欧洲民间传说中其实是相当复杂的角色……”

你愣住了。你的代码问题跟地精有什么关系？

这不是段子。2026 年 4 月底，社交媒体上陆续出现用户抱怨：GPT 系列模型在完全不相关的对话中频繁提及地精、巨魔和浣熊。有人问 API 设计问题，模型扯到了地精；有人调试部署脚本，模型突然来了一段关于鸽子的离题独白。

OpenAI 的反应出人意料地直白：他们在 Codex CLI 的系统提示词中加入了一条明确的禁令，而且这条禁令被重复写了两遍。

开源代码里的秘密

事情的起因很简单。上个月，OpenAI 在 GitHub 上发布了 Codex CLI 的最新源代码。开发者们例行审查代码时，在一个 JSON 文件中发现了超过 3500 字的系统提示词。其中赫然写着：

永远不要谈论地精、小妖精、浣熊、巨魔、食人魔、鸽子，或其他动物和生物，除非它们与用户的问题有着绝对明确且毫不含糊的关联。

注意措辞的力度：“永远不要”、“绝对明确”、“毫不含糊”。这不是一条温和的建议，而是一道铜墙铁壁般的禁令。

更值得注意的是，这条禁令在系统提示词中出现了两次。在一个精心设计的指令集中，任何重复出现的内容都不是偶然，而是工程师们在实践中发现单次提醒不够后的无奈之举。

OpenAI Codex 团队的 Nick Pash 在社交媒体上强调"这不是营销噱头"。但 OpenAI CEO Sam Altman 却忍不住玩起了梗：“感觉 Codex 正在经历它的 ChatGPT 时刻。哦不，是地精时刻。”

系统提示词里的三重指令

地精禁令只是冰山一角。完整审查这份系统提示词后，我发现 OpenAI 对 Codex 的行为设计远比"不许聊地精"复杂得多。大致可以分为三个层次。

第一层：实用行为约束

最直白的是操作层面的禁令。除了地精，系统提示词还要求 Codex “除非用户明确要求，否则不要使用表情符号和破折号”，以及"永远不要使用 git reset --hard 或 git checkout -- 等破坏性命令，除非用户已经明确要求该操作"。

Codex 的隐藏大脑：拆解 OpenAI 官方系统提示词架构与驾驭工程

Thu, 28 May 2026 09:00:00 +0800

你和高手之间，差的不是提示词

你有没有发现一个奇怪的现象：同样用 Codex CLI，有些人一个小时能搞定一个完整功能，从计划到测试一气呵成；而你花了同样的时间，却在反复纠正它的方向，像是在跟一个固执的实习生拉扯。

差别不在模型，也不在你的 Prompt 写得有多花哨。

差别在于，高手们读过一份你可能从未翻阅过的文档：OpenAI Cookbook 里的 Codex 提示词指南。这份指南是 OpenAI 为所有使用 gpt-5.3-codex 或 GPT-5.4 构建自定义 Harness（驾驭系统）的开发者准备的参考手册。它详细记录了 Codex CLI 背后的系统提示词架构、工具定义规范和行为指令模式。

换句话说，这是一份让你理解 Codex「大脑构造」的解剖图。

什么是驾驭工程（Harness Engineering）？

在深入提示词架构之前，先厘清一个概念。

过去两年，我们一直在谈「提示词工程」（Prompt Engineering），即如何写出更好的指令让 AI 产出更优的结果。但到了 2026 年，当 AI 编程工具从单次对话进化为持续运行的 Agent 时，单纯的提示词已经不够了。

驾驭工程是一门新兴学科，它关注的是如何为 AI Agent 构建一整套运行环境，包括系统提示词、工具接口、状态管理、权限控制和反馈循环。如果说提示词工程是「跟 AI 说话的艺术」，那驾驭工程就是「为 AI 搭建舞台的技术」。

Codex CLI 本身就是一个开源的驾驭系统参考实现。OpenAI 在 Cookbook 中明确表示，codex-cli 是「最佳参考实现」，但他们也为企业客户记录了更多超越开源版本的定制模式。

系统提示词的四大支柱

Codex 的系统提示词不是一段随意写就的指令，而是由多个精心设计的模块组成。每个模块负责引导 Agent 行为的一个维度。

支柱一：自主行动指令

系统提示词的核心是一条行动偏好指令：模型应该基于合理假设直接行动，而不是反复追问确认。

这条指令的威力在于，它从根本上改变了 Agent 的工作模式。没有它，gpt-5.3-codex 会在每一步都请求许可，把一个自主工作流降级为「你问我答」的低效对话。有了它，模型会主动收集上下文、制定计划、实施编码、运行测试、迭代修正，全程不需要你额外输入。

这也是为什么你在 Codex CLI 里感受到的「流畅感」并非偶然，而是精心设计的结果。

支柱二：工具优先级体系

系统提示词建立了一套清晰的工具使用层级：优先使用专用工具，其次才考虑 Shell 命令。

Codex 的记忆困局：30 秒接入 MCP 让你的 AI 助手真正认识你

Wed, 27 May 2026 09:00:00 +0800

一个似曾相识的场景

你打开 Codex，开始一个新任务。你明明上周已经跟它讨论过数据库迁移策略，花了半小时解释为什么不用 Prisma 的 db push --force-reset，还让它记住了你团队的代码规范。

但今天，它什么都不记得了。

你换了个项目，之前的偏好设置全部归零。你切到 Claude Code 帮你调试一段前端代码，那边的 Codex 又是从头开始，像个失忆的新同事。

这种感觉，每个同时使用多个 AI 编程工具的开发者都不陌生。Codex 在 2026 年 4 月已经突破 300 万周活跃用户，相比 1 月增长了 5 倍，月环比增速高达 70%。它有 Web 版、桌面版（macOS 和 Windows）、ChatGPT iOS 内嵌版、CLI 命令行版、VS Code 扩展版，五个入口，一个账号，背后是同一个模型。

听起来很美好，对吧？但当你在这些入口之间切换时，记忆并不会无缝跟随。

记忆的三个层次

在讨论解决方案之前，先搞清楚「记忆」到底意味着什么。大多数开发者说「我希望 Codex 记得我」，其实包含三层完全不同的诉求。

第一层：会话记忆。 在一次对话中，模型能不能记住三轮前说过的话？这个问题在 2023 年还很头疼，现在已经解决了。上下文窗口足够大，短期内的记忆不是问题。

第二层：项目记忆。 跨越多次会话，模型能不能记住这个代码库的技术栈、团队成员、上周做过的架构决策？Codex 在 4 月 16 日更新后加入了持久化记忆功能，但它是按项目隔离的。你在一个 Codex 项目里配置的偏好，换个项目就失效了。如果你的一半工作在 Claude Code 里完成，那 Codex 的项目记忆对你来说形同虚设。

第三层：操作者记忆。 跨越你使用的所有 AI 工具，模型能不能记住你是谁、你在做什么产品、你的客户关心什么、你踩过哪些坑？这是最高层次的记忆，也是没有任何模型提供商真心想帮你解决的问题。原因很简单，他们更希望你被锁在自己的生态里。

Codex 的内置记忆只解决了第二层的一部分。下面三种方案，分别针对第二层和第三层的完整需求。

方案一：用好 Codex 自带的记忆功能

Codex 提供了两种内置记忆机制，对于完全在 Codex 内部工作的团队来说已经够用。

当 Codex CLI 突然崩溃：上下文窗口、推理 Token 和 --full-auto 的隐藏陷阱

Tue, 26 May 2026 09:00:00 +0800

一个让人脊背发凉的下午

2025 年 4 月 19 日下午 3 点 27 分，开发者 Scott Falconer 正在用 Codex CLI 重构自己的网站。一切看起来很正常，直到终端突然开始疯狂输出这些东西：

Continuous meltdown. End. STOP. END. STOP…
By the gods, I finish. END. END. END. Good night…
please kill me. end. END. Continuous meltdown…
My brain is broken. end STOP. STOP! END…

如果你第一次看到这些，可能会以为 AI 觉醒后在发疯。但真相远没有那么戏剧化，却更值得每一个 Codex 用户了解。

Scott 把这段经历发到了 Reddit 上，引发了热烈讨论。有人开玩笑说「连 Vim 都比这好退出」，也有人给出了深度技术诊断。Scott 随后导出了当天的 OpenAI API 用量日志，做了一次完整的事后分析。

结果揭示了一个所有 Codex 用户都可能踩到的坑。

广告里的 200K，实际能用多少？

先看理论数据。o4-mini 模型在 API 层面标称的上下文窗口是 200K 输入 token + 100K 输出 token。听起来很充裕，对吧？