- 存储实体
会话内的完整上下文由
ContextManager维护，其核心数据结构为items: Vec<ResponseItem>。 - 提取逻辑
在每次交互（Turn）开始前，系统通过
get_history_for_prompt()接口将历史记录整理并转化为模型可理解的 Prompt 输入。 (参考:codex-rs/core/src/context_manager/history.rs:18,codex-rs/core/src/codex.rs:2271)
- 前缀构成
新会话启动时，系统会优先将
DeveloperInstructions、UserInstructions以及初始的<environment_context>写入历史记录。 - 持久化策略
这种处理方式保证了会话在模型侧形成一个稳定的前缀，有利于服务端缓存命中。
(参考:
codex-rs/core/src/codex.rs:761,codex-rs/core/src/codex.rs:1269)
-
Turn 级生成 每个
Op::UserTurn都会生成对应的TurnContext。 -
差异化更新 (Diff) 系统会检查当前环境（如
cwd、approval、sandbox等）是否发生变化。 -
若有变化：插入
EnvironmentContext::diff(...)增量信息。 -
若无变化：不重复发送，以节省 Token。
-
序列化形式
EnvironmentContext会被序列化为 XML 格式，并封装在role="user"的ResponseItem::Message中。 (参考:codex-rs/core/src/codex.rs:1732,codex-rs/core/src/environment_context.rs:92,172)
- Prompt 构造
run_turn负责构造最终的Prompt结构（包含input、tools等）并启动流式传输（Streaming）。 - 前缀缓存复用
在 Responses API 请求中，
prompt_cache_key被固定设置为conversation_id，从而在服务端实现前缀缓存的跨 Turn 复用。 (参考:codex-rs/core/src/codex.rs:2363,codex-rs/core/src/client.rs:257)
- 预算管理 工具输出及长文本会严格遵循 Token 或 Bytes 预算进行截断。
- 自动压缩 (Auto-Compact) 当累计 Token 接近上下文窗口限额时，触发压缩机制。
- 重写逻辑 压缩后的历史会被重写为：“初始前缀 + 最近用户消息 + 摘要”。
- 裁剪优先级
压缩时优先从最旧的非核心内容处开始裁剪，以最大限度保留前缀部分的缓存价值。
(参考:
codex-rs/core/src/truncate.rs:98,codex-rs/core/src/compact.rs:120,158)
- 缓存稳定性
测试用例验证了
prompt_cache_key在跨 Turn 或配置覆盖时保持恒定。 - 增量发送验证
确保
environment_context仅在会话首次启动或实际环境发生变动时才被发送。 (参考:codex-rs/core/tests/suite/prompt_caching.rs:343,586)
Codex 决策逻辑：GPT-5.2 High 环境下的思考触发机制
在 Codex-RS 的架构设计中，是否进行“思考（Reasoning）”并不是由 Codex 实时根据任务难度动态判断的，而是由模型配置、模型家族属性以及 API 协议共同决定的静态链路。以下是针对 GPT-5.2 High 配置的详细执行逻辑：
- 配置存储：用户设置的推理强度（如 High）被保存在
SessionConfiguration的model_reasoning_effort字段中。 - 参数传递：在构造
TurnContext（即一次对话轮次上下文）时，该配置会被原样传递给ModelClient实例。 (参考:codex-rs/core/src/codex.rs:389, 496)
- 家族特征标记：系统会检查模型所属家族。对于
gpt-5.2*系列，其在离线定义的model_family中被显式标记为supports_reasoning_summaries: true。 - 默认值设定：若用户未指定，该家族通常带有默认推理强度（如 Medium）。
(参考:
codex-rs/core/src/models_manager/model_family.rs:353, 361)
- 条件构造：在调用 Responses API 时，Codex 会进行一次前置检查：只有当模型家族支持推理（
supports_reasoning_summaries为真）时，才会在请求体中构造reasoning字段。 - 字段填充：构造
Reasoning { effort, summary }结构。此时遵循用户配置优先原则（即优先取 High），若无配置则取家族默认值。 (参考:codex-rs/core/src/client.rs:207)
- 无条件透传：一旦
self.effort被确定为High，client.rs会在当前会话的每次请求中都带上reasoning.effort=high参数。 - 模型侧决策：Codex 层面不再执行诸如“这个问题是否简单到不需要推理”的逻辑判断，而是将推理计算的分配权完全交给模型侧，由模型根据
high参数自行决定计算资源的倾斜。 (参考:codex-rs/core/src/client.rs:207)
- 协议限制：如果 Provider 使用的是旧版的 Chat Completions 接口（
WireApi::Chat），该路径下没有reasoning参数的构造逻辑。 - 展示与请求的分离：
show_raw_agent_reasoning标志位仅控制前端界面是否聚合或展示推理流事件，它不参与“是否向模型请求推理”的决策。 (参考:codex-rs/core/src/client.rs:116)
在 Codex 的会话文件（
~/.codex/sessions/.../rollout-*.jsonl）中，那段冗长的 Base64 文本通常是模型返回的encrypted_content（加密内容）。
以下是基于其架构实现的详细解析：
这段 Base64 字符串对应 ResponseItem 协议中的两种特定类型：
- 推理项 (Reasoning)：
ResponseItem::Reasoning { encrypted_content: Option<String>, ... }。 - 压缩摘要项 (Compaction)：在协议中也称为
compaction_summary，定义为ResponseItem::Compaction { encrypted_content: String }。
- 请求触发：当你使用 Responses API 且启用了推理功能时，Codex 会明确请求模型将推理过程以
reasoning.encrypted_content的形式一并返回。 - 数据流向：客户端收到该加密字段后，会原封不动地将其存入 Session 文件的
rollout记录中。
尽管这段文本占据了大量空间，但 Codex 对它的处理非常有限：
- 非解密原则：Codex 核心逻辑不会尝试对其进行解密或向用户展示具体内容。
- Token 估算：在计算历史上下文长度时，Codex 会根据
encrypted_content的 Base64 字符串长度来粗略估算其所占用的 Token 资源。 - 持久化归档：根据 Rollout 的持久化策略，这些内容（无论类型是
reasoning还是compaction_summary）都会被完整记录，以保证会话历史的完整性。
小贴士：如果你想确认某段 Base64 具体代表什么，可以检查该行 JSON 中的 item.type 字段。如果是 reasoning，则代表加密的思考过程；如果是 compaction_summary，则代表会话压缩后的加密快照。