上下文管理

大多数模型使用标准的 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+ 文件的大型代码库
• 跨整个项目的复杂多文件重构
• 横跨多个相关任务的长时间开发会话
• 当你希望尽量减少上下文管理开销时

信号：

• 响应准确度降低或不完整
• 遗漏对话中较早出现的重要细节
• 难以在长会话中保持一致性
• 对最近的更改或上下文感到困惑

具体示例：

• 提出你在本次会话早些时候已经否决的方案
• 忽略你在 20 条消息之前确立的编码约定
• 生成与对话早期所做更改相冲突的代码
• 提出与之前讨论过的项目架构不符的实现方案

主要信号： Verdent 的响应准确度降低或不一致

信号：

• 响应时间明显变慢
• 开始响应前的处理延迟变长
• 消息之间的延迟增加

具体示例：

• 通常需要 5-10 秒的响应现在需要 30+ 秒
• 发送消息后，输入指示器出现前有明显延迟
• 流式响应开始得比平常慢得多
• 工具执行（文件读取、搜索）耗时明显变长

主要信号： 响应耗时比平常明显更长

信号：

• 要求澄清已经提供过的信息
• 忘记之前确立的模式或约定
• 无法引用之前讨论过的文件或代码
• 重复询问项目结构

具体示例：

• 在你 30 条消息前已说明使用 React 后，仍问"你用的是什么框架？"
• 重复索要你已经 @-mentioned 多次的文件路径
• 不记得你在会话开始时确立的命名约定
• 重新解释你已附理由否决的概念或方法

主要信号： Verdent 询问已经讨论过的内容

信号：

• 接近 200K token 上限的最后五分之一（已使用约 160K+ tokens）
• 包含大量文件读取和工具输出的长对话
• 启用了多个带有大量工具定义的 MCP 服务器
• 反复将大文件加载进上下文

具体示例：

• 会话已运行 2+ 小时，包含 100+ 条消息
• 你在对话中加载了 20+ 个文件，@-mentions
• 多个大文件（每个 >1000 行）都在上下文中
• 你启用了 5+ 个带有大量工具定义的 MCP 服务器
• 对话包含大量 grep/搜索结果和文件读取

主要信号： 伴随大量文件/工具使用的超长会话

• 响应时间明显变慢
• 响应准确度降低或不一致
• 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 更大的上下文窗口，优化变得不那么关键——专注于任务质量而非激进的上下文管理。不过，良好的实践仍能提升效率和组织性。