context-engineering

上下文工程

概述

核心原则： 上下文是一种有限资源，收益会逐渐递减。应寻找信号密度高且尽可能精简的 token 集合，而非追求数量最大化。

200K 个 token 是共享空间：系统提示词 + 对话历史 + 你的处理内容。随着上下文增长，性能会有规律地下降。

适用场景

• 会话超过 30 分钟或达到 50k+ 个 token
• 指令被忽略或遗忘
• 需要反复澄清
• 规划多 Agent 工作流
• 为不同会话之间的交接做准备

快速参考

问题	症状	解决方法
中间遗忘	对话中段的指令被忽略	将关键信息移到开头或结尾
上下文污染	错误不断累积，幻觉被当作依据	总结并重置
上下文干扰	无关信息降低性能	大幅精简
上下文混乱	指引相互冲突，导致行为不一致	整合指令

性能下降模式

1. 中间遗忘效应

上下文中间的信息，其召回率比边缘位置低 10-40%。

[START - High attention]
  ↓
[MIDDLE - Low attention zone]  ← Instructions here get ignored
  ↓
[END - High attention]

解决方法： 策略性地安排位置

• 关键指令 → 开头（系统提示词、第一条用户消息）
• 最新决策 → 结尾（最近几条消息）
• 参考资料 → 中间（适合查阅，不适合放指令）

2. 上下文污染

早期幻觉被引用 → 不断累积 → 变成“事实”。

症状：

• 自信地陈述与早前事实相矛盾的内容
• 引用从未说过的内容，如“正如我们讨论过的……”
• 循环论证，援引自己先前的错误

解决方法： 设置检查点并总结

Every 10-15 exchanges, create explicit checkpoint:

"Let me summarize what we've established:
1. [Verified fact]
2. [Verified fact]
3. [Decision made]

Continuing from here..."

3. 上下文干扰

无关 token 会争夺注意力预算。

症状：

• 回复提及早先无关的话题
• 注意力从当前任务上偏移
• 对旧上下文做出不必要的保留说明

解决方法： 大幅精简

• 使用 /clear + 总结来开启新上下文
• 在多 Agent 场景中，只向子 Agent 提供相关上下文
• 不再将已解决的讨论纳入当前考量

4. 上下文混乱

多条相互冲突的指令会导致行为不一致。

症状：

• 在不同方案之间来回切换
• 犹豫不决，例如“从一方面看……但另一方面……”
• 为满足某些指令而忽略其他指令

解决方法： 整合

Before: "Use TypeScript" (message 3) + "Keep it simple" (message 12) + "Add types everywhere" (message 27)

After: "TypeScript with practical typing - types where they help, skip where obvious"

优化技巧

压缩

接近限制时，总结上下文中的各个部分：

## Session Summary (compacted)

**Goal:** [One sentence]
**Decisions made:**
- [Decision 1]
- [Decision 2]
**Current state:** [What's done, what's next]
**Key constraints:** [Still-active requirements]

---
[Continue with fresh context]

观察结果屏蔽

将冗长的工具输出替换为简洁的引用：

Before: [500 lines of file content in context]
After: "Read src/app/page.tsx - React component with Hero, About, FAQ sections"

上下文分区（多 Agent）

将子任务隔离到上下文清晰的独立 Agent 中：

Main Agent (orchestrator):
  - High-level plan
  - Synthesis of results

Subagent 1 (search):        Subagent 2 (implement):
  - Only search context       - Only implementation context
  - Returns summary           - Returns code

规则： 子 Agent 只获取任务和最低限度的必要上下文，不要提供完整的对话历史。

实用工作流

长时间会话（超过 1 小时）

digraph context_management {
  "Every 15-20 min" [shape=diamond];
  "Context healthy?" [shape=diamond];
  "Continue" [shape=box];
  "Create checkpoint summary" [shape=box];
  "Consider /clear + summary" [shape=box];

  "Every 15-20 min" -> "Context healthy?";
  "Context healthy?" -> "Continue" [label="yes"];
  "Context healthy?" -> "Create checkpoint summary" [label="degrading"];
  "Create checkpoint summary" -> "Consider /clear + summary";
}

健康检查问题：

• 最近的指令是否得到遵循？
• 是否始终聚焦于当前任务？
• 回复是否变得含糊或犹豫？

会话交接（/save-session）

为下一次会话记录：

1. 目标状态 - 我们想要实现什么？
2. 当前状态 - 哪些已完成，哪些存在问题？
3. 关键决策 - 为什么选择 X 而不是 Y？
4. 当前约束 - 哪些规则仍然适用？
5. 下一步 - 从哪里继续？

子 Agent

## Subagent Prompt Template

**Task:** [Specific deliverable]
**Context:** [ONLY what's needed - 50-200 words max]
**Constraints:** [Hard requirements]
**Output format:** [What to return]

[Do NOT include: conversation history, resolved discussions, unrelated files]

反模式

反模式	失败原因	更好的做法
“以防万一，把所有内容都加上”	稀释注意力，造成干扰	只包含现在所需的内容
每条消息都重复指令	浪费 token，还暗示对方没听到	信任系统提示词，仅在指令被忽略时重申
直接倾倒冗长文件，不做总结	中间遗忘效应	阅读 → 总结 → 引用总结
让已解决的讨论继续占据上下文	上下文混乱	总结解决方案，然后继续

Token 预算指南

上下文大小	预期质量	操作
< 20k	最佳	正常继续
20-50k	良好	监控是否出现性能下降
50-100k	下降	需要主动管理
100-150k	较差	尽快总结并重置
> 150k	危急	使用检查点重置

关键见解

“目标不是用完所有 200K 个 Token，而是用尽可能少的 Token 达成目标。”

信息量优先于面面俱到。只包含当前决策所需的内容，排除其他所有内容，并设计能够按需获取额外信息的系统。

---

Claude 负责什么，你决定什么

Claude 负责	你提供
监控上下文状态	决定重置还是继续
创建检查点摘要	验证摘要是否准确
清理无关内容	判断哪些内容仍有用
构建子 Agent 提示词	对任务进行策略性拆分
检测性能下降模式	决定何时干预

---

技能适用范围

此技能适用于：

• 长时间会话（>30 min、>50k 个 Token）
• 带有交接的多 Agent 工作流
• 跨多个会话的复杂项目
• 调试“忘记指令”问题

此技能不适用于：

• 简短、聚焦的交互 → 无需使用
• 单轮查询 → 不必要的开销
• 上下文范围天然有限的任务 → 已受到约束

---

技能元数据

name: context-engineering
category: meta
version: 2.0
author: GUIA
source_expert: Anthropic research, NeoLabHQ context-engineering-kit
difficulty: advanced
mode: centaur
tags: [context, tokens, memory, multi-agent, handoff, optimization]
created: 2026-02-03
updated: 2026-02-03