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]