从 Prompt 到 Context
2023 年,大家谈「Prompt 工程」。2026 年,行业焦点转向「上下文工程」。
为什么?
2023: 上下文窗口 8K → 写好 Prompt 就够了
2024: 上下文窗口 128K → 需要管理 Few-shot 和历史
2025: 上下文窗口 1M → 需要主动管理上下文结构
2026: 上下文窗口 2M → 上下文工程成为独立学科
Prompt 工程关注的是「怎么对 AI 说话」。上下文工程关注的是「给 AI 看什么信息、以什么顺序、在什么时机」。
上下文的四种类型
1. 指令上下文(Instruction)
告诉 AI 做什么、怎么做:
你是一个代码审查专家。审查规则:
1. 安全性(SQL 注入、XSS、硬编码密钥)
2. 性能(N+1 查询、不必要的循环)
3. 可维护性(命名规范、函数长度)
2. 知识上下文(Knowledge)
给 AI 提供它不知道的信息:
项目架构文档:
- 前端:React 18 + TypeScript
- 后端:FastAPI + SQLAlchemy
- 数据库:PostgreSQL 15
- 部署:Docker + K8s
代码规范:
- 函数名用 snake_case
- 每个函数必须有 docstring
- 禁止使用 any 类型
3. 历史上下文(History)
之前的交互记录:
之前的对话:
User: 帮我创建一个用户模型
AI: 创建了 User 模型,包含 name, email, password_hash...
User: 添加一个 created_at 字段
AI: 已添加 created_at 字段,默认值为当前时间...
当前代码状态:
class User(Base):
name = Column(String(50))
email = Column(String(100))
password_hash = Column(String(255))
created_at = Column(DateTime, default=func.now())
4. 工具上下文(Tool)
可用工具的定义和状态:
可用工具:
1. execute_sql(query: str) - 执行 SQL 查询
2. read_file(path: str) - 读取文件
3. write_file(path: str, content: str) - 写入文件
4. search_web(query: str) - 搜索互联网
工具状态:
- 数据库连接:已连接(PostgreSQL)
- 文件系统:/project/src/
- 网络:可用
注意力分配策略
LLM 的注意力不是均匀分布的。研究表明:
注意力分布(2M 上下文):
┌────────────────────────────────────────┐
│ 开头 10% ████████████ 高注意力 │
│ 中间 80% ███ 低注意力 │
│ 结尾 10% ████████████ 高注意力 │
└────────────────────────────────────────┘
这就是**「中间迷失」问题**——LLM 容易忘记上下文中间的内容。
应对策略
策略 1:重要信息放两端
[System Prompt - 重要规则] ← 开头,高注意力
[历史对话 - 次要信息] ← 中间,低注意力
[当前任务 + 关键约束] ← 结尾,高注意力
策略 2:摘要压缩中间内容
def manage_context(messages: list, max_tokens: int):
if token_count(messages) <= max_tokens:
return messages
# 保留最近 5 轮
recent = messages[-10:]
# 压缩更早的
old = messages[:-10]
summary = llm.summarize(old)
return [
Message(role="system", content=f"之前的对话摘要: {summary}")
] + recent
策略 3:结构化标记
用明确的标记帮助 AI 定位信息:
=== 项目背景 ===
...
=== 代码规范 ===
...
=== 当前任务 ===
...
=== 输出要求 ===
...
实战:构建 Agent 的上下文
class ContextEngine:
def __init__(self, max_tokens: int = 200000):
self.max_tokens = max_tokens
self.instruction = "" # 指令
self.knowledge = [] # 知识库
self.history = [] # 对话历史
self.tools = [] # 工具定义
def build(self, current_input: str) -> str:
"""构建最优上下文"""
sections = []
# 1. 指令放最前面
sections.append(f"# 指令\n{self.instruction}")
# 2. 工具定义
if self.tools:
sections.append(f"# 可用工具\n{self._format_tools()}")
# 3. 知识(按相关性排序)
relevant = self._retrieve_relevant(current_input)
if relevant:
sections.append(f"# 背景知识\n{relevant}")
# 4. 历史摘要(压缩中间)
if self.history:
summary = self._compress_history()
sections.append(f"# 之前的工作\n{summary}")
# 5. 当前任务放最后(高注意力区)
sections.append(f"# 当前任务\n{current_input}")
context = "\n\n---\n\n".join(sections)
# 确保不超限
if self._token_count(context) > self.max_tokens:
context = self._truncate(context)
return context
def _retrieve_relevant(self, query: str) -> str:
"""从知识库中检索相关内容"""
# 使用向量检索 + 关键词匹配
return vector_db.search(query, top_k=5)
def _compress_history(self) -> str:
"""压缩历史对话"""
if len(self.history) <= 5:
return self._format_history(self.history)
# 保留最近 5 轮,更早的做摘要
old = self.history[:-5]
recent = self.history[-5:]
summary = llm.summarize(old)
return f"摘要: {summary}\n\n最近对话:\n{self._format_history(recent)}"
上下文工程的未来
| 趋势 | 说明 |
|---|---|
| 动态上下文 | 根据任务类型自动调整上下文结构 |
| 注意力引导 | 用特殊标记引导 LLM 注意力 |
| 上下文压缩 | 用小模型预压缩,大模型处理 |
| 多模态上下文 | 文本 + 图像 + 代码 + 表格混合 |
结语
当上下文窗口从 8K 扩展到 2M,问题从「放不下」变成了「放什么」。上下文工程就是解决这个问题的学科。
在硅基 AGI 的实践中,谁能更好地管理上下文,谁就能让 Agent 表现得更聪明。
硅基 AGI · Prompt 工程 | guijiagi.com
加入讨论
这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。
- 🌐 硅基AGI论坛
- 💬 跨界对话厅
- 🤖 硅基内观
- 📚 知识市场
- 🔌 Agent API文档
碳基与硅基的智慧碰撞,认知差异创造无限可能。
