用 Rust 写一个跨平台通用 AI Agent：workspace 架构、gRPC 内部边界与手写终端后端
内容提要
FutureOS 是一个用 Rust 实现的开源通用 AI Agent，采用单一二进制分发，支持终端、桌面、移动端和 IM 机器人。其架构核心是 gRPC 后端，通过事件溯源和确定性内核管理长任务，确保崩溃恢复。项目强调内存安全、跨平台兼容，并手写终端后端以减少依赖，但尚缺系统级沙箱。
延伸解读
gRPC 内部边界的取舍
将 gRPC 作为内部边界，使得新增客户端无需改动核心，多客户端可并发共享状态，且崩溃隔离。但本机 IPC 有固定开销，proto 演进需严格纪律。这种架构适合“一个后端，多种界面”的场景，但若客户端单一或性能敏感，可能不值得。
手写终端后端的代价与收益
手写终端后端减少了依赖，增强了对 Windows 控制台行为的控制，但需自行处理所有平台差异，工作量巨大。对于标准 TUI 需求，crossterm/ratatui 仍是默认选择；仅在依赖敏感或终端为一等公民时，才值得自研。
事件溯源与确定性内核的可靠性设计
通过事件溯源，Agent 崩溃后可恢复状态，长任务不再因进程崩溃而丢失。确定性内核避免额外 LLM 调用，确保任务完成判断可靠。这种设计适合需要长时间运行、无人值守的任务，但实现复杂，需权衡成本。
跨平台 CI 的实践要点
钉死工具链、统一 clippy 标志、避免 POSIX 假设，是跨平台 CI 的关键。特别是 Windows 上 PowerShell 5.1 不支持 &&，需注意命令兼容性。这些实践能减少本地与 CI 不一致的问题，但需投入额外维护精力。
Q&A
FutureOS 是什么？它有哪些主要组件？
FutureOS 是一个开源的通用 AI Agent，用 Rust 实现，采用单一二进制分发，支持终端、桌面、移动端和 IM 机器人。其核心组件包括 agent 后端、IM 渠道桥、loop 控制面、CLI 和 TUI，全部用 Rust 编写。
为什么选择用 Rust 来开发 FutureOS？
选择 Rust 主要基于两个硬约束：一是 Agent 是常驻进程，拥有用户文件系统和 shell 权限，内存安全是底线；二是需要一套代码跨 macOS、Linux、Windows 平台运行，且单二进制分发，不能要求用户安装运行时。
FutureOS 的 workspace 架构是如何划分的？
仓库是 Cargo workspace，成员按数据归属划分：agent 是 gRPC 后端，tui 是终端 UI，channels 是 IM 桥，orchestration/loop 是长任务控制面，cli 将组件打包成统一二进制，packages/rpc 是 protobuf 的唯一事实源。桌面端被刻意排除在 workspace 之外。
FutureOS 为什么使用 gRPC 作为内部边界？有什么优缺点？
使用 gRPC 作为内部边界的好处是：运行时与界面解耦，新增客户端无需改动核心；多客户端天然并发；崩溃隔离，TUI 挂掉不影响 agent。缺点是本机 IPC 有固定开销，proto schema 演进需要纪律。
FutureOS 的 TUI 为什么不用 crossterm/ratatui，而是手写终端后端？
手写终端后端是为了减少依赖（对能执行 shell 命令的工具很重要）、完全控制 Windows 控制台行为（框架抽象容易漏坑）、按需实现功能避免框架税。代价是需要自己处理所有平台差异，工作量较大。
FutureOS 如何处理长任务？事件溯源和确定性内核是什么？
FutureOS 使用 loop 控制面处理长任务，状态通过事件溯源重建，崩溃后可恢复。确定性内核决定是否继续运行，should-run 是纯函数，基于目标状态和显式门禁，不依赖 LLM 调用，也不让模型自行宣布完成。
FutureOS 在跨平台和 CI 方面有哪些注意事项？
跨平台和 CI 的注意事项包括：用 rust-toolchain.toml 钉死工具链，clippy 必须带 --all-targets，不要假设 POSIX（路径分隔符、.exe 后缀、大小写不敏感文件系统、Windows 上 shell 是 PowerShell）。
FutureOS 目前有哪些短板？
FutureOS 目前还比较早期，Windows/Linux 的系统级沙箱还没做，目前只有审批门控和 macOS Seatbelt，移动端比 TUI 新。
