大型代码库理解指南：Codex上下文压缩机制深度解析

当你向Codex发出“重构service层错误处理逻辑”的指令时，它不会将整个庞大的代码库盲目塞入上下文。其关键在于，它能迅速定位到当前Rust项目中`src/service/error.rs`及其关联测试文件等核心位置。这种精准定位能力，并非依赖暴力加载，而是由一套分层筛选与动态上下文压缩机制协同实现。

Codex如何定位关键代码文件

定位过程始于一次目标明确的扫描。Codex启动时，首先会在项目根目录寻找名为AGENTS.md的配置文件。该文件如同项目“地图”，Codex从中解析`focus_dirs`（核心目录）、`exclude_patterns`（排除规则）和`entry_points`（入口点）三项关键配置。若当前目录未找到，它会向上递归查找，直至遇到`.git`目录，确保规则覆盖完整代码库。

获取规则后，Codex为所有文件建立优先级队列。入口文件（如`main.rs`、`lib.rs`）权重最高，设为10分；`focus_dirs`目录下的`.rs`文件权重为7分；与这些文件对应的测试文件（如`*_test.rs`）权重为5分。日志、锁文件及`target/`目录下的编译产物则被直接排除，避免干扰核心分析。

生成队列后，Codex对高权重文件执行“轻量级解析”。它仅进行基础AST分析，提取模块声明、结构体定义、impl块签名及公开函数头等接口契约信息，而不会深入函数内部实现。此举精准捕获了代码骨架与关键约定，同时规避了冗余的实现细节，为后续的精准上下文构建奠定基础。

上下文压缩触发时机与判断依据

这套压缩机制在三种典型场景下触发。

首先是自动触发，此为默认模式。当当前会话累计消耗的token数达到预设的`auto_compact_token_limit`阈值时（默认值由`models.json`中的ModelFamily配置决定，例如GPT-5.2-Codex模型对应196608），系统会在下一轮任务开始前自动启动压缩流程，防止上下文窗口溢出。

其次是手动触发，为用户提供即时控制权。在命令行界面输入`/compact`指令，即可立即对“温数据层”执行一次压缩。请注意，此操作不可逆——原始的详细对话日志将从实时历史中移除，仅保留结构化的摘要信息。

第三种是更具前瞻性的预防性触发。每轮对话结束后，Codex会估算新增token的消耗占比。若预测下一轮交互将导致超限，它会提前行动，压缩掉最早的两轮对话及其对应的工具输出。这种“未雨绸缪”的策略，有效避免了因上下文容量突然耗尽而导致的对话中断。

压缩过程如何保重点、去噪音

压缩的核心目标是实现信息的智能化分层与迁移，在剔除噪音的同时，确保关键信息零丢失。

整个上下文被划分为四个层级：固定层的内容，如AGENTS.md全文、用户权限规则等，会被永久保留。它们不占用对话窗口，而是在每次构造提示词时重新注入，作为不变的背景知识。

热数据层包含最近3轮对话及刚被编辑的2个文件。这部分内容保持原文完整，以确保对话的即时连贯性，使协作过程无缝衔接。

真正的压缩作用于温数据层（通常是4到12轮之前的历史）。模型会自主识别其中的核心决策链。例如，它将数十条消息和数百行日志，提炼为一句结构化摘要：“用户要求统一使用`anyhow::Result` → 已据此修改`error.rs`中的trait bound → 单元测试通过，但`integration_test.rs`报错”。历史的精髓得以传承，无关细节被果断舍弃。

最后是冷数据层，涵盖完整的测试输出、冗长的`cargo build --verbose`日志、PDF文档全文等。这些庞大数据体不会进入上下文窗口，仅保留一个检索锚点。当后续对话需要引用其中某段具体信息时，再通过MCP协议按需拉取，实现“随用随取”。

一个关键细节是：压缩绝非模糊概括。模型不会将“`src/service/error.rs`第42行改为`anyhow::Result`”简单压缩为“修改了错误类型”。相反，它会严格保留具体的文件路径、精确的行号、确切的类型名——这些是后续进行精准代码跳转和修改所必需的“坐标”。保住这些坐标，就保住了持续协作的精度。