[AI/Agent] Context Engineering/上下文工程

0 序

image

  • 前置知识:

1 概述：上下文工程

1.1 定义

  • Context Engingnnering/上下文工程，就是在 AI Agent 每一次决策/行动之前，动态构造一份“足以让模型做出正确决策”的最小信息环境。
  • Context Engineering = 为 AI Agent 的每一次推理，动态构造“正确的信息环境”。
  • 其解决的核心问题：在【模型】有限的【认知带宽】下，让 AI Agent 在正确的时间获得正确的信息，并避免错误、过时、冲突和冗余的信息干扰决策。
  • 这比“【管理 Prompt】”要本质得多。业界目前也基本从 Prompt Engineering 转向了对整个模型输入状态的工程化管理：系统指令(System Prompt)、任务(Task)、历史(History)、记忆(Memory)、知识(Knowledge)、工具(Tool)、工具结果(Tool Result)、运行状态(Running Status)等，都属于上下文的一部分。
  • 示意图

Tool Engineering（工具工程） 解决“Agent 能做什么”；
Memory（记忆组件） 解决“Agent 记得什么”；
Knowledge（知识库） 解决“Agent 能知道什么”；
Skill（技能） 解决“Agent 会怎么做”；
Context Engineering（上下文工程） 解决“Agent 此刻应该把什么带进脑子里”。

                         ┌──────────────┐
                         │   User Goal  │
                         └──────┬───────┘
                                ↓
┌────────┐   ┌────────┐   ┌────────────┐
│ Memory │   │Knowledge│   │    Skill   │
└────┬───┘   └────┬───┘   └─────┬──────┘
     │            │              │
     └────────────┼──────────────┘
                  ↓
           Context Engineering
                  ↑
     ┌────────────┼─────────────┐
     │            │             │
   History      Tools        Runtime State
     │            │             │
     └────────────┼─────────────┘
                  ↓
        ┌──────────────────┐
        │  Optimal Context │
        └────────┬─────────┘
                 ↓
              LLM/Agent
                 ↓
           Decision / Action

Memory、Knowledge、Skill、Tool 并不是 Context 本身的同义词，而是 Context 的不同“信息来源/能力来源”。
而 Context Engineering 是负责把这些东西在正确的时间，以正确的形式，组装成模型当前真正需要看到的 Context。

1.2 真正解决的问题/诞生原因

解决 AI Agent 的【认知输入问题】 —— 模型此刻不知道什么？

  • 它真正解决的，其一，解决 AI Agent 的认知输入问题——不是“模型不知道”，而是“模型此刻不知道什么”

LLM 本身并没有持续存在的“工作环境”。每次推理，本质上都是：当前 Context → Model → Decision / Action
所以， Agent 的智能上限，很大程度取决于：在这一刻，究竟给模型看了什么。

模型可能“有能力”解决问题，但如果当前 Context 中：
  没有用户真正的目标
  没有必要的历史
  没有相关 Memory
  没有正确的业务知识
  没有当前任务状态
  没有合适的 Tool
  有大量无关信息
  有互相冲突的信息
  历史信息过长导致关键信息被淹没

那么模型依然会做错。
因此，【上下文工程】本质上是在解决 Agent 的“【认知输入问题】”。

解决“【有限认知带宽】下的【信息选择】问题 => 在有限的【信息供给/信息预算】下，提供此刻【最有价值】的信息

  • 再往下抽象：其二，它解决的是“有限认知带宽下的信息选择问题”

Context Window(上下文窗口) 并不是越大越好。
AI Agent 执行过程中，会不断产生：`用户输入 → 历史 → Tool Call → Tool Result → 中间状态 → 新信息 → 新 Tool Result → ……``
如果全部塞给模型，Context 会越来越臃肿，而且信息越多并不一定越聪明，甚至会出现所谓的 context rot：上下文增长后，模型对其中关键信息的利用能力下降。

Anthropic 将问题概括为：Context 是有限资源，需要寻找最小的高信号信息集合。

所以，上下文工程真正做的是：从“所有可能相关的信息”中，选择“此时此刻最有价值的信息”。

  • 可以抽象成：
Context Universe
↓
Select / Retrieve
↓
Compress / Transform
↓
Order / Structure
↓
Inject
↓
LLM Decision

因此，它本质上是一个【信息供给】与【信息预算】问题。

1.3 辨析：Context Engineering ≠ Prompt Engineering

Prompt Engineering Context Engineering
核心问题 怎么告诉模型 模型此刻应该知道什么
关注对象 Prompt 整个 Context
时间尺度 一次调用 Agent 全生命周期/每一步
核心动作 写指令 获取、选择、组织、压缩、更新
典型内容 System Prompt、Instruction Prompt + Memory + Knowledge + Tool + State + History + Runtime Data
本质 语言设计 信息环境设计

Anthropic 对这一变化的描述非常直接：随着 AI Agent 从【单轮任务】变成【多轮】、【长时运行的循环系统】，【工程重点】从“写好 Prompt”转向管理整个不断变化的 Context State。—— Viewpoint's Link - Anthropic

1.4 最佳实践

  • 推荐文献

1.5 开源项目

  1. LangGraph：工业Agent首选；Checkpoint会话状态、消息中间件、Store存储，可自定义每一步送入LLM的消息，高度可控；compaction、消息过滤需要自己编排逻辑。
  2. OpenAI Agents SDK：内置compaction会话压缩、上下文‑存储分离，OpenAI模型栈快速落地首选。
  3. Letta(MemGPT)：Memory Blocks内存块机制，原生做上下文卸载，把部分状态放到窗口之外，适合长驻Agent。
  4. LLMACE：斯坦福，动态演进上下文，自动修剪、沉淀策略，实验性项目。
  5. Mem0：独立记忆层，产出记忆片段，记忆不等于上下文工程，召回结果仍需要上下文工程做组装。
  • 选型建议
  • 生产业务Agent：优先 LangGraph + LangMem，复用模板、checkpoint、token计数，业务侧实现自己的消息过滤、优先级、压缩策略。
  • 快速PoC：OpenAI Agents SDK / Dify低代码。
  • 长会话、跨会话Agent：评估 Letta / Mem0，记忆输出之后必须接入上下文工程流水线。

Y 推荐文献

X 参考文献

posted @ 2026-08-29 00:20  数据知音  阅读(2)  评论(0)    收藏  举报