Agent修完代码、PR合并，会话自动标记Done，过一段宽限期再删除。GitHub 9月18日周更新披露了这项可选预览能力。
列表变干净了，但如果一周后线上出问题，团队还需要回答：Agent看过哪些文件、跑过什么命令、为什么做出这次修改。
因此会话清理不是UI功能，而是审计数据生命周期。
状态至少包括Active、PR Open、Merged、Done、Grace Period、Deleted和Legal Hold。测试不能只验证“合并后变Done”，还要覆盖PR重新打开、回滚、多个PR关联一个会话、删除前出现事故冻结等路径。
def can_delete(session):
return (
session["state"] == "done"
and session["grace_expired"]
and not session["incident_hold"]
and session["artifacts_exported"]
)
删除前至少导出模型与工具版本、关键命令、文件Diff、测试结果和PR关联。敏感Prompt与凭据要按数据政策脱敏，不能为了审计永久保存全部原文。
保留策略还要按资产分层。完整对话可能只保留较短时间；脱敏后的工具轨迹、补丁哈希、测试结论和审批记录可以按工程审计要求保存更久；密钥和个人数据一旦识别，应立即从归档中移除。所谓“保留会话”不等于把全部上下文永久复制一份。
状态机比定时任务更重要
如果只写一个“合并七天后删除”的定时任务，很快会碰到边界：PR合并后又回滚，会话关联了两个PR，其中一个仍开放；补丁被拣选到发布分支，但原PR已经关闭；安全团队在删除前一分钟创建事故Hold。
正确做法是把每次转换记录成事件，并让删除操作再次读取最新状态。Merged只能触发进入宽限期，不能直接承诺删除；Legal Hold、回滚调查和未完成的归档都应拥有更高优先级。重复执行删除任务也必须幂等，不会产生一半删除、一半保留的残缺记录。
验收时模拟三种竞态：删除任务运行时PR被重新打开；事故Hold与删除同时写入；导出成功标记先写入但文件上传失败。最终都不能出现“会话删了、证据没留下”。
再补两条恢复测试：归档文件损坏时能否从原始会话重新导出；误删后能否在规定窗口恢复最小证据。恢复演练应真的执行，而不是只在制度里写“可恢复”。同时验证删除后的检索结果不会泄露标题、摘要或向量索引残留，否则主记录没了，影子副本仍然存在。
测试报告至少给出状态转换覆盖率、待删除数量、归档失败数、Hold命中数和超期未删数。它既要证明证据没有早丢，也要证明个人数据没有无限期保存。
自动清理的质量不在删得多快，而在该删的按期删除、该留的绝不丢，并且每次删除都有可解释记录。
