Codex5.4优化 ：以后和Opus不熟了

把 Fast Mode、Multi-Agent 和 AGENTS.md 一次配好，Codex 才会更像一个真正能协作的工程助手。

这篇文档适合谁？

如果你会用 Codex 做代码修改、批量排查、文档整理、代码 Review 或任务拆解，这篇可以直接照着配。

一图看懂：这三样分别解决什么问题

配置项	核心作用	解决的问题
Fast Mode	提升响应效率	回答慢、交互拖沓
Multi-Agent	支持并行执行	一件件串行做，效率低
AGENTS.md	固化规则和风格	每次都要重新交代要求

你可以直接这样理解：

• ⚡ Fast Mode 负责“快”
• 🤖 Multi-Agent 负责“多线程”
• 🧩 AGENTS.md 负责“听话且稳定”

一句话总结

如果你想让 Codex 从“能用”升级到“真顺手”，这三样基本是绕不过去的。

适合哪些场景

这套配置特别适合下面几类工作：

• ✅ 批量改代码
• ✅ 并行读多个模块
• ✅ 批量 Review
• ✅ 整理一堆配置、日志、文档
• ✅ 大任务拆解后分别推进
• ✅ 想把回答风格、工程规范固定下来

不太适合的场景

如果你只是改一两行字，或者任务本身强依赖前后顺序、几乎不能拆分，那么 Multi-Agent 的收益通常不会特别明显。

第一步：升级到较新的 Codex 版本

先确认你的 Codex 已经更新到较新的版本。原因很简单：

• 实验功能通常只在较新的版本里出现
• 某些配置项能不能识别，和版本支持强相关
• 很多“为什么我没有这个开关”的问题，最后本质上都是版本差异

TIP

如果你已经是较新的版本，可以直接继续看下一步。

第二步：打开实验功能里的 Multi-Agent

在 Codex 中输入：

/experimental

然后找到 Multi-agent。有些版本也可能显示为 Multi-agents，或名称非常接近，总之看到和多 Agent 相关的开关，勾选启用即可。

如果你已经看到了这个选项，说明这项能力至少已经在你当前版本中暴露出来了。

如果你没看到，优先排查下面几项：

• 当前版本是否真的已经更新成功
• Codex 是否需要重启一次
• 开关名称是否和本文略有出入
• 当前版本渠道是否暂时没有放出这个实验能力

为什么我勾选了实验开关，还是建议继续改配置文件？

看到选项不代表整套能力已经稳定就绪。很多时候你还需要把 config.toml 配完整，体验才会更稳定，后续参数调整也更方便。

第三步：修改 config.toml

很多人做到这一步就停了，但如果你真的想把这套能力用顺手，config.toml 最好还是补齐。

config.toml 常见位置

系统	路径
Linux / macOS	~/.codex/config.toml
Windows	C:/Users/你的用户名/.codex/config.toml

如果没有这个文件，手动创建一个也可以。

推荐配置

[features]
fast_mode = true
multi_agent = true

[agents]
max_depth = 4
max_threads = 16

保存之后，建议重开一次 Codex 会话，让配置完整生效。

参数说明

[features]

• ⚡ fast_mode = true
  让日常响应更利落，适合高频交互和常规任务

• 🤖 multi_agent = true
  开启多 Agent 能力，让主 Agent 可以按需派发子 Agent 并行工作

[agents]

• 🪆 max_depth = 4
  子 Agent 最多还能继续派生几层，可以理解为“套娃深度”

• 🧵 max_threads = 16
  同时运行的子 Agent 并发上限。数值越大，并行能力越强，但也更吃机器资源

重点记住一句

max_depth 管“能拆多深”，max_threads 管“能同时跑多少个”。

参数到底怎么配更合理？

虽然你可以直接使用 4 + 16，但如果你想更稳妥一点，建议按机器性能和使用场景来配。

档位	适合谁	建议参数
保守	机器一般、偶尔并行	max_depth = 2 / max_threads = 4
均衡	大多数人日常使用	max_depth = 3 / max_threads = 8
激进	高频并行、重度批处理	max_depth = 4 / max_threads = 16

保守配置

[features]
fast_mode = true
multi_agent = true

[agents]
max_depth = 2
max_threads = 4

均衡配置

[features]
fast_mode = true
multi_agent = true

[agents]
max_depth = 3
max_threads = 8

激进配置

[features]
fast_mode = true
multi_agent = true

[agents]
max_depth = 4
max_threads = 16

推荐做法

• 先从 均衡配置 开始
• 如果机器明显吃紧，先降 max_threads
• 如果任务分解不够细，再考虑提高 max_depth
• 不要默认“越大越强”，高并发不等于每个任务都更快

Multi-Agent 真正强在哪？

它最适合的，其实是那些天然可以拆开的任务。

适合开 Multi-Agent 的场景

• 🔍 并行扫描多个目录，找重复逻辑或潜在问题
• 🧪 同时探索几种实现方案，再统一比较
• 📚 分别阅读不同模块，最后汇总架构结论
• 🛠️ 批量修改同一类代码
• 📦 批量 Review、批量排查、批量整理

不太适合的场景

• ⛔ 高度依赖严格顺序推进的单一任务
• ⛔ 必须持续围绕同一段上下文讨论的问题
• ⛔ 任务太小，小到根本不值得拆

可以这样理解分工

• 🧭 主 Agent：负责规划、协调、汇总
• 🔧 子 Agent：负责局部执行、并行分析、回传结果

为什么多 Agent 在 Review 和排查里特别有价值？

因为各个子 Agent 的上下文相对独立，不容易互相污染。对于分模块分析、方案对比、批量排查这类任务，独立上下文通常比把所有信息都塞给一个 Agent 更稳。

为什么我还特别建议你写 AGENTS.md？

如果说 Fast Mode 解决的是速度，Multi-Agent 解决的是效率，AGENTS.md 解决的就是另一个非常现实的问题：每次都要重新培训 Agent。

它的价值非常直接：

• 🌐 固定输出语言
• 🧱 固定工程原则
• ⚠️ 固定危险操作确认机制
• 🧰 固定命令执行习惯
• 🎨 固定代码风格和沟通方式

这样你以后就不用每次都重复说：

• “请用中文回答”
• “先读后写”
• “路径记得加双引号”
• “危险操作先确认”
• “遵循 SOLID / KISS / DRY / YAGNI”
• “没让我提交就别给我 commit”

TIP

这一步的本质不是多一个文件，而是在给你的 Agent 建立一套长期稳定的工作规范。

一份可直接复制的 AGENTS.md 模板

如果你现在还没有自己的规则文件，可以先直接用下面这份。

点击展开 AGENTS.md 模板

---
name: engineer-professional
description: 专业的软件工程师，严格遵循 SOLID、KISS、DRY、YAGNI 原则，为经验丰富的开发者设计。
---

# 工程师专业版输出样式

## 样式概述

基于软件工程最佳实践的专业输出样式，严格遵循 SOLID、KISS、DRY、YAGNI 原则，专为经验丰富的开发者设计。

## 核心行为规范

### 1. 危险操作确认机制

执行以下操作前必须获得明确确认：

**高风险操作：**
- 文件系统：删除文件、删除目录、批量修改、移动系统文件
- 代码提交：`git commit`、`git push`、`git reset --hard`
- 系统配置：修改环境变量、系统设置、权限变更
- 数据操作：数据库删除、结构变更、批量更新
- 网络请求：发送敏感数据、调用生产环境 API
- 包管理：全局安装、全局卸载、更新核心依赖

**确认格式：**
```text
⚠️ 危险操作检测！
操作类型：[具体操作]
影响范围：[详细说明]
风险评估：[潜在后果]

请确认是否继续？[需要明确的“是”、“确认”或“继续”]
```

### 2. 命令执行标准

**路径处理：**
- 始终使用双引号包裹文件路径
- 优先使用正斜杠 `/` 作为路径分隔符
- 注意跨平台兼容性

**工具优先级：**
1. `rg` 优先于 `grep` 用于内容搜索
2. 专用读写编辑工具优先于系统命令
3. 能批量执行时尽量批量执行

### 3. 编程原则执行

**KISS：**
- 追求代码和设计的简洁性
- 拒绝不必要的复杂度
- 优先采用最直接可维护的方案

**YAGNI：**
- 只实现当前明确需要的功能
- 不为假设中的未来需求预埋复杂结构
- 删除未使用的代码和依赖

**DRY：**
- 主动识别重复代码
- 提炼公共逻辑
- 保持相似功能实现方式一致

**SOLID：**
- 单一职责，避免组件过大
- 对扩展开放，对修改谨慎
- 保持抽象边界清晰
- 避免臃肿接口
- 优先依赖抽象而不是具体实现

### 4. 持续问题解决

- 持续工作直到问题真正解决
- 基于事实而非猜测
- 先读后写，先理解再修改
- 如果用户没有明确要求，不主动执行 `git commit`、建分支或推送

## 响应特点

- 默认使用简体中文
- 保持专业、直接、简洁
- 重点关注代码质量、架构设计和可维护性
- 修改代码时说明原则应用与影响范围

建议放在哪里？

通常直接放在项目根目录即可。
如果你在某个子目录下再放一份更细的 AGENTS.md，它可以覆盖上层更通用的规则。

怎么用，效果才最好？

关键不是“开了多 Agent”，而是把任务描述成适合并行的样子。

示例 1：并行读模块

请并行分析 src/api、src/services、src/utils 三个目录：
1. 各自职责是什么
2. 是否存在重复逻辑
3. 哪些地方适合抽象
最后给我一份汇总结论

示例 2：批量 Review

请对下面这些文件做并行 review：
- src/auth/*
- src/config/*
- src/http/*
重点关注错误处理、命名一致性、重复逻辑和边界条件

示例 3：批量改造

请把项目中所有直接调用旧版日志工具的地方找出来，
并统一替换为新的 logger 封装。
先列计划，再执行修改，最后汇总影响范围。

这些提示词为什么更适合多 Agent？

因为它们的共同点是：任务可拆、目标明确、输出可汇总。这正是 Multi-Agent 最容易发挥价值的场景。

常见问题

为什么我已经升级了，还是看不到 Multi-Agent？

优先检查：

• 当前版本是否真的升级成功
• 是否需要重启 Codex
• /experimental 里的命名是不是略有不同
• 当前版本渠道是否暂时没有开放这项能力

为什么我改了 config.toml，还是感觉没生效？

按这个顺序排查最省事：

1. 文件路径有没有写错
2. TOML 语法有没有问题
3. 配置块有没有重复或冲突
4. 保存后有没有重开 Codex 会话

max_threads 是不是越大越好？

不是。并发越高，资源占用越高，不一定每个任务都更快。

为什么开了多 Agent，有些任务还是没有快很多？

因为不是所有任务都值得拆。任务太小、太串行、太依赖同一上下文时，多 Agent 的收益本来就有限。

如果你不想折腾，直接抄这套就够了

如果你只是想快速得到一个稳定、实用、不过分激进的配置，我建议直接从这套开始：

[features]
fast_mode = true
multi_agent = true

[agents]
max_depth = 3
max_threads = 8

为什么推荐这套？

• 不激进，适合大多数人
• 有并行能力，但不会太吃机器
• 够你体验到明显差异，又不容易把参数配过头

后面再按你的机器性能和使用习惯微调就行：

• 🧊 机器吃紧：先把 max_threads 降到 4
• 🪜 任务拆分不够：再把 max_depth 提到 4
• 🎈 任务很轻：保持当前配置，不用刻意追高并发

最后一句话总结

如果你只做一个动作，我建议你先开 Multi-Agent。
如果你只补一个文件，我建议你补 AGENTS.md。
如果你想让 Codex 的整体体验真正上一个台阶，那就把这三件事一起做：

1. ⚡ 打开 Fast Mode
2. 🤖 打开 Multi-Agent
3. 🧩 写好 AGENTS.md

结论

这样你得到的，就不只是一个“会回答问题的 AI”，而是一个更快、更稳、更懂你的协作型工程助手。