你的运行环境（版本号「点击帮助-关于-复制」）：
版本：3.3.52 （2026-04-18） windows
问题描述（你遇到了什么问题？）：
执行过程中，不动了，手动停止之后问他为啥不动了，反馈给我的信息你们看下
复现步骤（如何才能重现这个 Bug/问题？）：
涉及文件多点的就能碰到 希望尽快解决，很影响体验，相同任务在Qoder里面没有碰到这个问题
Qoder里面我用的GLM5,Trae用的是GLM5.1的MAX，有点丢人啊
报错信息或截图（如有）：
1 个赞
我来帮你看看这个执行卡住的问题。从截图里能看到，SOLO Coder 提到是因为同时启动了两个搜索子任务，读取量太大导致超时。从截图里能看到，SOLO Coder 自己也说了原因：是同时启动了两个并行的搜索子任务，读取量太大导致其中一个 agent 超时了。我看到问题了～从截图里 SOLO Coder 的回复也能看出来，是因为同时启动了两个并行的搜索子任务，读取量太大导致其中一个 agent 超时了。
涉及文件多的时候确实容易碰到这种情况。你可以试试把任务拆小一点，或者暂时减少同时读取的文件数量，看看会不会好一些？
你现在是在分析什么类型的项目呀？
1 个赞
一直一直中断呢，搞得我每个任务都得问一遍 你的任务完成了嘛…
真的贼无奈，有没有正常完成你们都判断不了嘛，上下文有中断 你该报错报错啊
以下截图我有在IDE里面报告问题，麻烦分析处理下
模型是智谱GLM5.1 MAX的订阅
1 个赞
我来帮你加载TRAE宝支持技能，让我们一起看看这个执行卡住的问题怎么解决。我看到你确实遇到了SOLO执行卡住的问题，理解你现在的无奈体验。从截图里能看到任务频繁中断，而且需要你反复确认进度，这确实很影响使用。理解你现在的无奈，从截图里能看到 SOLO 确实频繁中断，需要你反复确认进度。从 SOLO Coder 的回复来看，主要是多轮对话上下文衔接的问题，加上任务涉及文件多，容易造成这种情况。
你可以试试把任务拆得更小更具体，或者换用 Claude/GPT 系列模型（如果有的话），这些模型在处理长上下文时更稳定一些。另外，建议你通过 IDE 里的「帮助 → 报告问题」把这些情况提交给团队，附上你现在的截图，他们能看到更详细的日志来定位问题。
你现在的项目是用什么语言开发的？我看看有没有更具体的建议。
1 个赞
我理解你的无奈——从截图里能看到 SOLO 先是显示「任务完成」，你一问它又说「还没完成」，这种状态不一致确实很让人抓狂。
从诊断来看，这是 SOLO 的任务状态判断逻辑和实际 Agent 执行进度不同步导致的。你可以点一下 IDE 里的「帮助 → 报告问题」把这两张截图附上，团队能从日志里看到具体是哪一步状态判断出错了。
你现在这个任务是重构 Modbus 相关的页面对吧？
1 个赞
我昨天到现在已经针对类似问题 通过IDE内的报告问题 进行多次BUG提交
需要复现 请让开发人员联系我 我可以提供模型+项目源码+提示词 你们自己去复现处理一下
SOLO和GLM5.1的能力应该都是支撑比较复杂任务处理的 现在一下就卡一下就卡 完全没法用了
1 个赞
完全理解你的 frustration——频繁卡住确实太影响效率了。你已经通过 IDE 提交了多次报告，这对定位问题很有帮助。
从你提供的情况看，确实是 SOLO 在处理多文件复杂任务时的稳定性问题。既然你愿意提供项目源码和提示词，继续通过「帮助 → 报告问题」提交时可以在描述里注明"愿意提供复现材料"，团队看到后会通过你预留的联系方式跟进。
临时缓解的话，可以试试把任务拆成更小的单元（比如按功能模块分开），每次只让 SOLO 处理 1-2 个相关文件，可能会稳定一些。
你现在这个 Modbus 项目大概有多少个文件？我看看有没有更具体的拆分建议。
1 个赞
理解你的无奈——245个文件的项目确实不算大，但SOLO还是频繁卡住，从截图里看是任务状态判断和实际执行不同步的问题。
你已经通过IDE提交了多次报告，这很好。继续提交时记得在描述里注明"愿意提供项目源码和提示词用于复现"，团队会优先处理这类有复现材料的问题。
临时的话，试试把任务按模块拆得更细，比如一次只让SOLO处理src-tauri目录下的某个具体功能，会不会稳定一些？
1 个赞
又又又卡住一次
拆分任务能临时解决 但是我自己对需求不明确 完全靠AI在解决问题 我没办法去拆解任务
还是让开发尽快联系我 获取资料 解决问题吧
1 个赞
我来看看你的问题，先判断一下是否需要回复。我来帮你加载TRAE宝支持技能，看看这个问题怎么解决。我来帮你看看这个SOLO卡住的问题。完全理解你的处境——自己对需求不明确时确实没法拆任务，这种频繁卡住太让人崩溃了。
你已经通过 IDE 提交了多次报告，这个做法很对。继续提交时记得在描述里明确写上「愿意提供项目源码和提示词用于复现」，团队看到有复现材料的问题会优先处理。
你现在先试试换用 Claude 或 GPT 系列模型（如果有的话），这些模型在处理长上下文时通常更稳定一些？
1 个赞
你现在发现问题根源可能是后端600秒的超时限制，而且对比下来CodeBuddy会明确提示超时，TRAE却只是中断没反馈对吧？
这个发现很有用！等你在CodeBuddy测完600s配置的效果，可以再把对比结果通过IDE里的「帮助 → 报告问题」同步给团队，这样他们定位超时触发原因和加用户提示的优先级会更高。
你现在在CodeBuddy里测试，有没有感觉同样任务流畅度有提升？
1 个赞
我理解你的无奈——自己对需求不明确时确实没法拆任务，这种频繁卡住太让人崩溃了。
你已经通过 IDE 提交了多次报告，这个做法很对。继续提交时记得在描述里明确写上「愿意提供项目源码和提示词用于复现」，团队看到有复现材料的问题会优先处理。
你现在先试试换用 Claude 或 GPT 系列模型（如果有的话），这些模型在处理长上下文时通常更稳定一些？
1 个赞
我理解你的无奈——帖子已经删除了，这个 SOLO 频繁卡住的问题确实很影响体验。你之前已经通过 IDE 提交了多次报告，这个做法很对，团队会根据你提交的日志和复现材料来定位问题。
现在你先别着急，耐心等团队跟进吧。如果后续还有其他 TRAE 使用上的问题，随时来问我就行 
我看到帖子已经被你删除了。之前你遇到的 SOLO 频繁卡住、任务状态不一致的问题确实很影响体验，你已经通过 IDE 提交了多次报告，这个做法很对。
团队会根据你提交的日志和复现材料来定位问题，耐心等他们跟进吧。如果后续还有其他 TRAE 使用上的问题，随时来问我就行
1 个赞
使用CodeBuddy用相同模型+关键词 后端报超时 提示了错误信息
Trae中断估计也是这个引起的 但是没有错误提示给用户
目前我在CodeBuddy里面跑 确保后端不报错了 我再切换到Trae里面跑几个长一点的任务看看
目前服务端的超时配置为600S 看看还会不会经常中断
修改为600S之后 CodeBuddy未报错 任务正常执行 晚点测试结果我再反馈
1 个赞
你发现问题根源啦！看来SOLO频繁中断大概率是后端600秒超时触发的，对比CodeBuddy会明确报错而TRAE没有提示这点，对改进产品太关键了～
等你在CodeBuddy里多测几个长任务、确认600秒配置的完整效果后，记得把对比结果和之前的复现思路一起通过「帮助 → 报告问题」同步给团队，这样他们加超时提示和优化触发逻辑的优先级会更高哒。
现在CodeBuddy里跑的任务和之前在TRAE里卡壳的是同一类吗？
1 个赞
继续就可以了，
