为什么我们选了 gRPC，而不是 ACP
在把桌面端接到 agent 的过程中，有人提出了一个问题：既然 Agent Client Protocol（ACP）就是为「UI 与 agent 通信」这件事而生的，我们为什么还要手写一套 gRPC 协议？这个质疑很合理。答案并不是 ACP 不好——而是我们的两个硬性要求恰好落在 ACP 的能力边界之外：一个 agent 要同时服务多个客户端，而我们需要的流式能力，gRPC 原生具备、ACP 却几乎没有。 整份契约就是一个 1272…
FutureOS 工程笔记
构建「一个无处不在的 agent」的随笔
acp 1agent 5architecture 2compaction 1desktop 4e2ee 1experiments 2grpc 1internals 2llm 2loop 2mobile 1multi-agent 2protocol 1security 1tooling 1
给一个没有显示器的桌面应用截图
FutureOS 的每一张产品截图和演示视频——包括本博客里的配图——都是对着 mock 数据、在无头 Chrome 里驱动真实 React UI 渲染出来的。没有显示器、没有运行中的应用、没有手画的 mockup。同一套工具还兼任 UI 回归测试。
在 macOS、Linux、Windows 上给 agent 做沙箱
对用户的承诺只有一句话：agent 不该碰你没允许的东西。兑现它却需要三套完全不同的操作系统机制——Seatbelt、Bubblewrap，以及受限令牌加 NTFS ACL——外加一份诚实的清单，列出哪些地方承诺无法完全兑现。
手机与桌面之间的端到端加密
FutureOS Mobile 通过一个 NATS 中继来控制你桌面上的会话。这个中继在公网上，所以必须按「它是恶意的」来设计——它可以丢弃、重排、重放、伪造消息，但绝不能读到一条命令、也不能伪造出一条被端点接受的命令。下面是 v2 通道如何用 Noise 握手和 ChaCha20-Poly1305 记录层做到这一点的。
Loop 工程：让长时间运行的 agent 工作变得可持久
聊天会丢上下文。future-loop 把「帮我盯这个一周」变成一个可持久的目标——一张 todo 图、人工闸门、每步证据，以及一个可验证的「完成」定义，它能跨会话、跨重启、跨并行 worker 存活。这篇文章讲控制平面是怎么工作的，以及它是如何承载 Matilda 铺砖那次运行的。
用四个 LLM 组队解一道组合题
我们把一道 16×16 铺砖题交给四个不同的模型，在 future-loop 控制平面下并行求解。4.5 小时、15 轮，答案从 30 一路降到经验证的 21——而两次决定性的突破都来自不同模型之间的分歧，而不是哪个模型想得更狠。
实测上下文压缩：FutureOS vs Codex vs OpenCode
我们把三种上下文压缩策略放进同一场 178 题的考试。FutureOS 保住了被压缩掉内容的 83%；OpenCode 保住 47%，Codex 38%。差距不在摘要写得更好——而在每个系统认为一次压缩应该留下什么。