【Agent Harness实战】我为什么用 Rust 写 Agent 内核，却用 Go 和 React 写周边？

前几篇聊了 JSON-LD、CPU 缓存架构、Oxigraph、Qdrant——全是技术选型上的“为什么”。

这是技术选型系列的最后一篇。今天聊编程语言的选择：为什么核心用 Rust，配套服务用 Go，前端用 React？

先说一个暴论：编程语言的选择，本质上是“把复杂度放在哪里”的选择。

我把最复杂的部分——图数据库、记忆管理、调度器、安全校验——全塞进一个 Rust 二进制里。然后把网络交互、前端展示分给 Go 和 React。三者各干各的，互不添乱。

另外，这篇也是个承上启下。技术选型聊完了，接下来会进入设计细节——我会逐一拆解 Agent OS 的内部构造。先预告一下，敬请期待。

一、为什么核心必须是 Rust？

1. 性能：图数据库不等人
   Agent OS 的核心是个图数据库引擎。Oxigraph 是 Rust 原生库，直接编译进二进制。SPARQL 查询、JSON-LD 展开、MESI 状态机——全在一个进程里跑，没有任何 FFI 开销。

换成 Python？光是把 JSON-LD 转成 RDF 就能吃掉几百毫秒。换成 Go？没有成熟的 RDF 库，得自己造轮子。

Rust 是唯一能在“图数据库 + 语义推理 + 异步调度”这三个领域同时做到极致的语言。

2. 安全：系统调用门不容有失
   Agent 的工具调用必须经过 JSON Schema 校验 + Ed25519 签名验证。这是内核级的安全边界，不容有一丁点内存泄漏或段错误。

Rust 的所有权系统在编译期就把空指针、悬垂引用、数据竞争全干掉了。一个 Agent 挂了，不会带着整个系统陪葬。 这在 Python 或 JavaScript 里几乎是不可能的——一次 undefined 就能让整个事件循环炸掉。

3. 零依赖部署：一个二进制走天下
   我用的是 musl 静态编译：

bash
rustup target add x86_64-unknown-linux-musl
cargo build --release --target x86_64-unknown-linux-musl
产出的二进制文件 不依赖任何动态链接库——没有 glibc 版本问题，没有 OpenSSL 版本问题，没有“你机器上少了 libsomething.so”的破事。

整个 Agent OS 核心就一个文件，scp 到任何 Linux 机器上直接跑。

二、musl 静态编译 + ARM64：从树莓派到手机都能跑
很多人以为 Rust 二进制肯定是个庞然大物。来，看看实际的尺寸：

bash
$ ls -lh target/aarch64-unknown-linux-musl/release/gliding_horse
-rwxr-xr-x 1 user user 12.8M gliding_horse
不到 13MB。 对于一个内含图数据库引擎、SPARQL 查询器、JSON-LD 处理器、异步调度器、MESI 一致性协议、系统调用防火墙的完整 Agent OS 来说，这个体积堪称惊艳。

这意味着什么？

树莓派上跑 Agent
ARM64 交叉编译一把梭：

bash
cross build --release --target aarch64-unknown-linux-musl
二进制拷进树莓派，直接跑。一个 4GB 内存的树莓派 4B，能同时运行 Agent OS 核心 + Oxigraph 内存黑板 + 轻量 Qdrant 替代方案。边缘 AI Agent 不再是概念，是现实的部署方案。

手机和平板上跑边缘 Agent
musl 静态编译的 ARM64 二进制，通过 Flutter/Vue 前端套壳，能在 Android（Termux）和 iOS（越狱环境或企业签名）上运行。

结合我们后面会聊的 Teams 版架构（中心-边缘模式），边缘侧 Agent 可以跑在手机上，处理本地任务，只在需要时和中心服务器同步。

想象一下：你的手机在断网时依然能跑 Agent，帮你分析本地的代码、整理笔记、处理文档——等有网络了再同步到中心。

三、中心-边缘架构：Teams 版的部署拓扑
Teams 版采用中心-边缘（Hub-Edge）架构：

中心节点：跑完整的 Agent OS，负责全局任务调度、多 Agent 协作、持久化存储。Go 写的 API 服务处理 gRPC/WebSocket 通信，React 管理后台做可视化和人工介入。

边缘节点：跑简配版 Agent OS（裁掉中心独占的全局调度，保留记忆管理、本地 Skill、L2 缓存）。能在断网时独立工作，联网后自动同步。

这套架构下，Agent OS 不是服务器上的“云神”，而是跟着你随身走的“数字分身”。

四、为什么用 Go 写配套服务？
核心用 Rust 是一锤子买卖，但周边服务需要的是快速开发、高并发网络处理、和云原生生态无缝对接。

Go 的杀手锏：

goroutine：处理 WebSocket 长连接、gRPC 流式调用、并发 Session 管理，开箱即用

编译快：改一行代码，几秒后就能跑

云原生亲和：Docker、Kubernetes、Prometheus、Jaeger——全是 Go 写的

典型场景：code-server 会话管理器

我们的软件工程联邦架构里，每个编码任务会启动一个 Docker 沙箱。Go 服务负责管理这些沙箱的生命周期（创建、挂载卷、分配端口、销毁）。数百个沙箱同时跑，Go 的 goroutine 轻轻松松；换成 Rust，async Rust 的复杂性会让开发周期翻倍。

我的分工哲学：核心引擎用 Rust 做到极致，网络服务用 Go 做到高效开发。各用其长，不互相折磨。

五、为什么前端选 React？
Agent OS 需要三个人机交互界面：

管理后台：任务仪表盘、Skill 管理、审计日志、系统健康

对话嵌入：在 VS Code 或浏览器里显示 Agent 的思考过程（thought 面板）

设计文档 Diff：对比 Agent 生成的设计文档版本

React 生态有现成的一切：

组件库：Ant Design / MUI 一天搭出管理后台

代码编辑器：Monaco Editor 直接嵌入

状态管理：Zustand / Redux 管好 Agent 状态

WebSocket：实时推送 Agent 思考流

不用 React 也可以，但没必要。 前端领域，成熟生态比语言特性重要得多。

六、技术选型全景回顾（系列总结）

七、接下来：进入设计细节
技术选型系列到这里就结束了。从下一篇开始，我会逐一拆解 Agent OS 的内部设计：

记忆系统的实现细节：MESI 协议怎么落地、L3 投影引擎怎么写

技能系统的设计：Skill Graph 怎么存储、怎么查询、怎么自演化

SA 调度器的决策逻辑：感知器官怎么工作、PDCA 动态编排怎么实现

多 Agent 联邦架构：IRI 契约怎么传递、SHACL 怎么校验

前面讲的都是“为什么选”，后面开始讲“怎么实现”。感兴趣的可以关注，不迷路。

我这套系统叫 Gliding Horse（流马），所有代码都在 GitHub 上：https://github.com/doiito/gliding_horse

想玩 ARM64 版本的可以直接下载 Release 页面的 aarch64-unknown-linux-musl 二进制，拷进树莓派就能跑。有问题欢迎提 Issue，我看到会回。