Codex 高级用法：从单兵作战到多智能体协作

一、入门：临时召集几个智能体并行工作

入门阶段不需要写配置文件，也不需要创建自定义智能体。 只要在提示词中明确要求 Codex： 启动几个子智能体；每个智能体负责什么；是否等待全部完成；最后如何汇总结果。 例如：

这已经算是在使用 Codex 的高级能力了。

1. 最适合并行的任务

子智能体优先适合互不依赖、以读取和分析为主的工作： 分别检查前端、后端和数据库；分别检查安全、性能和测试；同时阅读多个模块；分析大量日志；对比多种技术方案；搜索多个问题的原因；分别研究代码与官方文档。 例如排查一个保存失败的问题：

2. 入门阶段的核心原则

不要只说：

要明确给出分工：

子智能体的数量不是越多越好。任务没有明确边界时，多个智能体可能只是重复阅读相同代码，最后消耗更多 Token，却没有增加有效信息。

3. 入门阶段的价值

单智能体经常需要经历：

所有中间信息都会进入同一个上下文。随着日志、搜索结果和测试输出越来越多，真正重要的需求与约束可能被淹没。 子智能体可以把这些“脏活累活”放到独立线程中，只把结论和证据返回主线程，从而减少： 上下文污染；长对话中的信息衰减；无关日志对决策的干扰。

---

二、中等：让不同智能体承担不同角色

入门阶段是临时分工，中等阶段则是建立相对固定的协作模式。 Codex 内置了三种基础智能体：

智能体主要用途default通用任务与兜底worker实现功能、修改代码、修复问题explorer只读探索代码库、收集证据小编认为，这里面最重要的不是记住三个名字，而是理解： 探索问题和修改代码，最好不要从一开始就混在一起。

1. 先探索，再修改

比较稳妥的工作流是：

例如：

这样可以避免 Codex 刚看到一点线索，就迫不及待开始修改代码。

2. 按专业维度拆分代码评审

PR 评审是非常适合子智能体的场景。

每个智能体只检查一个方向，通常会比“请全面检查代码”更加聚焦。

3. 控制并行写入

多个子智能体可以同时读取同一个仓库，但不适合随意同时修改相同代码。 推荐并行： 搜索代码；调查问题；分析日志；查阅文档；执行互不干扰的测试；审查不同风险。 谨慎并行： 修改相同文件；调整公共类型；修改数据库结构；重构共享模块；执行会改变外部数据的操作。 如果确实需要并行开发，应提前划分文件边界：

4. 管理智能体线程

Codex 会为每个子智能体创建独立对话线程。在 CLI 中可以使用：

查看和切换正在运行的智能体。 还可以要求主智能体： 给某个子智能体追加要求；纠正正在偏离方向的智能体；停止没有价值的调查；等待所有智能体完成；关闭已经结束的线程。 这意味着子智能体不是一次性提示词，而是可以在执行过程中继续管理的协作者。文档原文

三、高级：创建自己的 Codex 智能体团队

高级阶段不再每次临时描述角色，而是把角色、模型、权限、工具和工作规范固化成配置。 自定义智能体可以放在：

或者项目内：

二者的区别是： ~/.codex/agents/：个人所有项目复用；.codex/agents/：跟随当前项目，由团队共享。 每个智能体使用一个 TOML 文件定义，至少包含：

1. 自定义只读探索智能体

这个智能体适合： 新项目代码探索；Bug 调用链追踪；大型仓库定位；修改前影响范围分析。

2. 自定义高风险评审智能体

这类角色不是通用 Reviewer，而是结合自己的业务场景定制。对供应链、财务、库存和电子发票系统尤其有价值。

3. 自定义实现智能体

4. 为不同角色配置不同模型

所有任务都使用最强模型，并不一定最划算。 可以按照任务特点分配：

任务建议配置搜索代码、整理文件快速模型 + 中低推理分析日志、查阅文档快速模型 + 中等推理普通功能实现主力模型 + 中等推理安全、并发、一致性评审主力模型 + 高推理复杂架构取舍主力模型 + 高或更高推理这相当于为 AI 团队安排不同等级的工程师，而不是让所有人都用相同成本处理所有事情。

5. 为智能体限制权限和工具

自定义智能体还可以独立配置： sandbox_mode：只读或允许写入；mcp_servers：允许访问哪些外部工具；skills.config：启用或禁用哪些技能；model：使用哪个模型；model_reasoning_effort：投入多少推理资源。 例如： Explorer 只能读取代码；Docs Researcher 只能查官方文档；Browser Debugger 可以操作浏览器，但不能修改代码；Worker 可以修改工作区，但不能发布；Reviewer 只能审查，不能“发现问题后顺手修复”。 权限限制本身也是角色设计的一部分： 不只是告诉智能体应该做什么，还要从能力上限制它不能做什么。

---

四、真正高级的不是“开更多智能体”，而是设计协作关系

小编认为，Subagents 最容易被误解成“多开几个 Codex”。 但多个智能体同时工作，不一定等于多智能体协作。真正需要设计的是它们之间的依赖关系。

模式一：并行调查

适合问题尚未定位时使用。

模式二：流水线协作

适合从调查到修复的完整开发任务。

模式三：多维评审

适合 PR、架构方案和上线前检查。

模式四：证据与执行分离

一个智能体负责收集证据，一个智能体负责做判断，另一个智能体负责执行。 这种模式可以减少“自己提出假设，再自己证明假设”的倾向。

参考：Codex 子智能体文档