这篇内容深入剖析了 OpenAI Codex CLI 的运作机制，特别是其核心的“代理循环”是如何通过交替生成和执行工具调用来完成任务的。对于想了解大型语言模型如何在实际编码场景中实现复杂交互的开发者而言，提供了极具价值的内部视角和工程实践参考。
智能速览
Codex 通过“代理循环”交替生成回复与调用工具来完成任务。
构建稳定的提示前缀是提高 Prompt Caching 命中率的关键。
当前设计偏向无状态请求以更好地适配零延迟重试等场景。
对话历史过长时，会通过自动压缩机制避免超出上下文窗口。
工具列表或环境变更会破坏缓存，需采用“追加而非改写”策略。
精华内容
Codex CLI 的强大并非源于魔法，而是一套精密设计的工程架构。理解其内部的代理循环、缓存策略与状态管理，是洞悉现代 AI 代理工作原理的关键。
代理循环机制
Codex CLI 的核心是“代理循环”。当用户发出指令后，模型并非一次性给出所有答案，而是在 Responses API 框架下，交替生成自然语言回复和工具调用请求。例如，它可能会决定先执行一个 shell 命令来获取信息。
CLI 接收到请求后，执行相应的工具，并将工具的标准输出结果作为新的上下文再喂回给模型。这个“生成-执行-反馈”的循环会持续进行，直到模型认为任务已完成，并最终给出结果以及对代码库的实际改动。
提示与前缀缓存
为了提升响应速度并降低成本，Codex 高度依赖 Prompt Caching。实现高效缓存的关键在于构建一个稳定的提示前缀，这个前缀包含了系统指令、工具定义等不常变更的部分。
然而，当工具列表或环境配置发生变化时，缓存会立即失效。为解决这个问题，Codex 采用了“追加而非改写”的策略，尽量保持前缀内容的一致性，从而最大限度地利用缓存，提升交互效率。
状态管理与压缩
在设计上，Codex 目前偏向于无状态请求，即每次请求都是独立的，不依赖 `previous_response_id`。这种设计能更好地支持零延迟重试等高可用场景，提升了系统的健壮性。
但随着对话变长，完整的上下文历史很容易超出模型的上下文窗口。为此，系统内置了自动压缩机制，通过 `/responses/compact` 端点智能地精简历史记录，在保留核心信息的同时，确保对话可以持续进行，避免因上下文溢出而中断。
通过对 Codex CLI 架构的剖析，我们得以一窥顶尖 AI 代理在工程实践中的权衡与巧思。这些关于循环、缓存和状态管理的经验，不仅适用于 Codex，也为所有致力于构建复杂 AI 应用的开发者提供了宝贵的蓝图。未来，这些架构将如何进化？
