自学教程

Codex 工作流模式

Codex 教程

Codex 工作流模式定义了智能体执行任务的自主程度、人工介入强度与交互范式。根据任务目标的不同，可以切换三种基础工作流：提问模式、任务模式、Agent 自主模式。三种模式并非相互隔离，支持在同一会话内互相切换，也可以组合形成混合工作流，适配从代码查询、局部开发到大型重构的各类工程场景。本文介绍三种模式的特点、使用方式、选择策略、Agent内部执行循环、混合工作流、常见问题与设计原则。

一、三种基础工作流总览

不同模式的核心差异体现在智能体自主程度、人工参与占比、风险等级三个维度。

模式自主程度人工参与典型适用场景
提问模式低高代码咨询、架构分析、项目学习、方案调研
任务模式中中明确的开发任务、Bug修复、新增功能，分步确认执行
Agent 自主模式高低多步骤复杂任务、大型迁移、批量自动化处理

模式切换有两种途径：一是使用斜杆命令 /mode 在会话内切换；二是通过 CLI 参数 --full‑auto 在命令行指定；也可以直接通过用户指令的表达方式隐性切换工作模式。

二、提问模式

提问模式是安全性最高的工作流。在此模式下 Codex 仅做信息输出与分析，不会修改任何文件，不会执行 Shell 命令，定位等同于技术顾问与代码阅读器。

2.1 核心特点

  • 仅做分析、解释、输出方案，不产生代码变更；
  • 不会写入文件、不调用高危系统操作；
  • 适合项目前期调研，在动手修改代码之前先理清项目逻辑；
  • 依然会占用会话上下文，大量对话会造成上下文膨胀。

2.2 使用示例

不需要特殊开关，只下发查询、分析类指令即进入提问模式。

> 解释 src/parser/mod.rs 的 AST 模块结构
> 分析这个项目错误处理的实现模式
> TypeScript type 与 interface 的核心区别是什么
> 梳理当前模块之间的依赖关系

最佳实践：复杂修改任务，优先使用提问模式完成项目理解与方案规划，确认无误后再切换到修改类模式。

三、任务模式

任务模式是日常开发中最常用的默认模式，兼顾自主性与可控性。Codex 接收具体开发需求，分步执行改动，关键变更会等待人工确认，不会无限制自主推进。

3.1 核心特点

  • 可以修改代码、生成文件、执行命令，但单任务范围受控；
  • 每完成一个子步骤后会返回结果，由人继续下达下一步指令；
  • 平衡效率与风险，适合绝大多数业务开发；
  • 遵循任务拆解四大原则：单一职责、明确边界、包含验证标准、参考现有代码风格。

3.2 使用示例

下发具体实现类任务，限定修改范围。

> 为 auth 模块增加 JWT 登录支持
> 修复 test_user_login 测试用例失败问题
> 将 class 组件改写为 React Hooks
> 为接口增加请求限流中间件

3.3 任务拆解示例

以“用户注册功能开发”为例，任务模式建议拆分为多步执行，不要一次性交付超大需求。

  1. 创建 User 数据模型，包含 email、password_hash、created_at 字段
  2. 实现 POST /api/register 注册接口，增加邮箱格式校验
  3. 使用 bcrypt 完成密码哈希处理
  4. 编写注册流程集成测试
  5. 补充邮箱验证逻辑

四、Agent 自主模式

Agent 自主模式拥有最高的任务自主权。接收整体目标之后，Codex 自主完成任务拆解、步骤规划、执行、验证、重试迭代，开发者主要审查最终结果。该模式效率最高，但风险也同步提升。

4.1 核心特点

  • 自主规划多步骤完整流程，自动执行、自动校验，失败自动重试；
  • 适合步骤固定、可回滚的大规模批量工作；
  • 风险较高，必须配合沙箱、审批策略，建议操作前做 Git 提交备份；
  • Token消耗更高，多轮执行迭代会快速占用上下文窗口。

4.2 启用方式

对话内斜杆命令或者 CLI 参数两种方式：

# CLI 启用全自主模式
codex --full-auto "将整个项目由 JavaScript 迁移到 TypeScript"

会话内斜杆切换：

/mode full‑auto

4.3 Agent 内部工作循环

Agent模式内部遵循固定闭环循环：接收任务 → 分析理解 → 规划步骤 → 执行步骤 → 验证结果。执行失败则修正重试；执行成功进入下一个步骤；全部完成之后汇总结果向用户汇报。

graph TB
 A[接收任务] --> B[分析理解]
 B --> C[规划步骤]
 C --> D[执行步骤 1]
 D --> E[验证结果]
 E --> F{执行成功?}
 F -- 否 --> G[修正重试]
 G --> D
 F -- 是 --> H[执行步骤 2]
 H --> I[继续迭代]
 I --> J[汇总结果]
 J --> K[汇报任务完成]

4.4 Agent模式任务示例

> 将 Express 项目迁移到 Fastify：
> 1.替换全部路由定义
> 2.更新中间件语法
> 3.修改应用启动脚本
> 4.保证全部测试用例通过
> 5.更新 package.json 依赖

五、模式选择策略

5.1 简易决策逻辑

任务类型？
├── 仅需要信息调研 → 提问模式
├── 需要修改代码
│   ├── 任务简单、边界清晰 → 任务模式
│   └── 复杂多步骤任务
│       ├── 步骤可预测、出错可以回滚 → Agent 自主模式
│       └── 业务风险高、需要人工判断 → 任务模式分步执行

5.2 模式选择矩阵

任务描述推荐模式选择原因
阅读、解释代码逻辑提问模式无需任何代码改动
修复单个简单Bug任务模式需求明确，分步可控
新增一个业务功能任务模式需要人工确认每一步变更
整个项目框架迁移Agent模式步骤多、流程标准化，可回滚
数据库结构迁移任务模式风险极高，分步确认
批量生成单元测试Agent模式大量重复标准化工作

判断是否适合Agent模式，可以自问三个条件：

  1. 任务执行步骤是否可预期；
  2. 出现错误是否可以方便回滚；
  3. 过程中是否不需要大量人工业务判断。
    全部满足适合Agent模式；存在不满足则优先任务模式。

六、混合工作流

真实工程很少全程使用单一模式，通常采用混合工作流：先用提问模式完成调研分析，再使用任务模式实现核心逻辑，最后使用Agent模式批量审查、批量修复。

混合工作流示例：

  1. 提问模式：分析项目现有认证架构
  2. 提问模式：调研JWT刷新令牌行业最佳实践
  3. 任务模式：实现JWT刷新令牌接口
  4. 任务模式：编写单元测试用例
  5. Agent模式：批量审查auth模块，修复全部安全隐患

七、安全与最佳实践

  1. 会话可以随时切换模式，使用 /mode 切换；上下文过于臃肿时，使用 /compact 压缩上下文或者新建会话 /new。
  2. Agent模式执行前建议Git提交快照，一旦出现非预期修改可以快速回滚。
  3. Agent模式不要用于数据库变更、核心配置修改等高风险任务，优先使用任务模式分步确认。
  4. 三种模式均需要人工复核输出结果，Agent自动执行不等于直接信任输出。
  5. 企业环境中，管理员可以通过requirements.toml限制是否允许开启full‑auto自主模式。

八、常见问题

Q：同一会话内能否切换工作模式？
A：可以。通过/mode斜杆命令切换，也可以通过指令风格隐性切换；切换模式不会清空当前会话上下文。

Q：Agent模式是否安全？
A：安全性取决于沙箱、审批策略与任务本身风险。高风险业务场景尽量避免无约束Agent模式；执行前做好Git备份。

Q：提问模式是否消耗token？
A：会。问答内容全部计入上下文，大量调研后建议压缩或者新建会话。

Q：哪一种模式token开销最低？
A：提问模式开销最低；Agent模式因为多轮执行‑验证‑重试循环，token消耗最高。

九、总结

Codex 包含提问模式、任务模式、Agent自主模式三类基础工作流，分别对应不同的自主等级与风险等级。提问模式用于调研分析，不改动代码；任务模式作为日常开发主力，分步确认，兼顾安全与效率；Agent自主模式面向标准化复杂多步骤自动化任务。实际工程开发中，更推荐混合工作流：先调研分析，再分步实现，最后批量审查。根据任务风险合理选择模式，配合沙箱、审批策略与Git备份，能够充分发挥Codex自动化能力，同时规避误修改带来的工程风险。

标签：

0 条笔记