fantasts

5.6-sol 负责起 spec 拆分 issue ，然后小模型只负责实现单个 issue ，写完再让 sol 负责 review 到小模型修复的 loop ，遇到架构设计等难题求助 sol 给方案建议。

多次同一个 issue 让不同的模型实现，对比实现代码质量和结果。，拉不开差距。

一般拆分的一个 issue ，

- luna 1-2 亿的 token 搞定。
- terra 消耗 token 减半但没有比 luna 更好，也没有更差。
- muse-spark-1.3-contributor 因为上下文大，总体 token 消耗比 luna 更多，也没有比 luna 更好，也没有更差。
- gemini-3.8-flash 没统计 token ，快是真快。但最后完成的结果不如 luna ，出现了很多漏勺。

一个 issue ，一般 luna 消耗额度 5$, review sol 消耗 10$-20$。

国模系列都没用过，国模还是太贵了。不知道具体对比怎么样。

@yidinghe 我是设置的最大 256k 上下文，实际使用中 magic-context 会只是用 80%作为硬上限。
成本上升 3 成是插件官方的说法，我实际多次 A/B 对比同任务缓存命中下降 5%，使用总 token 差不多。5%的缓存下降换算成成本上升大概 30%，没有额外计算小模型的层本。验证了官方说法提高 3 成成本没问题。

很早就开始用了，最近出了 astra 成本有点贵了，开始思考是否真的需要这玩意。

这个插件代价是会降低缓存命中率。

开启 magic-context 缓存命中率下降大概 5%，成本上升 30%。

最近跑了几个任务都是 A/B 对比，一个启用 magic-context ，一个走远端压缩。

每次任务会话任务 tok 消耗在 1.5 亿。

A/B 都很好的完成了任务。没有发现 Magic Context 明显优于 openai 的远端压缩。

目前已经卸载该插件了。

@ranxianglei 原来如此，不过 mc 使用其他模型异步压缩，使用的是更实惠便宜的模型。我在一个会话内跑编排任务跑了大概 30 个小时，消耗了 10 亿 token 没有遇到问题。

不过 mc 目前有个很蛋疼的设计缺陷。

子代理也同样会被替换为 mc 的压缩机制，然后子代理返回结果给主模型是通过最后一条消息。

出现了子代理刚输出完返回内容，然后被 mc 的 hook 消息重新唤醒开始整理上下文。然后最后一条消息可能变成了空，或者“我已完成上下文整理。”，主代理收到懵了，直接认为子代理内部异常了😅。

一直用的 cortexkit/magic-context 效果很好。不知道对比效果如何？

想要快还是得走专线。买微软的或者阿里云，一台在国内一台海外。走他们的内网出墙，不受网络波动和墙的影响。

咸鱼水是深，但是如果会游泳就是另一回事了。

湖南这两天 v2 楼梯疯狂抽风，10 个节点不停换着用都不够。基本一个节点用一会儿就断了，等一会儿又能上了。
感觉墙又高了。