bojie_li 谈需要为AI Agent重做操作系统

非常赞同，现在的桌面操作系统假设用户是人，延迟几百毫秒无所谓。今天的 agent（特别是 GPT-6 这种默认只有 20 token/s 的龟速模型）大多每次工具调用延迟在 10 秒的量级，这样 harness、操作系统的几百毫秒延迟都无所谓。我们从 2024 年开始，就坚持用 Go 构建核心 agent 系统，这样才能把延迟降到足够低。

我们试过用 Python 处理实时语音，发现一个 core 只能处理一个并发，还经常不能保证实时性。为了支持实时语音，我们自己 host 的多种小模型线上 TTFT 都在 100ms-200ms，decode 都在 200 token/s 以上。@yifanxu_ephai 说的 SSD 容量瓶颈也非常现实。

我的开发机每个 worktree 都要几 GB，很多 subagent 在干完活之后不清理自己的 worktree，导致 3T 的 SSD 一天就占��了。此外服务器虽然有上百个核，上 T 的内存，也架不住每个 subagent 都启一堆并行任务。有时候甚至 memory pressure 高到了 SSH 都进不去的程度。

因此我还让 agents 自己维护了一个任务调度系统，管理任务队列、磁盘空间，清理垃圾。我感觉 CPU/GPU 任务调度、worktree 管理应该是 harness 的一部分。网络速度跟不上也是一个现实的问题，比如 computer use，很多客户的网络环境下，截图上传的延迟比 LLM 还高。

这时候就要做压缩传输，前几个月我挂到 arxiv 并开源的 Sema 就是一种方法。为 agent 重做一个操作系统看起来越来越紧迫了： 1. 低延迟、高并发的 UI 和后台任务管理 2. agent 与用户并发操作 UI、隔离用户环境 3. 软件自我修改、自我进化 OpenAI 对 Omarchy 的支持就是一个例子。