上下文可以丢，项目事实不能丢：长期智能体开发真正要保存什么
一个缺陷昨天已经被测试通过并关闭，今天修改了另一段代码，它又出现了。这里没有任何矛盾：昨天的验收属于昨天那个候选版本，不属于“这个项目从此永远正确”。
这也是长期智能体软件工程最容易被上下文窗口掩盖的问题。模型可以记住计划、最近失败和测试结果；但调用一结束，这些记忆就可能消失。下一次调用如果只拿到代码，它需要从实现反推未完成义务；如果只拿到一份文字摘要，它又可能不知道那份“已经通过”的证据到底测试了哪个版本。
因此，真正需要跨越会话持续存在的不是全部聊天记录，而是项目事实：候选版本是谁、制品是什么状态、哪些证据针对哪个版本成立、下一个角色凭什么继续工作。
对话连续，不等于项目连续
把更长上下文当作长期工程的主要解决方案很有吸引力。上下文越长，智能体越容易看到过去发生了什么，重复探索也可能减少。
但上下文解决的是“模型现在能看到什么”，不是“系统能证明什么”。一段对话即使完整保存，也不能自动回答四个问题：
- 哪个精确代码版本被测试？
- 当时哪些行为被验证，哪些问题仍未解决？
- 后续修改是否触碰了那些验证结论依赖的部分？
- 当前负责规划、开发或验收的角色，是否重新获得了正确的权限与输入？
如果这四件事只存在自然语言回忆里，恢复后的智能体很容易把“以前有人说通过了”误读成当前版本仍然通过。
一项长期软件实验把计划、开发和验收拆开
同日研究对象分析了 Harness-of-Harness（长期软件智能体组织实验框架）主研究。它把项目规划、开发和质量验收放在独立调用中执行，并让制品状态与证据状态分别跨循环持续存在。
研究报告在三个基准系列上，对三个框架—模型组合进行多轮迭代；三轮后的平均相对提升为 52.25%，其中被报告的最高相对提升为 82.86%。这些数字只属于研究所测试的配置，不能直接解释为所有软件团队都会获得同样的生产率提升。
更值得关注的是它的多日案例。项目运行超过 70 个循环，持续保存版本化代码、问题单和证据历史。到第 70 个循环，记录中的 81 个问题有 65 个关闭、16 个未解决，并有 17 个曾经关闭的问题因为后续变更导致回归而重新打开。
这 17 个重新打开的问题说明了一件很朴素但重要的事：验收具有版本新鲜度。
项目事实至少包含四种不同身份
从这组证据可以抽象出四类不能被一份“上下文摘要”互相替代的事实。
第一是候选身份。它回答“正在计划、修改、测试或接受的，到底是哪一个精确版本”。没有候选身份，测试结果只能证明某个模糊的“项目状态”。
第二是制品状态。代码、配置、资源和元数据共同定义候选本身。它告诉后续角色“现在有什么”。
第三是证据状态。已验证行为、未解决失败、测试观察、已知失败路径和验收边界回答“关于这个候选我们知道什么”。代码本身无法完整保存为什么一个问题仍然开放；证据如果没有候选指针，也无法证明观察属于哪个实现。
第四是角色权限。规划者、开发者和验收者每次重新进入工作时，都需要明确输入、权限和输出合同。恢复会话不应自动继承上一角色的所有权力。
这四类事实共同构成可恢复的项目真相。它们不要求保存每一个推理令牌，也不要求轨道机替智能体决定怎么写代码；确定性边界只需要固定身份、权限、必需制品和状态转换。
“开发完成”和“候选通过”必须是两件事
开发者说“我做完了”是一项实现声明。候选被接受则是另一项事实：某个独立验收角色或机制，对一个固定候选执行了规定观察，并产出了可核查证据。
这两个事实如果被合并，长期工作会产生一种危险的自我继承：实现者不仅修改代码，还把自己的信心写成最终完成状态；下一次调用再把这个状态当作既定事实继续向前。
独立验收并不必然要求不同模型厂商。独立调用、冻结候选输入、不同权限和候选绑定证据，已经能建立有意义的执行边界。但如果开发和质量验收使用同一模型家族，它们仍可能共享盲点，所以“角色分离”只能改善证据卫生，不能自动证明统计独立。
对高风险属性，仍可能需要不同模型、确定性测试、人类复核或外部评价。
变更以后，旧证据必须回答“还新鲜吗”
长期项目不能把“已关闭”理解为永久属性。更准确的状态是：某个问题在某个候选版本上，根据某组证据被关闭。
当后续修改影响这些证据依赖的行为时，系统应该重新判断新鲜度。最粗暴的方法是任何代码变化都重跑全部测试；更有效的方法则是让证据记录它依赖的模块、接口、配置或行为，再按影响范围失效和重跑。
这也是为什么持久证据不能只保存“通过”。它至少还需要候选身份、观察对象、执行环境、证据路径和新鲜度依赖。否则系统只知道“以前绿过”，却不知道这盏绿灯现在是否仍然有意义。
更长上下文仍然有用，但它不是事实源
这里并不是说上下文窗口不重要。更长上下文可以让智能体更快理解历史、减少重复探索，并保留难以结构化的局部理由。
但它适合作为推理材料，而不是最终权威事实源。项目恢复应该先恢复候选、义务、证据和权限，再把必要历史送回模型；顺序反过来，就会让模型的叙述承担本应由持久状态承担的责任。
同样，保存更多状态也不是目标。最小检查点只需保留下一次决定真正需要的事实：精确候选、未完成义务、有效证据、失效条件、重要失败路径以及下一角色权限。没有必要把每一次内部推理都变成永久档案。
证据边界与开放问题
当前证据来自研究作者报告的三个基准系列和一个大型多日案例。它说明这种分离式架构在所测试设置中能够改善结果并保留可恢复历史，但不能由此推出生产正确性、崩溃一致性、外部副作用的恰好一次执行、安全性或对所有软件任务的普遍迁移。
仍待回答的问题包括：一个最小验收包究竟需要保存多少内容；如何自动识别一次代码变更应使哪些证据失效；什么情况下角色分离已经足够，什么情况下必须增加模型或机构独立性；不可逆外部操作怎样与候选版本一起恢复；以及怎样让检查点足够小，又不丢失避免重复失败所需的决定事实。
长期智能体开发最终需要建立的，不是一段永不结束的聊天，而是一条更稳定的关系：上下文可以随调用消失，候选和证据的身份不能消失；实现可以不断变化，验收必须知道自己验的是谁。
证据与引用：