> ## Content Index
> Fetch the complete content index at: https://nigzu.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# 记首次 .NET 跨平台开发——Deepseek Harness Desktop
- URL: https://nigzu.com/csharp-dotnet-avalonia-deepseek-harness-client-ai/
- Published: 2026-08-16T22:53:02.000Z
- Updated: 2026-08-16T23:20:17.000Z
- Author: 宁嘉
- Tags: 砖工技术

史上增长最快的开源 Agent 框架 DeepSeek Harness（DSH）给我带来了 DIY 的乐趣。官方给的"命令行 + 网页"这套组合能用，但不方便用。我决定给它做个桌面客户端 [dsh-ng-desktop](https://github.com/code-gal/dsh-ng/tree/main/dsh-ng-desktop?ref=nigzu.com)：点击即开、托盘常驻、开机自启，界面直接内嵌原来的 Web 页面。

此前我就想体验.NET + Avalonia 开发桌面软件，这是一个很好的尝试契机，Avalonia 主打跨平台，配合 Native AOT 还能编译出精简安装包。我脑子里默认了一个等式：

> 优雅的语言 + 跨平台框架 + 智能体 = 高效的组合。

实践证明，这个等式所忽略的，是大语言模型这个超级做题家碰上冷门出题时的幻觉。

## 一个暴论和三个原因

一句话：

> 在 AI 编程的时代，用 Avalonia 做跨平台客户端并不合适；.NET 可能更适合服务端，Avalonia 可能更适合从传统 WPF 迁移的项目。

这里针对的是"AI 开发跨平台客户端"的具体场景，框架有它擅长的领域，关键变量也不是语言，而是有多少公开语料、生态里有多少现成的轮子。

在细节上踩坑多了，这些得到验证：

### 一、数据飞轮：AI 擅长"热门"，“冷门”容易出错

模型的训练数据，大量来自开源项目、社区问答和公开代码。像 TypeScript、Python、Go 这些开源世界的绝对主流，语料浩如烟海，模型对它们的常见写法和最佳实践了如指掌。而那些偏企业级的组合，语料就稀疏得多。

我用的这套 `.NET + Avalonia + Native AOT + macOS + WebKit` 冷门度是相乘的。AI 面对它时没有多少现成经验可抄，就容易"想当然"：忽略平台差异、套用它在别的栈里的直觉、犯一些很低级的错误。我换过好几个模型，结论都一样：不是模型不行，是语料密度不够。样例越少，幻觉率越高。

### 二、框架与平台不完善：生态需要解决的问题被我碰上了

跨平台框架存在的意义，本该是替开发者挡住平台差异。但真做下来，Avalonia 和 .NET 在这件事上的抽象并不完整，不少本该由框架或生态兜底的细节，直接漏到了我手上。

举两个例子。一个是 WebView 的数据清理：Avalonia 没给现成接口，只能额外写个 Objective-C 辅助程序去清 WebKit 的数据。另一个是单实例：客户端要保证只开一个，用 .NET 的命名管道实现，结果在 macOS 上它被映射成系统域套接字，路径有个 104 个字符的长度上限，GitHub Actions 的临时目录路径一长就直接溢出。

这些是框架没帮你做，你碰上了就得去调研和验证一堆本不该你操心的平台细节。

### 三、成熟方案缺失：没有现成库，只能自己摸索实现

热门生态里，很多坑早被人踩过、封装成了库。比如 macOS 下 GUI 程序从 Finder 启动时拿不到用户的 shell 环境变量、找不到 Node——这在 Node 生态里有 fix-path 这类现成库，一行就能解决。但在这个生态里没有，只能自己实现一段扫描逻辑，去 nvm、volta、fnm、asdf 各种版本管理器的目录里一个个翻。

遇到问题找不到直接可用的库，只能自己从头写；自己写，就意味着边界情况和平台差异全都自己扛。

## 信心与成本决定开发体验

当智能体花了十几分钟乃至几十分钟调研仍卡在一个步骤上的时候，看到状态栏里的套餐额度在以肉眼可见的速度减少，这是很影响开发体验的。

**信心**，来自两件事：出错少不少、能不能一次成。最影响体验的是低级错误，冷门栈里，AI 很容易写出"看着对、实际错"的代码。最典型的一次：为了在 macOS 上正确拉起和关闭子进程，智能体写了系统底层调用，结果把一个"按地址传参"写成了"按值传参"。这个错在 Windows 上根本不暴露，一到 macOS 上程序直接崩溃。够低级，也够致命，正是冷门组合下 AI"想当然"的典型。

**成本**，说的是为定位和验证这些细节花的力气。为省事，我只在 Windows 上开发，macOS 的问题推到 GitHub Actions 的 Apple Silicon runner 上跑，结果反而费事，改一次、等一次、崩一次、再改一次。翻了下记录，从 0.9.11 到 0.9.19 连续九个版本，几乎全在跟 macOS 的兼容问题较劲。为了定位那个崩溃，还专门在 CI 里加了崩溃转储的自动分析。真正耗时间的从来不是写功能，是这些细节的反复验证。

## .NET 与 Avalonia 也有它做得好的地方

为避免单方面控诉。公平地说，这套栈也有长处。

- **编译期防线**：可空引用类型、"警告即错误"、最新的代码分析器，能把一大类风险在编译期拦住，而不是像解释型语言那样等到运行时才炸。
- **AOT 分析器前置排雷**：Native AOT 虽冷门，但 .NET 提供 AOT/裁剪分析器，会在编译期提示"这段代码 AOT 不兼容"。
- **单文件自包含分发**：免装运行时的单文件，体积和资源占用比"每个应用捆一套浏览器内核"的方案强。
- **强类型建模**：清晰的类型边界、贯穿全程的异步取消，让代码结构足够工整。

但这里有个微妙的地方：这些长处，几乎全都服务于"有经验、愿意手搓、读得懂编译器诊断的人类开发者"。而 AI 辅助编程要的正好相反——大量能借鉴的语料、唾手可得的轮子。所以问题不在谁强谁弱，而在强项用错了场景：在一个靠 AI 大量生成代码、又指望生态兜底的场景里，这套栈的长处使不上劲，短处却被放大。反过来，别的平台也有自己的坑——体积、内存、弱类型的运行时错误——只是通常有更成熟的生态替你兜着。

## 经验教训

1. **冷门度会相乘**：评估选型要看「框架 × 运行时模式 × 目标平台 × 第三方组件」的冷门乘积，而不是只看框架本身。
2. **AI 的"想当然"与语料密度成正比**：冷门组合语料趋零、幻觉率高；换模型解决不了，换栈才能解决。
3. **跨平台是 API 级承诺，不是语义级承诺**：同一套 API 在不同平台语义可能不同，"在 Windows 上跑通"不等于"跨平台完成"。
4. **抽象泄漏到原生层，就是换栈的信号**：当你被迫手写系统级原生调用、或额外写一段原生辅助程序时，说明框架的抽象不完整，成本开始失控。
5. **冷门栈反而要求你更懂底层，热门栈允许你不懂**——因为生态已经替你懂了，那些现成库的存在就是"这个坑已被封装"的证明。
6. **验证成本是隐形的成本大头**：本地复现不了目标平台的问题时，"改 → 等 → 崩 → 改"的低效循环会放大一切痛苦。

## 留待想象

DeepSeek Harness 的[论文](https://github.com/cordiverse/paper?ref=nigzu.com)宣称发明了一种新的编程范式，AI带来的范式还会不断创新，本篇可以视为一种吐槽，没什么一定的结论。

如果能搭建起跨设备、平台、框架的Loop Engineering，让智能体拿着第一手信息自己闭环——查资料、做实验、跑验证，要什么自己实现，模型强到自己补完生态，那"语料少"这个约束会被削弱，性能、类型等基础优势反而会凸显。

就现阶段而言，兴趣是第一驱动力，也是没有更好，只有更适合。