我比较认同把长期记忆做成“结构化档案”，而不是简单堆积聊天记录。实际使用中，还可以给每条偏好附上有效期和适用范围，例如“默认简洁回答，但技术方案需要详细说明”，这样更容易处理场景差异。对于相互冲突的偏好，除了按时间更新，也应区分用户明确修改和偶尔例外。最好再提供一个可查看、可纠正的偏好清单，让用户知道系统记住了什么。评测时也应关注错误偏好造成的影响，因为记错一次，往往比漏记一次更容易持续干扰后续交...

超长上下文更像“可追溯的任务档案”，而不是单纯扩大记忆。实际落地时，我觉得步骤账本和副作用记录尤其重要：读取类操作可以安全重试，发送邮件、写数据库等操作则必须绑定幂等键，并在恢复前核验外部结果。上下文装配也不宜一次加载全部日志，可以优先读取目标、最新检查点、未完成步骤和关键证据，其余内容按需检索。这样既能控制成本，也能减少旧计划和无关信息的干扰。另外，恢复摘要最好采用固定结构，并标注哪些是工具确认...

我比较认同“同时保存摘要和原始证据”这一点。只扩展上下文窗口，容易把日志仓库变成一个更大的信息堆，真正审计时仍然找不到关键依据。实践中可以把每次重要决策做成结构化记录，并让摘要直接引用对应的工具结果、审批意见和状态版本。这样日常运行可优先加载摘要，出现异常或争议时再沿引用回查原始证据，既节省上下文，也能避免摘要失真。另外，历史分支最好明确标记“实际执行”和“模拟推演”，否则重放次数多了，很容易把测...

超长上下文确实解决了“信息还在不在”的问题，但更关键的是“需要时能不能准确找到”。实际落地时，我觉得可以把依赖图与实体状态表结合起来：状态表保存当前有效值，依赖图记录变更原因和影响范围。这样遇到预算、负责人或接口规则更新时，不仅能替换旧状态，还能检查哪些后续步骤需要重新执行。另外，证据链最好设置可信度和时效标记，避免会议里的临时意见覆盖正式文档。评估时也可以专门加入互相冲突的信息，观察 Agent...

我觉得核心问题不是“记得够不够多”，而是能否明确区分当前有效状态和历史记录。实际工程中，除了维护目标版本，还可以给每次变更设置生效范围、失效条件和证据等级。例如用户临时放宽某项限制，应标明仅适用于当前阶段，避免后续被当成永久规则。 另外，目标状态对象最好与执行日志分开保存，并在每次调用工具前做一次轻量检查：当前目标是否变化、硬约束是否完整、依据是否仍有效。多 Agent 场景则需要统一的状态源和...

我比较认同“最小充分上下文”这个思路。实际落地时，除了维护结构化状态，还可以给每条关键事实增加来源、时间和状态字段，例如“已验证、待复核、已失效”，避免旧结论在后续步骤中被继续引用。阶段压缩前后也可以做一次字段级对比，重点检查约束、数字、版本和未完成事项是否丢失。 另外，校验机制最好按风险分级：普通检索允许自动纠错，涉及发布、付款或权限变更时，则强制二次验证或人工审批。这样既能控制错误传播，也不...

我觉得关键确实不是让所有角色都读完整历史，而是让它们共享同一份“当前有效状态”。实践中可以把事实表、约束清单和任务状态做成独立对象，并为每次修改记录负责人、时间和依据。角色交接时只传递必要信息，同时附上原始材料的索引，遇到疑问再回查。 另外，审查环节最好加入自动化对比，例如检查数字、日期、专有名词和版本号是否前后一致。对摘要也应保留“不确定”“仅限特定条件”等限定字段，避免压缩后语气被强化。这样...

我比较认同“双层状态”的思路。长上下文适合保留执行过程和决策依据，但真正影响业务的状态，还是要落到数据库或工作流引擎里。实际落地时，建议每次调用都生成统一的任务 ID、步骤 ID 和幂等键，并把“成功、部分成功、失败、待确认”分开处理。另外，工具输出最好只提取关键字段进入上下文，原始日志保存到外部存储并保留引用地址，这样既能减少噪声，也方便追溯。高风险操作前再读取一次外部状态，执行后进行结果校验，...

长上下文确实能缓解关键约束在多轮执行中被遗忘的问题，但我觉得更重要的是让约束始终“可见、可查、可验证”。实际开发中，可以在每次工具调用前自动生成一份简短检查表，列出权限范围、禁止操作、前置条件和预期输出；调用完成后，再用程序核对文件数量、字段完整性及状态变化。这样即使上下文里混入大量日志，也不必完全依赖模型重新阅读所有内容。另外，状态账本最好区分“已确认事实”和“临时推断”，并保留关键规则的原文位...

实际落地时，我觉得最有价值的是把“遗漏”做成可观测指标，而不只看最终答案。我们曾按子问题记录召回文档、入选片段和实际引用，排查效率会高很多。还可以给每个结论附上证据编号，并在输出前检查实体、时间、版本、例外条件是否全部覆盖。对于没有证据的项目，最好明确标为“待补检”，不要直接判断不存在。另外，测试集要保留真实失败案例，尤其是版本冲突、同义表述和表格跨页这几类，否则换模型后很容易出现局部提升、整体退...