1. 为什么超级个体这个概念突然和 Codex 绑在了一起这两年超级个体这个词被说烂了但真正落地的人不多。我观察下来卡点从来不是没有工具而是工具之间的缝隙没人填。你会用 Codex 写代码会用 DeepSeek 做推理会用某个自动化框架跑测试但这些都是孤岛。真正让一个人顶一个团队的是把这些孤岛串成一条自动流水线——而 Codex 智能体恰好是那条流水线的中枢神经。先说清楚 Codex 在这里扮演什么角色。它不是单纯的代码补全工具而是一个可以读写文件、执行命令、调用外部接口、按 AGENTS.MD 规则自主决策的智能体运行时。你给它一个任务描述它会自己拆解步骤、调用工具、验证结果、修正错误。这和传统你写一行它补一行的辅助模式有本质区别——前者是执行者后者是打字机。那多场景自动化生产又是什么意思我自己的理解是同一个 Codex 智能体内核通过不同的 AGENTS.MD 配置和工具挂载可以切换成测试工程师、运维值班员、数据管道工人、甚至客服质检员。场景在变但底层那套感知-决策-执行-反馈的循环不变。这就是为什么值得系统学一遍而不是零散地抄几个 prompt。这篇文章适合谁看如果你已经能跑通 Codex 的基础安装但不知道怎么把它变成生产工具而不是玩具那这篇就是写给你的。如果你还在纠结 Codex 和普通 AI 助手的区别我也会在第二节把这件事讲透。全文基于我自己搭过的一套多场景流水线来写涉及 AGENTS.MD 编写、DeepSeek 接入、自动化测试集成、以及几个我踩过的坑。提示本文所有配置和步骤都基于公开可获取的工具链不涉及任何特殊网络环境。你只需要一台能正常访问开发资源的机器即可复现。2. Codex 智能体和普通 AI 助手的本质分界线2.1 从对话到代理的范式转移大多数人第一次用 Codex 类工具还是把它当聊天窗口用问一句答一句复制粘贴结果。这种用法浪费了它 80% 的能力。智能体的核心特征是自主性——你给目标它给结果中间的过程它自己管。我举个具体例子。普通助手模式下你想让它帮你写一个 pytest 测试用例你得说帮我写一个测试 login 接口的 pytest 用例要包含正常登录和密码错误两种情况。智能体模式下你只需要说给 login 接口补测试覆盖率要上去它会自己去读代码、找接口定义、看现有测试风格、生成用例、跑一遍、发现失败、修掉、再跑。这个差异不是提示词技巧是运行时架构决定的。Codex 智能体之所以能做到这一点是因为它有几个普通对话模型没有的能力文件系统读写它能直接打开你的项目文件不是靠你粘贴。命令执行它能跑pytest、npm test、git diff看到真实输出。多轮自我修正第一次跑失败它会读错误日志改代码再跑直到通过或确认无法通过。AGENTS.MD 规则约束你可以用一份配置文件告诉它在这个项目里改代码前必须先跑测试提交信息必须符合某个格式。这四点加起来才构成代理的完整闭环。2.2 AGENTS.MD 到底解决了什么问题AGENTS.MD 是我认为 Codex 生态里最被低估的东西。很多人装了 Codex 就直接用从来没写过这个文件然后抱怨它老是不按我的规矩来。问题就出在这里——AGENTS.MD 是智能体的行为宪法。它的作用类似于给一个新员工写的《项目操作手册》。你不写它就按通用常识干活你写了它就在你的约束下干活。我自己的 AGENTS.MD 里通常包含这几块配置块作用我的实际写法示例项目结构说明告诉它代码在哪、测试在哪源码在 src/测试在 tests/配置在 config/命令白名单限定它能跑哪些命令允许 pytest、ruff、mypy禁止直接改数据库代码风格统一生成风格用 black 格式化行宽 100类型注解必须写提交规范约束 git 行为提交信息格式type(scope): desc禁区明确不能碰的东西不要修改 migrations/ 下的文件写 AGENTS.MD 有个反直觉的点写得越具体智能体越省心。新手容易写得很抽象比如代码要优雅这种话它没法执行。你要写函数不超过 50 行嵌套不超过 3 层公共方法必须有 docstring。可执行的规则才是好规则。2.3 为什么是 Codex 而不是别的市面上智能体框架不少Coze、Dify、各种 Python 自建方案都能做。但 Codex 的差异化在于它离代码最近。对于开发者来说80% 的自动化场景最终都要落到改代码、跑代码、验证代码上。Coze 这类平台适合做客服、做知识库问答但你要它帮你重构一个模块、修一个 flaky test它够不着。Python 自建智能体灵活度最高但你要自己处理工具调用、上下文管理、错误重试、状态持久化一套下来没两周搞不定。Codex 把这些基础设施都内置了你只需要写 AGENTS.MD 和挂工具。这就是平台智能体和代码智能体的分工差异——前者做业务编排后者做工程执行。我的建议是业务侧用平台智能体工程侧用 Codex。两者不冲突甚至可以互相调用。比如 Coze 上的客服智能体识别到用户报了个 bug可以触发一个 Codex 任务去复现和修复。这才是超级个体的完整形态。3. 从零搭一套 Codex 多场景流水线的完整路径3.1 安装环节最容易翻车的三个点Codex 的安装本身不复杂但我在不同机器上装过五六次每次都会遇到点幺蛾子。这里把高频问题列一下省得你一个个搜。第一个坑是 Node 版本。Codex 的 CLI 对 Node 版本有要求太老的版本会报奇怪的语法错误。我建议直接用 nvm 装一个 LTS 版本别用系统自带的。装完node -v确认一下低于 18 的话先升级。第二个坑是全局安装的权限问题。Linux 和 macOS 上直接npm install -g经常报 EACCES。两个解法要么配 npm 的全局目录到用户空间要么用 npx 直接跑不装全局。我倾向后者干净。第三个坑是首次运行的认证。Codex 第一次跑会引导你走认证流程这一步如果卡住八成是本地时间不对或者代理配置有残留。检查一下系统时间清掉环境变量里的HTTP_PROXY之类的东西。装完之后跑一个codex --version确认能输出再跑codex进交互模式随便问一句能正常回就说明基础环境 OK 了。3.2 把 DeepSeek 接进来做推理后端Codex 默认的后端不一定适合所有场景尤其是你要做大量中文推理或者成本敏感的时候DeepSeek 是个很划算的选择。接入方式是通过配置文件指定 API 端点和密钥。具体操作是在 Codex 的配置目录下建一个配置文件填入 DeepSeek 的 API 地址和你的 key。这里有个细节DeepSeek 的接口是兼容 OpenAI 格式的所以 Codex 那边只要按 OpenAI 兼容模式配置就行不需要改代码。配置大概长这样{ model_provider: deepseek, providers: { deepseek: { base_url: https://api.deepseek.com/v1, api_key: 你的密钥, model: deepseek-chat } } }配完之后跑一个简单任务验证比如让它读一个文件总结内容。如果报 401 就是 key 不对报 404 就是 base_url 写错了报超时就是网络问题。这三种错误我全遇到过排查顺序就按这个来。注意API 密钥不要硬编码在会提交到 git 的文件里。用环境变量或者本地配置文件并且把配置文件加进 .gitignore。3.3 AGENTS.MD 的实战写法从空文件到能干活我见过太多人 AGENTS.MD 写得像散文智能体读完一脸懵。正确的写法是结构化、可执行、有优先级。下面是我一个真实项目的 AGENTS.MD 骨架你可以直接抄去改。# 项目智能体操作手册 ## 项目概览 - 这是一个 Python 后端服务入口在 app/main.py - 测试框架用 pytest测试文件在 tests/ - 依赖管理用 poetry不要用 pip 直接装 ## 允许执行的命令 - pytest跑测试 - ruff check代码检查 - mypy类型检查 - git status / git diff查看状态 ## 禁止的操作 - 不要执行任何数据库迁移命令 - 不要修改 .env 文件 - 不要 force push ## 代码规范 - 所有公共函数必须有类型注解和 docstring - 单函数不超过 50 行 - 异常必须显式捕获不要裸 except ## 工作流程 1. 改代码前先跑一遍相关测试确认基线 2. 改完代码跑 ruff 和 mypy 3. 测试通过后再提交 4. 提交信息格式feat/fix/refactor(模块): 描述这份文件的关键在于每一条都是可判定的。代码要优雅不可判定单函数不超过 50 行可判定。智能体执行时可判定规则能直接落地不可判定规则它只能猜。3.4 多场景切换的核心机制多场景听起来玄乎实现上其实很朴素不同的项目目录放不同的 AGENTS.MD。你在 A 项目里跑 Codex它读 A 的规则表现得像个测试工程师在 B 项目里跑读 B 的规则表现得像个运维。同一个内核不同的约束就是不同的智能体。我目前维护着四套配置对应四类场景测试场景AGENTS.MD 强调覆盖率、边界条件、mock 规范工具挂 pytest 和 coverage。重构场景强调不改行为、小步提交、每步跑测试工具挂 git 和 ruff。文档场景强调从代码生成文档、保持示例可运行工具挂 mkdocs。运维场景强调只读优先、变更需确认、日志留痕工具挂 ansible 和 shell。切换场景就是cd到对应目录零成本。这比在一个项目里塞一堆条件判断优雅得多。4. 自动化测试场景的深度实操4.1 让 Codex 自己写 pytest 用例这是我觉得最爽的场景。以前写测试是体力活现在你只需要给 Codex 一个目标把 user 模块的测试覆盖率提到 80% 以上。它会做的事先跑一遍pytest --cov看当前覆盖率然后读 user 模块的源码找出没被覆盖的分支逐个生成测试用例跑一遍失败的自己修直到覆盖率达标。整个过程你只需要在它跑偏的时候拉一把。我实测下来一个中等复杂度的模块从 40% 覆盖率提到 80%Codex 大概需要 15 到 20 轮迭代耗时 10 分钟左右。人工写的话同样的量我至少要半天。效率提升是实打实的。但有个前提你的 AGENTS.MD 里必须写清楚测试规范。否则它会生成一堆风格不统一的用例mock 用得乱七八糟后期维护成本反而更高。我的规范里会明确用 pytest 的 fixture 管理依赖mock 用 unittest.mock断言用原生 assert 不用 assertEqual。4.2 处理 flaky test 的排查链路flaky test时好时坏的测试是测试工程师的噩梦。传统排查方式是反复跑、加日志、猜原因运气不好能耗一整天。用 Codex 可以把这个过程自动化。我的做法是给它一个任务tests/test_order.py 里的 test_concurrent_submit 间歇性失败找出原因并修复。它会连续跑这个测试 20 次统计失败率失败时抓取完整日志和堆栈分析失败模式是时序问题是共享状态是外部依赖提出假设并验证修复后回归跑 50 次确认稳定这个链路里第 3 步是智能体真正发挥价值的地方。人类工程师看日志容易陷入确认偏误智能体没有这个包袱它会老老实实对比成功和失败的差异。我遇到过好几次它找出的原因和我一开始猜的完全不一样。提示让 Codex 排查 flaky test 时一定要在 AGENTS.MD 里允许它跑循环命令否则它跑一次就停了统计不出失败率。4.3 测试数据生成的边界处理自动化测试绕不开测试数据。Codex 生成测试数据时有个通病喜欢造完美数据就是那种所有字段都合法、长度都刚好、格式都标准的数据。这种数据测不出边界 bug。我的解法是在 AGENTS.MD 里强制要求边界覆盖。具体写法## 测试数据规范 - 每个字段必须覆盖空值、最小值、最大值、超长值、特殊字符 - 字符串字段必须测试空串、单字符、超长串、含 emoji、含 SQL 关键字 - 数值字段必须测试0、负数、极大值、浮点精度边界 - 时间字段必须测试时区边界、闰秒、跨年加了这段之后Codex 生成的测试用例质量明显上了一个台阶。它开始主动构造; DROP TABLE users; --这种恶意输入开始测试datetime.max这种极端值。这些用例抓出过好几个我手写测试时漏掉的 bug。4.4 和现有 CI 流水线的对接Codex 跑完测试只是第一步最终要接进 CI。我的做法是让 Codex 生成一个 GitHub Actions 的 workflow 文件然后人工 review 一遍再提交。这里有个经验不要让 Codex 直接改现有的 CI 配置。CI 配置一旦改错整个团队的流水线都挂。正确姿势是让它生成一个新文件你对比确认后再合并。我在 AGENTS.MD 里专门写了禁止直接修改 .github/workflows/ 下的现有文件只能新建。生成的 workflow 我一般会检查这几点缓存配置对不对、并行度合不合理、失败通知有没有配、超时时间够不够。这几点 Codex 默认生成的版本经常有疏漏需要人工补。5. 那些文档里不会写的踩坑记录5.1 上下文窗口被撑爆的典型症状Codex 跑长任务时最容易出的问题是上下文窗口被撑爆。症状是跑到一半突然开始失忆忘记前面定好的规则或者重复做已经做过的事。根本原因是它把太多文件内容、命令输出、历史对话都塞进了上下文。我的应对策略有三条在 AGENTS.MD 里限定读取范围比如只读 src/ 下的文件不要读 node_modules 和 dist。让它在长任务中主动总结比如每完成一个子任务就写一个进度摘要到临时文件。拆任务不要让它一口气干完 20 个文件的改造分成 5 个一批。这三条里第三条最有效。我现在养成了习惯再大的任务也拆成小批次每批跑完人工确认一下再继续。看起来慢实际上因为减少了返工总体更快。5.2 命令执行权限的失控风险Codex 能执行命令这件事是双刃剑。方便是真方便危险也是真危险。我踩过一次坑让它清理临时文件它跑了个rm -rf把不该删的目录也删了。还好有 git恢复回来了。从那以后我在 AGENTS.MD 里加了硬约束## 危险操作确认清单 以下操作必须先向我确认不得直接执行 - 任何 rm 命令 - 任何 git push / git reset --hard - 任何涉及数据库的写操作 - 任何修改系统配置的操作 - 任何安装或卸载软件包的操作加了这份清单之后它遇到这些操作会停下来问我确认了才继续。多一步交互但安全得多。5.3 模型自信地犯错的识别与纠正智能体最坑的地方不是它不会而是它不会还特别自信。它会用非常肯定的语气告诉你这个函数返回的是列表实际上返回的是字典。你如果不验证就信了后面全错。识别这种错误的方法关键结论必须让它给出证据。我在 AGENTS.MD 里要求任何关于代码行为的断言必须附上文件路径和行号。这样它说这个函数返回列表时必须给出src/utils.py:42我点进去一看就知道对不对。纠正的方法是用测试说话。它说改好了你就让它跑测试。测试通过才是真的通过它的自我报告不算数。这一点我强调一百遍都不为过。5.4 多场景配置互相污染的排查前面说多场景靠不同目录的不同 AGENTS.MD 实现但这里有个坑Codex 会向上查找 AGENTS.MD。如果你在子目录跑它可能读到父目录的配置导致规则串味。我遇到过一次在测试项目里跑结果它按运维项目的规则干活死活不肯改代码。排查了半天才发现是父目录有个 AGENTS.MD 被继承了。解法有两个一是在子目录的 AGENTS.MD 里显式声明本配置完全覆盖父级二是干脆把不同场景的项目放在完全独立的目录树里不要有嵌套关系。我后来选了第二种一劳永逸。6. 把智能体变成生产工具的几个进阶思路6.1 用 hooks 做任务前后的自动检查Codex 支持在任务执行前后挂 hook这是把人肉 review变成自动 gate的关键。我的用法是任务前 hook检查 git 工作区是否干净不干净就拒绝执行避免污染。任务后 hook自动跑 lint 和测试不通过就回滚。这两个 hook 一加智能体的产出质量立刻稳定了。以前它偶尔会留下没格式化的代码或者跑不过的测试现在这些都被自动拦住了。hook 的配置写在 Codex 的配置文件里指定一个 shell 脚本路径就行。脚本里爱怎么写怎么写我一般就是几行命令拼起来。6.2 让智能体自己维护 AGENTS.MD这是个有点 meta 的玩法让 Codex 根据项目演进自动更新 AGENTS.MD。比如它发现项目里新增了一个测试框架就主动在 AGENTS.MD 里补上相关规范。实现方式是给它一个定期任务检查项目结构和 AGENTS.MD 的一致性发现不一致就提 PR。我跑了一个月它确实抓出了几处配置和实际不符的地方比如 AGENTS.MD 里还写着用 unittest实际早就换成 pytest 了。但要注意AGENTS.MD 的修改必须人工 review。它是智能体的行为准则被智能体自己改乱了就麻烦了。我设的规则是它可以提 PR但合并必须我点。6.3 多智能体协作的雏形单个 Codex 智能体能力有上限但多个智能体分工协作可以突破这个上限。我目前试过一个简单模式一个规划智能体负责拆任务多个执行智能体并行干活一个审查智能体负责验收。规划智能体读需求输出任务清单执行智能体各领一个任务在独立分支上干活审查智能体跑测试、看 diff、决定是否合并。这套下来一个中等规模的重构任务可以并行推进总耗时压缩到单智能体的三分之一左右。当然这套还不成熟主要问题是智能体之间的通信协议得自己定容易出岔子。但方向是对的值得继续折腾。6.4 成本控制的几个实用手段智能体跑起来 token 消耗是实打实的。我统计过一个中等任务大概消耗几十万 token按 DeepSeek 的价格算下来几毛钱不贵。但如果你让它跑大任务不设限一天烧掉几十块也正常。控制成本的手段限定读取范围别让它读无关文件。设置最大迭代次数跑超过 N 轮就停人工介入。用便宜模型做粗活用贵模型做细活。比如文件扫描用便宜模型代码生成用强模型。缓存常用上下文避免重复读取。这四条里第一条效果最明显。我见过一个案例智能体因为读了整个 node_modulestoken 消耗直接翻了十倍。限定范围后立刻降下来。7. 我个人的一些使用体会搭这套东西的过程中我最大的感受是智能体的上限不取决于模型取决于你给它的约束质量。同一个 CodexAGENTS.MD 写得好的和写得烂的产出质量能差出三倍。这就像带新人你把规矩讲清楚了他就能独立干活你含糊其辞他就天天来问你。另一个体会是不要追求全自动。我一开始想的是我下个命令它全干完结果发现全自动场景下出错率很高返工成本反而大。后来改成半自动——它干一段我确认一下再干下一段。总体效率反而更高因为错误在早期就被拦住了。最后一个建议从一个小场景开始。别一上来就搞多智能体协作、全流程自动化。先挑一个你天天做的重复劳动比如写测试、改 lint 错误、生成文档用 Codex 把它自动化掉。跑顺了再扩展。我见过太多人一上来就搭大框架搭到一半发现基础没打牢全推倒重来。这套东西后续还能往哪扩我目前在试的是把 Codex 和本地的一些自动化工具串起来比如让它触发 Appium 跑移动端测试或者让它根据监控告警自动生成排查脚本。这些场景还在打磨等跑稳了再单独写一篇。