最近很多人在讨论 Claude Code、Codex，甚至会把它们和 Cursor、Copilot 放在一起比较。
但如果你真的用过一段时间，就会发现：
Claude Code / Codex 和传统代码生成工具，根本不是同一类东西。
传统代码模型做的是：
输入需求 → 生成代码 → 结束
而 Claude Code / Codex 做的是：
理解任务
→ 分析项目
→ 制定计划
→ 修改代码
→ 跑测试
→ 观察结果
→ 修复问题
→ 继续执行
也就是说：
它们不是“更强一点的模型”，而是“工程级 Agent 系统 + 模型”。
一、为什么普通代码模型做不到？
以传统代码生成模型为例。
你输入：
帮我给 Spring Boot 项目增加 JWT 登录
它通常会直接返回：
- 一个 JwtUtil
- 一个过滤器
- 一个登录接口示例
然后就结束了。
但真实项目里，问题远没有这么简单：
- 当前项目是不是已经有登录体系？
- 用的是 Spring Security 还是 Sa-Token？
- token 应该放 Header 还是 Cookie？
- 需要改哪些文件？
- 改完之后能不能跑通？
普通模型不知道。
因为它没有“工程上下文”。
它只是在回答一个问题。
而 Claude Code / Codex，会真的进入你的项目：
扫描代码仓库
→ 找到现有登录逻辑
→ 判断技术栈
→ 修改多个文件
→ 启动项目
→ 运行测试
→ 如果失败，再继续改
这已经不是“生成代码”。
而是在“做开发”。
二、它们真正运行的，其实是一个 Agent Loop
如果把 Claude Code / Codex 的行为拆开，你会发现它们内部其实一直在跑这样一个循环：
while task_not_finished:
读取当前状态
制定下一步计划
执行动作
观察环境反馈
调整策略
对应到实际场景，大概就是：
1. 用户：帮我修复项目启动失败
2. Agent：
- 查看日志
- 发现 Bean 注入失败
- 找到配置文件
- 修改配置
3. 再次启动
4. 发现数据库连接失败
5. 修改 datasource
6. 再次启动
7. 成功
这里最重要的一点是：
它不是“一次回答”，而是在持续推进任务。
而这，才是真正的 Agent。
三、Claude Code / Codex 的核心，其实是 4 层架构
我觉得可以把它们抽象成这样一套结构：
State（状态）
→ Planner（规划）
→ Executor（执行）
→ Feedback（反馈）
下面逐层拆。
四、State：它们维护的不是 Prompt，而是“工程状态”
很多人以为 Agent 的状态，就是聊天记录。
但在 Claude Code / Codex 里，真正的状态其实包括：
- 当前仓库文件树
- 文件内容
- 最近修改了哪些文件
- 当前任务进行到哪一步
- 测试是否通过
- 编译是否成功
- 最近一次失败是什么
例如：
{
"task": "给项目增加 JWT 登录",
"finished": [
"识别认证逻辑",
"新增 JwtFilter",
"修改 SecurityConfig"
],
"failed": [
"Bean 循环依赖"
],
"next": [
"调整依赖注入",
"重新启动测试"
]
}
这意味着它不是每次都重新开始。
而是像一个真正的开发者一样，知道：
我已经做了什么、失败了什么、下一步该做什么。
五、Planner：它们真的会“拆任务”
很多人觉得“让模型一步一步思考”，就叫 Planning。
其实不是。
真正的 Planning，不是把过程写出来。
而是：
先拆解任务，再决定执行顺序。
比如你说：
把这个单体项目改造成 MVC + Service + Repository 架构
Claude Code / Codex 不会直接改。
它会先分析：
1. 哪些文件属于 Controller
2. 哪些逻辑需要抽到 Service
3. 哪些数据库操作需要放 Repository
4. 哪些依赖关系会受影响
5. 应该先改哪里，后改哪里
最终形成一个执行计划：
Step1: 拆 Controller
Step2: 抽 Service
Step3: 重构 Repository
Step4: 修复依赖
Step5: 跑测试
而且执行过程中，如果发现：
Repository 改完之后导致 Service 报错
它还会动态调整计划。
这已经非常接近你在做多 Agent / MCP 系统时强调的那种：
状态驱动 + 动态规划。
六、Executor：它们不是“调用工具”，而是在“操作环境”
传统 Tool Calling：
调用一个 API
→ 返回字符串
但 Claude Code / Codex 的 Executor 更像这样：
- read_file()
- write_file()
- edit_file()
- run_command()
- run_test()
- git_diff()
它们控制的是一个真实环境。
你可以把它理解成：
LLM 在驱动一个虚拟程序员。
它可以：
- 打开项目
- 查看代码
- 修改文件
- 执行 npm test / mvn test / pytest
- 看报错
- 继续修改
这一步为什么重要？
因为只有操作环境，Agent 才能真正获得反馈。
否则模型永远只能“猜”。
七、Feedback：它们为什么会越来越准？
Claude Code / Codex 最大的价值，不在于第一次就写对。
而在于它们会不断修。
典型过程：
修改代码
→ 执行测试
→ 测试失败
→ 分析报错
→ 修复
→ 再测试
→ 直到通过
这就是一个完整的闭环：
执行 → 观察 → 判断 → 调整
你会发现：
真正的智能，不是来自“生成”。
而是来自“交互”。
这也是为什么它们看起来越来越像一个真正的程序员。
因为程序员最核心的能力，从来不是一次把代码写对。
而是：
能根据结果不断修正。
八、它们其实很像“运行时强化学习”
为什么 Claude Code / Codex 会不断变好？
因为它们运行时，本质上一直在做：
尝试
→ 看结果
→ 调整策略
→ 再尝试
如果用强化学习的视角看，其实非常像：
Policy = 当前执行策略
Reward = 测试是否通过
Environment = 代码环境
所以某种程度上，可以这样理解：
Claude Code / Codex，其实是在“运行时模拟强化学习”。
区别只是：
它们不是靠训练阶段一次学会。
而是在执行过程中，不断迭代自己的策略。
九、为什么 90% 的 Agent 做不到？
因为大多数 Agent，缺了最重要的 3 个东西。
1. 没有真实环境
很多所谓 Agent，只是：
Tool → 返回文本
没有文件、没有代码、没有执行结果。
所以它根本不知道自己到底成功没有。
2. 没有持久状态
每一步都重新 Prompt。
模型每次都像第一次见到任务。
自然不可能持续推进。
3. 没有反馈循环
很多 Agent 的逻辑是：
执行一次 → 输出 → 结束
但真正的 Agent，一定需要：
while not success:
retry()
没有循环，就不会有真正的智能。
十、如果你想自己做一个 Claude Code / Codex 类 Agent，最少需要什么？
最小可用架构，我建议至少有这 5 层：
1. State Store
2. Planner
3. Executor
4. Environment
5. Feedback Loop
进一步，可以继续加：
- MCP：统一能力协议
- 多 Agent 协同
- 长期记忆
- 自动回滚
- 任务编排
最终会变成：
User
→ Agent
→ MCP
→ Environment / Tools
→ Feedback
→ Agent
这时，你做的就不再是一个“会调用工具的大模型”。
而是一个真正能持续完成任务的工程系统。
最后
Claude Code / Codex 最值得关注的地方，不是它们会写多少代码。
而是它们第一次让大家看到：
Agent 不再只是“问一句答一句”。
而是可以像真正的开发者一样，持续工作、持续修正、持续推进任务。
这可能才是下一代软件开发方式真正开始的地方。
