--- title: "上下文管理" description: "有效管理上下文以获得更好的结果" --- --- 有效的上下文管理能确保 Verdent 在正确的时间获得正确的信息，同时避免因上下文过载导致的性能下降。 ### 你将学到什么 - 理解上下文窗口及其限制 - 有策略地选择文件以获得最佳上下文 - 识别并应对上下文过载 - 何时重置上下文以获得更好的性能 - 工作区组织方式如何影响上下文 --- ## 理解上下文窗口 Verdent for VS Code 的上下文窗口大小取决于所使用的模型。 大多数模型使用标准的 `200K` 上下文窗口： - **Claude 4.5 Sonnet** —— 适合复杂任务的均衡选择 - **Claude 4.5 Haiku** —— 快速高效 - **GPT-5** —— 推理能力出色（Beta） - **GPT-5-Codex** —— 为编码优化（Beta） **容量：** - 约 `200,000` tokens 的总记忆容量 - 足以应对大多数开发任务和中型项目 **包含的内容：** - 对话中的所有消息 - 加载进上下文的文件内容 - 工具输出和响应 - 系统提示词和指令 - MCP 服务器定义 **性能：** - 接近上限时会明显下降 - 注意上下文过载的信号（响应变慢、输出准确度降低） - 更频繁地重置上下文以获得最佳性能 当显式选择，或输入超过 `200K` tokens 时，Claude Sonnet 4.5 提供扩展上下文（`1M` tokens）。 **容量：** - `1,000,000` tokens 的总记忆容量 - 比标准模型大 5 倍 **优势：** - 非常适合无需分块就能加载整个大型代码库 - 消除了大型项目中的大部分上下文管理顾虑 - 在触及上下文上限前可工作更长时间 - 需要重置会话的次数更少 **何时使用：** - 包含 `1000+` 文件的大型代码库 - 跨整个项目的复杂多文件重构 - 横跨多个相关任务的长时间开发会话 - 当你希望尽量减少上下文管理开销时 --- ## 有策略地选择文件 选择文件时要有策略，以优化上下文使用并避免触及上限。 先从较少的文件开始，仅在需要时再添加，Verdent 在对话中随时可以读取更多文件。 ### 使用 @ 提及进行显式纳入 ``` @filename.js ``` Verdent 会自动加载相关文件，但 `@-mentions` 能确保精确的上下文。要有选择性——只纳入与当前任务直接相关的文件。 ### 监控上下文使用 - 注意会话变长时的性能下降 - 留意对话长度和文件数量 - 在可能时从上下文中移除不必要的文件 ### 避免上下文过载 - 将大任务拆分为更小的部分，每个任务使用更少的文件 - 只关注相关文件——不要一次加载整个代码库 - 使用 MCP 服务器管理来禁用未使用的集成 ### 最佳实践 - 只纳入需要修改或引用的文件 - 引用已有的模式，而不是加载示例文件 - 对于大型代码库，一次只处理一个模块 - 使用项目文档（`AGENTS.md`）而不是加载大量文件 - 对于内存密集型任务，避免使用上下文窗口的最后五分之一 ### 对于扩展上下文 (1M tokens) 文件选择的重要性大幅降低——你通常可以加载整个项目仓库而不会触及上限。 --- ## 识别上下文过载 **信号：** - 响应准确度降低或不完整 - 遗漏对话中较早出现的重要细节 - 难以在长会话中保持一致性 - 对最近的更改或上下文感到困惑 **具体示例：** - 提出你在本次会话早些时候已经否决的方案 - 忽略你在 `20` 条消息之前确立的编码约定 - 生成与对话早期所做更改相冲突的代码 - 提出与之前讨论过的项目架构不符的实现方案 **主要信号：** Verdent 的响应准确度降低或不一致 **信号：** - 响应时间明显变慢 - 开始响应前的处理延迟变长 - 消息之间的延迟增加 **具体示例：** - 通常需要 `5-10` 秒的响应现在需要 `30+` 秒 - 发送消息后，输入指示器出现前有明显延迟 - 流式响应开始得比平常慢得多 - 工具执行（文件读取、搜索）耗时明显变长 **主要信号：** 响应耗时比平常明显更长 **信号：** - 要求澄清已经提供过的信息 - 忘记之前确立的模式或约定 - 无法引用之前讨论过的文件或代码 - 重复询问项目结构 **具体示例：** - 在你 `30` 条消息前已说明使用 React 后，仍问"你用的是什么框架？" - 重复索要你已经 `@-mentioned` 多次的文件路径 - 不记得你在会话开始时确立的命名约定 - 重新解释你已附理由否决的概念或方法 **主要信号：** Verdent 询问已经讨论过的内容 **信号：** - 接近 `200K` token 上限的最后五分之一（已使用约 `160K+` tokens） - 包含大量文件读取和工具输出的长对话 - 启用了多个带有大量工具定义的 MCP 服务器 - 反复将大文件加载进上下文 **具体示例：** - 会话已运行 `2+` 小时，包含 `100+` 条消息 - 你在对话中加载了 `20+` 个文件，`@-mentions` - 多个大文件（每个 `>1000` 行）都在上下文中 - 你启用了 `5+` 个带有大量工具定义的 MCP 服务器 - 对话包含大量 grep/搜索结果和文件读取 **主要信号：** 伴随大量文件/工具使用的超长会话 **何时采取行动：** 性能下降是你的主要信号。如果 Verdent 的响应变得准确度降低、变慢或不一致——就开启一个全新会话或使用上下文管理策略。 如果 Verdent 的响应变得含糊或重复，可能正在发生上下文过载。重置对话以恢复完整性能。 **注意：** 使用 `1M` token 上下文（Claude Sonnet 4.5）时，这些问题要少见得多。 --- ## 何时重置上下文 - 响应时间明显变慢 - 响应准确度降低或不一致 - Verdent 遗忘早期的上下文或模式 - 接近上下文窗口上限（注意下降信号） **行动：** 质量下降时开启全新会话 - 在不相关的功能或模块之间切换 - 完成一个待办事项并转向下一个 - 在内存密集型任务（大型重构、架构工作）之后 - 从研究阶段转向实现阶段 **行动：** 为新的主要任务开启新会话 - 在将完成的功能提交到版本控制之后 - 在开发工作流的逻辑检查点之间 - 在测试-验证-提交循环之后 **行动：** 提交 → 测试 → 新会话 - 在开始重要新功能之前 - 当对话历史变得很长时 - 在完成多文件更改之后 - 在不同类型的工作之间（调试 → 功能开发） **行动：** 在上下文下降之前主动开启全新会话 **最佳实践工作流：** 完成一个原子工作单元 → 测试 → 提交 → 清除上下文 → 为下一个任务重新开始。 **注意：** 开启新会话即可重置上下文。对于 `1M` token 上下文，需要清除的频率要低得多。 --- ## 工作区组织的影响 工作区组织方式直接影响上下文的使用效率，以及 Verdent 浏览代码库的难易程度。 **更小、更聚焦的文件：** - 许多小文件比少数大文件更高效地利用上下文 - 更容易只加载相关模块 - 对上下文中的内容有更精细的控制 - 减少加载整个大文件的需要 **清晰的目录结构：** - 合理的组织帮助 Verdent 定位相关文件 - 基于功能或模块的组织改善上下文定位 - 减少加载无关代码的需要 **`Documentation in AGENTS.md:`** - 项目文档替代了加载大量示例文件的需要 - 架构模式描述一次，反复引用 - 编码规范集中记录 - 减少探索性文件读取带来的上下文开销 **优势：** - 在不加载整个代码库的情况下处理独立模块 - 清晰的边界使会话更聚焦 - 沿模块边界拆分工作变得自然 **问题：** - 庞大的单体文件迫使加载整个大型上下文 - 结构不清晰需要加载大量文件才能理解架构 - 同一文件中混杂多种关注点，在无关代码上浪费上下文 **影响：** - 频繁出现上下文上限问题 - 在无关代码上浪费 tokens - 难以将工作隔离到特定模块 - 更频繁地需要重置会话 **常见反模式：** - 单个 `5000+` 行且混杂多种关注点的文件 - 根目录下有 `100+` 个文件的扁平目录结构 - 功能/模块之间没有清晰分离 - 缺乏集中的文档 **重构方法：** - 将大文件拆分为更小、更聚焦的模块 - 按功能或领域组织（而非按文件类型） - 创建清晰的目录层级 - 将共享代码提取到独立模块 **文档：** - 创建包含架构模式的 `AGENTS.md` - 集中记录编码规范 - 每个模块维护 `README` 文件 - 记录设计决策 **上下文影响：** 对于标准 `200K` token 上下文，组织良好的工作区决定了你是频繁还是很少触及上限。对于 `1M` token 上下文，组织的影响较小，但仍能提升效率。 --- ## 上下文优化策略 有效的上下文优化结合了监控、策略规划和技术配置。 **注意性能信号：** - 在整个会话中监控响应质量和速度 - 注意响应何时变慢或准确度降低 - 手动跟踪对话长度和文件数量 - 主动开启全新会话 **需监控的内容：** - 响应的准确性和一致性 - 首次响应时间（输入指示器延迟） - 整体响应完成时间 - 对早期对话细节的记忆 **子智能体管理：** - 不需要时禁用未使用的自定义子智能体 - 每个启用的子智能体都会向系统开销添加定义 - 只保留正在使用的子智能体处于启用状态 - 在特定任务需要时再重新启用 **行动阈值：** 当你注意到 `2-3` 个下降信号时，就该开启全新会话了。 将响应质量作为上下文健康度的领先指标，响应质量下降意味着该重置了。 **分块方法：** - 将大任务拆分为更小的部分 - 在聚焦的会话中完成相关工作 - 避免在长对话中混合不同类型的任务 - 对于内存密集型工作，避免使用上下文窗口的最后五分之一 **会话管理：** - 在主要任务之间开启全新会话 - 提交后清除上下文：测试 → 验证 → 提交 → 新会话 - 使用待办事项进行多步骤规划 - 在各自聚焦的会话中处理待办事项 **最佳实践模式：** 1. 在 Plan Mode 中规划任务 2. 在全新会话中执行聚焦的实现 3. 测试并验证更改 4. 提交到版本控制 5. 为下一个任务开启新会话 **任务隔离：** 将调试与功能开发分开，将研究与实现分开。 **策略性纳入：** - 仅在必要时使用 `@-mentions` 进行显式文件纳入 - 利用 `AGENTS.md` 文档而非加载大量文件 - 对于大型项目，一次只处理一个模块 - 将大文件拆分为更小、更聚焦的组件 **文件选择原则：** - 只纳入需要修改或直接引用的文件 - 优先使用文档而非加载示例文件 - 不再需要时从上下文中移除文件 - 即时加载文件，而非提前加载 **大文件处理：** - 考虑拆分超过 `500` 行的文件 - 将工具函数和辅助函数提取到独立文件 - 使用清晰的模块边界 - 在 `AGENTS.md` 中记录文件关系 **优化工作流：** 监控性能 → 识别会话膨胀 → 禁用未使用的子智能体 → 主动开启全新会话 → 专注于任务质量 **日常实践：** - 每个主要功能都以全新上下文开始 - 频繁提交，并在提交之间重置 - 让每次会话聚焦于单一目标 - 在自然的断点处审视上下文使用情况 **`For Extended Context (1M tokens):`** 借助 Claude Sonnet 4.5 更大的上下文窗口，优化变得不那么关键——专注于任务质量而非激进的上下文管理。不过，良好的实践仍能提升效率和组织性。 --- ## 常见问题 标准模型（Claude 4.5 Sonnet、Haiku、GPT-5、GPT-5-Codex、MiniMax-M2）拥有 `200K` token 上下文窗口，足以应对大多数任务。Claude Sonnet 4.5 提供扩展的 `1M` token 上下文（大 5 倍），适用于包含 `1000+` 文件的大型代码库、复杂的多文件重构或长时间的开发会话。当输入超过 `200K` tokens 时，`1M` 上下文会自动激活，也可以显式选择。 你必须手动开启新会话来重置上下文——Verdent 不会自动清除上下文。最佳实践：在完成一个原子工作单元、测试并提交到版本控制后再重置。对于 `1M` token 上下文，需要重置的频率要低得多。 没有固定的文件数量限制——这取决于文件大小和总 token 数。对于 `200K` 上下文，避免加载 `20+` 个大文件（每个 `>1000` 行）。专注于与当前任务直接相关的文件。有选择地使用 `@-mentions`，并利用 `AGENTS.md` 文档而非加载大量示例文件。使用 `1M` 上下文时，文件选择的重要性大幅降低。 会话中的所有内容：对话中的全部消息、加载进上下文的文件内容、工具输出（grep/搜索结果、文件读取）、系统提示词和指令，以及 MCP 服务器定义。这些都会消耗你总上下文容量中的 tokens。 不会——重置上下文只会从内存中清除对话历史和已加载的文件。你实际的代码更改、提交和文件修改都会保留。为安全起见，请在重置上下文前始终将工作提交到版本控制。重置 → 开启全新会话 → 继续处理下一个任务。 --- ## 另请参阅 编写有效提示词的最佳实践 理解执行模式及其资源影响 监控 token 使用、积分和性能