REMOTE ARC BLOG
为什么 Remote Arc 选择 Go？Mac 和 Windows 上的 Agent 性能实测
Go 并非每项指标都更快。Remote Arc 选择原生 Go Agent，主要依据是长期驻留、低内存和执行环境独立，而不是宣称 Go 总会击败 Node.js。
比较的是相同任务，而非语言印象
L1 使用本地 JSONL IPC 测量执行核心，L2 使用认证的本机回环 WebSocket 测量完整前台 Agent。每种常规文件操作收集 600 次样本，交替运行并区分预热。结果不是经生产 Cloudflare 或 ChatGPT 的端到端延迟。
Mac：Atomic 与 Durable 必须分开比较
在 Intel Mac 上，相同版本的 L2 Atomic 写入中，TypeScript P50 为 5.327 ms、Go 为 2.713 ms；批次后 RSS 分别为 100.69 MiB 和 16.35 MiB。Durable 写入因同步磁盘数据，双方延迟都接近 200 ms，不能据此判断语言本身优劣。
Windows：先发现回退，再修复
Windows 早期 Go Atomic 写入 P50 为 29.152 ms，慢于 TypeScript 的 20.977 ms。修正原生路径处理后，后续版本 Go 为 9.687 ms，TypeScript 为 21.294 ms。两组数字来自不同源码修订，必须分开标注。
长期驻留看的是稳定性与资源
隔离的两小时驻留实验覆盖 Undo、文件冲突、受管进程和重连场景；它不能替代真实断电、升级或长期生产运行的可靠性验证。
尚未解决的问题
真正的 L3 性能还要测从 AI 客户端到 Cloudflare Relay 再到本机工具的完整路径。当前数据支持选择 Go 作为原生常驻 Agent，但不支持『Go 在任何操作下都更快』的结论。