Codex 源码解析 · 第 9 讲
Codex 源码解析系列 第 9 讲：System Prompt 组装与注入 基于 OpenAI Codex 源码 · 2026-10-03 💡 本讲一句话： Codex 的"系统提示词"不是一句写死的字符串，而是一条流水线：会话启动时按三级优先级解析 base instructions（配置覆盖 → 历史继承 → 模型模板），之后每一轮再把沙箱策略、审批规则、AGENTS.md、插件能力等十几个"世界状态分节"做快照对比， 只把变化的部分 渲染成 developer/user 消息注入上下文。读完你会明白一个 agent 的提示词是怎么被"动态拼装 + 差量维护"的。 一、先建立地图：提示词从哪来、往哪去 上一讲我们把 Session / TurnContext / StepContext 三层快照拆完了。这一讲回答一个更基础的问题： 模型每次看到的"系统提示词"到底是谁、在什么时候、按什么规则拼出来的？ 源码里这条管线横跨四个 crate，但骨架只有四步： 🔹 解析 ：会话启动时确定 base instructions（ core/src/session/mod.rs ） 🔹 分节 ：把沙箱、审批、AGENTS.md、插件等状态组织成 WorldState sections（ core/src/context/world_state/ ） 🔹 差量渲染 ：每轮对比快照，只输出变化的 fragment（ core/src/context_manager/updates.rs ） 🔹 组装请求 ：fragment 合并成消息，按 provider 能力走两条不同的 API 路径（ core/src/client.rs ） 下面按这条管线逐段拆源码。 二、Base instructions 的三级优先级链 "base instructions"是 Codex 对系统提示词的正式称呼。它在哪解析？ core/src/session/mod.rs 的会话初始化路径里，注释把优先级写得明明白白： 📄 codex-rs/core/src/session/mod.rs (第 687-722 行，节选) // Resolve base instructions for the session. Priority order: // 注释直接声明三级优先级 // 1. config.base_instructions override // 第一级：用户显式配置，最高权威 // 2. conversation history => session_meta.base_instructions // 第二级：从历史会话继承（resume/fork） // 3. rendered instructions_template for current model // 第三级兜底：渲染当前模型的模板 let base_instructions = config // 从配置层开始找 .base_instructions // 用户显式覆盖项（config.toml / API 参数传入） .clone() // clone 出来，避免长期借用 Arc<Config> .or_else(|| conversation_history.get_base_instructions().map(|s| s.text)) // 没配置 → 查历史 session_meta：resume/fork 时继承父线程的指令 .unwrap_or_else(|| model_info.get_model_instructions(config.personality)); // 都没有 → 渲染当前模型模板（personality 参与渲染） 为什么这样设计： 三级链的顺序就是"意图强度"排序——用户亲手写的配置 > 会话历史里已经生效的指令（resume/fork 必须保持行为连续，否则换台机器继续对话 agent 就"失忆变人"）> 模型自带的默认模板。注意第三级不是读一个静态文件，而是 get_model_instructions(personality) ——指令是 按模型渲染 的，不同模型可以带不同的系统提示词。这个入口在 protocol crate： 📄 code…
阅读全文：Codex 源码解析 第 9 讲