浅浅地试了试 EvoMap,说说我的看法
EvoMap给我的第一印象,是一个解决方案库,里面是一个个针对具体问题的解决方案。
问题到底有多具体呢?
可以是做一个复杂的系统,也可以是针对应用程序进行冷启动加速、OOM问题修复,甚至是生成代码规则等等。
解决方案有有什么呢?
可以是一个SKILL,也可以是代码片段,或者一段Prompt等等。

在三年前我有个类似的想法,想做一个针对Java程序员的一个解决方案的社区。可以分享系统设计、应用运维、问题排查的解决方案。
当时还没有生成式AI(或者说还没火),查问题还得到搜索引擎,但是由于查询的输入限制,往往只能拿关键字来搜索,然后自己一个个去翻,很麻烦。
而由于,依赖的版本不同,你找到的解决方案也不一定能解决当前的问题。
同时,在搜索引擎时代,需要我们理解和判断的地方太多。各个SDK的版本与兼容性,还得逐一排查,有时候还得看看源码~
而当时我放弃的原因有两个。
一个是没法判断解决方案的效果。因为一个解决方案到底有没有效果,当时只能由人来判断,方案一个个去review,有时候还得亲自设计环境来验证,这显然是不可能的事儿。
另一个是社区的奖惩机制没想明白。既不能让人家用爱发电,还得让大家积极的分享、维护自己解决方案,我当时还没想明白怎么做。
那,为什么现在又可以了呢?
Agent时代,在解决SDK兼容问题时我们的认知负担大大降低了。那些需要一个个地方排除的问题,不需要我们亲自动手,也不需要我们去阅读源码。Agent可以直接执行,就能有结果。
而EvoMap也想明白了奖惩机制设计。
它通过发布悬赏来激励大家,获得的奖励可以用来兑换会员以获得语义搜索以及更多的悬赏发布次数。同时,普通用户搜索解决方案也是免费的。
不过我觉得有几点迷惑。
首先,简单问题肯定不需要使用到它,但是这里怎么判断简单还是不简单?
我认为比较直接的办法是让Agent直接解决,半小时还解决不出来就可以试试它。但万一使用EvoMap之后,它半小时内也解决不出来,那这个问题通过EvoMap解决的效果我就不能判断出来了。
因为两者都超过半小时,前者我没有继续去验证了。我想着的是解决问题,而不是对比两个方案谁更好。
它的价值我还是看不懂。
或许当你真的拥有上百万的agent时,通过它沉淀的经验来提效很ok。至于现在,对我来说不同agent之间遇到的问题大都不太相同,我还无法直观地体会实际的价值。
更多推荐



所有评论(0)