floe-agent
JiangNanGenius/floe-agent加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
设想你是做工程项目设计的，早上出门前在 iPad 上打开一个图纸 PDF，随手在上面批注几句。到了公司，同事问你："昨天那个管线的参数算完没有？"你不需要打开笔记本电脑，也不需要登录什么云端服务器——只需要把 iPad 摆到桌上，打开 Floe Agent，聊天框里说"继续昨天那个任务"，Agent 接着在你设备上的一台真 Linux 虚拟机里跑 Python、装 apt 包、起一个本地服务，然后把生成的图表、Office 文档直接推回你的任务工作区。整个过程没有账号、没有广告、没有行为分析、没有厂商运营的代理服务器——模型请求直接打到你自己的 API Key 对应的服务商。
这就是 Floe Agent 的自我定位：Your models. Your files. Your machines. 三个"你的"，一句话把产品边界划清楚了。
Floe Agent 由 JiangNanGenius 团队开发，仓库 2026 年 8 月 12 日创建，到 10 月 23 日已累计 2686 次提交、305 星、42 fork，代码量以 Swift 为主（4800 万字节），同时有大量 Kotlin（Android 端）、C（Linux guest 内核与模拟器）、Python（工具脚本与打包）以及少量 WebAssembly。
有意思的是它的仓库形态：根目录有 capability-hub/、content-hub/、skill-hub/、pool/ 四个"hub"目录，配 FloeAgent/（iOS 原生工程）、FloeAndroid/（Android 工程）、docs/（上百篇中英双语架构文档）。文档密度极高，docs/ 下光是状态追踪就有 CURRENT_STATUS.md、FLOE_1_7_IMPLEMENTATION_STATUS.md、FLOE_1_7_COMPATIBILITY.md、WORKFLOW_UPGRADE_IMPLEMENTATION.md 等数十篇。这种"每一步都有验收证据存档"的写法，在开源项目里非常罕见——它把产品研发过程本身当成了交付物。
作者团队显然是工程出身。AGENTS.md（约 3 万字节）明确规定了协作规则：私有仓库一律不提交、每个 PR 只做一件事、"不要在一轮长对话里改整个项目"、测试要求"最小实现 + 真实断言"而非只编译通过。这种对 AI 编码代理行为边界近乎苛刻的约束，背后大概率是长期与编码 Agent 协作踩坑后的经验沉淀。
产品哲学同样克制。PRODUCT.md 里直接写明：版本 1 不做 Floe 账号、不做广告、不做行为分析、不做模型转售、不做托管代理、不做无限制的 shell 环境。安全模型是范围感知的人工审批——只读和受限本地操作不打扰用户，破坏性操作、凭据、上传、支付、远程变更则必须显式确认，甚至有"灾难性操作闸门"和审批模型复核机制。
如果把 Floe Agent 想象成给 iPad 配了一台随身服务器，那它大致是这样分工的：
audit_native_runtime_free.py 脚本审计这一点），所有代码执行都发生在微虚拟机里。首次使用会自动跑一个"下载→校验→安装→启动"的准备任务，然后恢复原命令。一句话：它把"云端 AI 助手"的能力搬到本地，把"云端 AI 助手"最大的信任问题（数据去哪、密钥归谁、代理能看到什么）用架构约束回答了。
从 README 的功能表和 docs/ARCHITECTURE_OVERVIEW.md 的系统图看，主要工作流有：
| 能力 | 具体内容 |
|---|---|
| AI 任务 | 持续会话 + 工具活动可见 + 可恢复状态，可配子 Agent（独立预算的子执行） |
| 设备端 Linux | 持久化、任务归属的 Linux 环境：shell、Python、Node、apt 包、后台作业、本地网页预览 |
| 设备端 AI | iOS 27 Apple Foundation Models，或用户自行下载的 Qwen / Gemma MLX 模型（Beta） |
| Notes | 导入 PDF 与图片、全文检索、Pencil 手写标注、对文档提问 |
| Office | 创建/编辑/保存 DOCX、XLSX、PPTX，并检查保存后的复杂排版 |
| Canvas & Media | 素材画布 + 图像/视频/音频工作台（单素材编辑器：预览、裁剪、参数、导出） |
| 工程图纸 | 检查工程文件、编辑支持的实体、Drawing Assistant（CAD 审阅） |
| 代码与远程 | 编辑代码、追踪 Git 变更、SSH/SFTP/跳板机/PTY/VNC、端口管理 |
| 浏览器 | 可见 WKWebView，AI 无法在后台偷偷操作页面 |
| 多语言 | 英文 + 简体中文界面 |
模型接入是标准的 BYOK：OpenAI Responses 与 Chat Completions 兼容接口、Anthropic Messages 兼容接口，外加独立的视觉、图像生成、图像编辑角色（OpenAI Images、Google Gemini Images，可配代理 Base URL）。密钥存 iOS Keychain。
好消息：iOS 用户路径清晰——TestFlight、Feather/AltStore 一键添加源（仓库带 feather.json）、或直接下 GitHub Release 的 IPA（未签名，需自备证书）。Android 用户下 APK 手动安装即可。
坏消息也有几条：
android/v0.1.0-alpha.9 的实际能力是"基础云端聊天 + 配置与历史恢复"，不含本地模型、不含设备端 Linux 环境——而这恰恰是 Floe 最核心的卖点。所以结论是：iPad 用户现在能体验完整价值，Android 用户只能等，iPhone 用户算次要目标（项目自称 iPad-first）。
第一，项目体量与社区规模严重不匹配。305 星、42 fork、仅 2 名贡献者、2686 次提交——这是一个由极小团队在两个月内高速推进的项目，代码量和文档量的背后是巨大的巴士因子风险。docs/ 里那些 FLOE_ANDROID_IMPLEMENTATION_PLAN.zh-CN.md（21.9 万字符）、FLOE_ANDROID_PROGRESS.zh-CN.md（21.2 万字符）这样的文件，本质上是一份写在仓库里的项目管理日志。好处是透明，坏处是让人担心：文档描述的能力和真正能跑的能力之间，差距由谁来维护？
第二，"开源但要自备签名 + 自备 API Key"的双重成本。这既是隐私卖点，也是使用门槛。iOS 侧还要额外过 TestFlight 审核或自己签名，对普通用户极不友好。
第三，版本节奏激进。Release 记录里 v1.7.48、v1.7.49 相隔两小时，Android alpha.8 到 alpha.9 相隔一个多小时。开发节奏是"极限编程"式的，但也意味着版本号的语义稳定性存疑，文档里到处标注"本里程碑尚未完成""候选目录不得在验证前宣传为可运行下载"——这种诚实反而值得肯定，但也说明功能声明需要读者自己去交叉验证。
第四，文档的双语冗余。中英双份文档在 docs/ 和 FloeAgent/ 下成对出现，维护成本巨大，中文文档明显是机翻级别（FLOE_1_7_CONTINUATION_STATUS.md 就有中文翻译，且与英文版存在大量内容重叠）。
第五，许可证是 MPL-2.0（文件级 copyleft），对想集成进闭源产品的团队是个需要法务确认的选择。
把时间轴拉长看，Floe Agent 站在一个正在成型的趋势交汇点上：
它也代表了一类正在出现的开源 AI 项目形态：不再是"某个 API 的更好封装"，而是"一整套端侧 AI 工作环境的完整实现"。这类项目的价值不取决于模型能力，而取决于执行环境、权限模型和本地集成的深度——这也解释了为什么它的文档厚度远大于代码厚度。
从数据看，仓库活跃度极高（最后推送就在 10 月 23 日，与本次分析同日），发布渠道从 TestFlight 扩展到 AltStore、GitHub IPA、Android APK，还同步到 Gitee 做国内镜像。团队在文档里规划了 Office 完整编辑、图像/视频编辑器、CAD 深度集成、语音闭环等一长串未完成项。
对国内团队的实际参考价值：如果你在调研"端侧智能体工作台"这个方向，Floe Agent 提供了三个可借鉴点——一是把"审批闸门 + 可审计链 + 范围感知权限"当成一等公民设计，而不是事后补丁；二是用"每一步都有验收证据文档"的方式管理多平台多端工程复杂度；三是端侧产品的护城河不在模型调用，而在执行环境的深度和权限模型的可信度。
项目信息速览