OpenAI技术架构与工程实践 - OpenAI通过一个PostgreSQL主库和近50个只读副本的架构，支撑了ChatGPT等产品8亿用户和每秒数百万次查询的访问需求，生产环境中客户端99分位延迟保持在十几毫秒，服务可用性达到五个九标准[25] - 过去一年，公司PostgreSQL的负载增长超过10倍，仅出现过一次零级严重故障，发生在ChatGPT图像生成功能上线导致一周内超1亿新用户注册、写流量突发暴涨超10倍期间[25] - 对于写密集型负载，公司已将可分片业务迁移至CosmosDB等分片式数据库系统，并正与微软Azure合作推动级联复制功能，以实现只读副本的安全、大规模扩容[26] Codex智能体循环框架 - Codex智能体的核心是Agent Loop，负责协调用户、模型以及工具调用之间的交互，该框架支撑了包括Codex CLI、Codex Cloud和Codex VS Code插件在内的一系列软件智能体产品[5] - Agent Loop的工作流程始于接收用户输入并构建提示词，随后进行模型推理生成输出token，模型可能生成最终回复或要求执行工具调用，工具调用结果会附加至提示词并再次查询模型，此过程循环直至模型生成面向用户的助手消息[8][9][10] - 在对话过程中，提示词长度会随着内容增加而增长，智能体可能在单次对话中发起数百次工具调用，因此管理模型的上下文窗口限制是其核心职责之一[12] 响应API与提示词构建 - Codex借助响应API驱动智能体循环，该API接收包含指令、工具和输入字段的JSON负载，服务器负责将这些信息组织为模型可处理的提示词格式[13][16] - 初始提示词中，内容条目按角色分为系统、开发者、用户、助手等类别，优先级从高到低，提示词前三项的顺序由服务器决定[14][18] - 为提升效率并保护用户隐私，Codex未启用可缓解数据量二次方增长的`previous_response_id`参数，而是采用复杂的提示词缓存和上下文窗口压缩策略[22] 性能优化策略 - 提示词缓存是关键优化手段，当新提示词是旧提示词的完整前缀时，可复用前次推理计算结果，将模型采样的时间复杂度从二次方降至线性[19][22] - 为充分发挥缓存优势，需将指令、示例等静态内容置于提示词开头，而将用户专属信息等可变内容放在末尾，Codex团队在开发新功能时必须审慎避免破坏缓存机制，例如确保工具枚举顺序一致[22][23] - 为规避上下文窗口耗尽，Codex采用对话压缩策略，当词元数量超过`auto_compact_limit`阈值时，会自动调用专用的`/responses/compact`端点，用更精简的条目列表替代原有输入以释放窗口空间[24] 行业影响与内部应用 - 有网友评价OpenAI的数据库扩容方案“极简”，将最佳实践做到极致，以“加只读副本”的简洁方案服务十亿级用户，与行业过去十年推崇的“一切皆分片”论调形成对比[26] - 有爆料称Codex已接管OpenAI 100%的代码编写工作，此前公司员工roon（被Sam Altman称为其小号）曾表示其100%的编码工作基于OpenAI模型进行[1][3]

OpenAI 技术架构与工程实践深度剖析 - 公司通过一个PostgreSQL主库和近50个只读副本的架构，支撑了ChatGPT等核心产品8亿用户和每秒数百万次查询的访问需求，过去一年负载增长超10倍 [29] - 生产环境中，数据库客户端99分位延迟稳定在十几毫秒，服务可用性达到五个九标准，过去12个月内仅出现一次零级严重故障 [29] - 公司正将可分片的写密集型负载迁移至CosmosDB等系统，并探索级联复制、分片架构等方案以应对持续增长的基础设施需求 [30][31] Codex 智能体循环框架揭秘 - Codex智能体循环的核心是协调用户、模型及工具调用的“智能体循环”，该框架支撑了包括Codex CLI、Cloud和VS Code插件在内的一系列软件智能体产品 [5] - 循环流程为：接收用户输入并构建提示词 -> 查询模型进行推理 -> 根据模型输出决定生成最终回复或执行工具调用 -> 将工具输出附加至提示词并再次查询模型，直至模型生成最终“助手消息” [6][7] - 智能体循环的输出不仅限于文本消息，核心输出通常是在用户设备上编写或编辑的代码 [7] 响应API与提示词工程优化 - 响应API通过接收包含指令、工具、输入等核心参数的JSON负载来驱动智能体循环，由服务器决定如何将信息组织为模型可处理的提示词格式 [12][15] - 提示词中不同角色（系统、开发者、用户、助手）的内容具有不同权重，Codex会主动拼接一套精心设计的提示词结构，用户输入通常出现在末尾 [12][13] - 为提升性能，公司重点优化了提示词缓存机制，当提示词存在完全匹配的前缀时，模型采样的时间复杂度可从二次方降至线性 [23] - 可能导致缓存未命中的操作包括：在对话中修改工具列表、更换目标模型、修改沙箱配置或当前工作目录等 [24][25] 上下文窗口管理与对话压缩策略 - 所有模型都存在上下文窗口限制，智能体可能在单次对话中发起数百次工具调用，存在耗尽上下文容量的风险 [11] - 通用管理策略是当词元数量超过阈值时对对话进行压缩，即用一个更精简、能代表对话核心内容的新条目列表替代原有输入 [27] - 早期压缩需用户手动触发，后响应API新增了专用的`/responses/compact`端点以实现高效自动压缩，Codex会在词元数超过`auto_compact_limit`时自动调用 [27] - 在长对话中，为保持缓存命中率，针对配置变更（如工作目录改变）会通过在输入中追加新消息来体现，而非修改早期消息 [24][26]

OpenAI发布Agent Loop架构与PostgreSQL极限架构技术细节 - 公司首次公开了Codex AI Agent的核心“大脑”运转机制，即Agent Loop（智能体循环）架构，这是一个包含“观察-思考-行动-反馈”闭环的智能系统，使AI能够独立解决问题而非简单问答 [8] - 公司分享了支撑ChatGPT等产品的后端数据库架构：仅使用1个PostgreSQL主节点配合50个只读副本，即支撑了全球8亿用户和每秒数百万次的查询处理 [24] - 此次技术发布被视为对竞争对手Anthropic旗下Claude Code产品的直接回应，Claude Code因其端到端的开发体验和能在终端独立工作的能力对Codex CLI构成了威胁 [37] Agent Loop架构详解 - Agent Loop作为“总指挥”，将用户意图、模型大脑和执行工具串联成闭环，其工作流程包括构建Prompt、模型推理、工具调用、结果反馈及循环，直至任务完成 [6][9][12] - 该架构使AI具备了自主规划路径、检查错误和验证结果的能力，实现了从“陪伴聊天”到“独立干活”的飞跃 [12] - 公司针对Agent开发的两大痛点进行了优化：通过Prompt Caching（提示词缓存）技术，将长对话成本从平方级增长降至线性级 [13][14][16][17]；通过Compaction（对话压缩）技术，在Token数超阈值时将对话历史压缩成加密摘要，以克服上下文窗口有限的限制，保持AI在处理超长任务时的“智商”在线 [18][19][21][23] PostgreSQL高性能架构关键技术 - 公司通过PgBouncer连接池代理将平均数据库连接建立时间从50毫秒降低至5毫秒，在每秒百万级查询的场景下带来了巨大的性能提升 [27][28] - 采用了缓存锁定/租约机制，当缓存未命中时只允许一个请求查询数据库并回填缓存，有效避免了缓存雪崩 [29][30] - 实施了查询优化与负载隔离，例如将涉及12张表连接的复杂查询逻辑移至应用层处理，并将请求按高、低优先级分流，由专用实例处理以防止“吵闹邻居”效应 [31] - 架构设计核心是读写分离与极致优化读路径，读流量全部分流至副本，主库运行于高可用模式，即使主库宕机服务仍能保持只读可用 [27][32][33] 当前架构面临的挑战与未来方向 - 当前架构已触及物理极限，主要问题在于PostgreSQL的MVCC机制导致的写放大与读放大，以及随着副本数量增加，主库向所有副本推送预写日志带来的网络压力和副本延迟 [34][35] - 为突破限制，公司正计划将可分片的高写入负载迁移至Azure Cosmos DB等分布式系统，并测试级联复制技术，目标是支持超过100个副本 [35] 行业竞争与战略信号 - OpenAI此次更新展示了其在Agent架构上的成熟度与深厚工程积累，包括Prompt Caching、Compaction、MCP工具集成等实打实的能力 [38] - 通过展示支撑8亿用户的后端工程能力，公司暗示其“护城河”不仅在于AI模型，更在于整个强大的工程体系 [39] - 行业内的竞争，如Claude Code与Codex的争霸，正在加速双方的产品迭代与创新，最终将使开发者受益 [41]