12. Context Engineering

12.1 原理

Context Engineering 决定“模型在当前 Step 能看到什么、以什么顺序、带什么权威和来源”。它比 Prompt Engineering 范围更广，涵盖检索、记忆、Skill、工具结果、历史、压缩、窗口预算和 cache 稳定性。

12.1.1 Context 编译工厂怎么读

如何读图： 左侧是候选来源，不是默认全部注入的内容；中间六个阶段把候选转成带来源、顺序和预算记录的 Step Context；右侧只服务当前一次模型采样。下一 Step 会基于新的工具结果和世界状态重新编译，不能把上一步大字符串原样当成真相继续追加。

四个经常混淆的对象在图中处于不同位置：Prompt 是高权威指令构件，也会参与最终请求编排；Context Window 是 Token 物理约束；Memory 是需要经过权限、时效和相关性筛选的候选源；Compression 是预算或上下文质量触发的历史替换策略。这样拆开后，模型“忘记事实”才可以继续判断是候选未召回、过滤错误、排序靠后、压缩丢失，还是最终预算不足。

一个 Context Item 建议包含：

id, type, content, source, authority,          // 唯一标识、内容类别、正文、来源和权威等级
created_at, freshness, token_cost,             // 创建时间、新鲜度评分和注入所需 Token 成本
scope(session/project/user), hash, provenance  // 保存可见范围、去重哈希和可追溯的来源记录

选择逻辑应综合：相关性、权威级别、新鲜度、Token 成本、是否已存在于缓存前缀、是否与当前计划阶段匹配。上下文不是越多越好；错误或低权威内容必须被标记，而不能与系统规则混成同一文本层。

12.2 Claude Code 源码

Claude Code 的 Context 并非只靠聊天历史：压缩后会重建 Session Hook、近期文件、计划、Skill 和后台 Agent；Fork 子 Agent 会过滤不完整 ToolCall，并构造缓存一致的父上下文前缀。这些都是典型 Context Engineering：compact.ts:1402、forkSubagent.ts:98。

12.3 Codex 源码

Codex 为每个 Step 捕获 StepContext，记录精确的模型可见状态；World State 只在变化时记录，Prompt History 从 clone_history().for_prompt(...) 投影而来：turn.rs:198、turn.rs:297、turn.rs:333。

Codex 仓库规范进一步要求所有注入片段有硬上限、单项不超过 10K Token，并避免频繁改写历史导致 cache miss。这体现了 Context Engineering 的三个底线：增量、稳定、有界。

12.4 伪代码

function buildStepContext(turn, world):                                // 为一次模型采样构建确定的上下文视图
    mandatory = [systemPolicy, developerPolicy, currentUserGoal]       // 固定保留高优先级策略和当前用户目标
    dynamic = [                                                        // 收集与当前计划步骤相关的动态候选信息
        diff(world, turn.referenceWorldState),                         // 只注入相对参考快照发生变化的世界状态
        retrieveCode(turn.plan.currentStep),                           // 检索完成当前步骤所需的代码片段
        retrieveMemory(turn.query),                                    // 召回通过权限和新鲜度过滤的相关记忆
        activatedSkills(turn.query),                                   // 加载当前意图命中的 Skill 指令与必要资源
        recentToolEvidence(turn)                                       // 加入近期工具结果及其可验证证据
    ]                                                                  // 结束动态候选集合
    dynamic = deduplicateByHash(dynamic)                               // 用内容哈希消除跨来源重复片段
    dynamic = rejectLowerAuthorityConflicts(dynamic, mandatory)        // 丢弃与强制策略冲突的低权威信息
    dynamic = budgetedRerank(dynamic)                                  // 按价值排序并裁剪到当前 Step 预算
    return stablePrefix(mandatory) + ordered(dynamic)                  // 稳定高权威前缀后追加排序后的动态内容

12.5 工程检验题

问：Prompt Engineering 与 Context Engineering 的边界？

Prompt Engineering 优化指令表达；Context Engineering 管理进入模型的全部信息及其生命周期。工具结果截断、代码检索、记忆召回、Skill 激活和历史压缩都属于 Context Engineering。

12.6 原理深化：Context 是 World State 到模型视图的确定性投影

Context Engineering 的核心对象不是文本，而是“某一 Step 对世界的可重复观察”。真实世界包括 cwd、文件系统权限、模型、工具目录、协作模式、AGENTS.md、已批准命令和当前时间等可变状态；Step 需要捕获版本化快照，再把相对上一个已知基线的变化渲染为模型可见片段。这样模型既不会一直看到过期权限，也不必每轮重复接收整份环境。

Codex world_state 为环境、权限、模型、协作模式等分别定义状态对象和差异渲染；例如权限状态比较无批准前缀的稳定部分与新批准项，环境状态只在 cwd、平台或文件系统 Profile 变化时产生更新：environment.rs:21、environment.rs:115、permissions.rs:17。History 还保存最近已追加的 World State 基线，使下一 Step 能生成增量而不是猜测差异：history.rs:59、history.rs:98。

因此 Context Builder 应满足四个性质：确定性，同一快照和预算产生同一顺序；有界，所有外部片段有明确上限；可追溯，每项保留来源记录与选择理由；可失效，文件、Memory、MCP Schema 或权限变化后能撤销旧的模型可见视图。检索相关性只是其中一步；若没有可信度、时效和可见范围，最相关的片段也可能是最危险的错误上下文。

12.7 DeepSeek Harness：每个模型可见 Context 都有持久来源

packages/context/agent-instructions 沿工作区目录层级发现指令文件并保留 digest，time-context 提供当前时区和时间，tmux-context 提供终端环境，session-reference 将受权的其他 Session 有界投影序列化为不可信 Context。这些贡献与 System Prompt section 在 preStep() 组装，再通过 Runtime Context Projection 进入已领取消息。

关键不变量是“模型可见 ⇔ 可从日志重建”。agent.inject() 只将消息放进 next-step Inbox，真正被接受时才作为 user/message 写入 Session；Skill 显式调用、后台任务完成通知和 Session Reference 都携带 Message Source，UI 和审计不需从自由文本反猜来源。