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]