[开源] FutureOS：用 Rust 写了一个通用 AI Agent——终端、桌面、手机、飞书钉钉，同一个后端
## 先一句话说清是什么
FutureOS 是一个开源的通用 AI Agent：一个跑在本地的 Rust gRPC 后端，同时驱动终端 TUI 、桌面应用、移动端（ Android/iOS ）、CLI 和 IM 机器人（飞书/钉钉）。同一个 Agent ，同一份会话和记忆，跟着你走。
GitHub: [https://github.com/futuregene/future-os](https://github.com/futuregene/future-os)
## 为什么做它
Coding agent 长在终端里，个人助理长在聊天软件里，而我的工作场景两边都有：在终端里让它干活，出门后想在手机上刷一下进度，晚上跑长任务，早上想在飞书里收它的交付物。维护两套 Agent 太蠢了，所以写了一个后端 + 五个客户端的架构。
## 三个自己比较坚持的设计
**1. 信任先于能力**
今年 Agent 安全的事故大家都看到了。FutureOS 的默认姿态是：每一次工具调用（ read / write / edit / shell ）都需要你显式批准，没有任何文件写入和命令执行是静默发生的。沙箱分三档（ off / manual / macOS Seatbelt ）——坦白说 Windows 和 Linux 的系统级沙箱还在 roadmap 上，这是目前最大的短板，仓库里 [SECURITY.md](http://security.md/) 把信任模型和已知边界都写清楚了。
**2. 一个后端，所有界面**
Agent 是只监听 127.0.0.1:50051 的独立 gRPC 服务，TUI 、桌面端、移动端、CLI 、IM 桥都是薄客户端。会话是 JSONL 存储，还能像 git 一样 fork 分支（/fork 、/tree 命令）。数据全部本地，凭证只发往对应的模型供应商。
**3. 24 小时以上的长任务，靠工程不靠提示词**
内置一个 loop 控制面（/future-loop ）：持久化目标/todo/门禁，状态是事件溯源的，agent 半夜崩了能断点续跑；"该不该再跑一轮"由确定性内核决定而不是再问一次 LLM ；任务完成要过验证门控，不是它自己说做完了就算完。我的典型用法是晚上扔一个深度调研目标进去，早上在手机上验收。
## 模型
内置 3800+ 模型、140+ 供应商目录，ctrl+p 会话中途切模型；任何 OpenAI 兼容端点都能接（ Ollama / vLLM / 本地部署都行）。今年几家大厂的 OAuth 封锁事件之后，"不绑定单一供应商"我觉得是刚需。
## 快速体验
macOS / Linux:
```bash
curl -fsSL https://dl.future-os.cn/install.sh | bash
```
Windows (PowerShell):
```powershell
iex (irm https://dl.future-os.cn/install.ps1)
```
然后 `future auth login && future agent`，再开一个终端 `future tui` 就能用了。
## 诚实的短板清单
- Windows / Linux 还没有系统级沙箱（只有审批门控）
- 移动端比 TUI 新，毛边更多
- 项目非常早期，star 还没过百，欢迎围观所有粗糙之处
如果觉得有意思，欢迎 Star 和拍砖；对 loop 控制面或者多端架构有想法的，尤其欢迎来 issue 里聊。
---
原文链接：[点击查看](https://www.v2ex.com/t/1235540)
FutureOS 是一个开源的通用 AI Agent：一个跑在本地的 Rust gRPC 后端，同时驱动终端 TUI 、桌面应用、移动端（ Android/iOS ）、CLI 和 IM 机器人（飞书/钉钉）。同一个 Agent ，同一份会话和记忆，跟着你走。
GitHub: [https://github.com/futuregene/future-os](https://github.com/futuregene/future-os)
## 为什么做它
Coding agent 长在终端里，个人助理长在聊天软件里，而我的工作场景两边都有：在终端里让它干活，出门后想在手机上刷一下进度，晚上跑长任务，早上想在飞书里收它的交付物。维护两套 Agent 太蠢了，所以写了一个后端 + 五个客户端的架构。
## 三个自己比较坚持的设计
**1. 信任先于能力**
今年 Agent 安全的事故大家都看到了。FutureOS 的默认姿态是：每一次工具调用（ read / write / edit / shell ）都需要你显式批准，没有任何文件写入和命令执行是静默发生的。沙箱分三档（ off / manual / macOS Seatbelt ）——坦白说 Windows 和 Linux 的系统级沙箱还在 roadmap 上，这是目前最大的短板，仓库里 [SECURITY.md](http://security.md/) 把信任模型和已知边界都写清楚了。
**2. 一个后端，所有界面**
Agent 是只监听 127.0.0.1:50051 的独立 gRPC 服务，TUI 、桌面端、移动端、CLI 、IM 桥都是薄客户端。会话是 JSONL 存储，还能像 git 一样 fork 分支（/fork 、/tree 命令）。数据全部本地，凭证只发往对应的模型供应商。
**3. 24 小时以上的长任务，靠工程不靠提示词**
内置一个 loop 控制面（/future-loop ）：持久化目标/todo/门禁，状态是事件溯源的，agent 半夜崩了能断点续跑；"该不该再跑一轮"由确定性内核决定而不是再问一次 LLM ；任务完成要过验证门控，不是它自己说做完了就算完。我的典型用法是晚上扔一个深度调研目标进去，早上在手机上验收。
## 模型
内置 3800+ 模型、140+ 供应商目录，ctrl+p 会话中途切模型；任何 OpenAI 兼容端点都能接（ Ollama / vLLM / 本地部署都行）。今年几家大厂的 OAuth 封锁事件之后，"不绑定单一供应商"我觉得是刚需。
## 快速体验
macOS / Linux:
```bash
curl -fsSL https://dl.future-os.cn/install.sh | bash
```
Windows (PowerShell):
```powershell
iex (irm https://dl.future-os.cn/install.ps1)
```
然后 `future auth login && future agent`，再开一个终端 `future tui` 就能用了。
## 诚实的短板清单
- Windows / Linux 还没有系统级沙箱（只有审批门控）
- 移动端比 TUI 新，毛边更多
- 项目非常早期，star 还没过百，欢迎围观所有粗糙之处
如果觉得有意思，欢迎 Star 和拍砖；对 loop 控制面或者多端架构有想法的，尤其欢迎来 issue 里聊。
---
原文链接：[点击查看](https://www.v2ex.com/t/1235540)
评论
暂无评论。