<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>FutureOS 工程笔记</title>
    <link>https://future-os-blog.github.io/zh/</link>
    <description>FutureOS 团队的工程笔记：agent 内部机制、RPC 线路协议、loop 编排，以及建立在其上的桌面 / 移动端 / 终端界面。</description>
    <language>zh-CN</language>
    <lastBuildDate>2026-09-21</lastBuildDate>
    <atom:link href="https://future-os-blog.github.io/zh/feed.xml" rel="self" type="application/rss+xml" />
  <item>
    <title>为什么我们选了 gRPC，而不是 ACP</title>
    <link>https://future-os-blog.github.io/zh/posts/why-grpc-not-acp.html</link>
    <guid isPermaLink="true">https://future-os-blog.github.io/zh/posts/why-grpc-not-acp.html</guid>
    <pubDate>Mon, 21 Sep 2026 00:00:00 +0000</pubDate>
    <description>在把桌面端接到 agent 的过程中，有人提出了一个问题：既然 Agent Client Protocol（ACP）就是为「UI 与 agent 通信」这件事而生的，我们为什么还要手写一套 gRPC 协议？这个质疑很合理。答案并不是 ACP 不好——而是我们的两个硬性要求恰好落在 ACP 的能力边界之外：一个 agent 要同时服务多个客户端，而我们需要的流式能力，gRPC 原生具备、ACP 却几乎没有。 整份契约就是一个 1272…</description>
    <category>protocol</category>
    <category>grpc</category>
    <category>acp</category>
    <category>desktop</category>
    <category>architecture</category>
  </item>
  <item>
    <title>给一个没有显示器的桌面应用截图</title>
    <link>https://future-os-blog.github.io/zh/posts/screenshotting-a-desktop-app-with-no-display.html</link>
    <guid isPermaLink="true">https://future-os-blog.github.io/zh/posts/screenshotting-a-desktop-app-with-no-display.html</guid>
    <pubDate>Mon, 14 Sep 2026 00:00:00 +0000</pubDate>
    <description>FutureOS 的每一张产品截图和演示视频——包括本博客里的配图——都是对着 mock 数据、在无头 Chrome 里驱动真实 React UI 渲染出来的。没有显示器、没有运行中的应用、没有手画的 mockup。同一套工具还兼任 UI 回归测试。</description>
    <category>desktop</category>
    <category>tooling</category>
    <category>internals</category>
  </item>
  <item>
    <title>在 macOS、Linux、Windows 上给 agent 做沙箱</title>
    <link>https://future-os-blog.github.io/zh/posts/sandboxing-an-agent-on-three-oses.html</link>
    <guid isPermaLink="true">https://future-os-blog.github.io/zh/posts/sandboxing-an-agent-on-three-oses.html</guid>
    <pubDate>Sun, 06 Sep 2026 00:00:00 +0000</pubDate>
    <description>对用户的承诺只有一句话：agent 不该碰你没允许的东西。兑现它却需要三套完全不同的操作系统机制——Seatbelt、Bubblewrap，以及受限令牌加 NTFS ACL——外加一份诚实的清单，列出哪些地方承诺无法完全兑现。</description>
    <category>agent</category>
    <category>desktop</category>
    <category>internals</category>
  </item>
  <item>
    <title>手机与桌面之间的端到端加密</title>
    <link>https://future-os-blog.github.io/zh/posts/phone-desktop-e2ee.html</link>
    <guid isPermaLink="true">https://future-os-blog.github.io/zh/posts/phone-desktop-e2ee.html</guid>
    <pubDate>Sat, 29 Aug 2026 00:00:00 +0000</pubDate>
    <description>FutureOS Mobile 通过一个 NATS 中继来控制你桌面上的会话。这个中继在公网上，所以必须按「它是恶意的」来设计——它可以丢弃、重排、重放、伪造消息，但绝不能读到一条命令、也不能伪造出一条被端点接受的命令。下面是 v2 通道如何用 Noise 握手和 ChaCha20-Poly1305 记录层做到这一点的。</description>
    <category>agent</category>
    <category>mobile</category>
    <category>desktop</category>
    <category>security</category>
    <category>e2ee</category>
  </item>
  <item>
    <title>Loop 工程：让长时间运行的 agent 工作变得可持久</title>
    <link>https://future-os-blog.github.io/zh/posts/loop-engineering.html</link>
    <guid isPermaLink="true">https://future-os-blog.github.io/zh/posts/loop-engineering.html</guid>
    <pubDate>Sat, 22 Aug 2026 00:00:00 +0000</pubDate>
    <description>聊天会丢上下文。future-loop 把「帮我盯这个一周」变成一个可持久的目标——一张 todo 图、人工闸门、每步证据，以及一个可验证的「完成」定义，它能跨会话、跨重启、跨并行 worker 存活。这篇文章讲控制平面是怎么工作的，以及它是如何承载 Matilda 铺砖那次运行的。</description>
    <category>agent</category>
    <category>loop</category>
    <category>multi-agent</category>
    <category>architecture</category>
  </item>
  <item>
    <title>用四个 LLM 组队解一道组合题</title>
    <link>https://future-os-blog.github.io/zh/posts/solving-combinatorics-with-four-llms.html</link>
    <guid isPermaLink="true">https://future-os-blog.github.io/zh/posts/solving-combinatorics-with-four-llms.html</guid>
    <pubDate>Thu, 13 Aug 2026 00:00:00 +0000</pubDate>
    <description>我们把一道 16×16 铺砖题交给四个不同的模型，在 future-loop 控制平面下并行求解。4.5 小时、15 轮，答案从 30 一路降到经验证的 21——而两次决定性的突破都来自不同模型之间的分歧，而不是哪个模型想得更狠。</description>
    <category>agent</category>
    <category>loop</category>
    <category>multi-agent</category>
    <category>llm</category>
    <category>experiments</category>
  </item>
  <item>
    <title>实测上下文压缩：FutureOS vs Codex vs OpenCode</title>
    <link>https://future-os-blog.github.io/zh/posts/context-compaction-measured.html</link>
    <guid isPermaLink="true">https://future-os-blog.github.io/zh/posts/context-compaction-measured.html</guid>
    <pubDate>Tue, 04 Aug 2026 00:00:00 +0000</pubDate>
    <description>我们把三种上下文压缩策略放进同一场 178 题的考试。FutureOS 保住了被压缩掉内容的 83%；OpenCode 保住 47%，Codex 38%。差距不在摘要写得更好——而在每个系统认为一次压缩应该留下什么。</description>
    <category>agent</category>
    <category>compaction</category>
    <category>llm</category>
    <category>experiments</category>
  </item>
  </channel>
</rss>
