OpenAI产品发布与预告 - OpenAI首席执行官山姆·奥特曼预告，从下周开始的接下来一个月，公司将发布许多与Codex相关的激动人心内容，并特别强调了网络安全主题[1] - 作为对预告的响应，OpenAI官方发布了一篇技术博客，深入揭秘了Codex CLI的核心架构——智能体循环[3] Codex CLI产品定位与开源情况 - Codex CLI是OpenAI的跨平台本地软件智能体，可以生成相当高质量的软件变更[7] - 自2024年4月首次发布CLI以来，公司在构建世界级软件智能体方面积累了大量经验，并计划通过系列博客分享见解[8] - Codex项目在GitHub上已获得57k星标，拥有7.4k个分叉，并有363人关注，显示出较高的社区活跃度[9] 智能体循环核心架构 - 智能体循环是Codex CLI的核心逻辑，负责协调用户、模型以及模型为执行软件任务而调用的工具之间的交互[10] - 循环过程包括：输入、推理、解码、决策、执行与重试，该过程会重复直到模型生成最终回复[16] - 从“用户输入”到“智能体回复”的过程被称为一个对话轮次，一个轮次可以包含模型推理和工具调用之间的多次迭代[18] 模型推理与API集成 - Codex CLI通过向Responses API发送HTTP请求来运行模型推理[23] - 使用的Responses API端点是可配置的，支持多种后端，包括ChatGPT、OpenAI官方API、本地运行的ollama或LM Studio，以及云服务商如Azure[24][25][26] 提示词构建与管理 - 初始提示词由多个部分组成，包括系统指令、工具定义和用户输入，这些信息通过JSON负载发送给Responses API[28][30] - 提示词中的每个项目都关联一个角色，优先级从高到低为：系统、开发者、用户、助手[28] - 在对话过程中，提示词长度会随着历史记录和工具调用的增加而增长，因此上下文窗口管理是智能体的关键职责之一[19][20] 性能优化策略 - 公司通过保持“提示词前缀一致”来触发提示词缓存，从而优化性能，当命中缓存时，采样模型的时间复杂度是线性的而非二次方的[45][52] - 缓存命中仅适用于提示词内的精确前缀匹配，因此建议将静态内容放在提示词开头，变量内容放在末尾[53] - Codex目前避免使用`previous_response_id`参数以保持请求完全无状态，并支持零数据保留配置，这简化了API提供者的工作并与ZDR不冲突[51] 上下文管理与自动压缩 - 为避免耗尽上下文窗口，公司采用的总策略是：一旦Token数量超过某个阈值，就对对话进行压缩[58] - 压缩过程用一个代表对话的小型新项目列表替换输入，使智能体能够在理解上下文的情况下继续工作[58] - Codex现在会在超过`auto_compact_limit`时，自动使用`/responses/compact`端点来压缩对话[59] 未来技术分享方向 - 本篇博客是系列文章的第一篇，后续文章将深入探讨CLI的架构、工具调用的具体实现方式，以及Codex的沙箱模型[63]