Context Engineering

问题

什么是 Context Engineering？它和 Prompt Engineering 的区别是什么？如何设计 AI 应用的上下文结构、管理上下文窗口、选择性注入上下文、处理长任务中的上下文膨胀？有哪些常见反模式？

面试速答版

什么是 Context Engineering？它和 Prompt Engineering 的区别？ 2026 年的共识：用户那一句 Prompt 只占上下文的 0.1%，剩下 99.9% 才是决定 AI 表现的关键，这就是 Context Engineering 的研究对象：

• Prompt Engineering 关注「怎么写好一句话」；Context Engineering 关注「整个上下文窗口里塞了什么、怎么组织、何时淘汰」。
• 一个 Agent 上下文通常是：System Prompt + Rules + 工具 schema + 对话历史 + RAG 片段 + 工具结果，30K~700K tokens。
• 它是从 Prompt 工艺升级为系统工程的过渡。

如何设计上下文结构、管理窗口、选择性注入、处理上下文膨胀？ 按四个维度拆：

• 结构：分层拼装（system / rules / tools / history / retrieval / user），每层用 XML 或 Markdown 标题清晰隔离。
• 窗口管理：估算 token 预算，按优先级裁剪——保留 system + 最新几轮，老对话用摘要替换。
• 选择性注入：Skill / Tool / RAG 都按需加载，而不是开局全塞。
• 长任务膨胀：用 Compaction（摘要旧轮次）、子 Agent（隔离子任务上下文）、Prompt Caching（缓存稳定前缀降本 90%）。

有哪些常见反模式？ 踩过坑的人都知道这几个：

• All-in 上下文：把所有文档、所有历史一股脑塞进去，又贵又稀释关键信息（lost in the middle）。
• System Prompt 越长越好：超过 2K 后边际效益递减，反而压缩了可用窗口。
• 不做 Compaction：Agent 跑十几轮后上下文炸裂、性能断崖。
• 重要信息放中间：放头尾命中率最高，关键约束要么放最前面要么放最后。

答案

一、从 Prompt Engineering 到 Context Engineering

2023-2024 年大家在谈 Prompt Engineering——如何写好一句 Prompt 让 AI 给出好答案。2026 年行业共识是：单次 Prompt 的影响力远小于完整上下文的影响力。一个现代 Agent 的上下文里通常包含：

system prompt (1-3K tokens)
+ Rules / 项目约定 (2-10K)
+ 工具定义 schemas (5-30K)
+ 对话历史 (10-100K)
+ 检索到的文档片段 (5-50K)
+ 工具调用结果 (10-500K)
+ 用户 prompt (0.1K)
———————————————————
总计 30K - 700K tokens

用户写的那一句 Prompt 其实只占上下文的 0.1%。真正决定 AI 表现的是其余 99.9% 的内容——这就是 Context Engineering 的研究对象。

定义：Context Engineering 是对 LLM 上下文窗口中每一个 token 的系统性设计——包括它们从哪来、怎么组织、什么时候加载、什么时候淘汰、如何压缩。

二、上下文窗口的物理限制和经济学

物理限制

模型	上下文窗口	输出上限	注意事项
Claude Opus 4.7	200K（1M beta）	64K	1M 版本需要申请权限
Claude Sonnet 4.6	200K（1M beta）	64K	同上
Claude Haiku 4.5	200K	32K	—
GPT-5	400K	128K	—
Gemini 3 Pro	2M	64K	超长但检索准确度随长度下降

经济学与性能

不是上下文越长越好。三个关键代价：

1. 成本：输入 token 按量计费。200K 输入 = $0.6~$3（视模型）。一个 Agent 长任务输入 token 可能消耗 50M+，单次对话几十美元
2. 延迟：上下文越长，首个 token 延迟（TTFT）越长。200K 输入的 TTFT 可能达到 10-30 秒
3. 质量下降：LLM 存在 "Lost in the Middle" 效应——中间位置的信息被忽视概率最高。上下文超过 50K 后，模型对中间内容的使用率显著下降（2024 年 Stanford 研究，在主流模型上仍成立）

结论：追求最小充分上下文，不是最大可能上下文。

Prompt Caching 的经济学

Anthropic/OpenAI/Gemini 都提供 Prompt Caching：不变的上下文前缀（system prompt + rules + 工具定义）缓存后，后续命中只收 1/10 成本。

实践要点：

• 稳定内容放在上下文最前面（利用前缀匹配）
• 变化内容（用户消息、检索结果）放在最后面
• Claude 缓存 TTL 5 分钟，期间连续调用都命中
• 对话场景能省 50-80% 输入成本

详见 AI 应用性能优化。

三、上下文的构成与分层

一个设计良好的 AI 系统，上下文应该是分层结构：

分层设计原则

层级	稳定性	加载时机	典型大小	Cache 策略
System Prompt	永不变	每次请求	1-3K	强制缓存
Rules / CLAUDE.md	项目内稳定	每次请求	2-10K	强制缓存
Tool Definitions	迭代级稳定	每次请求	5-30K	强制缓存
Skill Metadata	迭代级稳定	每次请求	1-5K	强制缓存
Skill Content	按需加载	触发时	0.5-10K	按会话缓存
Conversation History	会话级变化	每次请求	可变	增量缓存
RAG 检索结果	每次变化	按需检索	2-20K	不缓存
User Prompt	每次变化	当前轮次	0.01-1K	不缓存

关键原则：越稳定的内容越靠前，越动态的内容越靠后——这样能最大化 Prompt Cache 命中率。

四、上下文注入的 6 种来源

1. 预注入（Static Injection）

最传统，System Prompt + Rules 文件一次性注入。

const systemPrompt = `
你是前端代码审查助手。
${await fs.readFile('.claude/rules.md')}
${await fs.readFile('package.json')}
`;

优点：简单、可控、可缓存 缺点：所有信息平铺，容易撑爆上下文

2. 按需注入（On-Demand Injection）— Skills

AI 根据任务描述自主决定是否加载某个 Skill 的详细内容。

主上下文：[Skills 清单（500 tokens）]
↓ 用户要创建表单
主上下文：[Skills 清单] + [form-builder Skill 详细内容（3K tokens）]

优点：节省 token、信息精准 缺点：依赖 AI 正确匹配，description 要写好

详见 AI 辅助开发 的 Skills 部分。

3. 检索注入（Retrieval Injection）— RAG

根据用户问题从知识库检索相关片段。

rag-inject.ts

// 1. 用户提问
const query = "我们的支付回调接口怎么处理重复通知？";

// 2. 向量检索
const chunks = await vectorDB.search(query, { topK: 5 });

// 3. 重排（可选，大幅提升准确度）
const reranked = await rerank(query, chunks, { topK: 3 });

// 4. 构造上下文
const context = `
以下是从内部文档检索到的相关资料：

${reranked.map((c, i) => `
<doc id="${i}" source="${c.source}">
${c.content}
</doc>
`).join('\n')}

请基于以上文档回答用户问题。如果文档中没有相关信息，请明确告知。
`;

要点：

• 用 XML 标签包裹检索结果，让模型清晰识别
• 明确标注来源（便于溯源）
• 指令里说明"如果文档中没有，请告知"（防止幻觉）

详见 RAG 检索增强生成 和 向量搜索与 Embedding。

4. 工具返回注入（Tool Result Injection）

Agent 调用工具后，结果自动注入下一轮上下文。

陷阱：工具结果常常是上下文膨胀的最大来源。例如：

• list_files 返回 1000 个文件 = 30K tokens
• fetch_api 返回未处理的 JSON = 100K tokens
• read_file 读取大文件 = 50K tokens

最佳实践：

• 在工具层面做聚合/过滤，不要把原始数据都返回
• 长结果先摘要：让 AI 先总结，下轮用摘要代替原文
• Subagent 委派：让 Subagent 处理大量原始数据，只返回结论

5. 动态上下文（Session Memory）

记住用户的偏好、历史决定、未完成的任务——跨会话持久化。

.claude/memory/user_prefs.md

---
type: user
name: 用户偏好
---

- 偏好简洁回答，不要冗长解释
- 代码优先 TypeScript
- 使用 pnpm（不用 npm/yarn）
- 不使用 tailwind 的 @apply

实现方式：

• 文件系统（CLAUDE.md、memory 目录）— 最简单
• SessionStart Hook 注入（只在每个新会话注入一次）
• 专用 Memory 工具（让 AI 主动读写）

6. 实时上下文（Live Context）

在每次请求时动态抓取实时信息：

session-start-hook.ts

// SessionStart Hook：每次会话开始时注入当前状态
const liveContext = `
<current_state>
- Git 分支：${await exec('git branch --show-current')}
- 未提交改动：${await exec('git status --short')}
- 运行中的进程：${await exec('ps aux | grep node')}
- 最近一次构建：${await getLastBuildInfo()}
</current_state>
`;

典型用途：

• 分支/Git 状态
• 运行中的服务/进程
• 最近的报错日志
• 待办任务（Linear、Jira）

五、上下文组织：结构化标记

当上下文超过几千 token，结构化比纯文本好得多。主流模型（Claude、GPT、Gemini）都经过训练识别 XML 风格的标签。

推荐格式

<system_instructions>
你是前端代码审查助手...
</system_instructions>

<project_rules>
- TypeScript strict mode
- 禁止使用 any
</project_rules>

<relevant_files>
<file path="src/api/user.ts">
...
</file>
<file path="src/api/user.test.ts">
...
</file>
</relevant_files>

<conversation_history>
...
</conversation_history>

<current_task>
审查上述文件的安全性
</current_task>

为什么有效：

1. 模型能清晰区分不同上下文来源
2. 模型能引用："根据 <relevant_files> 中 user.ts 第 23 行..."
3. 便于修改/删除某一段（正则匹配标签）

Markdown 也是结构化

除了 XML，良好的 Markdown 结构（一级标题 / 二级标题 / 代码块）同样有效。选一种保持一致即可。

反模式：上下文"大泥球"

// ❌ 坏例子
你是前端审查助手。这是项目代码：function foo() {...} function bar() {...}
package.json 内容是 {...}。用户问题：这里有什么问题。

// ✅ 好例子
<role>前端审查助手</role>

<project_manifest>
{...}
</project_manifest>

<code_to_review>
<file path="foo.ts">...</file>
<file path="bar.ts">...</file>
</code_to_review>

<user_question>
这里有什么问题？
</user_question>

六、长任务中的上下文管理：Compaction

Agent 跑长任务时上下文会无限膨胀：工具调用、错误重试、探索尝试都会堆积在历史里。几小时后上下文可能达到 500K+，触发以下问题：

• 💰 成本爆炸（每轮都带着 500K 输入）
• 🐢 响应变慢（TTFT > 30 秒）
• 🧠 质量下降（Lost in the Middle）
• ❌ 最终撞上下文上限

解决方案：Compaction（压缩）

当上下文达到阈值（如 70% 上限），自动对历史做摘要：

Claude Code 内置 Compaction：当上下文接近上限自动触发 /compact。也可以手动触发。

自己实现 Compaction 的要点：

compact-conversation.ts

async function compactHistory(messages: Message[]): Promise<Message[]> {
  const threshold = 150_000; // 70% of 200K
  const tokens = countTokens(messages);
  if (tokens < threshold) return messages;

  // 保留最近 10 轮（近期上下文完整）
  const recent = messages.slice(-10);
  const older = messages.slice(0, -10);

  // 让小模型做摘要（节省成本）
  const summary = await haiku.complete({
    messages: older,
    systemPrompt: `
总结以上对话。**必须保留**：
1. 已做出的关键决定（架构选型、命名约定）
2. 用户明确的需求和反馈
3. 还未完成的待办事项
4. 曾经犯过的错误（避免重犯）
5. 重要的代码位置引用（文件+行号）

**可以丢弃**：
- 探索过但没采用的方案
- 已完成的代码细节（代码在文件里）
- 重复的工具调用结果
`,
  });

  return [
    { role: 'system', content: `<previous_context_summary>\n${summary}\n</previous_context_summary>` },
    ...recent,
  ];
}

Compaction 是有损的

一定会丢失细节。所以：

• 重要决策要在摘要之外持久化（比如写到 CLAUDE.md 或 memory 文件）
• Compaction 后的新会话要主动告诉 AI "关键决策见 memory/decisions.md"
• 复杂长任务建议拆分成多个短会话，每个有明确输出物

七、上下文质量：信噪比是王道

一条定律：上下文中无关内容每增加 1 倍，有效内容的"注意力"就减半。

降低噪音的具体手段

噪音来源	降噪手段
工具返回的原始 JSON	在工具层先过滤、只返回需要的字段
大文件全量读取	用 Grep/Glob 精确定位，只读相关行
整个目录的所有文件	只读需要的 3-5 个文件
未过滤的日志	按时间/严重级别过滤，提取错误堆栈
重复的对话历史	Compaction 压缩
整个 package.json	只提取 dependencies 和 scripts
冗长的错误说明	提取关键错误码和堆栈首部

反模式：@codebase / 整库检索

很多工具提供"整库检索"功能（Cursor 的 @codebase、Copilot 的 @workspace）。看似方便，但在大型仓库中效果很差——它会把 20 个弱相关的文件全塞进上下文，核心文件反而被淹没。

更好的做法：

• 自己用 Grep 精确定位（grep -rn "关键词"）
• 用 Subagent 做初筛，返回 3-5 个最相关的文件路径
• 手动 @mention 指定文件

正例：典型高质量上下文

目标：让 AI 审查一个支付回调接口

<task>
审查 src/api/payment/callback.ts 的安全性
</task>

<file path="src/api/payment/callback.ts">
// 完整文件内容
</file>

<file path="src/lib/payment-signature.ts" reason="被 callback.ts 调用的签名校验工具">
// 只引用部分
</file>

<project_rules relevant="security">
- 所有支付回调必须做签名校验
- 回调处理必须幂等（参考 src/lib/idempotency.ts）
- 日志不得记录完整卡号和 CVV
</project_rules>

<past_incidents>
- 2025-11：曾因未校验 signature 导致重放攻击（见 postmortem-2025-11.md）
</past_incidents>

这 4 段加起来大约 3K tokens，信噪比极高，AI 能给出靶向精准的审查。

八、Context Engineering 在 RAG 中的特别挑战

RAG 是 Context Engineering 最复杂的场景，关键挑战：

1. Chunking（分块）策略

• 固定长度分块（最简单）：500 tokens 一块，有 50 tokens 重叠
• 语义分块：按段落/代码块/函数切分
• 层级分块：章节 → 段落 → 句子，多粒度索引

详见 RAG 检索增强生成。

2. Reranking（重排）

向量检索召回的 top-K 准确度一般（~70%）。加一层 Reranker 能显著提升到 ~90%：

rag-with-rerank.ts

// 1. 向量检索粗召回 20 条
const candidates = await vectorDB.search(query, { topK: 20 });

// 2. Cross-Encoder 重排精选 3 条
const reranked = await cohere.rerank({
  query,
  documents: candidates,
  topN: 3,
});

// 3. 只把精选的 3 条注入上下文

3. 混合检索

单纯向量搜索对"精确关键词"效果差（比如检索函数名）。组合使用：

• 向量检索：语义相近
• BM25 / 全文检索：关键词精确匹配
• Metadata 过滤：按标签/时间/作者过滤

九、Context Engineering 反模式

这些都是常见陷阱：

1. Context Stuffing（硬塞）

❌ 把整个代码库的 README、CONTRIBUTING、ARCHITECTURE、FAQ 全塞进 system prompt

后果：模型开始"失焦"，回答越来越泛化、越来越重复官方话术。

正解：只塞最小充分集，其他做成 Skills 按需加载。

2. Context Poisoning（中毒）

❌ 把错误的、过期的、矛盾的信息混入上下文

例如：Rules 说"用 React 18"，但 package.json 写着 react@19。AI 会产生判断失误。

正解：

• 定期审查 Rules 的时效性
• 优先使用自动同步的上下文（直接读 package.json 而非写"用 X 版本"）
• 检测矛盾：Hook 在 SessionStart 时对比 Rules 和实际状态

3. Context Leaking（泄露）

❌ 敏感信息（API Key、生产数据、用户隐私）进入了 AI 上下文

后果：数据被发给第三方、可能被用于训练、审计合规风险。

正解：

• .gitignore + .cursorignore 排除敏感文件
• PreToolUse Hook 拦截包含敏感模式的 Bash 命令
• 生产数据在送给 AI 前做脱敏

4. Context Drift（漂移）

❌ 长会话中，历史指令与新需求冲突但都留在上下文

例如：开头说"全用 TypeScript"，中间又让 AI 写一个 Python 脚本，AI 开始混乱。

正解：

• 不同领域的工作开新会话
• 明确纠正时说"忽略之前的 X，现在按 Y 处理"
• 阶段性 Compaction 重置

5. 工具返回爆炸

❌ list_files("/") 返回 10 万行文件列表占满上下文

正解：

• 工具返回设上限（如最多 100 行）
• 超限时返回前 N 条 + 提示"还有 9990 条，请缩小范围"
• 用 Pagination / Filter 让 AI 分批读取

十、Context Engineering 成熟度模型

Level	特征	典型表现
L1：裸 Prompt	每次都手写 Prompt，靠运气	用 ChatGPT 网页版写一次性任务
L2：项目 Rules	有 CLAUDE.md / .cursor/rules	AI 知道技术栈和约定
L3：结构化上下文	XML/Markdown 标签分层	审查/生成质量明显提升
L4：按需加载	Skills + Subagents	Token 成本降低，响应更快
L5：全生命周期管理	Compaction + Memory + Hook 动态注入	Agent 可以跑数小时长任务
L6：团队级基建	所有工程师共享一套经打磨的上下文体系	参见 AI 研发基建

大多数团队目前在 L2-L3 之间。从 L3 跳到 L4 是最大价值跃迁——这就是 2026 年 AI 工具升级的重点。

---

常见面试问题

Q1: Context Engineering 和 Prompt Engineering 有什么区别？

答案：

Prompt Engineering 是 "how to ask"：关心那一句用户 prompt 怎么写（角色、格式、Few-shot 示例等）。

Context Engineering 是 "what to show"：关心整个上下文窗口里每一个 token 的价值——system prompt、Rules、工具定义、检索结果、对话历史、工具返回全都是研究对象。

用户写的那一句话在现代 Agent 里只占上下文的 0.1%，剩下的 99.9% 决定 AI 表现。所以行业共识已经从 "prompt engineering" 升级为 "context engineering"，后者包含前者。

Q2: 上下文不是越长越好吗？为什么还要精心设计？

答案：

三个原因：

1. 成本：200K 输入约 $0.6-$3，一个 Agent 长任务累计 50M 输入 token 很常见，轻松几十美元
2. 延迟：上下文越长 TTFT 越慢，200K 上下文 TTFT 可达 10-30 秒，交互体验严重下降
3. 质量下降：LLM 存在 Lost in the Middle 现象——上下文越长，中间位置的信息被忽略概率越高。实测 50K 以上质量明显下降

结论：追求"最小充分上下文"而不是"最大可能上下文"。通过 Skills 按需加载、Subagent 隔离、Compaction 压缩来控制。

Q3: 怎么设计一个 AI 应用的上下文结构？

答案：

按"稳定性 + 加载时机"分 7 层：

System Prompt (永不变，1-3K)
↓
Rules / CLAUDE.md (项目内稳定，2-10K)
↓
Tool Definitions (迭代级稳定，5-30K)
↓
Skill Metadata (迭代级稳定，1-5K)
↓
Skill Content (按需加载，0.5-10K)
↓
Conversation History (会话级变化)
↓
RAG 检索结果 / User Prompt (每次变化)

关键原则：

• 越稳定越靠前（最大化 Prompt Cache 命中）
• 越动态越靠后（不污染 cache）
• 用 XML/Markdown 标签把每层包起来，让模型清晰区分

Q4: 长任务跑了几小时，上下文爆炸了怎么办？

答案：

Compaction（上下文压缩） 是标准解法：

1. 保留最近 N 轮对话不动（保证近期上下文完整）
2. 更早的历史交给小模型做摘要，只保留：
   • 已做出的关键决策
   • 用户明确的需求和反馈
   • 未完成的待办
   • 曾犯过的错误（避免重犯）
   • 重要代码位置引用
3. 用摘要替代原始历史

Claude Code 的 /compact 就是这个机制。也可以自己写代码实现。

进一步预防：

• 关键决策写到文件（CLAUDE.md、memory/decisions.md），不依赖上下文记忆
• 长任务拆成多个短会话，每个有明确输出物
• 对话达到 70% 上限就触发 Compaction，不要等撞墙

Q5: 什么是 Prompt Caching？怎么设计上下文最大化命中率？

答案：

Prompt Caching：Anthropic/OpenAI/Gemini 提供的功能——前缀相同的上下文可以被缓存，重复命中时只收 1/10 成本、TTFT 也快几倍。

最大化命中率的设计：

1. 稳定内容前置：system prompt + Rules + 工具定义放最前，这些几乎不变
2. 动态内容后置：用户消息、RAG 检索结果、工具结果放最后
3. 避免频繁修改稳定部分：修改 system prompt 会导致整个缓存失效
4. 控制 TTL：Claude 的缓存 TTL 是 5 分钟，连续交互能持续命中

一个聊天 App 正确设计的话能省 50-80% 输入 token 成本，对 B 端高频使用场景差别巨大。

Q6: 工具返回结果太大污染了上下文，怎么办？

答案：

工具返回是上下文膨胀的 最大来源。4 层防御：

1. 工具层做聚合/过滤

工具设计时就不要返回原始数据。例如 list_files 不要返回所有文件，只返回匹配 pattern 的前 N 条，超限时告知"还有 X 条请缩小范围"。

2. AI 层主动摘要

告诉 AI："读完这个大 JSON，先给我一句话总结，不要把原始内容复述"。

3. Subagent 委派

把需要处理大量原始数据的任务派给 Subagent（独立上下文），只让它返回结论：

主 Agent: "搜索整个代码库中所有 SQL 拼接的地方" 
→ 派给 security-reviewer Subagent
→ Subagent 在独立上下文扫描 200 个文件
→ 返回主 Agent："发现 3 处高危拼接，位于 a.ts:23, b.ts:45, c.ts:67"

主上下文只新增几十个 token，不是几万个。

4. 分页读取

大文件用 offset/limit 分批读，AI 根据需要决定是否继续读更多。

Q7: Context Engineering 的常见反模式有哪些？

答案：

5 个高频陷阱：

1. Context Stuffing（硬塞）：把所有文档、README、FAQ 都塞进 system prompt。后果：AI 失焦、回答越来越泛化
2. Context Poisoning（中毒）：上下文里有过期/错误/矛盾的信息。例如 Rules 说 React 18 但 package.json 是 React 19
3. Context Leaking（泄露）：敏感信息（API Key、用户隐私、生产数据）进了上下文，合规和安全风险
4. Context Drift（漂移）：长会话中历史指令和新需求冲突，AI 开始混乱
5. 工具返回爆炸：一个 list_files("/") 占满上下文

缓解手段：

• 审查 Rules 时效性，优先自动同步（直接读 package.json 而不是写"用 X 版本"）
• .gitignore + .cursorignore + PreToolUse Hook 防泄露
• 工具返回设上限，超限分批
• 不同领域工作开新会话，避免 Drift

Q8: @codebase 这种整库检索为什么效果不好？

答案：

Cursor 的 @codebase / Copilot 的 @workspace 会自动往上下文塞进一堆弱相关文件。问题：

1. 信噪比低：塞 20 个文件，可能只有 2 个真正相关。另外 18 个是噪音
2. 撑爆上下文：大型项目单次检索塞 50K tokens 是常态
3. Lost in the Middle：塞得越多，关键文件被忽略概率越高
4. 成本高：每次请求都重新检索，每次都付全额 token 费

更好的做法：

• 自己用 Grep / Glob 精确定位（grep -rn "关键词"）
• 手动 @mention 指定 3-5 个关键文件
• 用 Subagent 做初筛：让子 Agent 扫描代码库，只返回"我认为最相关的文件路径"清单，再由主 Agent 有选择地加载

大型项目中这个差异能带来 2-5 倍的效率和质量提升。

Q9: RAG 场景下 Context Engineering 有哪些特殊考量？

答案：

RAG 是 Context Engineering 最复杂的场景。3 个关键设计：

1. Chunking（分块）

• 固定长度最简单但不够好
• 推荐语义分块：按段落/代码块/函数切
• 高级做法：层级分块（章节→段落→句子），召回时按粒度组合

2. Reranking（重排）

• 向量检索召回 top-20 准确度只有 ~70%
• 加一层 Cross-Encoder Reranker 精选 top-3，准确度提升到 ~90%
• Cohere Rerank、Voyage Rerank 是主流方案

3. 混合检索

• 单纯向量对"精确关键词"效果差
• 组合：向量 + BM25 全文检索 + Metadata 过滤

4. 注入格式

<retrieved_docs>
<doc source="..." id="1">...</doc>
<doc source="..." id="2">...</doc>
</retrieved_docs>

请基于以上文档回答。如果没有相关信息，请明确告知。

• XML 标签让模型清晰识别检索内容
• 标注 source 便于溯源
• 明确"没有就说没有"防止幻觉

详见 RAG 检索增强生成。

Q10: 一个 Agent 应用上下文设计应该达到什么成熟度？

答案：

6 级成熟度模型：

Level	特征
L1 裸 Prompt	每次手写 prompt 靠运气
L2 项目 Rules	有 CLAUDE.md / .cursor/rules
L3 结构化上下文	XML/Markdown 标签分层
L4 按需加载	Skills + Subagents
L5 全生命周期管理	Compaction + Memory + Dynamic Context
L6 团队级基建	共享一套打磨好的上下文体系

大多数团队在 L2-L3 之间。目标是 L5 及以上：

• L3 → L4（最大价值跃迁）：能力封装成 Skills，大模型成本降低 50%+
• L4 → L5：支持小时级 Agent 长任务不中断
• L5 → L6：团队共享，新人入职当天就有完整 AI 能力加持

详细建设方法参考 AI 研发基建。

相关链接

• Anthropic: Context Engineering Guide
• Anthropic: Prompt Caching
• Lost in the Middle (Stanford, 2023)
• Prompt Engineering - Prompt 技巧详解
• Harness Engineering - AI 运行时壳层设计
• AI 辅助开发 - Skills / Subagents / Slash Commands / Hooks
• AI 研发基建 - 企业级 AI 平台建设
• RAG 检索增强生成 - RAG 完整指南
• 向量搜索与 Embedding
• AI 应用性能优化 - Prompt Caching 深入