TuriX长任务如何不失忆recent、summary、snapshot三层记忆压缩与read_files召回机制源码解析【免费下载链接】TuriX-CUAThis is the official website for TuriX Computer-use-Agent项目地址: https://gitcode.com/gh_mirrors/tu/TuriX-CUATuriX 是一款开源的桌面端 AI AgentComputer-use Agent它通过Brain Actor双模型架构驱动 macOS 完成多步 GUI 操作。当任务步骤超过几十步时上下文窗口很快就会被挤爆。TuriX 用recent短期记忆→ summary压缩摘要→ snapshot原始快照三层记忆压缩配合read_files 按需召回让长任务始终记得关键信息而不撑爆 token。下面结合源码逐层拆解这套机制。一、为什么长任务会失忆TuriX 的 Brain 模型每一步都要接收系统提示词 记忆摘要 两张截图 UI 树状态。以 32000 token 的输入上限为例十几步之后历史消息就会逼近天花板。如果简单地把所有步骤塞进上下文结果只有两种直接报错token 超限强行截断丢失早期步骤的关键信息Agent 开始失忆TuriX 的解法是分级压缩 按需召回——热数据留在内存冷数据压缩成摘要原始数据落盘成快照需要时再按文件名精确取回。二、三层记忆架构总览核心状态变量定义在 service.py层级变量内容预算缓冲区pending_recent_memory当前步骤尚未被评估不计入预算最多 20 行短期记忆recent_memory已评估的最近步骤Step N | Eval: success | Goal: …memory_budget_tokens长期摘要summary_memory多轮压缩后的高层摘要memory_budget_tokens × 4预算比例在 service.py 中配置memory_warn_ratio 0.7预警线、memory_hard_ratio 1.0触发压缩线。三层数据最终拼接为 Brain 模型的输入拼接逻辑见_refresh_brain_memorySummarized memory (compressed from earlier steps…) → Recent steps → Pending steps三、第一层pending 缓冲区与 recent 短期记忆3.1 步骤如何进入 pendingActor 执行完动作后_update_memory会写入一行Step 5 | Eval: pending | Goal: 在 Safari 中搜索航班这一行进入pending_recent_memory此时不参与预算计算避免刚执行完就被压缩掉。3.2 pending → recent 的晋升下一步 Brain 评估完前一步后brain_step会把Eval: pending替换为真实结果success/failed并把该行从 pending 移入recent_memory。同时调用_save_step_record将该步骤的 eval goal analysis持久化到磁盘文件名如step_5.txt为后续召回留底。3.3 预算检查与触发压缩每次晋升后brain_step检查recent_memory的 token 数超过budget × 1.0硬限制→ 立即调用_summarise_recent_memory超过budget × 0.7预警线→ 仅打日志提醒四、第二层summary 压缩与 snapshot 快照4.1 压缩前先拍快照_summarise_recent_memory的核心流程调用memory_llm对recent_memory做摘要无论成功还是失败都先调用_save_memory_snapshot把原始文本落盘摘要通过_is_summary_valid校验必须 ≥10 token 且比原文短校验通过 →recent_memory清空摘要追加到summary_memory快照文件的描述固定为Pre-summarization snapshot of recent memory at step Nrecord_type标记为snapshot这样 Brain 在索引中能看到它和step/info记录的区别。4.2 摘要的二次压缩summary_memory也会增长。当它超过自己的预算memory_budget × 4时_summarise_summary_memory会再做一轮更高层的压缩——相当于摘要的摘要始终保持总占用可控。4.3 快照存储位置所有快照通过 RecordStore 写入memory_snapshots/目录每个文件带 YAML frontmattername、description、type、step_id、created_at为 read_files 召回提供结构化元数据。五、第三层read_files 按需召回5.1 记忆索引每步 Brain 调用前_format_memory_index会渲染一份索引最多 50 条最新在前- step_12 (step, step 12): Step 12 (Success): 点击下一步按钮 - user_profile (info, step 3): 用户偏好靠窗座位 - memory_snapshot_recent_step_8 (snapshot, step 8): Pre-summarization snapshot of recent memory at step 8这份索引随截图一起送入 Brain 模型。5.2 Brain 发起召回Brain 提示词 明确告诉模型当索引中某条记录的描述表明它包含你需要的细节时输出{read_files: {files: [step_5, user_profile]}}代替正常的 analysis/current_state。5.3 召回执行流程BrainSearchFlow 负责拦截与执行parse_response解析 Brain 的 JSON 输出extract_read_files检测是否存在read_files字段maybe_reinvoke从 RecordStore 读取文件全文拼入 state_content重新调用 BrainBrain 拿到完整内容后输出正常的analysiscurrent_state这意味着被压缩掉的早期步骤只要 Brain 判断需要就能按文件名精确取回原始记录而不必把所有历史都留在上下文里。六、容错与断点恢复孤儿清理_sweep_orphaned_pending会回收因 Brain 调用失败而滞留的 pending 行将其标记为Eval: unknown并补写 step 记录断点恢复load_memory从memory.jsonl恢复全部三层状态兼容旧版本格式如 pending 行混在 recent 里的情况会自动迁移Token 兜底当消息窗口仍超限时MessageManager.cut_messages 按先删图片 → 再删最旧消息 → 最后截断尾部三阶段降级七、关键源码文件索引文件职责src/agent/service.py三层记忆状态管理、压缩调度、快照保存、断点恢复src/agent/prompts.pyBrain 提示词中 read_files 召回协议src/utils/record_store.py带 frontmatter 的文件级记录存储src/utils/brain_search.pyread_files 检测与二次调用src/agent/message_manager/service.pyToken 计数与消息裁剪这套机制让 TuriX 在 OSWorld 基准上保持高成功率——记忆压缩保证上下文不溢出read_files 召回保证关键信息可回溯两者结合正是长任务不失忆的核心。【免费下载链接】TuriX-CUAThis is the official website for TuriX Computer-use-Agent项目地址: https://gitcode.com/gh_mirrors/tu/TuriX-CUA创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考