用途
Context Management 用于管理 AI 编码代理的上下文窗口，在上下文压缩（compaction）和跨会话场景下持久化状态。Claude Code 运行在约 128K token 的上下文窗口中，窗口填满时会自动压缩。压缩后，任务状态、工具结果（摘要形式）、近期用户消息和系统指令会保留；而代理的推理与分析、中间探索结果、读取过的文件内容、未记录的决策会消失。若不显式管理状态，代理在压缩后会“失忆”——知道该做什么，却不知道已经做了什么、决定了什么。
该技能适用于：规划长周期或多步骤任务、协调多个子代理、接近上下文上限（响应变慢、重复、推理退化）、需要在压缩或会话之间保留状态、编排带交接的复杂工作流。不适用于：简单单轮任务、快速问答、一次响应即可完成的任务。
主要能力
任务作为可存活的状态层
任务不只是追踪器，而是持久记忆层。使用 TaskCreate、TaskUpdate、TaskList、TaskGet 管理可跨压缩存活的状态。任务中可记录：当前工作（状态 in_progress）、已完成工作（状态 completed）、发现的待办工作（状态 pending）、关键决策（写入任务描述）、代理交接（含 agentId 元数据）、阻塞项（创建阻塞任务并用 blockedBy 字段关联）。
任务纪律：任意时刻只有一个 in_progress 任务；开始前用 TaskUpdate 标记 in_progress；完成时立即标记 completed，不要批量处理；在任务元数据中包含代理 ID 以支持可恢复会话；随发现动态扩展任务，不要预先全部列出；任务主题使用动词，如“Implement X”“Fix Y”“Review Z”。
状态流转：pending → in_progress → completed；若被阻塞，不要标记完成，而是为阻塞项创建新任务并用 addBlockedBy 关联。
压缩前模式
当上下文填满时（表现为响应变慢、重复、推理退化），执行压缩前检查清单：捕获进度（用 TaskUpdate 将已完成任务标记 completed 并在描述中写明结果）；记录决策（决定了什么、为什么，写入任务描述）；注明当前状态（在 in_progress 任务中写明具体位置）；排队发现的工作（TaskCreate 为 pending）；标记依赖（用 addBlockedBy）；记录后台代理 ID（写入任务元数据）。
示例对比——差（状态会丢失）：
- [x] Research auth approaches
- [ ] Implement auth
- [ ] Test auth
好（状态可存活）：
- [x] Research auth approaches → middleware + JWT (see src/auth/README.md)
- [ ] [in_progress] Implement JWT refresh flow
- Using jose library (already in deps)
- Endpoint: POST /api/auth/refresh
- Handler started in src/auth/refresh.ts:15
- Remaining: validation logic, token rotation
- [ ] Add refresh flow tests (after impl)
- [ ] [reviewer] Security review auth module (after tests)
通过委派保留上下文
主对话上下文很宝贵，每读一个文件、每条搜索结果、每个中间想法都消耗 token。子代理在隔离上下文中运行，只有最终输出返回。默认立场：能委派就委派。
委派决策树：探索/研究 → Explore 代理（总是）；多文件读取 → 子代理（为你总结）；独立子任务 → 后台代理；专业领域 → 领域代理（reviewer、tester 等）；简单、聚焦、单文件 → 主代理（可选）。
注意：插件代理需要 plugin:agent-name 格式（如 outfitter:reviewer）；内置代理（Explore、Plan、general-purpose）无需前缀。使用 /agents 查看可用代理。
节省上下文的模式：研究委派（不读 10 个文件，而是让 Explore 代理定位并总结认证流程，主代理只收到简洁摘要）；并行审查（单条消息多个调用，均 run_in_background: true，如 outfitter:reviewer 做安全审查、outfitter:analyst 做性能审查，主代理保持精简）；后台执行（独立工作用 run_in_background: true，继续其他工作，稍后用 TaskOutput 取回）。
任务集成：用任务追踪委派工作，例如 [analyst] Research caching strategies（pending，metadata: {taskId: "def456"}）、[engineer] Implement cache layer（pending，blockedBy: analyst task）等。后台代理完成时，TaskUpdate 状态并处理结果。
不应委派的情况：需要对话历史的直接用户问答；对已在上下文中的文件做简单编辑；需要你判断的最终综合。
跨会话模式
跨会话工作需要配置 episodic-memory MCP 服务器；若不可用则跳过本节，任务系统可处理单会话持久化。
保存状态：在会话结束或长时间暂停前，调用 episodic-memory:save，内容包含 task、status、completed、remaining、decisions、files_modified、next_steps 等字段。
恢复状态：会话开始时调用 episodic-memory:search，查询如 "auth refresh implementation"，然后用 TaskCreate 从保存状态重建任务。
跨会话适用场景：多日项目、步骤繁多的复杂重构、会被打断的工作、交接给未来会话。单会话工作仅用任务系统即可。
使用方式
工作流集成：任务开始时，用 TaskCreate 创建初始范围；若复杂，用 Plan 子代理探索以保留主上下文；将第一个任务 TaskUpdate 为 in_progress。执行期间，随进展 TaskUpdate；将探索委派给子代理；立即标记完成（不批量）；为发现的工作 TaskCreate；在已完成任务描述中记录决策。接近压缩时，运行压缩前检查清单，确保当前状态写入 in_progress 任务描述，在任务元数据中记录后台代理 ID。压缩后，用 TaskList 读取任务状态（会持久化），从 in_progress 任务恢复，利用保存的细节继续而无需重新探索。任务完成时，将最终任务 TaskUpdate 为 complete 并在描述中写明结果；若跨会话，保存到 episodic memory；向用户报告摘要。
始终：对超过 2-3 步的工作使用任务；重大操作前 TaskUpdate；立即标记完成而非批量；在任务元数据中包含代理 ID 以支持可恢复会话；将探索委派给子代理；在已完成任务描述中记录决策；上下文填满时运行压缩前检查清单。
绝不：依赖对话历史在压缩后存活；在主上下文中保留大量研究结果（委派或总结）；同时有多个 in_progress 任务；因上下文顾虑提前停止（应持久化状态）；批量完成多个任务；任务描述含糊（“do the thing” → “Implement refresh endpoint”）。
适用场景
长周期或多步骤任务规划；多子代理协调；接近上下文上限时；需要在压缩或会话之间保留状态；带交接的复杂工作流编排。
限制
不适用于简单单轮任务、快速问答、一次响应即可完成的任务。跨会话模式依赖 episodic-memory MCP 服务器，未配置时不可用。上下文窗口大小（约 128K token）和自动压缩行为为 Claude Code 的既定特性。