做AI代理AI Agent时间久了你会遇到一种很诡异的情况同一个任务上午跑得好好的下午同样的输入结果完全不一样甚至开始胡言乱语。不是模型变笨了也不是代码有Bug而是上下文Context失控了。我过去大半年一直在折腾各种代理框架从简单的工作流到带工具的自主Agent踩了无数坑之后得出一条结论AI代理的上下文需要像软件代码一样有一套完整的开发生命周期Context Development Lifecycle来管理。这篇文章不会讲那些“提示词技巧”而是把上下文当成一个需要被设计、开发、测试、部署、运维的工程制品。里面会涉及上下文数据流图怎么画、执行上下文怎么构建、Cursor这类工具到底怎么把上下文喂给模型、本地模型加AI代理助手时怎么分配上下文、Claude超限会怎样、幻觉和温度到底有什么关系。如果你正在做Agent应用或者被上下文超限、遗忘、幻觉折磨过这篇应该能给你一套可以落地的解决框架。1. 先把问题说清楚AI代理“失忆”不是模型不行是上下文没人管1.1 从一次失控的代理任务说起我之前做过一个多步骤的市场分析代理。流程很简单第一步联网搜索行业新闻第二步抓取几家公司的财报摘要第三步综合前面所有信息生成一份投资分析报告。单看每一步提示词都没问题工具调用也正常但整套流程跑下来第三步的报告里居然出现了一个完全不存在的数据而这个数据是第一步搜索时明确排除掉的错误信息。当时我第一反应是模型幻觉换了更强的模型结果还是偶尔出错。后来把每次调用记录里的上下文全部dump出来看才发现问题出在第二步工具返回财报摘要后代理框架把第一步的搜索结论做了截断所谓的“历史”只保留了最后两轮对话。第三步的模型根本没看到第一步的原始数据于是只能靠自己的先验知识去“脑补”。这不是模型不行是上下文的生命周期在设计阶段就被切断了。那次排查之后我意识到大多数Agent项目的问题都不是单个环节的提示词写得不好而是从上下文产生、加工、注入、消费到清理的整条链路没有被人为管理起来。你用再强的模型也架不住有人把你记忆里的关键信息悄悄删掉。1.2 上下文失控的三种典型症状幻觉、遗忘、超限我把自己和他人的踩坑经验整理了一下上下文的失控通常表现为这三种症状症状直观表现根因方向排查手段幻觉生成了上下文里根本没有的事实或数字上下文缺失模型用先验知识填补温度过高加剧对比模型输出与注入上下文的内容找“凭空出现”的断言遗忘前面步骤的关键结论后面步骤完全没用到历史被截断、被覆盖、被摘要过度压缩检查每一轮工具调用后的上下文保留策略超限请求直接报错或长文被静默截断Token超出模型窗口部分框架做“中间截断”而非“尾部截断”监控Token增量查看截断位置评估压缩策略这三种症状经常一起出现。上下文超限导致截断截断关键信息导致遗忘遗忘导致模型开始脑补脑补出来的内容又变成下一步的“事实”最后整个Agent的行为像多米诺骨牌一样连环失控。你去看那些跑得稳的Agent产品它们的上下文一定是有生命周期的谁产生的数据、谁加工了它、它进入哪一层的上下文、什么时候被消费、什么时候被摘要、什么时候被清理每一步都清晰可控。这不是锦上添花而是Agent能不能落地的基本前提。2. 设计阶段上下文工程的第一步是画数据流图而不是写提示词2.1 上下文数据流图的分解方法我在设计任何一个Agent之前都会先画一张上下文数据流图。不需要画得多漂亮画在纸上或者用最简单的文本格式都行但一定要把下面这几类节点标出来源头用户输入 / 知识库检索结果 / 工具返回结果 / 系统状态 加工过滤 / 摘要 / 重排 / 字段抽取 / 格式转换 消费大模型输入 / 工具调用参数 / 记忆更新 存储长期记忆向量库/键值库 / 短期记忆会话窗口 清理过期数据归档 / 噪声丢弃 / 安全脱敏每个节点之间标出数据的大致体积。比如“知识库检索结果”这一步检索可能返回10篇文档共3万字但真正进入上下文的摘要可能只有2000字中间那个“加工”节点就是上下文工程的核心战场。实际项目里很多人直接让工具返回的原始文本一股脑全塞给模型这就是数据流图上“加工”节点的缺位Token消耗和噪声同步起飞。画完这张图你就能回答三个关键问题上下文从哪里来经过哪些转换最终给谁消费答不上来说明这个Agent的上下文是“野生”的早晚出事。2.2 给上下文划分边界什么该进什么不该进很多人的直觉是上下文越多越安全其实恰恰相反。模型窗口就像厨房的灶台调料全都堆在上面真正炒菜的时候反而找不到盐放哪了。我给上下文划定边界时会遵守三条原则相关性、时效性、可验证性。相关性指这条信息是否直接影响下一步动作。比如查天气的Agent用户当前城市是相关的半年前的历史搜索记录大概率不相关时效性指信息是否还有效。昨天的股票收盘价可以用来分析趋势但不能作为今天的实时报价可验证性指信息是否有明确来源。工具API返回的JSON字段是可验证的模型上一次“猜测”出来的中间结果是不可验证的这类信息尽量不要进入后续步骤的上下文。实际工作中我还会把“可检索但不必常驻上下文”的数据单独划出来。比如一个客服Agent的完整知识库可能有几万个文档不需要每次都塞进上下文而是通过检索按需取用。只有当用户问到一个具体问题时才把最相关的几段内容注入进去。这一步做好能直接省下80%以上的Token开销。2.3 上下文分层系统层、任务层、会话层、工具层把好关之后我会把上下文集成分成四层每层有独立的预算和生命周期系统层模型角色、能力边界、全局规则。这层最稳定基本不随对话变化固定占用一小部分Token预算。任务层当前目标、已完成步骤、下一步计划。这是Agent的执行状态机每次工具调用后需要更新生命周期跟当前任务绑定。会话层用户反馈、历史对话的摘要。不是每一轮都完整保留而是定期把老对话压缩成摘要。工具层工具的描述、上一步工具返回的关键数据。这层最活跃也是最容易失控的地方必须刻意控制体积和保留时间。举个例子一个上下文窗口为50k Token的Agent我通常这样分配系统层控制在2k任务层控制在5k会话层用摘要方式控制在8k工具层根据工具数量固定在15k以内剩下20k留给当前这一步的实际数据和模型输出。当然这个比例不是死的但它逼着你在设计阶段就想清楚哪部分数据可以长期占坑哪部分用完就丢。3. 实现阶段把“执行上下文”变成工程制品3.1 执行上下文的构建与注入从Cursor到FastAPI画完图、分好层下一步就是写代码实现。我观察过一个很有趣的现象很多人用Cursor这类AI编码工具时感叹它“好像懂我的项目”但并不知道它到底做了什么。其实Cursor的上下文构建逻辑对自建Agent非常有参考价值。Cursor会收集当前打开的文件、光标所在的代码段、最近编辑过的文件列表、项目里的检索结果再拼上用户的自然语言指令一起发给模型。它不会把整个项目全部塞进去而是选一个和当前操作最相关的子集。这个逻辑落实到你自己的Agent里就是要有一个明确的“上下文构建器”统一负责从各个数据源拉数据、过滤、拼装。我自己的项目里用FastAPI搭Agent后端时会在中间件层维护一个请求维度的上下文对象from contextvars import ContextVar from fastapi import FastAPI, Request app FastAPI() request_context: ContextVar[dict] ContextVar(request_context, default{}) app.middleware(http) async def init_context(request: Request, call_next): token request_context.set({ session_id: request.headers.get(x-session-id, ), user_input: , task_state: {}, tool_outputs: [], budget: 50000, }) try: response await call_next(request) finally: request_context.reset(token) return response这里用ContextVar而不是全局变量是为了避免并发请求之间互相污染上下文。每个请求进来时初始化一份新的上下文请求结束时清理掉这就是执行上下文最基本的生命周期。不要小看这一步我见过不少Agent框架因为用了全局列表存上下文两个用户一起用的时候数据串得一塌糊涂。3.2 如何显式指定AI编码上下文路径、规则与动态拼装再说说“AI编码如何指定上下文”这个问题。Cursor里你可以通过文件名手动带上某个文件可以用.cursorrules来固定项目级规则也可以在对话里直接说“参考src/utils.py”。这些操作的底层引擎就是把你指定的路径通过工具读取出来转成文本片段放进上下文模板的特定位置。自建Agent要做类似的事核心是把“上下文来源”显式化。我的做法是定义一个基础上下文构建器用声明式的方式描述每一步要注入什么class ContextBuilder: def __init__(self, system_prompt: str): self.layers { system: system_prompt, task: {}, session: [], tool: [], } self.budget 50000 def with_task(self, task_state: dict): # 任务状态序列化后放在任务层 self.layers[task] task_state return self def with_tool_output(self, tool_name: str, data, max_chars3000): # 工具返回只保留最近N个字符防止爆量 truncated str(data)[:max_chars] self.layers[tool].append({tool: tool_name, data: truncated}) return self def build(self) - str: # 按固定顺序拼装各层上下文 sections [] sections.append(f[System]\n{self.layers[system]}) sections.append(f[Task State]\n{self.layers[task]}) sections.append(f[Session History]\n{self.layers[session]}) sections.append(f[Tool Outputs]\n{self.layers[tool]}) return \n\n.join(sections)这段代码不复杂但代表了一个关键转变上下文从“随缘拼接”变成了“受管制的工程对象”。每一层的数据来源清晰调用方必须显式地把数据放进来而不是靠模型自己去记忆里翻。等上下文出问题时你也能快速定位是task层更新错了还是tool层截断得太狠。3.3 本地模型AI代理助手组合下的上下文供给策略最近很流行“AI代理助手加本地模型”的组合把模型跑在本地通过代理助手的框架去做工具调用和复杂编排。这种组合的好处是数据私密性好、响应可控但最大的难题是本地模型的上下文窗口通常比云端大模型小部署机器的显存也限制了并发上下文的数量。我的策略是把上下文供给拆成“轻推理”和“重推理”两条路。轻推理路线用本地模型负责分类、抽取、工具调用参数生成这类任务不需要太长上下文我通常只给它任务层和工具层最近一次的结果整体控制在4k以内重推理路线负责总结、长文生成、复杂决策这类任务才把完整的多层上下文拼起来甚至可以转发给云端大模型执行。另外有个细节本地模型的上下文是“珍贵资源”不能像云端那样靠BufferedSummary大法。我每次工具调用结束后会立即对原始返回做摘要压缩只把结构化结果存进上下文原始文本直接丢弃或落盘备份。这样即使下一轮要回溯重要信息也可以从备份里重新检索而不是长期占着窗口不放。4. 测试与度量阶段别等幻觉发生才想起来评估上下文4.1 上下文质量的四大指标相关性、新鲜度、一致性、冗余度很多团队把Agent上线后只盯着“用户满不满意”这个最终结果完全不看中间消耗的上下文质量。这就像做菜只尝出锅味道却不管放了多少盐、炒了多久。我建议从四个维度给上下文打分指标含义度量方式相关性上下文中对当前步骤有直接帮助的信息占比人工抽样标注或让一个便宜模型打分0-5新鲜度有多少信息能反映最新的系统/工具状态检查关键字段的更新时间计算过期字段占比一致性前一轮注入的事实与后一轮是否冲突抽取事实三元组跨轮对比矛盾数量冗余度重复信息、噪声信息在总Token中的占比计算相似度聚类或统计同一来源被重复注入的次数你可以在开发环境里跑几十条测试任务每跑一步记录一次上下文快照然后用这四类指标给快照打分。如果相关性低于3分大概率是检索排序有问题如果冗余度超过40%就该做去重了。我见过一个检索型Agent每次把同一个README文件的三个版本都塞进上下文模型经常分不清哪个版本才是当前生效的最后行为完全随机。这全靠质量指标才揪出来。4.2 视觉内容上下文模型让上下文状态可观测“视觉内容上下文模型”这个说法可能有点抽象我的理解是把上下文这种看不见摸不着的东西变成可视化的内容状态让人一眼看出哪里不健康。我做的第一个可视化实验就是“Token热力图”。具体做法是给每一条注入模型的内容打上标签比如来源是“工具A返回”、“用户消息”还是“历史摘要”然后在一条请求处理完之后把各标签占用的Token数量画成堆叠条形图。你会发现很多时候模型窗口明明还剩一大半但真正和当前任务相关的Token只有可怜的一小条其余全是历史对话的完整原文。看到那张图你就不难理解为什么Agent会“答非所问”。更实用的可视化工具有两类一类是时间线视图展示每个步骤里哪些上下文被新增、被覆盖、被压缩对应Agent的执行轨迹另一类是依赖视图展示当前模型输出依赖了哪些上下文来源像代码的依赖图一样哪条信息是悬空的、无源头的一眼就能看见。我自己实现过后者的简化版在每次补全请求前把注入上下文的来源路径按哈希值记录成树状结构再跟前一步对比新增节点里如果存在“model_previous_output”这种无源来源就说明模型自己的旧输出正在污染新的决策。4.3 大模型能力边界幻觉、上下文、温度之间的三角关系聊上下文质量的尽头必然撞上大模型本身的能力边界。幻觉、上下文、温度这三者的关系我常常用一句话概括**模型的输出不是“查出来的”而是“顺着概率推出来的”。**上下文负责提供概率分布里的确定性温度负责控制你有多大程度偏离最高概率的路径而幻觉就是当上下文提供的确定性不够时模型只能靠自己见过的世界“继续编”。我做过一个简单实验同一个事实抽取任务上下文里有原文、无上下文、温度从0.2调到0.8三组组合跑下来无上下文高温度组合的幻觉率最高有上下文低温度组合最稳。这个实验也印证了Agent工程里的一个基本原则**能用上下文解决的事不要靠调温度解决。**温度调低只能让模型更保守地选择概率高的词但如果上下文压根没给足信息保守也救不了事实性错误。更重要的是你要对“模型分不清‘我没看到’和‘这不存在’”这件事有敬畏。哪怕是Claude、GPT这样的前沿模型在上下文缺失时也会给你一个看似流畅但完全错误的答案。所以上线前做上下文质量测试不是给模型挑错而是在揭示系统设计是否存在漏洞。5. 运行与维护阶段上下文超限不是报错是事故5.1 Claude超过上下文限制会发生什么症状与抢救手段网上经常有人问“Claude超过上下文限制会怎么样”我的回答是分两种情况API明确报错是最好的一种最怕的是框架帮你“静默处理”。API层通常会返回类似context_length_exceeded的错误请求直接失败输出没有至少你知道出了问题。但很多Agent框架为了“好用”会在发送请求前自动裁剪历史而且裁剪策略往往是把中间部分删掉只留开头和结尾。这种“中间丢失”的后果非常隐蔽。开头是系统提示词和初始任务结尾是最近的对话中间正好是最重要的中间推理和工具返回被删掉的却是它们。模型接收到一个头尾完整但中间空洞的上下文并不会直接报错而是会生成一个看起来正常、实则严重偏离事实的回复。这也是为什么我一直强调**宁可让请求失败也不要静默截断。**失败能触发告警和人工介入静默截断只会让你在错误的方向上越走越远。抢救手段我一般按顺序尝试第一步把历史对话做摘要压缩保留结论、删除推理过程第二步把工具返回的原始数据存到外部存储只把必要的结构化字段留在上下文第三步引入RAG按需检索而不是把所有文档都堆进去。这三步做完绝大多数场景都不需要换更大的窗口。5.2 监控、告警、回滚上下文生命周期的运维视角上下文进了生产环境就得按运维的标准对待。我给自己每个Agent配了四个监控指标上下文占用率、上下文增长速度、工具返回体积、截断次数。占用率超过窗口的70%就触发告警系统会自动对会话层做一次摘要压缩压缩完还超70%再升级为人工处理。增长速度异常时说明某个工具返回正在快速膨胀需要检查是不是API把一张大表全部返回了。工具返回体积是最容易被忽视的指标。我曾经被一个数据库查询工具坑过一个看似简单的查询返回了200万字符的日志直接把上下文打爆。截断次数只要大于0就说明生命周期设计出了问题需要回到设计阶段重新画数据流图。监控之外我还给每个请求上下文拍快照。每次模型调用前把上下文的序列化版本存一份到对象存储键名带上时间戳和请求ID。这样一旦生产环境出现行为异常可以直接把当天和昨天的快照做diff看到底是哪一层上下文变了。这个做法帮我定位过好几次“昨天还好好的今天突然坏了”的诡异问题最终发现都是因为某个上游工具改了返回字段名。5.3 上下文版本管理让每次Agent行为都可复现软件有版本管理Agent的上下文也要有。我给上下文的每次“正式构建”打一个内容哈希作为幂等键存进KV存储。同一个任务重跑时如果上下文的哈希和上次一致理论上模型的输出也应该一致在温度很低的情况下。如果不一致那就说明有非确定性因素混了进来。有一次我把这个思路应用到复盘场景用户反馈某个Agent给出的答案“时好时坏”。我拉取了同一天20次请求的上下文哈希发现哈希落在三种完全不同的值上。对照后发现差别源于会话层里保存的聊天历史没有做顺序归一化有时按时间升序有时按插入序导致同样的语义内容在Token排列上差异巨大。模型对Token顺序又极其敏感排列一换输出风格跟着换。把会话层统一成按时间升序之后哈希值的分布立刻收敛行为也稳定了。上次复盘结束我在项目文档里写下一句话“上下文是Agent的潜意识。”模型的参数量再大也必须在限定窗口里去理解世界而你给它什么样的一段上下文就约定了它在当下这个瞬间能调动多少有效信息。我个人的体会是上下文生命周期管理不需要一步到位先从一个阶段切入——比如先做设计阶段的数据流图或者先做运行阶段的快照对比——只要开始把上下文当代码看待后面所有的工程手段都会自然长出来。