上下文工程：Agent 时代真正的护城河

2025 年大家还在卷 Prompt Engineering。2026 年顶尖团队已经在卷 Context Engineering——Prompt 只是上下文的一小部分。

从 Prompt 到 Context

Prompt Engineering（2023-2024）:
  关注 → 怎么写更好的指令
  范围 → 用户输入的那几句话

Context Engineering（2025-2026）:
  关注 → 给 LLM 的完整信息环境
  范围 → System Prompt + Skills + 检索文档 + 工具结果
         + 历史对话 + 代码文件 + 错误日志 + ……

Anthropic 和 Cursor 的工程博客都在强调：同样一个 Prompt，不同的上下文组成，输出质量可以差 10 倍。

上下文的组成

一次 Agent 调用的完整上下文：

┌─ System Prompt ─────────────────────────┐  ~500 tokens
│  基线规则、角色、安全约束                  │
├─ Skills（按需加载）──────────────────────┤  ~1000 tokens
│  当前任务相关的 SOP                      │
├─ MCP Resources ────────────────────────┤  ~2000 tokens
│  检索到的文档、schema、配置              │
├─ Code Context ─────────────────────────┤  ~8000 tokens
│  相关源文件、目录结构                    │
├─ Tool Results ─────────────────────────┤  ~3000 tokens
│  之前 tool call 的返回                   │
├─ Conversation History ───────────────────┤  ~5000 tokens
│  多轮对话历史                            │
├─ User Message ─────────────────────────┤  ~200 tokens
│  当前用户输入                            │
└────────────────────────────────────────┘
                              Total: ~20,000 tokens
                              Window limit: 128,000

看起来窗口够用？实际问题：

中间迷失——LLM 对上下文中间部分的关注度显著低于首尾
噪声干扰——不相关的文件/文档会「带偏」模型
成本线性增长——每多 1000 token，延迟和费用都在涨

六大上下文策略

1. 精确检索，而非全量灌入

❌ 把整个 repo（500 文件）塞进上下文
✅ 用代码索引 + 语义搜索，只加载 5-10 个相关文件

Cursor 的 @file 和 @codebase 就是这个思路——@file 精确，@codebase 语义检索后精选。

2. 分层摘要

长对话 / 长文档的处理：

原始对话（5000 tokens）
  → 摘要（500 tokens）：「用户想重构 auth 模块，已完成 JWT 实现，正在写测试」
  → 只保留摘要 + 最近 3 轮完整对话

Claude Code 在长任务中会自动压缩早期步骤的上下文，保留关键决策和最新状态。

3. 工具结果的 selective inclusion

Agent 调了 10 次 tool，不是 10 次结果都留：

Tool call 1: ls → 保留（目录结构有用）
Tool call 2: cat config.json → 保留（配置信息）
Tool call 3: npm test → 只保留失败的那几行（全文 2000 行太长）
Tool call 4-7: 中间调试 → 丢弃（已被后续结果 supersede）
Tool call 8: 最终 fix → 保留

4. 动态 Skill 加载

不要一次性加载 20 个 Skill。根据任务类型加载 1-3 个最相关的：

任务: "创建 PR"
  → 加载: git-commit Skill, PR-template Skill
  → 不加载: deploy Skill, test Skill

5. 结构化 > 自然语言

同样的信息，结构化格式比散文省 token、准确率高：

❌ 「这个项目用 TypeScript，框架是 Astro 5，样式用 Tailwind 4，
    部署在 Cloudflare Pages，数据库没有……」（100 tokens）

✅ stack: { lang: "TS", framework: "Astro 5", css: "Tailwind 4",
           deploy: "CF Pages", db: null }（30 tokens）

6. 关键信息的位置优化

利用 LLM 的「首尾效应」：

[System Prompt]     ← 规则放这里，模型始终遵守
[... 大量中间内容 ...]
[User Message]      ← 当前任务放这里，模型最后看到
[Recent Tool Result] ← 最新结果紧贴 user message

真实案例：Cursor 的上下文策略

Cursor Agent 模式的实际上下文构建（基于公开信息和观察）：

System Prompt — Cursor 内置的 coding agent 指令
Rules — .cursor/rules/ 项目规则
Skills — 匹配的 SKILL.md
Codebase Index — 预建的语义索引，检索 top-K 相关文件
Open Files — 用户当前打开的文件（权重更高）
Terminal Output — 最近的命令输出
MCP Resources — 配置的 MCP Server 返回的数据
Conversation — 当前 session 的对话历史

Cursor 的 Harness 核心优化之一就是 Codebase Index 的检索质量——这决定了 Agent 能不能找到正确的文件。

真实案例：Claude Code 的长任务上下文

Claude Code 处理「重构整个模块」这类长任务时：

初始：加载相关文件 + CLAUDE.md 项目指令
中间：每完成一个 sub-task，压缩已完成步骤为摘要
遇到 error：只保留 error message + 相关 stack trace，不保留完整 log
最终：上下文里主要是「当前状态 + 剩余任务 + 最近操作」

这让 Claude Code 能在 50+ 步的操作中保持连贯，而不是到第 30 步就「忘了」最初的目标。

度量上下文质量

指标	含义	怎么测
Context Precision	上下文中有多少是真正相关的	人工标注 relevance
Context Recall	该给的信息是否都给了	对比「理想上下文」
Token Efficiency	达到同样效果用了多少 token	A/B 不同策略的 token 数
Needle-in-Haystack	关键信息被淹没后模型能否找到	标准 benchmark

小结

Prompt 是你对模型说的话。Context 是模型看到的世界。 优化 Context，比优化 Prompt 重要一个数量级。

这是 Agent Harness 里 ROI 最高的优化方向——下一篇讲怎么度量 Agent 到底好不好：Eval 与可观测性。