TRAE Work 上下文压缩后丢失任务执行状态，导致重复读取代码文件并浪费大量 Token
问题背景
在使用 TRAE Work 执行复杂代码任务时，由于任务需要持续读取多个项目文件、分析代码逻辑和调用工具，会逐渐接近当前上下文限制（约 200K）。
当上下文达到限制并触发自动压缩后，TRAE Work 会继续执行任务，但压缩后的上下文没有完整保留之前 Agent 已完成的代码分析状态。
问题现象
在上下文压缩之前：
TRAE Work 已经完成：
-
阅读参考页面实现
-
阅读目标页面代码
-
分析 JS 数据流程
-
分析函数逻辑
-
查看后端接口
-
建立相关文件之间的关联关系
例如已经读取：
-
订单入库标签页相关代码
-
采购详情页 JS
-
drawPieChart 方法
-
warehouse 数据处理逻辑
-
后端 API
此时 Agent 已经具备继续修改代码所需的信息。
但是，当上下文压缩发生后：
TRAE Work 重新开始执行类似初始化流程：
“我将按照 develop skill 的流程执行。首先重新阅读相关文件以确认当前状态……”
随后重新：
-
查找项目文件
-
读取之前已经读取过的文件
-
重新分析已经确认过的数据结构
-
重新建立代码上下文
导致之前已经完成的分析过程被重复执行。
核心问题
当前上下文压缩机制只保留了部分对话内容，但没有有效保留 Agent 在任务执行过程中的：
-
已读取文件记录
-
文件之间的关联关系
-
已完成的代码分析结果
-
已确认的数据流
-
当前任务执行阶段
-
已做出的技术判断
因此压缩后 Agent 无法继承之前的工作状态。
实际影响
1. Token 大量浪费
大量 Token 消耗在：
-
重复读取同一个文件
-
重复搜索代码
-
重复分析相同逻辑
而不是用于完成当前开发任务。
2. 长任务执行效率严重下降
对于大型项目：
-
文件数量多
-
业务逻辑复杂
-
涉及多个模块
一次上下文压缩可能导致 Agent 重新进行一轮代码探索。
任务越复杂，浪费越明显。
3. Agent 工作连续性被破坏
正常情况下：
读取代码
↓
理解业务
↓
定位修改点
↓
实施修改
应该持续推进。
但当前表现：
读取代码
↓
理解业务
↓
上下文压缩
↓
重新读取代码
↓
重新理解业务
↓
继续任务
导致 Agent 像“失去记忆”一样重新探索项目。
问题本质
1、上下文容量限制太死了
2、上下文压缩后，TRAE Work 没有保存 Agent 在任务执行期间形成的工作状态（Task State / Working Memory），导致压缩后的 Agent 无法延续之前已经完成的代码理解过程，只能重新扫描项目建立上下文。
