如果maka tui是这样的，是不是很酷 demo使用 nsh.dev 编写，在我的fork添加了tui backend。在支持kitty sixel iterm2 图形协议的终端上可以显示成这样，不支持的终端回退到 unicode 字符。原理也比较简单，就是利用nsh的gpui后端生成可提取的像素，然后注入到nsh tui后端即可

发现不少小伙伴很好奇我是怎么用 Mac 来开发Windows软件的，以及Windows软件现在一般用什么技术栈来实现，刚好有空，来和大伙随便聊聊关于多客户端下技术选择的思考以及我的一些想法。 以下是第一篇，给大伙介绍介绍各种桌面、移动端开发技术的选择以及对应选择的思考。 做过前端客户端的小伙伴应该都知道，这些年端的开发一般是这三条路。 第一种最简单方便的是，直接写 Web 代码，塞到浏览器就能跑，包括早年的 PhoneGap、Cordova 就是把网页塞进一个原生壳里，然后提供一些bridge的能力让js可以调用到一些原生的能力，比如唤起手机摄像头这类的 Web 不好做的事情。 第二种是跨端开发，也就是好多年前大家经常听到的一码多端，当时移动端有 React Native、Weex 这一类技术，当时主要是为了解决 Web 性能差的问题，一份代码同时打包出 iOS 和 Android，这里国内大厂使用跨端技术还有一个非常大的原因就是动态化和热更新，讲的土一点就是可以绕过商店审核直接下发新页面，这也是国内跨端在当时移动互联网高速发展时特别流行的重要原因。 桌面端大家熟悉的就是 Electron，大家熟知的现在不少AI桌面端、VS Code、Slack 是用这个做的，代价是相当于每个应用都自带一份 Chromium 和 Node.js，安装包一百多 MB，内存也占得多。但好处是在 Chromium 渲染引擎的统一下能够很好的保持多端的展示一致性，加上里面写的代码非常好写，后续不少桌面的速成就会用这个技术。 跨端后面也慢慢延伸出更多有趣的解决方案，类似Flutter 自己实现一套渲染引擎，早期靠 Skia，现在换成了自研的 Impeller 渲染引擎来保障多端一致和性能效率的均衡，包括桌面端上老牌的 Qt，和 Flutter 一样自己画界面。 这两年桌面跨端也出现了用 Rust 写的 Tauri、Go 写的 Wails，他们和 Electron 不一样的地方就是，他没有塞一个Chromium进去，而是使用的系统自带的 WebView，包会小非常多，但是整体还是基于 Web 这一套研发思路和对应实现语言去进行桥接交互，但是由于系统 Webview 每个平台不一样，Windows 上是 WebView2，Mac 上是 WKWebView，Linux 上是 WebKitGTK，所以多端显示的一致性反而不如 Electron，还是要写兼容代码。所以这种情况下，即使 Electron 很大内存占用也不低，还是会被选择更多。 第三种是原生开发，也是没有 AI之前，大家觉得开发难度很大的一种方式，特别是之前的苹果系使用的 Objective-C，Android 系使用的 Java、Windows 系 C、C#，均是我认为需要科班花非常多时间去学习、看书、手编代码，要想做得好，需要花大量时间研究对应的系统底层原理，能够方便你写出相比普通研发性能更好更稳定的代码，在我看来是前期投入大，后期用户很享受的技术，我当时17年时候刚工作 2 年多的时候，职业发展比较爽的一个很大原因是我抽了半年时间学习 Objective-C 和 iOS 研发，让我自己本质前端的工作提前往跨端方向走了，刚好可以解决一些这两个工种结合的不能解决的难题，也是我当时做一线开发非常快乐有趣的时间。 等到后面 Swift + SwiftUI、Kotlin + Jetpack Compose、C# + WinUI 3 慢慢出来成熟后，这些原生端语言的写法也慢慢像高级语言靠齐，也更易写了，声明式代码更短、更好读了。但是在国内完全被 React Native、Flutter、Electron 的广泛使用被盖过去了，导致开发者不多，生态发展完全靠官方推动，从而出现了出活很快，但是大家普通感觉怎么用久了卡卡的缘故的一个很大的原因，同时还占大头，而且想迁移到原生假如之前架构实现不好大概率只能重写，完全不能复用，实现得好比如说你把业务逻辑早就抽出，类似 Kotlin Multiplatform 这类方案把业务逻辑共享、界面各写各的原生，算是第四条路，也是最近几年的趋势。 聊到这里大家应该大概明白了，这里也有一个不可能三角，就是研发效率、体验、性能这三者，选择 Web 是多效率少性能，选原生是多性能体验少效率，选跨端就是刚好是这三者取一个中间，做得好容易都占，做得不好，容易没有一边占到好处的尴尬局面。 那么在 AI Coding 写代码已经不是问题的情况下，我们应该选择啥技术呢？很多时候也取决于你的场景，比如你就是一个 Web 场景的浏览、点点按钮、阅读这一类 Web1.0 阶段的东西，那还是非常建议直接 Web 技术来弄；假如你需要调用到系统底层的能力，或者需要操作更顺手更好分发，以及本身就是一个应用的场景，我还是非常建议使用原生技术来实现，这样可以第一时间享受到系统官方本身的众多调优，以及最原生的交互效果、最低的内存占用，加上 AI 让写两份原生代码的成本大幅下降，三角形的效率那一边被补上了，只是两个平台的调试和验证变成了新的成本，这里正是人需要重点做的事情了。 当然假如实在技术选型不那么重要，工作量非常之大，以及业务效果远大于技术体验选择，选择跨端技术也是可以的，这样快，迭代发布也快，可以第一时间让你的用户收到你的最新的特性更新。 不过说到底，技术是给业务服务的，最终还是需要往解决问题方向走，好比抢演唱会门票，大家不会关注你这个客户端怎么这么卡，只会关注我用你能不能抢到票，即使你做得十分顺畅，但是抢不到票也是会被骂得很惨，技术栈的选择在这里就选的好变成了锦上添花的工作，最终还是需要优先保障用户的最真实需求的解决，然后做好这里，再去想，我如何让用户体验更好，接下来才是考虑我是否需要使用原生技术来实现。 一下子居然写了这么多，明天继续来聊，想给大伙来分享我是如何在 Mac 上搭建了一套研发 Windows 原生软件的环境，以及我对于 Windows /Mac 多端研发上的一些踩过的坑以及最佳实践，哈哈，欢迎交流，我们来聊聊不问 AI 自己脑袋里面的技术栈选择，挺有意思。

🚀 Introducing DeepInfer, our in-house inference framework, now fully open source! Powering DeepSeek-V4.1-Flash at scale with high throughput and low latency. We’re sharing our production stack to help the community lower compute costs, reduce energy use, and make AI more affordable. 🔗 github.com/deepseek-ai/DeepI… 1/4

预告「未来硅世界」最新一期，邀请3 万 Star开源项目 opencli 作者卡比 @jakevin7 锐评当下顶级模型和 Personal Agent使用感受，分享AI Coding开发经验。 朋友说，跟卡比聊天像听AI 圈脱口秀，哈哈哈。 时间本周六晚 20:00，届时打开飞书加入直播间互动。 vc.feishu.cn/j/108720872 或关注 WaytoAGI 微信视频号观看。

现在几乎主要的 Agent 都是用 Electron 方案，Codex、Claude...一旦同时跑的 Session 和工作多了，性能消耗和资源占用都很大，尤其是 Web 渲染的各种动画。 我们在把整个 Maka 重写为 Rust + GPUI。为未来几十/上百/上千个 agent 并行做好准备。 已经几乎可用了： github.com/apache/maka/tree/…

How do always-on, proactive agents like @Bot work? Watch my lecture at Stanford CS146S: 2:35 How we got here 6:13 What changed in the models 10:06 Inside an always-on agent 18:07 The harness 27:26 Context engineering 34:26 Where this is going