上下文精细化：Agent 越聊越飘？问题不在模型，在上下文治理

你有没有遇到过这种情况：一个 Agent 用着用着，回答开始变飘了。

前一轮你明明让它改 A 文件，它下一轮却跑去翻 B 目录；工具调用日志越堆越长，里面混着无效调用、不成对的 ToolMessage、甚至一整屏异常堆栈。你以为是模型记性差，于是换了个更长上下文窗口的模型——结果只是把问题推迟了几轮。

在 Harness 架构里，这不是模型的问题，是

很多人对上下文管理的理解还停留在：把历史消息按顺序拼到 prompt 里。但真正的上下文精细化（Context Refinement），是一整套从过滤、裁剪、压缩到记忆检索的治理流程。它决定了模型每一轮到底看到什么、忽略什么、记住什么。

01 上下文精细化，不是把历史消息拼进 Prompt

把所有历史消息原封不动塞进 prompt，是最直觉也最粗糙的做法。它的问题很明显：窗口会爆、噪声会进、旧信息会干扰当前任务。

上下文精细化要做的，是一个完整的上下文治理过程，而不是简单拼接。它至少包含七项能力：

这七项能力不是并列的功能清单，而是一条流水线：从用户输入进来，经过过滤、裁剪、压缩，再加上检索到的长期记忆，最后组装成模型真正看到的上下文。

一句话：展示给用户看的历史，和传给模型的上下文，不是同一套东西。

02 七层上下文：不同信息住在不同的地方

既然要治理，首先得搞清楚信息从哪来、存在哪、活多久。

在当前项目里，上下文被分成了七层。每一层有自己的存储位置、生命周期和职责：

这七层看起来多，但核心区别只有两个维度：

从生命周期看，最上面三层（当前用户输入、任务类型、运行状态）只活一轮，用完就丢；中间两层（会话历史、业务摘要）活多轮，支持用户继续追问和修订；最下面两层（仓库长期记忆、工作区说明）跨会话、跨任务，是稳定的知识沉淀。

从存储位置看，单轮数据在 runtime 里，多轮对话存在 checkpoint，业务记录落在 sqlite，跨会话知识放在 LangGraph Store。不同的东西住在不同的仓库里，各取所需。

前端历史展示和模型运行上下文是分离的。

用户在界面上滚动看到的历史消息，是从 checkpoint 查出来的；但模型每一轮真正看到什么，是由 runtime + middleware 重新组织的。前端展示需要完整，模型上下文需要精炼——这两件事不能混为一谈。

03 两道压缩防线：自动摘要 + 主动 compact

上下文越长，模型越容易被噪声带偏。窗口上限是硬约束，所以压缩是必须的。

。SummarizationMiddleware 会持续监控当前消息上下文是否接近模型窗口上限。一旦逼近阈值，它自动调用指定模型生成历史摘要，用摘要替换掉较早的旧消息，同时保留近期消息。后续模型调用就基于摘要加近期消息继续推理。这道防线是框架层面的，开发者不用管，它自己会跑。

。除了中间件自动压缩，框架还通过 create_summarization_tool_middleware 给 Agent 提供了一个 compact_conversation 工具。Agent 可以在阶段性任务完成后，主动调用这个工具做一次阶段性压缩。

一个是快撑不住了自动挤一挤，一个是活儿干完了主动收一收。两道防线配合，既防止窗口溢出，也保证上下文始终围绕当前任务。

04 长期记忆：用确定性路径，而不是向量检索

聊到长期记忆，很多人的第一反应是向量数据库加语义检索。但当前项目的长期记忆走了另一条路：

就这三步，没有 embedding，没有相似度计算，没有可能相关的模糊匹配。

为什么这么做？因为仓库知识的特点是

。一个仓库的技术栈、入口文件、测试方式、依赖安装方法，这些信息不会天天变，而且按仓库维度天然隔离。与其做模糊检索，不如直接按路径精确读取。

需要特别注意的是：这个 /memories/ 是 StoreBackend 的虚拟路径，不是 LocalShellBackend 的真实文件目录。它存的是仓库分析后的结构化记忆，不是磁盘上的 markdown 文件。

说了这么多机制，回到最实际的问题：做这套上下文精细化，到底解决了什么痛点？

不做裁剪和分层，多轮对话很快就会顶到窗口上限。

第二，避免每轮重复分析仓库。

仓库分析是很贵的操作——第一次处理一个仓库时，Agent 要搞清楚技术栈、入口文件、测试命令、依赖安装、哪些目录不能动、之前改过什么。如果每轮都重新扫一遍，效率低不说，还容易得出不一致的结论。有了 repo_memory，第一次分析完沉淀成记忆，后续直接读取。

第三，避免历史消息污染模型。

多轮对话里混着太多东西：上一轮方案、上一轮报错、用户确认、无关追问、旧测试结果、已经修复的问题。这些对前端展示有价值，但不该全部进模型上下文。区分展示历史和模型上下文，就是为了解决这个问题。

第四，避免工具消息破坏上下文。

Agent 调工具后，消息里可能混着无效 tool_call、不成对的 ToolMessage、过长异常堆栈、重复工具输出、格式不兼容的 AIMessage。这些如果直接传给下一轮模型，轻则干扰推理，重则直接报错。中间件在注入上下文前会做清洗和整理。

所以，判断一个 Agent 系统的上下文管理做得好不好，不用先看它用了多贵的模型，看四件事就够了：

它有没有把上下文分层？它会不会在窗口快满时自动压缩？它能不能把仓库知识跨会话复用？它是否区分了给用户看的历史和给模型看的上下文？

上下文精细化的本质，不是让 Agent 记住更多，而是让 Agent 每一轮都看到最该看的东西。

AI Agent 上下文精细化：不止是拼历史消息

人工智能

架构设计

后端

上下文精细化是Agent系统治理的核心，通过过滤、裁剪、压缩和记忆检索七项能力，将上下文分层管理，避免模型被噪声干扰。采用自动摘要和主动compact双压缩防线，配合确定性路径检索长期记忆，区分展示历史与模型上下文，确保每轮精准获取相关信息，提升推理效率。

向量数据库

中间件

数据库

Agent

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

AI Agent 上下文精细化：不止是拼历史消息

AI Agent 上下文精细化：不止是拼历史消息

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐