Appearance
长任务如何跨 Context 延续：Structured Artifacts 与 Reset
维护 progress.md 、plan JSON、test report 和 git diff；context reset 后新 Agent 读取这些 artifact，而不是回放几十万 token 聊天。长期 coding agent 每完成一个阶段写 progress + checkpoint，然后启动新 context，从 workspace 和 progress 恢复；比无限 summary 更稳定。
Long-Horizon Structured Artifacts
progress.md、task list、decision record、checkpoint summary 等外部 artifact 可让新 context 重新读取状态，减少把全部连续性绑定在 transcript 上。
长任务需要把进度外部化到文件/数据库等 structured artifact，而不是把 transcript 当唯一记忆。Artifact 应能让新进程或新模型快速恢复“已完成/待办/证据”。
Context Reset vs Compaction
Compaction 是保留当前工作上下文，只把历史压小；Reset 则是结束这一份 working context，从 durable state / artifact 重新组装一个新的上下文。
text
Compaction:
old context → summarize/filter → smaller same session context
Reset:
old context → persist durable facts/artifacts
→ new context starts from those facts超长 Coding/Research Run 中，如果历史已经积累了大量失效假设和噪声，仅继续 summary 可能让 drift 越来越严重，此时 Reset 更干净。但它要求真正重要的状态已经外置；如果关键信息只存在旧 transcript，Reset 会直接丢失它。
Reset 前要生成的是“恢复包”，不是一段泛化总结
一个新 Context 至少需要重新建立：
text
goal + current phase
hard constraints / user decisions
completed work + evidence refs
pending work / blockers
workspace/artifact identity
important failures already tried
next safe action这些信息最好来自结构化 Run facts、workspace manifest、plan/decision records，再由模型做必要的可读摘要。若全靠模型从几十万 token 历史“总结一下”，重要约束是否保留无法验证。
什么时候 Reset 比继续 Compaction 更合适
当旧 Context 已经多次压缩、历史噪音明显、任务进入新阶段，或者模型/worker 本来就要切换时，reset 可以建立更干净的 working set。相反，短任务只差少量 token 时，频繁 reset 会增加 rehydrate 成本。
可以把触发条件做成 policy：context utilization、compaction count、phase boundary、handoff、模型迁移等共同决定。Reset 后用固定 checklist 验证关键 state/artifact 都能重新读取，再继续执行。
自测
- Reset 前只保存一段自然语言摘要，恢复后却不知道哪些测试真实通过。恢复包还应该包含哪些结构化事实？
- 新 Context 为什么应从 durable progress/artifacts 重建，而不是把旧 transcript 全量回放？