有人在某社交媒体上说了一句很实在的话：
如果你觉得 Codex 设计得很好，架构处理和 edge case 都做得很好，你觉得你的 Agent 也应该和 Codex 一样设计——很简单，开个 goal，让 Codex 自己去读 GitHub 上 Codex 的源码，完全复刻成适合你业务的版本就行。
这不是开玩笑。Codex 的源码是 Apache 2.0 开源的，整个 Agent 的循环逻辑、工具调用、沙盒隔离、权限边界都写得清清楚楚。与其从零开始搭一个 Agent 框架，不如直接把成熟的设计搬过来。
这篇就是拆解 Codex 的架构，说清楚它为什么设计得好，以及怎么用它自己的模式复刻一个适合你业务的 Agent。
一、Codex 的架构到底好在哪
Codex 不是一个大语言模型套个壳。它的核心用 Rust 写的，代码结构非常清晰，可以按职责分成几层：
1. Core（核心）— Agent 的大脑
codex-rs/core/ 里是 Agent 的核心逻辑。包含系统提示词模板（gpt_5_codex_prompt.md）、Agent 循环（agent loop）、对话状态管理（codex_thread.rs）、上下文压缩（compact.rs）。Agent 怎么思考、怎么决定下一步，都在这层。
2. Exec（执行）— 动手干活的
codex-rs/exec/ 和 codex-rs/exec-server/ 负责实际执行命令。写文件、运行 shell、调 API。核心和执行分离，意味着 Agent 的逻辑和它对外部世界的操作是解耦的。
3. Tools（工具）— 可调用的能力
codex-rs/tools/ 定义了 Agent 能用的工具：文件读写、搜索替换（apply_patch.rs）、shell 命令、代码搜索。每个工具都是独立的模块，增加新工具不需要改核心逻辑。
4. Sandboxing（沙盒）— 安全边界
codex-rs/sandboxing/、codex-rs/linux-sandbox-rs/、codex-rs/windows-sandbox-rs/。Agent 的所有操作都在沙盒里跑。它不能随便删你硬盘上的文件。
5. Guardian（守卫）— 权限控制
codex-rs/core/guardian/ 管权限审批。哪些操作需要用户确认，哪些可以自动执行，都在这里定义。exec_policy.rs 定义了执行策略，network_policy_decision.rs 管网络访问权限。
6. Goals（目标）— 长时任务
codex-rs/core/goals.rs。这就是那个可以让 Agent 跨轮次保持任务状态的机制。一个 goal 可以跑几个小时甚至十几个小时，中间不需要用户一直盯着。
每一层都有明确的职责边界。核心不碰执行，执行不碰沙盒，沙盒不碰网络。出了问题，你知道去哪找原因。
二、Agent Loop：Codex 最核心的设计
Codex 和其他 AI 编码工具最大的区别是它的 Agent Loop——内部叫"Ralph Loop"（以《辛普森一家》里做事笨拙但坚持不懈的角色 Ralph Wiggum 命名）。
工作流程是这样的：
第一步：行动 — Agent 接收任务，生成代码或执行命令。
第二步：检查 — 它用具体的标准检查结果：lint 通过了吗？测试跑过了吗？文件写入成功了吗？不是让 AI 自己判断"我觉得这代码不错"，而是用客观标准验证。
第三步：反馈 — 把检查结果（错误输出、测试失败信息）塞回上下文。
第四步：重试 — Agent 根据反馈重新生成代码。循环回到第一步。
这个循环会一直跑，直到满足退出条件（所有测试通过、达到最大重试次数、用户手动终止）。
大多数 AI 工具只做第一步——生成代码，然后交给你。Codex 做了完整的闭环。这就是为什么它跑出来的代码通常能直接用。
三、为什么要用 Codex 的架构做参考
自己搭 Agent 框架，常见的问题是：
- 没有沙盒，Agent 能执行任何命令，风险不可控
- 没有权限分级，要么全自动（容易出事），要么全手动（效率太低）
- 没有长时任务机制，上下文一长就崩，任务中途断掉
- 工具耦合严重，加一个新工具要改核心逻辑
- 没有明确的边界编码，Agent 变成事实上的"决策者"，连完美的工作记忆也救不回来
Codex 的架构把这五件事都处理了。而且它是 Apache 2.0 开源的，可以直接读、直接改。
四、怎么让 Codex 复刻成你的业务 Agent
核心思路是：用 Codex 读 Codex 自己的代码，理解它的架构，然后按你的需求改写。
步骤一：克隆源码
git clone https://github.com/openai/codex.git cd codex步骤二：开一个 goal，让 Codex 读自己的架构
在 Codex 里运行：
/goal 请阅读本项目的 codex-rs/ 目录结构，分析： 1. 核心模块的架构关系 2. Agent Loop 的实现逻辑 3. 沙盒和权限控制的设计 4. 工具注册机制 帮我写一份完整的架构分析报告。Codex 会自己扫源码，生成一份结构化的分析。这一步的目的是让 Agent 理解自己的设计。
步骤三：定义你的业务需求
想清楚你的 Agent 要做什么。比如：
- 如果你的业务是电商：需要对接商品 API、订单管理、库存同步
- 如果你的业务是客服：需要对接企业微信/钉钉、知识库检索、工单流转
- 如果你的业务是内容生产：需要对接 CMS、图片生成、多平台发布
步骤四：让 Codex 基于架构分析生成你的 Agent
/goal 基于上面的架构分析，帮我复刻一个适合我业务的 Agent。 我的业务需求是：[填写你的需求] 具体要求： 1. 保持 Codex 的 Agent Loop 设计（行动→检查→反馈→重试） 2. 把我的业务 API 封装成独立 Tool 模块 3. 加入执行策略和沙盒隔离 4. 生成完整的代码和架构文档Codex 会根据源码里的设计模式，生成一套结构类似的代码。你不需要从零开始搭框架。
五、复刻时要保留的关键设计
不管你的业务是什么，Codex 的这几个设计模式值得照搬：
1. 核心和执行分离
Agent 的决策逻辑和业务 API 调用解耦。改 API 不用改核心，改核心不影响 API。Codex 用 codex-api 和 exec 两个目录做的分离，你的项目也可以用同样的思路。
2. 工具模块化
每个工具是独立模块，有独立的输入输出和错误处理。加一个工具就是往 tools/ 里扔一个新文件。不要把所有逻辑写在一个函数里。
3. 边界编码在循环外面
这是 Codex 最常被忽略但最重要的设计：权限策略（exec_policy.rs）、网络策略（network_policy_decision.rs）、守卫机制（guardian/），全部不在 Agent 的循环逻辑里。这意味着即使 Agent 的提示词写得再完美，边界也是硬编码的——不是靠 AI 的"自觉"来遵守规则。
4. 完整的 Agent Loop
生成→检查→反馈→重试。不要只做到生成那一步。跑完之后用测试、lint、业务规则去验证，然后把结果喂回去让它改。这才是 Codex 能产出可用代码的原因。
5. 长时任务保持
用 goals.rs 的模式：任务状态持久化，跨轮次保持上下文。如果你的业务需要 Agent 跑几个小时，这个设计是必须的。
六、实际效果如何
已经有开发者用这个方法跑了 14 小时的设备驱动项目，Agent 自己读源码、理解架构、生成代码、跑测试、修 bug，全程不需要人盯着。
有人用同样的思路复刻了一个企业微信客服 Agent，把企业微信的限制规则（比如机器人不能主动给外部客户群发消息）写进 exec_policy，避免了之前踩过的 10 天白干的坑。
GitHub 上已经有 130+ 个基于 Codex 的社区 Subagent，按类别整理好了。说明这条路是走得通的。
总结
Codex 的架构设计好，不是因为用了什么神秘技术，而是因为它做了软件工程该做的事：分层清晰、边界明确、模块化、可测试。
与其从零开始搭 Agent 框架，不如直接让 Codex 读自己的源码，把经过生产验证的设计模式搬过来。开源代码就放在那，不读白不读。