context-engineering

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Context Engineering

上下文工程

Overview

概述

Core principle: Context is a finite resource with diminishing returns. Find the smallest high-signal token set, not the largest.

200K tokens is shared space: system prompt + conversation history + your processing. As context grows, performance degrades predictably.

**核心原则：**上下文是一种收益递减的有限资源。要找到最小的高信号token集，而非最大的。

200K tokens是共享空间：系统提示词 + 对话历史 + 处理内容。随着上下文规模扩大，性能会出现可预见的下降。

When to Use

适用场景

Session > 30 minutes or 50k+ tokens
Instructions being ignored or forgotten
Repeated clarifications needed
Planning multi-agent workflows
Preparing handoffs between sessions

会话时长超过30分钟或token数达到50k+
指令被忽略或遗忘
需要反复澄清问题
规划多Agent工作流
准备会话间的交接

Quick Reference

速查指南

Problem	Symptom	Fix
Lost-in-middle	Mid-conversation instructions ignored	Move critical info to start/end
Context poisoning	Errors compounding, hallucinations referenced	Summarize and reset
Context distraction	Irrelevant info degrading performance	Prune aggressively
Context confusion	Conflicting guidance causing inconsistency	Consolidate instructions

问题	症状	解决方法
丢失中间信息	对话中途的指令被忽略	将关键信息移至开头/结尾
上下文污染	错误不断叠加，幻觉内容被引用	总结并重置上下文
上下文干扰	无关信息导致性能下降	大幅删减无关内容
上下文混淆	冲突的指引导致行为不一致	整合指令内容

Degradation Patterns

性能下降模式

1. Lost-in-Middle Effect

1. 丢失中间信息效应

Information in context middle gets 10-40% lower recall than edges.

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

Fix: Strategic placement

Critical instructions → START (system prompt, first user message)
Recent decisions → END (last few messages)
Reference material → MIDDLE (acceptable for lookup, not instructions)

上下文中间位置的信息召回率比首尾低10-40%。

[开头 - 高关注度]
  ↓
[中间 - 低关注区域]  ← 此处的指令会被忽略
  ↓
[结尾 - 高关注度]

**解决方法：**策略性放置信息

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

2. Context Poisoning

2. 上下文污染

Early hallucination gets referenced → compounds → becomes "fact".

Symptoms:

Confident statements contradicting earlier facts
"As we discussed..." referencing things never said
Circular reasoning citing own previous errors

Fix: Checkpoint and summarize

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..."

早期出现的幻觉内容被引用 → 不断叠加 → 变成「事实」。

症状：

自信的陈述与早期事实矛盾
出现「正如我们之前讨论的...」但实际从未提及
循环引用自身之前的错误进行推理

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

每10-15轮对话，创建明确的检查点：

"我来总结一下我们已经确认的内容：
1. [已验证事实]
2. [已验证事实]
3. [已做出的决策]

接下来继续推进..."

3. Context Distraction

3. 上下文干扰

Irrelevant tokens compete for attention budget.

Symptoms:

Responses reference unrelated earlier topics
Focus drifts from current task
Unnecessary caveats about old context

Fix: Aggressive pruning

Use
```
/clear
```
+ summary for fresh context
In multi-agent: give subagents ONLY relevant context
Remove resolved discussions from active consideration

无关token占用注意力预算。

症状：

回复引用不相关的早期话题
偏离当前任务焦点
对旧上下文做出不必要的说明

**解决方法：**大幅删减

使用
```
/clear
```
命令+总结来获取全新上下文
在多Agent场景中：仅向子Agent提供相关上下文
从活跃上下文移除已解决的讨论内容

4. Context Confusion

4. 上下文混淆

Multiple conflicting instructions create inconsistent behavior.

Symptoms:

Alternating between approaches
"On one hand... on the other hand..." hedging
Ignoring some instructions to satisfy others

Fix: Consolidate

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"

多条冲突指令导致行为不一致。

症状：

在不同方法之间切换
出现「一方面...另一方面...」的含糊表述
为满足部分指令而忽略其他指令

**解决方法：**整合指令

整合前："使用TypeScript"（消息3）+ "保持简洁"（消息12）+ "处处添加类型"（消息27）

整合后："使用TypeScript并采用实用类型定义——在有帮助的地方添加类型，明显的地方可以省略"

Optimization Techniques

优化技巧

Compaction

压缩

When approaching limits, summarize context sections:

markdown

undefined

当接近token上限时，总结上下文段落：

markdown

undefined

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]

undefined

目标： [一句话描述] 已做出的决策：

[决策1]
[决策2] 当前状态： [已完成内容，下一步计划] 关键约束： [仍生效的要求]

[使用全新上下文继续对话]

undefined

Observation Masking

观察屏蔽

Replace verbose tool outputs with compact references:

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

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

替换前：[上下文包含500行文件内容]
替换后："已读取src/app/page.tsx - 包含Hero、About、FAQ组件的React组件"

Context Partitioning (Multi-Agent)

上下文分区（多Agent场景）

Isolate subtasks in separate agents with clean contexts:

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

Rule: Subagents get task + minimum required context, NOT full conversation history.

将子任务隔离到独立Agent中，每个Agent使用干净的上下文：

主Agent（编排者）：
  - 高层级计划
  - 结果整合

子Agent 1（搜索）：        子Agent 2（实现）：
  - 仅拥有搜索相关上下文       - 仅拥有实现相关上下文
  - 返回总结内容           - 返回代码

**规则：**子Agent仅获取任务+最低必要上下文，而非完整对话历史。

Practical Workflow

实用工作流

For Long Sessions (>1 hour)

长会话（>1小时）

dot

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";
}

Health check questions:

Are recent instructions being followed?
Is focus staying on current task?
Are responses becoming vague or hedgy?

dot

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";
}

健康检查问题：

近期指令是否被遵循？
是否保持对当前任务的关注？
回复是否变得模糊或含糊其辞？

For Handoffs (/save-session)

会话交接（/save-session）

Capture for next session:

Goal state - What were we trying to achieve?
Current state - What's done, what's broken?
Key decisions - Why did we choose X over Y?
Active constraints - What rules still apply?
Next steps - Where to pick up?

为下一次会话记录以下内容：

目标状态 - 我们要实现什么？
当前状态 - 已完成内容、存在的问题？
关键决策 - 为什么选择方案X而非Y？
生效约束 - 哪些规则仍然适用？
下一步计划 - 从哪里继续推进？

For Subagents

子Agent使用

markdown

undefined

markdown

undefined

Subagent Prompt Template

子Agent提示词模板

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]

undefined

任务： [具体交付物] 上下文： [仅提供必要内容 - 最多50-200词] 约束： [硬性要求] 输出格式： [返回内容格式]

[请勿包含：对话历史、已解决的讨论、无关文件]

undefined

Anti-Patterns

反模式

Anti-Pattern	Why it fails	Better approach
"Include everything just in case"	Dilutes attention, causes distraction	Include only what's needed NOW
Repeating instructions every message	Wastes tokens, implies they weren't heard	Trust system prompt, reinforce only when ignored
Long file dumps without summary	Lost-in-middle effect	Read → summarize → reference summary
Keeping resolved threads active	Context confusion	Summarize resolution, move on

反模式	失败原因	更好的做法
"为以防万一，包含所有内容"	分散注意力，导致干扰	仅包含当前需要的内容
每条消息重复指令	浪费token，暗示之前未被听取	信任系统提示词，仅在被忽略时强化
直接大段粘贴文件而不总结	出现丢失中间信息效应	读取→总结→引用总结内容
保留已解决的对话线程	导致上下文混淆	总结解决方案，继续推进

Token Budget Guidelines

Token预算指南

Context size	Expected quality	Action
< 20k	Optimal	Continue normally
20-50k	Good	Monitor for degradation
50-100k	Degrading	Active management needed
100-150k	Poor	Summarize and reset soon
> 150k	Critical	Reset with checkpoint

上下文规模	预期质量	行动建议
< 20k	最优	正常继续
20-50k	良好	监控性能下降情况
50-100k	下降中	需要主动管理
100-150k	较差	尽快总结并重置
> 150k	严重	基于检查点重置上下文

Key Insight

核心见解

"The goal isn't to use all 200K tokens. It's to use the fewest tokens that achieve your outcome."

Informativity over exhaustiveness. Include what matters for current decisions, exclude everything else, and design systems that access additional information on demand.

"目标不是用完所有200K tokens，而是用最少的token达成目标。"

优先信息性而非全面性。仅包含当前决策所需的内容，排除所有无关信息，并设计可按需获取额外信息的系统。

What Claude Does vs What You Decide

Claude负责的工作 vs 你需要做的决策

Claude handles	You provide
Monitoring context health	Decision to reset or continue
Creating checkpoint summaries	Validation that summary is accurate
Pruning irrelevant content	Judgment on what's still needed
Structuring subagent prompts	Strategic task decomposition
Detecting degradation patterns	Timing of interventions

Claude负责	你需要提供
监控上下文健康状况	决定重置或继续会话
创建检查点总结	验证总结内容的准确性
删减无关内容	判断哪些内容仍需保留
构建子Agent提示词结构	策略性任务分解
检测性能下降模式	确定干预时机

Skill Boundaries

技能边界

This skill excels for:

本技能擅长处理：

Long sessions (>30 min, >50k tokens)
Multi-agent workflows with handoffs
Complex projects spanning multiple sessions
Debugging "forgotten instruction" issues

长会话（>30分钟，>50k tokens）
涉及交接的多Agent工作流
跨多个会话的复杂项目
调试「指令遗忘」问题

This skill is NOT ideal for:

本技能不适合：

Short, focused interactions → Not needed
Single-turn queries → Overhead unnecessary
Tasks with naturally bounded context → Already constrained

简短、聚焦的交互 → 无需使用
单轮查询 → 会增加不必要的开销
上下文天然受限的任务 → 已处于约束状态

Skill Metadata

技能元数据

yaml

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

yaml

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