Context Engineering
AI Agent 的能力不只取决于模型多强，而取决于每一轮调用模型时你到底给了它什么上下文。Context Engineering 是系统化设计"模型完成本轮任务所需全部信息包"的工程学科。
[!info] related notes
- 所属 MOC: AI MOC, Context Engineering MOC
- 工程实践: Context Builder 模式, Context Contract 协议
- 应用场景: 问诊状态 Schema, 结构化信息采集
- 反模式: 上下文反模式
- 相关概念: Coding Agent Memory Landscape, Augmented LLM
Context Engineering
Context Engineering 是系统化设计”模型完成本轮任务所需的全部有效信息包”的工程学科。它不是简单传历史消息，而是把角色规则、安全边界、任务目标、会话状态、结构化数据、检索结果、工具输出等组装成一个经过筛选和压缩的上下文包。
一句话定义
上下文不是聊天记录，而是”模型完成本轮任务所需要的全部有效信息包”。
为什么需要
很多人一开始会以为：
context = system prompt + all messages但真实工程里应该是：
context =
角色规则
+ 安全边界
+ 当前任务目标
+ 当前会话状态
+ 结构化症状信息
+ 最近几轮原始对话
+ 早期对话摘要
+ 用户画像/限制条件
+ 检索到的知识
+ 工具调用结果
+ 当前 UI 状态
+ 当前用户输入AI Agent 的能力，不只取决于模型多强，而取决于每一轮调用模型时，你到底给了它什么上下文。
核心思想
| 维度 | 传统做法 | Context Engineering |
|---|---|---|
| 上下文来源 | 只有 messages | 多源：状态、知识、工具结果、UI 等 |
| 历史处理 | 全量传入或只传当前消息 | 筛选、压缩、摘要、分层 |
| 状态管理 | 让模型从聊天记录里推理 | 结构化状态对象独立维护 |
| 信息采集 | 用户自由输入 | 结构化采集 + 自由输入混合 |
| 跨服务协议 | 随意拼接 | Context Contract 显式定义 |
上下文的组成部分
对一个 AI Agent 产品（如健康问诊），上下文至少包含以下几类：
1. 对话上下文（Conversation Context）
用户和 AI 之前说了什么。这是最基础的 short-term memory。
[
{"role": "user", "content": "我膝盖有下坠感"},
{"role": "assistant", "content": "持续多久？是否伴随疼痛？"},
{"role": "user", "content": "大概一周，走路明显"}
]2. 结构化状态（Structured State）
比原始聊天记录更重要。模型不应该每轮都从聊天记录里重新推理这些字段。
{
"body_part": "膝盖",
"symptom": "下坠感",
"duration": "约一周",
"trigger": "走路时明显",
"pain": "未明确",
"swelling": "未明确",
"missing_slots": ["疼痛程度", "是否肿胀", "是否外伤"]
}详见 问诊状态 Schema。
3. Agent 流程状态（Agent Flow State）
任务不是自由聊天，而是有阶段的。
{
"stage": "symptom_collection",
"next_action": "ask_missing_slots",
"last_question": "是否伴随疼痛或肿胀？",
"pending_user_answer_for": ["pain", "swelling"]
}4. 知识库上下文（Retrieved Knowledge）
按当前问题动态注入，而不是每轮都塞大量固定知识。
{
"retrieved_knowledge": [
{
"title": "膝关节不稳定常见原因",
"content": "可能与股四头肌控制、髋膝踝力线、韧带损伤相关..."
}
]
}5. 用户画像（User Profile）
跨会话的长期信息。
{
"age": 35,
"gender": "male",
"exercise_habit": "每周跑步3次",
"known_limitations": ["腰椎间盘突出"]
}6. UI / 前端状态
比如人体 SVG 当前高亮部位、右侧结构化看板、用户点击了哪个快捷选项。
上下文组装流程
用户发送消息
↓
服务端创建 turn_id / message_id
↓
保存当前用户消息，状态 pending
↓
ContextBuilder 加载上下文
↓
过滤、压缩、排序、结构化
↓
调用 AI Service（传递 Context Contract）
↓
LangGraph / Agent 执行任务
↓
SSE 返回 text / extracted_info / ask_options / state_patch
↓
更新 message、extracted_info、UI state业界实践
LangGraph
官方把 memory 分成 short-term memory 和 long-term memory。短期记忆用于同一个 thread 内的多轮对话，长期记忆用于跨会话保存用户级或应用级信息。生产环境推荐数据库型 checkpointer（如 Postgres）。长对话超过上下文窗口时，常见方案包括 trim messages、delete messages、summarize messages。
OpenAI Agents SDK
Sessions 机制：每次 run 前自动取出 session history，和当前输入合并；run 后再把新消息、工具调用、结果写回 session。
Claude
官方在 context editing 文档里明确提到，上下文是有限资源，且有边际收益递减；无关内容会削弱模型关注重点。支持清理旧工具 results、thinking block 或进行压缩。
MCP Elicitation
服务端可以向客户端请求额外用户信息，支持表单模式和 URL 模式，客户端负责展示交互界面。这个思想可以应用到结构化信息采集中。
详见 结构化信息采集。
推荐的上下文结构
LLM Context =
system_prompt
+ task_rules
+ structured_state
+ conversation_summary
+ recent_messages（最近 6~10 轮原始消息）
+ retrieved_knowledge（动态注入 top 3~5）
+ current_user_input这比”全量消息历史”稳定得多。
与 Memory 的关系
| 概念 | 作用 | 生命周期 |
|---|---|---|
| Context | 本轮 LLM 调用的信息包 | 单轮，每次重新组装 |
| Short-term Memory | 同一会话内的多轮对话 | 会话级 |
| Long-term Memory | 跨会话的用户画像、知识 | 永久 |
| Structured State | 当前任务的结构化快照 | 会话级，每轮更新 |
Context Engineering 关注的是：如何从 Memory、State、Knowledge 等来源中，为每一轮 LLM 调用组装出最优的信息包。