问智能体处理复杂任务时对话稍长就开始“忘记”前面的内容或者生成的内容越来越零散。加大上下文窗口能解决问题吗答不能。把窗口从128K扩到1M只是把“显性遗忘”变成了“隐性遗忘”——模型依然会在长上下文的中间位置丢失信息。真正解决上下文超载的方法不是扩窗口是拆分任务。一、长上下文不等于好记忆先看一个真实场景用户对智能体说“帮我分析一下A客户这个季度的订单情况如果订单量环比下降超过10%查一下是什么原因如果下降和产品质量有关查一下对应的质检记录最后生成一份分析报告发给销售总监。”这个任务包含6个步骤查订单→算环比→判断是否超阈值→查原因→查质检记录→生成报告→发送。如果把这些全部塞进一次对话模型在处理到“查质检记录”的时候很可能已经忘了“为什么要查质检记录”——它只记得“查质检记录”这个动作但不记得是要验证“是否和产品质量有关”。上下文窗口不够用的本质不是“放不下”是“理不清”。即使窗口能放下全部内容模型的注意力机制也很难在长文本中准确维持多步推理的因果关系。二、任务拆分比扩窗口更有效解法是让智能体学会“拆”——把一个复杂任务拆成多个子任务每个子任务单独执行结果汇总。上述“A客户订单分析”的正确执行流程是子任务1查询A客户本季度订单总额查询A客户上季度订单总额 → 结果本季度520万上季度610万子任务2计算环比变化 → 结果下降14.7%子任务3判断是否超阈值10%→ 是触发根因分析子任务4查A客户近半年的退货记录、客诉记录 → 结果退货率从2.1%升至5.8%子任务5关联质检记录查对应批次 → 结果某批次尺寸偏差超标子任务6汇总生成报告 → 输出每个子任务只处理一个简单问题上下文干净、逻辑清晰、不容易出错。任务拆分的工程本质把“长上下文依赖”转化为“短上下文状态传递”。智能体不需要一次性记住所有信息只需要在子任务之间传递结构化的结果对象。三、拆分的三个原则实践中总结出三条拆分原则原则一每个子任务只做一件事。“查订单”和“算环比”是两个事不要放在同一个子任务里。前者是数据查询后者是数值计算。拆开之后每个步骤的输入输出都清晰可校验。原则二子任务之间的依赖关系要明确。哪个任务依赖哪个任务的结果需要显式声明。上述例子中“计算环比”依赖“查两个季度的数据”“判断是否超阈值”依赖“环比计算结果”。依赖关系不明确任务执行顺序就会乱。原则三异常时能回退到上一步。如果“查质检记录”这步查不到数据应该能回退到“查原因”这步尝试用其他方式找原因而不是直接报错退出。FAQQ任务拆分是智能体自己做的还是开发人员预设的A两者结合。像“A客户订单分析”这类固定流程的任务可以在智能体设计时预设好子任务链。对于完全未知的开放式任务可以用调度智能体Orchestrator做动态拆分——但动态拆分的准确率目前还达不到100%关键业务场景建议预设为主、动态为辅。Q任务拆分后子任务之间的上下文怎么传递A用结构化对象传递不用自然语言。每个子任务输出一个JSON格式的结果对象下游任务解析这个对象获取需要的数据。不要用“上一步的结果是......”这种自然语言描述来传递模型解析容易出错。Q扩上下文窗口完全没用吗A也不是完全没用。扩窗口对“一次性阅读理解”类任务比如读一份200页的PDF后回答简单问题有效。但对于“多步推理工具调用”的智能体任务扩窗口解决不了问题。两种场景需要区分对待。一句话总结智能体上下文超载的解法不是扩窗口是拆任务。把复杂任务拆成多个独立子任务用结构化对象传递状态比把一切塞进一个窗口让模型自己消化要可靠得多。
