一个开发任务结束了，下一个任务该继续原会话、先 compact、fork 一份历史，还是直接新开？
我们做了两轮、两个模型、五种会话策略的对照，共 120 次运行。结果没有给出统一最优解：完整历史在部分分组里显著增加成本与耗时，但在另一模型上又可能更快；短摘要也没有稳定胜过直接新开。
1. 比较的是对话交接，不是有没有项目知识
所有组拿到相同的新任务说明、代码、文档和证据。"新开"仍能读取仓库，只是不继承旧聊天。
| 策略 | 接手方式 |
|---|---|
| 新开 | 从任务说明与仓库接手 |
| 继续 | 保留完整对话 |
| compact | 原生压缩后继续 |
| fork | 复制历史，新建会话身份 |
| 摘要新开 | 空会话加一份共用、冻结的短交接摘要 |
实验规模：两轮 × 两模型 × 两目标任务 × 五策略 × 三次重复 = 120 次。
模型为 gpt-6.1-sol（medium）和 deepseek-flash（请求 medium，运行时解析为 high；页面显示为 DeepSeek V4.1 Flash）。
旧历史来自真实开发。第二轮换成更复杂的旧工作，包括持久队列、幂等、租约与 fencing、取消、崩溃恢复和重试预算。更复杂不等于更长：Sol 历史约从 44.2 万变成 42.5 万 token，DeepSeek 从 33.1 万变成 29.5 万。因此，这不是严格控制变量的上下文长度阶梯实验，不能用来推断长度阈值。
新目标只有两类：
- E2E 验证：验证已实现的导出功能，预期内失败也必须如实报告。
- 脱敏 bugfix：可见文本需要脱敏，但结构标识和原始差异比较不能变；显示文本与布局宽度都必须使用脱敏后的结果。
复杂旧任务只是历史来源，不是第三类目标任务。
2. 保留完整历史，未必增加交付收益
先看 Sol · 复杂旧任务轮 · E2E 这一组。每种策略三次运行：
| 策略 | 每次平均记录费用（美元） | 中位耗时（分钟） | 完整交付 |
|---|---|---|---|
| 新开 | 0.194 | 2.7 | 3/3 |
| 继续 | 2.293 | 14.0 | 3/3 |
| compact | ≥0.548 | 6.8 | 2/3 |
| fork | 3.813 | 14.2 | 3/3 |
| 摘要新开 | 0.207 | 2.6 | 3/3 |
≥ 表示中断造成的记录下界。失败尝试仍计入均值。费用与时间包含原生 compact，不含旧任务开发和共用摘要准备。
本组中，继续和 fork 更贵、更慢，但没有比新开多完成交付。
这个顺序不能推广到所有模型。DeepSeek 复杂轮 E2E 中，新开约 6.8 分钟，继续约 3.0 分钟，fork 约 2.2 分钟，且都是 3/3 完整合格。对它来说，继承历史有时能省时间。
3. 缓存命中，不代表整个任务便宜
Sol 复杂轮 E2E 中，继续会话的缓存读取费用单项 平均约 1.266 美元，而新开任务全部费用约 0.194 美元，前者约为后者的 6.5 倍。
这是任务级费用之比，不是缓存 token 单价之比。
继续组每次运行累计读取约 633 万缓存 token。旧历史在多次调用中反复进入输入；单次读取便宜，乘以累计用量后仍可能昂贵。
完整历史组的平均输出 token 也约为新开组的 2.8--3.8 倍。Trace 显示了更长的验证过程、脚本和重复检查，但不能据此认定增加的每一步都没有必要。
长输入费率阶梯也推高了开销。保持记录用量不变、仅移除长输入加价重新计算，本组继续与 fork 约有 47% 和 49% 的记录费用来自这项加价。定价造成的成本上升，不是"上下文重力"的证据。
4. 短摘要值得试，但没有证明它最好
下面的原始图表把八组实验放在一起。新开为 1×，费用和耗时小于 1 也不代表交付更好，需要同时看完整交付次数。
Sol 的摘要与新开表现接近。DeepSeek 复杂轮 E2E 中，摘要约 0.082 美元、4.1 分钟，新开约 0.103 美元、6.8 分钟；但两轮 bugfix 中，摘要的功能验收是 4/6，新开是 6/6。
我们的下一步会先试"新会话＋短摘要"，这只是当前选择，不是已被证明的最优策略。本次使用共用冻结摘要，没有为每个新任务单独编写，主比较也没有计入摘要生成成本。
5. 功能做对和完整交付，需要分开统计
120 次运行中，102 次完整合格。其余 18 次包括：
- 14 次运行故障或超时；
- 4 次已完成运行中的功能边界缺陷。
某些中断发生时，代码已通过验收，只是最终交付协议尚未完成。把它们全部称作"代码失败"，会掩盖问题来源。
真实缺陷集中在 DeepSeek 脱敏任务：有的把可见路径误当成不可修改的结构身份，遗漏脱敏；有的显示内容已替换，布局宽度仍使用原始文本。后者违反明确的布局要求，但不能直接描述成敏感明文泄露。
复杂轮 60 次运行没有修改旧任务模块。我们看到了一些旧任务用语残留、更多检查和输出，还没有看到稳定的"旧任务接管新任务"。
6. 这些结果能支持什么
每组仅三次运行，每轮使用一份固定的开发历史；三次重复并不代表三份独立历史。缓存冷热、路由和宿主负载没有完全控制。
四个 E2E 原始判分因允许的独立验证脚本位置而经过人工复核修正，保留原判分，没有因此让模型重跑。
费用按冻结费率计算，是 API 等价估算，不是当前价格或实际订阅账单。包括记录的非缓存输入、缓存读取、缓存写入及输出，推理 token 已包含在输出中，不重复计算。本次缓存写入记录均为零；中断后用量不完整的费用只能视作下界。
目前可以确定的是：会话策略应按模型、任务、交付要求分别评估，不能只看上下文长度或单次 token 价格。尚未识别出稳定最优策略，也没有找到上下文重力阈值。
下一步需要比较面向新任务的专用摘要，计入摘要准备成本，并测试"关键决策只存在于旧聊天、仓库里找不到"的情况。
本文改编自 Sunny Code 工程实验原文。完整原文包含可交互分组对照、八组总览和聚合数据下载。