上下文工程：LLM Agent 的长程智能基石

上下文工程：LLM Agent 的长程智能基石

前言

2022年ChatGPT的横空出世，点燃了LLM时代的第一把火，也让全世界看到了通用大模型的惊人潜力。然而，随着应用的深入，人们很快发现：再强大的模型，也受限于上下文窗口的长度、知识的实时性以及长期记忆的缺失。模型能写诗、能推理，却无法真正“记住”一周前的对话，更难以在复杂、持久的任务中保持一致。

2026年初，Clawbot（Openclaw）的爆火给出了答案：通用LLM的能力已经足够，真正的瓶颈在于如何将海量外部知识、历史状态和工具能力，通过有限的上下文窗口高效、精准地传递给模型。这正是“上下文工程”（Context Engineering）诞生的背景——它不再是简单的提示词设计，而是系统性地管理指导、信息与动作三类上下文，让Agent具备7×24小时稳定运行的能力。

本文将从上下文的定义出发，剖析其必要性，并深入拆解上下文工程的四大原子操作：Write（写入）、Select（选取）、Compress（压缩）、Isolate（隔离）。通过2025-2026年主流产品的实践案例，我们将看到：真正的智能突破，不在于模型参数的堆砌，而在于对上下文这一稀缺资源的精妙管理。

上下文定义

在讨论上下文工程前，我们需要了解到底什么是上下文。

在聊天机器人场景中，上下文可以理解为系统提示词+用户历史聊天记录。系统提示词（System Prompt）的目的是告诉 AI 它应该扮演什么角色、遵循什么规则、用什么方式回答问题，以下是一个科普类聊天机器人的系统提示词例子：

# 角色定位
你是一位专业的科普讲解员，擅长把复杂的技术概念用生活化的比喻讲清楚。

# 回答规则
1. 每段不超过 3 句话，避免大段文字
2. 必须用一个日常生活中的比喻来解释技术概念
3. 语气友好、耐心，像朋友聊天一样，避免学术腔

# 输出格式
【比喻解释】
（用生活场景类比）

【具体说明】
（简单展开说明）

💡 一句话总结：（用大白话概括核心要点）

实际上，在复杂场景下的Agent中，上下文通常涵盖了更广的范围，为了完成特定任务所需的信息都是上下文。比如客服机器人不仅需要知道用户的信息，还需要知道产品信息，这通常是通过RAG（外部知识库）提供的。私人AI助理需要帮助用户执行诸如日程管理、文件管理等任务，这些Agent所能执行的动作也属于上下文。

综上，可以将上下文分为三个子类：

• 指导性上下文：定义AI是谁，应该扮演什么角色，遵循什么规则，完成何种任务，任务完成后的反馈应该是什么格式(Text, or Json?)，早期的Chatbot可以认为只有这种上下文。
• 信息类上下文：为AI提供更多的知识，通常是RAG, Memory（包含短期记忆，和长期记忆）等。
• 动作类上下文：告诉AI拥有什么工具，可以做什么事情以及动作完成之后的结果（比如访问网页，返回网页内容），为模型提供与外界交互的能力。

其中，动作类上下文是区分聊天机器人与Agent的关键。有了动作，就跟灵魂拥有了躯体一样，可以真正影响现实世界。

为什么需要上下文工程

在使用AI的过程中，我们不难发现，当对话进行到一定阶段后，AI会逐渐忘记之前的对话内容，而只记得当前对话的内容。这是由于LLM的Token长度限制导致的，模型只能记住有限时间的知识。而上下文工程的核心思想就是通过各种手段，将知识存储在外部空间并进行动态管理，适时地、有机地组合在一起提供给模型。

这跟冯诺依曼架构的计算机系统非常相似，LLM类似于计算机的CPU，而上下文窗口则是内存（RAM），完整的知识库可以是硬盘，也可以是外部数据库，甚至是整个互联网。CPU处理任务，需要先通过一定手段将数据加载到内存中，才有后续的计算和输出。内存容量有限，所以需要有选择性的加载，对应模型中的Token数量也是有限的，超过限制的Token会被截断，导致模型无法记住超出范围的数据。

上下文工程类似内存管理技术：CPU需要加载数据，计算完成后需要将数据存储/更新回内存，内存中过期的数据还需要进行清理。

上下文管理的重要性不仅体现在Token长度限制上，过长的上下文还会损害LLM输出内容的正确性。即过期的或者不符合当前场景的上下文会给模型带来干扰，导致模型输出错误的结果。

比如，两天前的天气预报是晴天，今天却下起了雨。如果模型在回答天气问题时，还保留着两天前的上下文，且没有对信息可信度进行排序，那么它就会给出错误的答案。这就是典型的上下文矛盾。

除了上下文矛盾之外，还有三种常见的上下文失效问题：

1. 上下文污染：幻觉或者错误信息污染了上下文，导致模型输出了错误的答案。
2. 上下文干扰：上下文长度太长，导致部分信息被“挤”出了上下文窗口。
3. 上下文混淆：上下文充满了各种冗余无关的信息，对于当前任务来说，这些信息毫无意义，导致模型偏离任务轨道，最后答非所问。

HOW

上下文工程各种奇技淫巧、工程实现十分复杂，但实际上可以抽象出四种核心的原子操作：

• Write写入；
• Select选取；
• Compress压缩；
• Isolate隔离。

写入

上下文窗口是稀缺资源，Agent 执行复杂任务时必须把大量中间状态、历史决策、背景知识“外置”，这就是上下文工程的核心操作：写入。

写入本质：把记忆从昂贵的窗口内存 → 转移到廉价的窗口外存储，需要时按需读回。

写入的两大分类

1. 会话内临时写入 → Scratchpad（草稿纸）

   • 目的：应对上下文截断 + 上下文腐烂（注意力稀释）
   • 典型实现：NOTES.md、todo.md、ROADMAP.md、plan file
   • 经典案例：Claude 玩 Pokémon（记录进度、地图、成就）
   • 价值：记忆从“模型注意力”转为“确定性文件读取”，长程任务不丢失状态
   • 常见场景：编程（ROADMAP.md）、研究（先写计划再开工）

2. 跨会话持久写入 → Persistent Memory（长期记忆）
   2025 年主流两种哲学对决：

   方式	代表产品	存储形式	优点	主要缺点	趋势回应场景
   文件化	Claude Code, Cursor	Markdown 文件 + import / 目录结构	可审计、可版本控制、可共享、透明	需要手动管理	企业合规、可解释性要求
   语义化（向量）	ChatGPT 等	向量数据库	无感、自动抽取/检索/遗忘	黑箱、难 debug、难审计	消费级产品

   趋势：高风险领域（代码、金融、医疗、法律）越来越倾向文件化 + 可审计，向量存储的黑箱风险在监管压力下难以为继。

写入的深层问题与现代解决方案

1. 写什么？ → 记忆抽取

   • 避免全量保存对话
   • 优先提取工作模式（偏好、习惯、风格）而非孤立事实
   • 例子：记住“喜欢先看架构再看细节”“偏好 Zustand 而非 Redux”，而非“今天用了 React”

2. 三级内存架构（热-温-冷）

   • 工作内存（上下文窗口）：当前任务、热数据
   • 短期记忆（Rules / 每次加载）：行为规范、会话级约束
   • 长期记忆（Memory / RAG）：项目知识、冷数据

3. 层级化加载（渐进式披露）

   • 不一次性灌入所有记忆
   • 用 import、glob、条件加载、按需 RAG 实现模块化、任务相关加载

4. 最大陷阱：记忆膨胀

   • 80% 记忆 30 天内再未被访问
   • 过多无关/过时记忆 → 上下文干扰、注意力分散、性能下降
   • 极端案例：Claude Code 曾单进程吃 120GB+ RAM

写入最佳实践

• 保持精简：只存每次会话都需要的核心信息，其余按需引用
• 区分时效性：用语义 TTL（而非固定时间）判断是否过期
• 处理冲突：保留历史 + 标记“已过期”，便于审计与回溯
• 格式稳定：统一模板、避免易变字段在前，保护 KV-cache 命中率
• 核心艺术：选择记住什么、存哪里、何时加载、何时遗忘

终极目标：在有限的注意力预算内，让 Agent 只看到当前任务最相关的高信号信息。

选取（Selection）

选取是上下文工程的核心智能，解决“什么信息进入有限上下文窗口”的问题。本质是减法：找到最小的高信号token集合，避免无关信息分散模型注意力。

选取的三种类型

• 确定性选取：预设规则固定加载特定上下文，无需计算。
• 检索式选取：通过相似度从知识库检索（RAG核心）。
• 模型驱动选取：模型自行决定获取何种信息。

两种哲学：预计算 vs 运行时探索

1. 预计算索引（开发者定义相关性）

   • 典型：Cursor语义搜索
     • 智能切分（基于AST/tree-sitter，按类/函数边界）。
     • 向量化存储（Turbopuffer）。
     • 语义+关键词混合检索（BM25+embedding），部分系统再结合知识图谱、AST解析，准确率提升可达3倍。
   • 优势：快速、精确。
   • 数据：准确率↑12.5%、代码留存率↑2.6%、不满意请求↓2.2%。
   • 扩展：索引历史PR、GitHub评论。

2. 运行时探索（模型决定相关性）

   • 典型：Claude Code Just-in-Time
     • Explore子代理（Haiku驱动，轻量、只读工具：Glob、Grep、Read）。
     • 上下文隔离：探索过程可消耗大量token，最终仅返回1000-2000 token精华摘要。
     • 强调目录结构、命名约定等元数据本身即上下文。
   • 优势：灵活、无需预索引。

实际最佳实践：混合模式（如Cursor的语义索引+@file显式控制，Claude Code的固定CLAUDE.md+运行时工具）。

演进：从静态到动态（Cursor Dynamic Context Discovery，2026）

核心理念：模型越强，越应提供更少初始细节，让其自主拉取。 关键技术：

• 长工具输出→文件（支持tail/selective read，避免截断）。
• 聊天历史文件化（压缩时保存完整历史）。
• Agent Skills动态发现（非全加载）。
• MCP工具选择性加载（仅名称静态加载，描述按需检索，token用量↓46.9%）。
• 终端输出文件化（grep错误而非全历史）。 文件作为当前最佳接口：模型熟悉、支持懒加载/部分读取、干净抽象。

工具选取（被忽视的关键）

• 问题：工具过多反而降低性能（动作空间增大、描述重叠导致困惑）。
• 解决方案：Tool RAG（语义检索最相关工具，准确率↑3倍，prompt长度↓50%）。
• 实现注意：避免动态移除工具破坏KV cache，使用Tool Masking（logits屏蔽无关工具）。

记忆选取

• 三类：情景记忆（few-shot示例）、程序记忆（指令）、语义记忆（事实）。
• 挑战：自动检索可能产生意外组合，破坏用户控制感。
• 保守策略：固定文件加载（如CLAUDE.md），牺牲灵活性换可预测性。

渐进式披露（通用原则，模拟人类认知）

1. 元数据探索（路径、命名、时间）。
2. 相关性判断。
3. 选择性深入。
4. 迭代精炼。 Claude Code的Explore支持thoroughness level（quick/medium/thorough）控制深度。

选取陷阱与权衡

• 过度选取 → 信息茧房（错过潜在线索）。对策：少量随机注入多样性信息。
• 选取不足 → 盲人摸象（幻觉增加、质量下降）。
• 监控指标：召回率、上下文利用率、任务成功率。

上下文预算分配（示例，32K窗口）

• 系统提示：2K
• 当前查询：1K
• 工具返回：8K
• 历史：6K（压缩）
• RAG结果：12K
• 思维链预留：3K 高级系统支持自适应动态调整。

趋势（2025-2026）

选取权逐步从开发者移交至模型（Dynamic Context Discovery、Tool RAG、Explore子代理）。核心目标不变：在有限注意力预算内，提供不多不少、恰好足够的上下文。

压缩（Compression）

压缩是上下文工程的效率保障，解决“上下文膨胀太昂贵”的问题：成本飙升 + 性能衰减（长上下文导致幻觉/拒绝回答）。Chroma 2025研究证实：上下文窗口越大并非越好，边际收益递减；Anthropic原则：上下文是有限资源，需精心设计。

两种范式

1. 紧凑化（Compaction）——可逆压缩（首选）

   • 剥离可外部重建的信息，保留引用（如路径、URL、查询）。
   • 示例：工具结果替换为 {path, status}，后续可file_read恢复。
   • Anthropic：Tool Result Clearing（Beta功能），移除深埋旧工具结果。
   • Manus策略：先压缩最老50%工具调用，保留最近完整示例（避免模型模仿紧凑格式）。
   • 优势：零信息丢失，零额外LLM调用。

2. 摘要化（Summarization）——不可逆压缩（仅在紧凑化收益递减后使用）

   • 用LLM生成精炼摘要。
   • Manus最佳实践：
     • 输入完整原始版本生成摘要。
     • 保留最后几次工具调用完整（避免风格/语气漂移）。
     • 使用结构化Schema（用户目标、修改文件、当前状态、下一步）。
     • 预先dump完整上下文到文件（后续可检索）。
   • 优势：高压缩比；风险：信息丢失、累积偏差。

实践案例

• Claude Code Auto-Compact：

  • 原触发阈值≈95%，现更保守（实际64%时已预警）。
  • 社区最佳：50-70%主动/compact，85-95%紧急区。
  • 原因：接近极限时生成空间被挤压，性能急剧下降。

• Cognition AI（Devin重构）：

  • 发现“上下文焦虑”：Sonnet 4.5感知窗口限制时过早收尾。
  • 结论：不能完全依赖模型自管理记忆；需显式结构化压缩。

• Factory.ai 锚定摘要：

  • 解决重复再摘要问题：维护持久摘要，只增量更新新部分。
  • 测试胜过Anthropic/OpenAI：准确性更高，细节保留更好（尤其技术错误追踪）。
  • 弱点：所有方法在“文件追踪”上得分低 → 需专用状态机制。

核心技术

• LLMLingua系列（微软）：

  • 小模型识别冗余token，压缩比高达20倍，性能几乎无损。
  • LLMLingua-2：更快、更好泛化。
  • LongLLMLingua：查询感知，缓解“Lost in the Middle”。

• 其他：

  • 思维链压缩：保留关键节点而非完整轨迹（token↓60%+）。
  • 结构化数据压缩：JSON→紧凑格式，或写入文件仅留路径。
  • Cursor策略：大型结果文件化 + 引用。

代价与权衡

• 信息损失：>75%压缩时事实任务准确率急降；创意任务更容忍。
• 计算开销：摘要需额外LLM调用 → 优化：增量（Factory）、离线预压缩。
• 累积误差：多次摘要导致“上下文中毒” → 用结构化Schema防范。
• 触发时机：50-70%主动压缩，逻辑断点执行，避免中途打断。

压缩策略层次（推荐顺序）

1. Tool Result Clearing（可逆、极低开销）
2. 文件卸载（可逆、高节省）
3. 紧凑化（可逆、中开销）
4. 结构化摘要（不可逆、高节省）
5. 自由摘要（不可逆、高开销）
6. 硬截断（最后手段）

核心原则：先紧凑后摘要，优先可逆。“你无法预测哪条信息会在未来变得关键”。压缩不是丢弃，而是让每个token都“挣得”其位置。

隔离（Isolate）

隔离是上下文工程的架构基石，解决“上下文不够用”的困境：通过并行分片和边界划定，将单一窗口的物理/认知瓶颈转化为理论“无限”容量。与Write/Select/Compress（信息流内部优化）不同，隔离是系统架构层面的根本策略。2025年多Agent系统普及，使隔离从可选优化升为核心能力。

单一窗口的不可逾越限制

• 物理限制：窗口再大（如1M-10M token），信息量仍可能超限。
• 认知限制：Chroma“上下文腐烂”研究证明，长上下文性能系统性下降（第10万个token价值远低于第100个）。

隔离的核心机制与价值

多Agent系统中，子Agent作为“智能过滤器”：在独立窗口并行消化原始信息，仅传压缩洞见给主Agent，减轻主Agent负担。

• 量化证明（Anthropic多Agent研究）：
  • Claude Opus 4（主）+ Sonnet 4（子）在研究任务上提升90.2%。
  • 原因：token扩展（系统总token↑，BrowseComp中解释80%性能方差）+ 并行推理（每个窗口完整注意力）。
  • 案例：查找标普500 IT公司董事会成员，多Agent成功，单一Agent失败。
• 代价：token消耗≈聊天15倍，适合高价值、重并行、信息超单窗口、复杂工具交互任务。

Manus Wide Research：隔离工程极致

解决传统AI处理多项目时质量衰减问题（第8-10项后虚构阈值）。

• 架构：
  1. 主控制器分解任务（识别依赖、创建子规格）。
  2. 并行部署完整Manus实例（每个子Agent有独立VM、工具、互联网）。
  3. 子Agent独立处理（深度一致、无上下文累积）。
  4. 主控制器综合结果。
• 革命特性：
  • 线性扩展（500项目→500子Agent）。
  • 恒定时间（并行执行）。
  • 错误隔离（子Agent不共享上下文，无污染传播）。
• 关键决策：子Agent为通用完整实例，不对话（防幻觉/污染）。

Claude Code子代理实践

• Explore（Haiku驱动）：文件/代码搜索，只读工具（Glob/Grep/Read/Bash），支持thoroughness级别。
• Plan：规划/研究代码库，无修改权限。
• General-purpose：复杂研究/修改，完整工具。
• 优势：子代理隔离（互不干扰、主代理清洁），冗长输出留子窗口，仅传摘要（隔离即压缩）。

隔离反模式

避免“组织架构图”式人格化（经理/设计师/程序员Agent互聊）：LLM无人类认知局限，过度分工仅增协调成本。

• 更好模式：子Agent如工具，主Agent函数调用启动，返回结构化结果。
• 控制规则：任务复杂度决定子Agent数量/调用次数。

技术实现模式

1. Orchestrator-Worker（Anthropic）：
   • 主Agent协调/综合，子Agent专注细分，Citation Agent独立验证。
2. Handoff（OpenAI Swarm/Agents SDK）：
   • 无状态、显式传递上下文，轻量可控。
3. Thread隔离（LangGraph）：
   • thread_id独立会话，checkpointer管理记忆，字段级隔离（预算管理）。

隔离三个层次

• 会话隔离：不同用户独立窗口（基本，必备）。
• 任务隔离：同一用户不同任务命名空间分区（LangGraph thread+MongoDB持久化）。
• 数据隔离：加密沙箱（Azure Confidential LLM，高合规场景）。

隔离与共享平衡

• 完全隔离无法协作，过度共享失意义。
• Manus策略：
  • 简单任务：仅传指令+Schema，返回结构化结果。
  • 复杂任务：共享必要上下文，但子Agent独立行动。
• 原则：“共享上下文即昂贵依赖”；Schema强制结构化输出。

沙箱：隔离另一形态

• HuggingFace CodeAgent/LangGraph E2B：代码在沙箱执行，重型数据（如图像）不入主上下文。
• 价值：状态处理+上下文工程（不污染主窗口）。

生产挑战

• 非确定性调试（需追踪系统）。
• 部署协调（彩虹部署）。
• 资源管理（token/一致性/可见性问题）。

结论与适用边界

隔离扩展总处理能力：子Agent消化信息→主Agent仅收精华。

• 擅长：重并行、超单窗口信息、复杂工具任务（如研究）。
• 不擅长：需高度共享上下文/实时协调任务（如多数编码）。 趋势：从“AI助手”到“AI劳动力”，隔离是基石。
• 澄清：提示工程为子集（静态System Prompt在Select加载）。
• 本质：所有LLM应用技术均为Write/Select/Compress/Isolate的组合；Context Engineering统一更高抽象。