Codex使用指南：掌握Agent工作流的五个关键概念

Codex的本质是Agent，不是聊天机器人

很多人第一次使用Codex时，会把它当作普通的ChatGPT来用——说一句话，期待它直接给出一个答案。但这种用法不仅浪费了Codex的能力，还可能带来真正的风险：一个不看项目就直接改代码的Codex，才是最危险的。

要理解这一点，需要先区分两种根本不同的AI系统。聊天机器人（如早期的ChatGPT对话模式）本质上是「一问一答」的无状态系统：输入一段文字，输出一段文字，每次交互相对独立。而**Agent（智能体）**则是具备「感知-决策-行动」闭环能力的系统——它能够主动调用外部工具、读取环境状态、根据中间结果调整下一步行动，并持续循环直到完成目标。这种模式在AI领域被称为ReAct（Reasoning + Acting）架构。

Codex正是基于这一架构设计的：它不仅能理解自然语言指令，还能调用文件系统、代码搜索、终端命令等工具，形成真正的「观察→思考→行动→再观察」循环。这也是为什么Codex更像一个会在项目里「边看边做」的Agent。它不是只靠语言回答问题，而是会读文件、搜代码、改文件、跑命令、看结果，然后继续调整。当你看到它先搜索、先打开文件、先看配置时，不要觉得它在绕路——这恰恰是它正确工作的方式。

理解Codex工作方式的五个关键词

要真正用好Codex，需要记住五个核心概念：Thread、Workspace、Tools、Patch、Verification。这五个关键词串起了Codex从接收任务到交付结果的完整链路。

Thread：保持上下文的连续性

Thread就是当前这次任务会话。同一个任务尽量放在同一个Thread里完成。你前面让它读过什么、它已经判断过什么，都会影响后面的动作。

Thread的重要性源于大语言模型的核心机制——上下文窗口（Context Window）。现代LLM在处理任务时，所有的「记忆」都存储在当前的上下文窗口中：包括之前的对话历史、已读取的文件内容、工具调用结果等。一旦开启新的Thread，这些信息全部清空，模型需要从零开始重新理解项目。对于代码Agent来说，上下文的连续性尤为关键——一个复杂项目的架构理解、模块依赖关系、已发现的潜在问题，都是Agent在工作过程中逐步积累的「工作记忆」。

比如前面已经分析过登录模块，后面再让它改登录按钮，它就能接着前面的上下文继续走。但如果你新开一个会话，它很可能要重新读项目——不是它变笨了，是上下文断了。频繁切换Thread不仅会让Agent重复做无用功，还可能因为丢失关键上下文而做出错误判断。专业的AI编程工作流通常建议：一个完整的功能开发或Bug修复任务，应该在同一个Thread内从头到尾完成。

Workspace：确认工作区和权限

Workspace是Codex当前看到的工作区。它能看到哪些文件，首先取决于你打开的是哪个目录；它能不能改文件、能不能跑命令，还要看当前权限和模式。

新手每次开始任务前都应该先确认两件事：工作区目录和操作权限。 可以直接问它一句，让它先报告工作区和文件结构，再决定后面要不要动手。这个简单的确认步骤能防住很多问题——目录开错了，后面做得越多错得越远。

Tools：关注工具调用的逻辑

Codex会调用各种工具：读文件是工具，搜索是工具，编辑文件是工具，运行测试也是工具。你不用害怕它使用工具，真正要看的是两点：

1. 它有没有先说明使用工具的理由
2. 用完以后有没有根据结果调整判断

这里有一个底层机制值得理解：Codex的每一轮工作循环（Agent Loop）包含「思考→工具调用→观察结果→再思考」四个步骤。先搜索、先读文件，这些都是Loop中必要的「观察（Observation）」步骤，而不是浪费时间。一个跳过观察直接给出结论的Agent，才是在走捷径、在猜测。

如果它没看文件就开始下结论，你可以打断它，让它先去搜相关文件，而不是凭项目惯例猜路径。一个不看项目就直接改代码的Agent才真的危险。

Patch：审查实际改动范围

Patch就是Codex真正改了什么。这一概念来自软件工程的版本控制实践——在Git等版本控制系统中，Patch指的是对代码库的精确差异描述：哪些文件被修改、哪些行被增删。

审查代码改动时，重点不是它说了什么，而是它改了哪些文件。「最小化变更（Minimal Diff）」是软件工程中的重要原则：每次修改应该只包含解决当前问题所必需的改动，不引入无关变更。在AI Agent场景下这一原则尤为重要——Agent可能因为「顺手」修复它发现的其他问题，导致改动范围超出预期；大范围改动还会使代码审查变得困难，一旦引入新问题也难以回滚和定位。

一个小需求如果突然动了十几个文件，就要停下来问清楚。你可以让它按文件逐一说明：这次为什么必须改？把非必要改动收敛到最小范围。改动越小，风险越可控。

Verification：改完必须验证

改完不验证就不算结束。在软件工程中，验证手段有严格的层次体系，从轻量到重量依次是：静态分析（Lint）——检查代码风格和潜在错误，无需运行代码；类型检查（Type Check）——如TypeScript的tsc或Python的mypy，验证类型安全性；单元测试（Unit Test）——验证单个函数或模块的行为；集成测试（Integration Test）——验证多个模块协同工作；端到端测试（E2E Test）——模拟真实用户操作验证完整流程。

验证不一定每次都跑全量测试——小任务可以跑Lint、跑类型检查，或者给出手动验证步骤。合理的做法是根据改动范围选择对应层次的验证：修改了一个工