算笔糊涂账贰!

上次不是很严谨,这次work vs work,首先声明下,上次测试之后,我对代码做过一些优化,因此所有的任务需要重新跑。 此次运行workbuddy 的时候,默认启动了多agent 进行并行代码检索,且wordbuddy 输出了markdown。本着一视同仁的原则,我对trae work的提示词如下: 扫描代码库,给出GA 算法的完整实现方式,以及是如何配合其他模块实现进化,要详细阅读,开启多agent来做。最终输出为一个markdown

workbuddy 的提示词: 扫描代码库,给出GA 算法的完整实现方式,以及是如何配合其他模块实现进化的

下图 workbuddy中 ds v4 flash 0731

积分消耗&& token 计算

TRAE work ds v4 正式版

workbuddy 的积分消耗 17.72 token 数: 约103.1k
Trae 积分消耗: 35.35 token 数未知

存在差距的原因:

  • 内置提示词差异
  • agent 间协作有待改善
  • 上下文严重不足,期间trae 进行过一次上下文压缩。

附:

裁判对两个AI 生成的文档对比,裁判是GLM5.2

GLM 统计的GA 模块的代码量,这并非小任务。

时间维度: workbuddy运行时间 5min54s, trae 运行时间是 5min 22s

人为评判:我的提示词要求是对GA算法模块整个梳理,以及如何与外部协作,显然Trae 有些偏题。

Trae 的优点在于 变异概率表、参数范围、时序图这些深度内容 的梳理总结,这回合如果不看积分消耗,算是有来有回吧。当然如果能弥补上下文短以及hint cache 的问题,我相信在长任务的注意力上效果会更好。

大家请理性讨论,不要拉踩哦

1 个赞

完成时间差了2分多钟? 有点诡异

不好意思,忘了写时间了,感谢提醒。 workbuddy 是 5min 54s , trae是 5min22s , 差了30s

1 个赞

trae的上下文限制真的影响很大,目前也没有消息说开放,唉,可惜

快了,快了,呼声大的话,应该就要来了 :grinning_face:

然后trae的上下文压缩还有很大的优化空间,压缩后完全丢失了上下文一样,AI会又重新读取文件,可以看这里 TRAE Work 上下文压缩后丢失任务执行状态,导致浪费大量 Token

是的,这个影响确实蛮大的,尤其是压缩时机,我合理推测,这次任务偏移实际预期,一方面是上下文不够长,另一方面就是消息压缩之后失真

200k 和 1000k 的context length影响了,坐等升级,快了估计