Instruction Context指令上下文包含了 System Prompt、业务 Spec、行业标准等内容核心是用来限定 Agent 应该怎么思考、能做什么、不能做什么。Goal Context目标上下文包含了用户最终目标、当前子目标等它是一把标尺用来衡量你后续的所有步骤。User Context用户上下文包含了用户画像、历史决策等它是你的 Agent 是否“懂我”的关键点。Task Context任务上下文包含了当前任务、执行步骤等它用来记录你的 Agent 曾经、现在、未来做了什么。Tool Context工具上下文包含了工具输入、输出等它记录了工具调用的相关信息一般历史工具调用也出现在这里。Constraint Context约束上下文包含了硬约束、软约束等它清晰定义了 Agent 的运行边界。…WindowInject(Order(Compress(Select(Retrieve(Context)))))Retrieve找出可能相关的 ContextSelect选择当前真正需要的内容Compress压缩到合适的粒度Order决定内容的排列顺序Inject以合适的结构注入大模型。滑动窗口算法其实滑动窗口算法是一种思想它可以用在很多地方。当用在管理上下文内容的时候是指窗口只保留最近一段上下文旧的上下文随着对话推进逐渐被挤出去。比如说用户和 Agent 已经聊了 100 轮但是当前模型窗口只能放 20 轮那么系统就只保留最近 20 轮对话。如果是在实践中直接无脑用滑动窗口算法就可以。通常来说滑动窗口实现起来有两种方式都是跟窗口大小的计量单位有关一是按照轮次来计算比如前面说的窗口放 20 轮对话二是按照 Token 来计算比如说 64K 窗口。不在窗口内的对话内容怎么办靠摘要和细节召回。生成摘要可以让大模型帮你生成摘要你要做的、能做的就是提供一些摘要的规则也就是描述什么保留什么不保留。每隔 N 轮生成一次摘要N 窗口大小。有两个生成时机可选即时生成——在第K×N 轮即本轮最后一批结束时立刻生成延迟生成——等到下一轮即第K×N1 轮开始时再回过头来生成。分层上下文按照生命周期分层按照作用范围分层按照信息形态分层按照权威性分层按照冷热程度分层压缩你是 Agent 上下文压缩器。请将输入内容压缩成给后续大模型使用的高密度上下文而不是给用户看的自然语言摘要。要求1. 删除礼貌表达、转场句、口语填充词、重复解释、情绪价值表达。2. 保留目标、实体、关键事实、硬约束、软偏好、用户确认、用户否认、数字、时间、决策、理由、风险、缺失信息、证据来源。3. 可以使用短句、列表、键值对不要求自然语言流畅。4. 不得改变原意。5. 不得把不确定信息改成确定事实。6. 不得把建议改成已执行决策。7. 不得把 Assistant 推测改成用户确认事实。8. 硬约束和用户否认内容必须显式保留。...// 后续内容用户画像基础方案1、用户画像必然包含用户的一些基本信息如年龄、性别等。2、目标画像用户究竟想达成什么3、能力画像用户的理解能力如何用户能做到什么程度的事情4、偏好画像用户喜欢什么用户不喜欢什么5、决策画像用户通常怎么做选择6、关系画像用户讨论的人之间是什么关系人物建模首先来看人物。你首先要考虑的就是为人物单独记录一张表这张表的核心不是记录这个人叫什么而是记录这个人在用户的世界里面是谁。你可以参考这个表结构的定义事件建模用户画像什么时候提取1、实时提取实时提取是指每一轮用户对话结束之后立即判断是否产生了新的画像。比如说用户输入不要推荐苹果最近实在不想用 iOS 了。系统在这一轮结束后可以实时提取出一些用户画像下面是一个例子{ profile_type: brand_preference, profile_value: 当前不考虑苹果, scope: 本次手机购买任务, time_level: current_task, source: explicit_statement }2、对话结束后提取第二种是在一次对话或一个任务结束之后统一提取通常表现为一轮对话后提取。当然你也可以用任务来作为维度在 N 个轮次之后任务结束再提取用户画像。重点应该分析为什么还要分析最初表达和中间表达直接用最终表达不就可以吗这就是关键点了因为用户的最终选择可能是“无奈的折中”而不是真的喜欢。理论上来说你的 Agent 还要区别“折中、妥协”和真的喜爱之间的区别。3、离线提取4、实时加离线的混合方式5、进阶方案这些因素可以合并在一起为用户画像计算一个稳定性分数里面的 w 代表的是权重最简单的情况下可以将 w0、w1、w2、w3 这些都设置为 1。stability_score w0 * 出现次数得分 w1 * 持续时间得分 w2 * 跨场景得分 w3 * 用户确认得分长任务问题1、长任务中的各种“漂移”2、基础解决方案前面提到的各种漂移看起来很多但是基础解决思路并不复杂不要让 Agent 一口气跑到最后而是在执行过程中不断停下来重新确认自己有没有走偏。具体怎么做要看你的 Agent 使用的是 Plan 机制还是 ReAct/TAO 这种循环式执行机制。当然你要是使用混合形态那么长任务的解决方案你也可以混合下面两个基础解决方案。2.1、Plan通过 Checkpoint 定期校准方向在 Plan 模式中解决长任务漂移最基础的方式就是设置 Checkpoint。Checkpoint 不能保证 Agent 永远不出错但可以阻止一个小错误被后续几十个步骤不断放大。Checkpoint 不需要每一步都设置否则会带来大量模型调用和 Token 开销。一般放在业务阶段结束、关键中间产物生成、高风险工具调用以及被大量后续步骤依赖的节点之后。因此在关键节点完成后要暂停执行并检查• 原始目标有没有发生漂移• 用户的硬约束有没有被违反• 当前任务状态是否准确• 中间结果和证据是否可信• 原计划是否仍然适用• 是否需要 Retry、Rollback 或 Replan。2.2、ReAct Loop每一轮都重新回答“我还差什么”Plan 的处理思路是提前规划再通过 Checkpoint 定期校准。而 ReAct/TAO 的特点是走一步看一步所以看起来两者差异还挺大的。一个基础的 ReAct Loop 通常包含Thought、Action、Observation。从循环的角度来说你有两个点可以执行检查• 一轮循环开始的地方• 一轮循环结束的地方这里往往也就是 Observation 的地方。检查的内容其实很有限只查关键的几个维度• 目标判断我当前要逼近的最终目标是什么• 状态判断哪些事情已经完成哪些还没有完成• 约束判断当前 Action 是否违反用户的硬约束• 差距判断我现在距离目标还缺少什么• 证据判断上一轮 Observation 能否支持当前结论3、高级解决方案基础方案能够降低长任务跑偏的概率但它依然偏被动完全是等任务执行到 Checkpoint或者 ReAct Loop 主动检查时才发现上下文已经出了问题。从实践中来看其实也够用了但是在面试中就显得有点弱了。所以对于更复杂的长任务我们还可以进一步引入以下三种机制。3.1、上下文健康检查与漂移检测引入一个独立的 Context Verifier定期检查当前上下文是否已经发生漂移。你可以理解为它就是前面 Plan 固定位置 Checkpoint、ReAct 每个循环执行检查的异步化而已。检查的内容和前面也差不多包括当前 Goal 是否偏离原始目标硬约束是否丢失或被弱化Task State 是否与真实执行情况一致关键结论是否仍然有 Evidence 支撑当前窗口是否混入过期、重复或冲突的信息Observation 是否被错误地当成确定事实。其他任何你觉得有可能引起漂移的内容。3.2、事件溯源与可信快照不要只维护一份不断被覆盖的当前状态而是记录长任务执行过程中发生的关键事件。3.3、分阶段执行与上下文交接第三种思路是避免让同一个 Agent 携带全部历史执行完全部任务。这种思路违背了“优先使用单 Agent 原则”所以慎用。这个思路是将长任务拆成多个阶段例如需求分析、信息收集、方案生成、执行、验证。如何设计一个富有竞争力的上下文管理机制以下是基础策略我们不会简单地把所有历史对话都放进 Prompt而是会先将上下文拆成用户信息、目标和约束、任务状态、历史对话、知识内容以及工具结果等几类。根据数据结构和生命周期分别存放在运行时状态、Redis、MySQL、ES、向量数据库和对象存储中。每次调用大模型之前会根据当前意图和执行步骤通过结构化查询、关键词检索和向量检索找出候选上下文只选择当前任务真正需要的内容进入窗口。窗口不足时普通历史对话会摘要工具结果会抽取关键字段但是目标、硬约束和关键任务状态会独立保留。同时摘要和压缩不会删除原始数据。当当前摘要不足以完成指代消解、事实判断或者错误定位时会重新召回原始对话、工具结果和中间产物。1、你的 Agent 里面有什么上下文可以这么介绍当前会话和历史对话用户画像和商品偏好当前用户目标和预算约束商品候选集和商品知识当前 Plan、执行步骤和中间结果Action 执行结果用户已经确认或者否定过的关键事实。2、这些内容分别怎么存其实说白了怎么存就是在内存、Redis 和持久化数据库中选两三个而已。当前会话、当前任务状态放在 Redis 或运行时状态中也会被持久化。用户画像、关键事实、约束和任务状态放在 MySQL也会被缓存到 Redis 中。历史对话、Agent 输出和大型工具结果放在 ES 或向量数据库……3、这些上下文怎么找出来存内存必然是本地缓存那种 GET 接口。存 Redis那差不多就是适用 Redis 的命令。存 MySQL基本上就是 SQL 了。例如在找用户画像的时候大概率就是 WHERE uid xxx 这种查询。存 ES要注意撰写 ES 的查询语句。在细节召回这种场景下可能需要大模型来帮你撰写 ES 查询语句至少也要大模型来撰写召回细节的关键字。向量数据库类似查询 ES都要考虑借助大模型的力量来撰写查询语句。4、上下文太长了怎么办基础方案里面不需要详细讨论多级压缩算法。你只需要讲清楚两个原则。第一个原则是不同内容采用不同的处理方式。你可以举例子比如说硬约束这种东西是不管你的上下文多长都是要保留的。第二个原则是压缩不能一刀切。毕竟有些内容丢失只是让回答差一点有些内容丢失则会直接导致任务失败。5、压缩之后怎么找回细节所有被压缩的内容都保留原始数据和索引。当摘要不足以支持当前推理时可以重新召回原始细节。6、高级策略在我们的电商 Agent 里面用户画像不是一个简单的静态标签而是分成当前会话、中期和长期。用户新表达的偏好先进入短期层我们会根据出现频率、持续时间、跨场景一致性以及点击、收藏、购买等行为证据判断它是否应该升级为长期画像避免将用户的一时兴起误判成稳定偏好。每次推荐之前系统会根据当前商品品类、用户意图、Plan 步骤和剩余 Token从不同层级画像、历史对话、行为记录和商品知识中生成候选上下文再按照相关性、重要性、新鲜度、证据强度和 Token 成本进行筛选。如果上下文窗口比较紧张会对不同内容采用不同压缩粒度。当前预算、硬约束和用户明确确认的偏好保留原文长期画像保留结构化结论普通历史行为只保留统计摘要低相关内容则只保留召回索引。当短期画像和长期画像冲突或者摘要不足以解释用户当前选择时Agent 会主动触发细节召回从历史对话、行为记录和画像证据中重新查找原始内容再判断这是长期偏好变化、场景差异还是一次性的临时兴趣。如果仍然无法确定就向用户澄清而不是直接覆盖画像。窗口动态编排根据实时运行的情况来决定放什么以及放到什么为止用户画像提取、适用重点在两个地方建模以及识别偶然的偏好变化。长任务的解决方案尤其是重点讨论漂移问题。在这个过程你可以混入 Plan 和 ReAct 的混合形态再引入几个异步运行的东西比如说摘要提取、漂移检查等。摘要和细节召回的特殊机制可以重点讨论你的分层摘要机制以及配合这个机制的细节召回算法。