企业级 AI Agent 工程方法论:上下文工程与记忆体系实战(中)

上一篇我们聊了 AI Agent 的核心架构、工具工程化和 RAG 演进路径。这篇来讲两个在生产中极其关键但容易被忽视的环节:上下文工程记忆生成流水线。大部分 Agent 在生产中翻车,根因往往就出在这两块。


一、从静态提示词到上下文工程

很多人把写 Prompt 当成 Agent 的核心能力,但在真实的 Agent 系统中,光靠人工编写静态提示词是远远不够的。

Agent 在执行任务时,每一次跟大模型交互,本质上都是在组装一个上下文包------系统指令、工具定义、检索结果、历史对话、用户最新输入......这些信息需要被精心编排,才能让大模型给出正确的响应。

上下文工程的核心 ,就是对上下文窗口内全生命周期的数据进行组装、优化与管理


二、上下文负载的三大组件

整个上下文可以拆成三个层次,理解这三层是做好上下文工程的基础:

1. 引导性上下文(Guiding Context)

组成 特点
系统指令(System Prompt) 固定提示词,整个对话期间不变
工具定义(Tool Schemas) 声明 Agent 可调用的能力
少样本示例(Few-shot) 引导模型理解期望的输出格式

特点:相对静态,作为整个对话的"基调"。

2. 事实性证据(Factual Evidence)

组成 特点
长期记忆检索结果 经过沉淀的用户偏好与历史知识
RAG 文档片段 检索到的相关背景知识
工具执行返回结果 实时调用外部系统获得的数据

特点:动态但经过沉淀,是当前任务的知识基础。

和引导性上下文的区别在于:引导性上下文是给大模型定方向的,事实性证据是给大模型提供具体任务中的知识和数据。

3. 即时性信息(Immediate Context)

组成 特点
当前对话历史(压缩后) 最近对话的摘要
推导草稿 最新的推理与规划
用户最新输入 当前轮次的原始请求

特点:实时变化,代表用户最新的指令和 Agent 最新的推理状态。

一句话理解这三层:引导性上下文是"不变的规则",事实性证据是"沉淀的知识",即时性信息是"当前的指令"。


三、注意力管理与 NIAH 优化

大模型有个已知的特性:对首尾敏感,对中间容易丢失注意力(Lost in the Middle)。这意味着上下文工程不仅要管"放什么",还要管"放哪里"。

三个核心策略

1. 结构化隔离

明确界定组件边界,防止模型混淆指令与数据。

复制代码
System Prompt    →  系统指令区(角色、目标、约束)
Context          →  事实证据区(检索结果、工具返回)
User Prompt      →  用户输入区(当前请求)

不要把什么都往一个地方塞,模型需要清晰的边界来区分"规则"和"数据"。

2. 位置偏置优化

关键指令放在首部和尾部

  • 首部:角色定义、核心目标、行为约束
  • 尾部:最新提示、当前任务的关键补充
  • 中间:背景知识、工具返回等辅助信息
3. 性能与成本平衡

对于 32K 量级的静态背景数据(System Prompt、工具库定义),开启缓存可以显著降低首字延迟(TTFT)。因为引导性上下文是相对不变的,缓存起来可以避免每次请求都重复计算。


四、动态截断与滑动窗口

Agent 在多轮对话中,上下文会不断膨胀。如果不加控制,很快就会超出 token 预算。

滑动窗口 + 递归摘要

核心思路:

  1. 滑动窗口:仅保留最近 N 轮对话,确保低延迟和上下文相关性
  2. 递归摘要:滑动丢弃的对话不是直接扔掉,而是用大模型压缩成语义摘要

为什么不能只滑动不摘要?

如果只做滑动窗口,用户一开始说的意图就会随着对话推进而丢失。比如用户第 1 轮说"帮我订明天去北京的票",到第 10 轮你把前面的对话全丢了,Agent 就不知道自己在干什么了。

递归摘要的作用就是:把丢弃的对话中的关键信息压缩保留,让 Agent 始终知道"我们在做什么"。

这也是为什么你用 AI 编程工具(如 Claude Code、Cursor)时,经常能看到一个"会话历史已压缩"的提示------本质上就是在做对话压缩。


五、上下文的优先级堆栈

当多种上下文信息竞争有限的 token 空间时,需要明确的优先级:

复制代码
优先级 1(最高):系统指令 + 工具定义
优先级 2:        用户当前轮次的原始请求 + 关键约束
优先级 3:        动态知识(RAG 检索、工具返回数据)
优先级 4:        历史摘要(滑动窗口 + 递归压缩)

这个优先级意味着:当 token 预算不够时,先砍历史摘要,再砍动态知识,但系统指令和用户请求不能砍。


六、JIT 动态注入:需要时才加载

JIT(Just-In-Time)注入是上下文工程中的一个关键技术,核心思想是:避免全量填充,仅在推理时按需动态注入

四步流程

复制代码
Fetch   →  检索相关的记忆片段 / RAG 文档
Prepare →  清洗、格式化、去噪
Invoke  →  注入上下文,触发模型推理
Update  →  更新上下文状态,为下一轮准备

这样做有两个好处:

  1. 解决 Lost in the Middle:不一次性塞满所有信息,而是按需精准注入,减少噪声
  2. 成本控制:200 token 的结构化记忆,可以替代 20K token 的原始历史,大幅降低推理成本

七、会话管理:Agent 的工作台

会话的构成要素

每个会话由一系列事件构成,事件是会话的原子单位:

  • 用户输入
  • 模型响应
  • 工具调用及返回结果

会话状态(Working Memory)

会话不只是消息列表,它是有状态的。这个状态就像一个结构化草稿板

  • 当前任务进度
  • 待办列表
  • 中间计算结果
  • 规划执行状态

多 Agent 会话策略

策略 适用场景 实现方式
中央日志 紧密耦合任务,多个 Agent 需要共享相同上下文 所有 Agent 读写同一份记录
独立历史 松耦合协作,跨系统的 Agent 间交互 各自维护私有日志,通过 A2A 协议显式通信

我的经验:如果多个 Agent 在同一个系统内工作,用中央日志就好了,没必要搞 A2A 通信------它们需要的上下文基本一致,共享效率更高。A2A 更适合跨系统、跨组织的场景。


八、生产环境的会话管理要点

在生产环境中,会话管理还需要考虑几个关键点:

1. 安全隔离

  • ACL 访问控制:不同用户的会话严格隔离
  • 数据脱敏:敏感信息在存储前进行脱敏处理

2. 数据完整性

  • 事件确定性排序:保证事件的顺序一致性
  • TTL 自动清理:过期会话自动归档或删除

3. 分层存储

复制代码
近期会话  →  Redis(高速缓存,加快响应)
远期历史  →  对象存储(低成本归档)

九、记忆生成流水线(Memory ETL)

记忆不是简单的日志存储。它是一条由大模型驱动的异步 ETL 流水线,将原始交互数据静默净化为结构化知识。

三步流程

Step 1:提取(Extract)

从原始数据(对话事件、工具输出)中,利用大模型识别关键的陈述性事实:

  • 用户偏好("我喜欢靠窗座位")
  • 实体关系("用户要去参加百度大会")
  • 关键约束("我对花粉过敏")

大模型天然具备结构化信息提取的能力,利用这个能力可以过滤掉噪声、提取关键信息。

Step 2:整合(Transform)

每次提取后,要与历史知识进行冲突检测

  • 发现冲突 → 根据优先级决定覆盖还是保留
  • 无冲突 → 去重后合并

冲突优先级:引导类数据 > 用户显式输入 > 工具输出

这个优先级很重要。如果引导数据写错了,后果会很严重------因为它的优先级最高,会覆盖一切。所以引导数据一定要编写那种在任何场景下逻辑都不会出错的原则性内容

Step 3:加载(Load)

将结构化片段写入记忆库,供下次会话检索和注入。

记忆组织的三种形式

形式 特点 适用场景
结构化画像 类似联系人卡片的静态事实集合,便于快速查询 用户基本偏好
滚动摘要 关于项目进度的单一演进式摘要,动态更新 任务规划跟踪
知识图谱 存储实体节点与关系边,支持深度推理 复杂关系推理

遗忘与修剪机制

记忆不是越多越好,旧记忆需要衰减:

  • 时间衰减:旧记忆权重随时间降低
  • 低置信度修剪:自动清理矛盾或模糊信息
  • 有选择地遗忘:丢弃垃圾信息,为高质量记忆腾出空间

十、Memory ETL 驱动深度个性化:一个实例

来看一个具体的场景:用户说"帮我订明早去北京的票"。

后台静默流程

历史记忆提取(3 个月前的对话):

复制代码
用户原话:"我对花粉过敏,酒店房间别放花"
  ↓
提取结果:
  - 健康注意事项:花粉过敏(置信度 0.95)
  - 住宿偏好:无花粉环境

短期记忆(5 分钟前):

复制代码
用户要去参加百度大会

长期记忆检索

复制代码
用户偏好:二等座、靠窗

上下文融合 → Agent 行动

Agent 最终执行的操作:

  1. 预订明早去北京的高铁,二等座靠窗
  2. 酒店备注:需要无花粉环境

两个问题被解决了

  • 长期遗忘:通过结构化存储,"花粉过敏"这个信息即使过了 3 个月也没丢失
  • 成本优化:仅注入 200 token 的结构化记忆,替代了 20K token 的原始历史

十一、核心工程价值总结

整个上下文工程 + 记忆 ETL 其实就干了两件事:

1. 上下文缓存

把引导性上下文(系统指令、工具库)缓存起来,避免每次请求都重复计算,降低延迟和成本。

2. 动态截断与记忆压缩

把历史对话压缩为结构化记忆,按需注入,既保留关键信息,又控制 token 成本。

其他的技术手段------结构化隔离、位置偏置优化、优先级堆栈------本质上都是在降低模型幻觉、提升推理准确性

关键是做好三大组件

复制代码
引导性上下文  →  定好规则,保持稳定
事实性证据    →  按需检索,精准注入
即时性信息    →  保持新鲜,及时压缩

写在最后

上下文工程和记忆体系是 Agent 生产化的隐性基础设施。很多团队把精力花在模型选择和工具接入上,却忽视了上下文的管理------结果就是 Agent 在多轮对话中越聊越离谱,或者记忆丢失导致体验断裂。

解决 Agent 的"健忘症"和"注意力缺陷",靠的不是更强的模型,而是扎实的上下文工程

下一篇我们来聊 Agent 的安全红线、MCP/A2A 工程实践、AgentOps 运营体系,以及如何建立一套完整的质量评估与 CI/CD 流水线------这些是 Agent 从 demo 走向生产的最后一道门槛。


如果觉得有帮助,欢迎点赞收藏关注,我们下期继续深入企业级 AI Agent 工程实践!

相关推荐
chimooing5 小时前
OpenClaw 进阶:多 Agent 协作与任务编排实战
ai agent·开发者工具·自托管·openclaw
最初的↘那颗心7 小时前
企业级 AI Agent 工程方法论:安全防线、协作网格与质量飞轮(下)
ai agent·安全防御·agentops·mcp·a2a
最初的↘那颗心9 小时前
企业级 AI Agent 工程方法论:从原型到生产的完整指南(上)
大模型·rag·ai agent·mcp·企业级ai
人工智能研究所1 天前
字节开源 DeerFlow 2.0——登顶 GitHub Trending 1,让 AI 可做任何事情
人工智能·深度学习·开源·github·ai agent·字节跳动·deerflow2.0
QC·Rex2 天前
AI Agent 编排实战:从零构建多智能体协作系统
人工智能·ai agent·任务编排·多智能体系统·claude code·自主代理·llm 应用
新知图书2 天前
LangGraph中的输出范式
人工智能·ai agent·智能体·langgraph
arvin_xiaoting3 天前
OpenClaw学习总结_II_频道系统_5:Signal集成详解
java·前端·学习·signal·ai agent·openclaw·signal-cli
一晌小贪欢3 天前
【计算机科普知识】:什么是AI智能体(AI Agent)
人工智能·ai·chatgpt·ai agent·智能体·ai智能体
新知图书3 天前
LangGraph节点的并行化处理
人工智能·ai agent·智能体·langgraph