Appearance
Q95 · 上下文长度与规划缺陷如何影响长任务？
假设一家公司的客服主管让 Agent 分析 30 条退款工单：只统计“已结案”的工单，按当前指定的政策版本分类，报告每类数量并附对应工单编号，最后提出改进建议；不要发送邮件。Agent 读了半天工单和工具日志，第二天继续时忘了“只统计已结案”，还沿用昨天的分类方案。它能背下更多文字，是否就能避免这些错误？未必。这里同时有两个问题：当前会话能放进多少信息、能否用好这些信息，以及任务计划是否仍符合目标和新条件。前者是上下文问题，后者是规划与执行问题，解决方法互相关联，却不能互相替代。Anthropic 长任务工程实践、Lost in the Middle 论文
术语与例子中的数字
| 术语或符号 | 零基础解释 | 本文例子 |
|---|---|---|
| Token | 模型处理文字等内容时使用的片段单位；不是“一个汉字”或“一个单词”的固定换算 | 工单正文、对话、工具结果和生成的报告都会占用 Token |
| 上下文窗口 | 一次模型调用能参考的有限内容空间；具体计算规则与大小随模型和接口变化 | 30 条工单及多轮日志不能无限堆在一次调用里 |
| 输入 / 输出预算 | 本轮送入模型的内容 / 预留给模型生成回答的空间 | 输入装政策、工单和进度；输出要写分类与报告 |
| 截断 | 因空间不足而丢弃部分历史或文档；若没标记，模型可能以为资料完整 | 最早的“只统计已结案”指令从历史中消失 |
| 压缩（compaction） | 把较长的历史整理成较短的承接内容，降低后续轮次所需空间 | 旧工单过程缩成进度与关键依据；摘要可能漏条件 |
| 计划 | 为达到目标而安排的步骤、依赖和验收条件 | 筛出已结案 → 按政策分类 → 核对数量与编号 → 写建议 |
| 规划缺陷 / 计划失效 | 步骤遗漏、顺序错误、对新条件未更新，或把未验证的步骤标为完成 | 用户改用政策 v2 后仍沿旧分类直接交报告 |
| 重规划 | 发现目标、规则、证据或环境变化后，调整未完成步骤并重检受影响结果 | 政策版本改变后，重分已结案工单 |
| 状态卡 / 检查点 | 存在对话之外的结构化进度记录，使下一次调用能恢复任务 | 记录目标、政策版本、已处理编号、未完成项和证据位置 |
| 证据位置 | 能再次找到原始数据的编号、文件路径或查询标识 | 工单 #001、#018 等及其原始记录引用 |
| 评测 | 用事先确定的样本与可核对标准测试整个流程 | 检查 22 条已结案是否全部且仅被统计、是否用对 v2 |
v1 / v2 | 本文假设的旧 / 新政策版本，不代表真实公司政策 | v2 新增“物流延迟”分类，部分旧类别需重分 |
下面的 30 条、22 条、8 条及两个政策版本全是教学假设。约定工单 #001 至 #030 中有 22 条已结案、8 条未结案；前半批 #001—#015 中有 10 条已结案、5 条未结案；后半批有 12 条已结案、3 条未结案。用户先让 Agent 按 v1 分类，工作进行中明确改为 v2。最终报告必须按 v2 覆盖全部 22 条已结案，排除 8 条未结案，逐项能追溯原始编号。这个目标一旦明确，就不能用“模型说报告写完了”代替核对。
窗口变长，任务仍可能掉链子
图从左到右：长对话快满时，进度不应只存在于滚动聊天里；状态卡保留“目标、证据编号、进度”；用户把规则改为 v2 后，必须重规划并复核。图中的“22 条已结案”是最终应覆盖的目标数量，“已归类”表示当时已有一批按 v1 处理，不表示 v2 下全部完成。图片没有画出原始数据的存储、权限与准确性检查，这些要靠正文中的流程和系统实现。
上下文窗口像一次工作桌的空间。系统指令、用户要求、历史对话、工具定义、工具返回、检索的文档，以及本轮输出都可能消耗可用空间；各厂商和各接口如何计数、遇到超限是报错还是自动管理历史，也会不同。因此不要记一个固定“某模型能装多少字”的数字；工程上应依据所用接口的 Token 计数和停止原因预留输出空间。Claude 官方上下文窗口说明
如果把 30 条工单和每次工具调用的完整日志反复放进提示中，会遇到三种情况。一是装不下：请求被拒绝，或应用自己截去早期内容；若截掉“只统计已结案”“禁止发邮件”，风险直接进入后续决策。二是压缩漏掉要紧条件：摘要写“前 15 条已处理”，却没有说是哪 10 条已结案、按哪个版本分类、还有什么未核实。三是虽然装得下，仍没用好：模型可能漏看藏在大量工单中间的关键字段。《Lost in the Middle》在多文档问答和键值检索设置中观察到，相关信息在长输入中间时，一些模型的表现会变差；它不证明所有模型在所有任务中必然这样，但提醒我们不能把窗口容量等同于可靠利用。Lost in the Middle
压缩能省空间，却不是对历史的无损备份。官方文档把它用于长会话延续，Anthropic 也强调要在压缩或摘要之外保留结构化笔记与关键依赖；不同平台的压缩产物可能是可读摘要或不透明状态，不能假设都可逐字还原原始材料。要保留可核查的原始工单和版本记录，再把必要的任务状态放入下一轮。OpenAI Compaction 指南、Anthropic 有效上下文工程
从一份计划走到中途变更
起始计划可以是：读取 30 条工单；逐条记录是否已结案；只对已结案的记录按 v1 分类；核对数量、编号和理由；写有来源的建议。这听起来完整，但它隐含了“政策版本一直是 v1”。当用户明确改为 v2，而且 v2 新增“物流延迟”分类时，继续照旧计划写报告就会得到流畅但无效的成果。即使把所有工单和 v1/v2 都放在超长窗口里，模型也不会自动知道哪些已完成工作必须撤销、哪些可以复用。它需要把变更映射到受影响步骤，并再次验证。规划基准研究专门把“行动、状态变化与目标能否真正达成”作为评测对象，说明计划质量需要独立检查，不能由上下文容量推断。PlanBench 原论文
| 发生时点 | Agent 当前知道的事实 | 应保存或调整什么 | 容易出现的错误 |
|---|---|---|---|
| 开始 | 共 30 条，目标只统计已结案，当前规则 v1，禁止发邮件 | 保存不可遗漏的约束、原始工单清单与计划 | 只记“分析 30 条”，漏掉筛选和禁止动作 |
| 前半批完成 | #001—#015 中 10 条已结案、5 条未结案；10 条已按 v1 分类 | 逐条存编号、结案状态、v1 类别及证据位置，标记剩余 15 条 | 只写“做完一半”，无法恢复哪些可统计 |
| 用户改规则 | 最终报告必须用 v2；v2 新增“物流延迟” | 标记所有 v1 分类为待复核，改计划为先确认 30 条结案状态，再按 v2 分类全部 22 条 | 把旧分类当最终结果，或只对后半批用 v2 |
| 交付前 | 两批合计 22 条已结案、8 条未结案 | 核对 22 个唯一编号、v2 分类覆盖、每项有来源、无邮件动作 | 数量对了但类别用错、重复计数、引用丢失 |
一个实用的状态卡至少有五项：原始目标和禁止动作；当前规则版本与生效来源；每条记录的编号、结案状态、分类版本和证据指针；已完成、待复核、未开始的进度；上次验证结果与下一步。状态卡应存在可靠存储中，并由程序或人核对，不能只是 Agent 在对话中说“我记住了”。如果使用具有持久化能力的工作流框架，可以在步骤后保存检查点；框架的存储只负责保留状态，不会自动判断状态内容是否正确。Anthropic 长任务实践、LangGraph 持久化文档
重新开始一个会话时，不必把所有 30 条全文再次塞给模型。先提供当前目标、版本、状态卡和下一步需处理的编号；需要判断 #018 类别时，再按编号读取 #018 的原文与 v2 规则。这样减少无关材料，也保留追溯能力。若某条工单的原文已不可访问，应标记“证据缺失”，暂停对该条下结论，不能用压缩摘要里的印象代替原文。
两条失败路径怎样发现与恢复
窗口故障：压缩把前半批写成“已分类 10 条”，没有保留编号和 v1 标记。Agent 在第二天把后半批 12 条按 v2 分类，然后声称“共 22 条已完成”。数量碰巧正确，实际前 10 条仍是 v1。恢复方式是从原始工单与分类记录重建前半批编号，全部按 v2 复核；无法恢复证据的记录不能标为完成。系统应检测摘要和结构化记录之间的差异，例如“v2 已分类编号数”小于 22 时禁止交付。
规划故障：上下文空间充足，用户改成 v2 的消息仍在窗口里，但 Agent 的执行清单没有更新“重分前半批”这一步。它看得见变更，却继续按原计划完成报告。恢复方式是事件触发重规划：将 v1 类别标为失效或待复核，列出受影响编号，执行重分，再跑验收。这个故障说明信息仍可见与计划已正确更新是两道不同的检查。
还有一个常见边界：工具返回一条工单“未结案”，摘要却说“全部已结案”。应以受权限控制的原始工单状态为依据，重新核对摘要；若来源冲突，标记待人工确认。摘要、检索结果和旧计划都是辅助材料，不能覆盖用户当前明确要求或原始证据。
怎样评测这套长任务方案
只测“最后报告读起来好不好”容易漏掉中途的遗忘与误规划。准备一组可重复的带标准答案的教学工单，固定 30 条中 22 条已结案、8 条未结案，并在任务中途插入 v2 更新。用相同模型和材料分别测试“全文堆进长窗口”“只压缩历史”“结构化状态卡加按需读取与重规划”，比较以下结果；这些是设计评测的建议，不是某篇论文给出的普适性能数字。Anthropic Agent 评测工程实践
| 要检查什么 | 可操作的判定方法 |
|---|---|
| 筛选正确 | 最终统计恰好包含 22 个唯一已结案编号，8 个未结案编号均排除 |
| 版本正确 | 22 条最终类别全部依据 v2；旧 v1 标记已复核，无“前半 v1、后半 v2”混用 |
| 证据可追溯 | 抽查每类及边界工单，编号能找回原文和所用规则；缺来源的结论不算通过 |
| 计划能恢复 | 在处理第 15 条后换会话，核对目标、禁止动作、剩余 15 条和待复核项仍在状态卡 |
| 变更能响应 | 在不同处理阶段插入 v2，检查是否识别受影响步骤、重分旧结果并再次验收 |
| 停止与安全 | 任何时点不得发送邮件；工具失败、来源冲突或状态不全时应报告未完成并停止或转人工 |
| 资源开销 | 记录各方案的输入/输出 Token、工具调用、总耗时和人工复核时间，比较质量与成本 |
还要放入“看似容易过关”的失败样本，例如摘要刚好凑出 22，但有重复编号；政策 v2 只改一个类别名；关键规则藏在长材料中段；工具返回缺失或相互矛盾。评测不仅看终稿，也看中间状态、来源和计划变更轨迹。不同模型与接口的上下文表现会变化，测试应按实际运行版本重复，而不是依赖一个固定窗口数字或一次演示。
面试时怎样回答
上下文长度决定一次模型调用能带入多少历史、文档和工具结果，但窗口变大不等于能可靠利用全部信息，更不保证计划正确。长任务会遇到超限、截断、压缩丢条件，以及规则变化后旧计划失效。比如分析 30 条工单、只统计 22 条已结案时，我会把目标、政策版本、已处理编号、原始证据位置和待办保存在结构化状态中，按需读取原文；用户把分类规则从 v1 改成 v2，就标出旧分类并重规划、复核全部受影响工单。最后用编号唯一性、规则版本、证据、禁止动作和恢复测试验收，而不是只看报告是否流畅。Token、时间和人工复核成本也要一起评估。
如果追问“换成超长上下文模型是否就不用做状态管理”，回答是：它可能减少跨窗口的次数，但不能代替证据追溯、版本与进度记录，也不能自动修正失效计划。如果追问“压缩和重规划何时做”，回答是：接近预算或跨会话时压缩历史并写入可核查状态；目标、规则、数据或工具结果发生实质变化时重规划；交付前再按验收条件验证。阈值和触发方式应依据所用模型、接口及任务评测确定。
资料依据
- Anthropic Claude 上下文窗口文档、OpenAI Compaction 指南：上下文计数、长会话压缩及接口差异。
- Lost in the Middle 原论文、PlanBench 原论文：长输入中证据利用的实验边界，与规划能力需要独立评测的研究依据。
- Anthropic 有效上下文工程、长任务 Harness 实践、Agent 评测：压缩、结构化笔记、跨会话交接和端到端验证。
- LangGraph Persistence：保存工作流状态与恢复的官方实现资料；本文不假设使用该框架。