目前主要的 feature 就是可以直接跑本地大模型！（默认 Qwen3-4b)
- 不需要花钱买 API
- 不需要 docker
- 不需要 ollama
memory 层面做了内置的 graph database ，team 方面使用的 tree 状的 agent dispatch 模型，还有一堆其他乱七八糟的设计..
本来想做到完美再发出来，但是优化实在是无底洞，还是想边交流边做
This topic created in 69 days ago, the information mentioned may be changed or developed.
 |
1
Eddiegaao Mar 11
什么应用场景？ openclaw 好用的原因不就是因为有一个强有力的模型才能支撑它的牛逼之处啊，用 4b 本地模型 连个翻译都够呛，还跑 agent ？？？
|
 |
2
udtrokia OP 其实大部分的日常场景都可以处理的，机器好的话也可以跑 35B, 122B ，所有的开源大模型都可以跑，远程的也是可以支持的
|
|
3
udtrokia OP 用的最多的 kimi ，如果机器允许的话，也是可以本地跑的，其实没差的，openclaw 能做的 openwalrus 都可以做
|
|
4
udtrokia OP 不过感觉应用场景这个确实，有个具体的东西才好讲，不然太抽象了就很飘了，我目前打算的最先开发的几个用途：
1. 用 openwalrus 运营 discord channel ，记录群里面的人的问题，因为 walrus 支持 graph memory ，所以直接把用户碰到的问题记录并且分类好 2. openwalrus 运营 twitter ，通过 browser 帮忙自动发帖运营，绕过 twitter 的 API call ，包括可以通过 browser 调用 grok 来去优化检索 3. 周期性的行业 research ，比如我现在做的这些 blogs ，https://openwalrus.xyz/blog?tag=research ，agent 去检索总结效率是非常大的 我目前主要是运营需求，@Eddiegaao 老哥你有啥需求我看看我的架构能不能解决？ |
 |
5
hewitt29 Mar 11
能本地搭大模型的，还需要你来帮忙建龙虾池？
|
 |
6
Hilong Mar 11
本地跑还是得用 N 卡，我的苹果的 Prompt 预处理（ Prefill ）速度很慢，龙虾的上下文又很长，基本一个消息要几十秒才能回复
|
|
8
udtrokia OP @Hilong 如果是 apple chip 现在的 metal batch prefill 应该是和 Nivia 不相上下的吧，其次应该就是 memory 设计和 compaction 设计的问题：
1. memory 的问题我用 graph memory 解决了，每次 compact 不仅 summary 还会 vector db 索引相关的记忆 2. compaction 这个我昨天还在思考，如果是子任务的话，有没有可能使用 leader 来 compact members ，结果会更精准一些 3. 第三个效率补充就是，在思考如果长时间没有对话，后台其实也可以周期性的自动 compact 一下，我感觉豆包的处理应该就是这样的 https://openwalrus.xyz/blog/context-compaction |
|
9
udtrokia OP 最理想的情况下，肯定是希望用户对 compact 没有任何感知的，包括我可以并行 compact ，这个豆包真的是感觉体验上绝了跟别的产品比
|
 |
11
shikidong Mar 12
@Hilong mac 的话你看下这个 https://github.com/jundot/omlx
|
Select Language