微信扫码
添加专属顾问
我要投稿
探索AI智能体高效运作的关键:上下文工程如何优化LLM性能并降低成本。 核心内容: 1. 上下文工程的定义与核心组件解析 2. 从提示工程到智能体工具的三大发展阶段 3. 当前面临的主要挑战与优化解决方案
著名AI专家 Andrej Karpathy 曾将大型语言模型(LLM)比作一种新型操作系统,其中LLM是CPU,而其上下文窗口(Context Window)则是RAM。正如操作系统需要精心管理内存(RAM)一样,我们在构建智能体时也必须高效地管理模型的“工作记忆”——上下文窗口。当智能体执行长时程、多步骤任务时,不断累积的指令、工具调用反馈和知识会迅速填满上下文窗口,导致成本飙升、延迟增加,甚至引发上下文中毒(Context Poisoning)、上下文分心(Context Distraction)等性能退化问题。“上下文工程”(Context Engineering)正是解决这一挑战的艺术与科学,它专注于在智能体运行的每一步,都为其上下文窗口精确填充“恰到好处”的信息。
DeepMind的工程师Philipp Schmid对上下文工程的理解如下:
如图所示,他将系统提示词(System Prompt)、指令(Instruction)、长期记忆(LongTerm Memory)、可用工具(Tools)、用户提示词(User Prompt)以及召回信息(Retrieved Infomation)、历史对话等短时记忆(History)甚至是结构化的输出(Structured Output)统称为上下文。
Chroma的首席执行官Hammad Bashir在他的一次演讲中,将上下文的定义总结为下图:
虽然和Philipp Schmid的图不完全一样,但是都大体的含义是一样的,即:上下文不止包括用户输入的单、多轮对话prompt与回答,也包括能够调用的工具、能够合作的智能体等“工具”,同时还包括“长期/短期记忆”、“环境状态”等抽象的概念。
AI智能体的核心工作模式是在LLM调用和工具调用之间进行循环,利用工具的反馈来决定下一步行动。这个过程必定会产生大量的上下文信息。
随着任务的进行,来自工具调用的上下文会不断累积,这种会直接导致多种严重问题:
针对目前的上下文问题,业界涌现出四大策略:写入(Write)、选择(Select)、压缩(Compress) 和 隔离(Isolate)。
“写入”是指将信息保存到上下文窗口之外的存储中,以便将来使用。
便笺是一种在单次任务会话中供智能体使用的“临时记事本”。它允许智能体在执行任务时记录中间思考、计划或重要发现,而无需将这些信息始终保留在上下文窗口中。
与便笺的“会话内”特性不同,记忆旨在实现跨会话的长期信息持久化。这使得智能体能够从过去的交互中学习和成长。如今,像 ChatGPT、Cursor 等主流产品都已经内置了基于用户交互自动生成和管理长期记忆的机制。
“选择”是指在需要时,从外部存储中精准地拉取相关信息并注入到当前上下文窗口中。
选择机制与写入机制相对应。如果便笺是工具,智能体可以通过调用读取工具来获取信息。如果记忆存储在数据库中,就需要一套高效的检索机制。记忆可以分为不同类型,以服务于不同目的:
选择的要点在于确保相关性。简单的实现是始终加载固定的规则文件,如Claude Code使用的CLAUDE.md。而更复杂的系统(如ChatGPT)则使用 嵌入(Embeddings)或知识图谱(Knowledge Graphs) 来索引海量记忆,并进行语义检索。
当智能体拥有大量工具时,它可能会因为工具描述重叠而感到困惑。对工具描述应用RAG(检索增强生成)是一种有效的解决方案,它能根据当前任务动态选择最相关的工具,有研究表明这能将工具选择的准确率提高3倍。对于知识的检索,RAG同样至关重要。
“压缩”是指在保留任务所需核心信息的前提下,尽可能减少上下文中的Token数量。
这种方法通常使用一个LLM来提炼和浓缩信息。例如,当Claude Code的上下文窗口使用率超过95%时,它会自动触发“auto-compact”功能,对整个用户-智能体交互轨迹进行总结。总结可以应用于不同层面:对整个对话历史进行递归或分层总结,或在特定节点对高Token消耗的工具输出(如网页搜索结果)进行后处理。
与使用LLM进行智能总结不同,裁剪通常依赖硬编码的启发式规则来过滤或“修剪”上下文。最常见的方法是简单地移除消息列表中最旧的消息。更高级的方法,如Provence,是训练一个专门用于问答场景的上下文修剪器。
“隔离”是指将上下文分解到不同的单元中,以降低单个上下文窗口的复杂性并实现关注点分离。
将一个复杂任务分解给多个专职子智能体是隔离上下文最流行的方式。每个子智能体都有自己独立的上下文窗口、指令集和工具集,可以并行处理不同子任务。Anthropic的多智能体研究系统证明,这种架构的性能远超单个大型智能体,因为每个子智能体的上下文窗口都可以更专注于一个狭窄的子任务。当然,其挑战在于更高的Token总消耗量和复杂的任务规划与协调。
另一种隔离方法是使用沙箱环境。例如,HuggingFace的CodeAgent并不直接调用工具API,而是生成可执行代码。这些代码在一个隔离的沙箱中运行,只有必要的返回值才会被传回给LLM。这种方式非常适合处理和隔离高Token消耗的对象(如图片、音频文件),只需在沙箱中将其赋值给一个变量,即可在后续步骤中复用,而无需将庞大的数据本身放入LLM的上下文中。
一个精心设计的运行时状态对象(State Object)本身就是一种强大的隔离机制。通过定义一个包含多个字段的模式(Schema),我们可以将提供给LLM的消息(如messages字段)与其他仅供程序逻辑使用的信息(如工具调用的原始JSON输出)分离开来。这样,LLM只看到它需要看到的信息,而其他上下文则被安全地隔离在状态对象的其他字段中。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2025-08-21
2025-08-19
2025-08-21
2025-10-02
2025-09-16
2025-09-19
2025-09-08
2025-09-17
2025-08-19
2025-09-29
2025-11-17
2025-11-15
2025-11-14
2025-11-12
2025-11-10
2025-11-09
2025-11-09
2025-11-08