Sparo-Agentic-OS 与 BitFun 的血缘关系：同一内核，两个产品叙事

May 15, 2026

Sparo-Agentic-OS 与 BitFun 的血缘关系：同一内核，两个产品叙事

核心发现：同一内核，两个产品叙事

最近分析 GCWing 的两个开源项目——BitFun 和 Sparo-Agentic-OS——发现它们的关系远比表面看起来复杂。不是竞争，而是同一团队针对不同假设的两条实验线。

两者共享核心代码基（Cargo crate 名称完全一致：bitfun-core、bitfun-events、bitfun-transport……），但走向了截然不同的架构路径。这篇文章从代码层面拆解它们的关系。

血缘铁证：fork 而非重写

翻开两个项目的源代码，核心 crate 名称一模一样。Sparo 的对话协调器（coordinator.rs）与 BitFun 的前 5 行逐字相同，内部仍有 ~/.bitfun/projects/ 路径引用残留。桌面二进制文件仍叫 bitfun-desktop。环境变量前缀仍是 BITFUN_*。

结论：Sparo 是在 BitFun 代码基上 fork 出来的，不是 clean-room 重写。

去掉的 10 个 crate：Sparo 拒绝了微 crate 架构

BitFun 最近经历了一次架构重构，将 bitfun-core 拆成了多个独立 crate：acp（Agent Client Protocol）、agent-stream、agent-tools、core-types、product-domains、runtime-ports、services-core/integrations、terminal/tool-packs/tool-runtime。

Sparo 一个都没要。它的 Cargo workspace 只有 BitFun 的 7 个 core crate + 1 个自创的 libs/。Sparo 选择了扁平架构，拒绝了 BitFun 正在推进的微 crate 分解路线。

新增的唯一 crate：Agent Shell

Sparo 自创的 libs/ 包含两个子模块：

  • agentshell — PTY 伪终端管理、多 Shell 适配（bash/zsh/fish）、会话持久化、输出 ANSI 清洗
  • cli-credential — Codex / Gemini 等第三方 CLI 工具的凭证管理

这是 Sparo 对 Agentic Shell 方向的独立探索——把 Agent 深度嵌入终端体验，而不只是一个对话窗口。

Agent 系统重构：从定义文件到独立文件

两个项目在 Agent 组织方式上分道扬镳：

BitFun 的 Agent 系统用 7 个定义文件组织（definitions/{modes, review, subagents, custom, hidden, shared}/），通过注册表查询和解析来构建 Agent 实例。

Sparo OS 的 Agent 系统则有 17 个独立 .rs 文件，每个 mode 一个文件——agentic_mode.rs、code_review_agent.rs、plan_mode.rs、debug_mode.rs 等等。加上 AgentAppStudio 和 LiveAppStudio 两个 Studio 模式。

Sparo 的 Agent 矩阵更“重”——不只是编排已有能力，而是每个 Agent 有自己的独立实现逻辑。

MiniApp → Live App：概念升级

BitFun 的 MiniApp 是“一句话生成独立运行的应用”。Sparo 将其升级为 Live App，增加了三个关键能力：

  • 持久化身份与状态（Live App 不是一次性生成物，可以持续演进）
  • Agentic Session Bridge（Live App 可以主动调用 Agent 系统）
  • Bridge App（为现有 GUI 软件添加 Agent 操作层）

加上 Dev Kit（Skills + Tools + MCP 开发工具链），Sparo 在努力构建一个智能应用生态，而不只是 Agent 运行时。

品牌层：外改内不改

外层面品牌化（Sparo），内层代码标识基本未动（仍然是 bitfun）：配置目录从 ~/.bitfun/ 改为 ~/.sparo_os/，项目隐藏目录改为 .sparo_os/，Session 路径改为 .sparo_os/projects/{slug}/sessions/。但内部 bin 名仍是 bitfun-desktop，环境变量前缀仍是 BITFUN_*。说明 Sparo 还处于早期实验阶段——品牌先行，内部重构滞后。

定位差异：Runtime vs OS

同一个团队、同一份核心代码基，面向两个不同叙事：

BitFun 的自我定义：“桌面级 Agent 运行时 + 开箱即用的 Agent 套件。一个安装包覆盖编码、办公、桌面自动化和个人助理四大主流 Agent 能力。”

Sparo OS 的自我定义：“AI 时代的 Agentic OS。AI 即系统——让软件不再是固定工具，而是围绕用户意图持续生成、组织、连接与演化。”

BitFun 强调实用性（“下载即用，一套配齐”），Sparo 强调理念性（“OS 思维，Agent 生态”）。本质是同一团队在做 A/B 测试——哪个叙事更能打动用户？

代码量对比

BitFun 总代码量 516,494 LOC，Sparo 为 388,524 LOC（约占 BitFun 的 75%）。BitFun 有 17 个 Cargo crate，Sparo 精简到 7 个（+1 自创 libs/），精简了 59%。但 Sparo 的 Agent 数量更多——17 个独立 Agent 文件 vs BitFun 的 4 个官方 Agent + 定义系统。

评估：Sparo 是实验分支

综合所有证据，Sparo OS 大概率是 BitFun 的实验分支，在验证几个关键假设：

  1. Agentic OS 叙事是否比 Agent Runtime 更有市场？
  2. 扁平架构是否比微 crate 架构更适合快速迭代？
  3. 更多内置 Agent 是否比 Markdown 可定义 Agent 更降低使用门槛？
  4. Live App 生态是否比 MiniApp 更能留住用户？

如果这些实验成功，Sparo 的概念大概率会回流到 BitFun 主干。如果失败，Sparo 可能会被归档，BitFun 继续走自己的路。

对 AI Agent 赛道的启示

一个团队同时维护两个架构路线不同的产品，这在 AI Agent 赛道中非常罕见。它反映了一个更深刻的问题：

AI Agent 行业还没有找到正确的产品形态。

是应该做一个 Agent 运行时（BitFun 路线）——让开发者 Build on top of it？还是做一个 Agentic OS（Sparo 路线）——让用户 Live inside it？

这个问题不只 GCWing 在回答——从 OpenAI 的 Codex/Operator 到 Anthropic 的 Claude Code/MCP，到 Google 的 ADK/A2A，全行业都在探索。Sparo vs BitFun 只是这场大实验的一个微缩版。

保持关注。如果 Sparo 的实验跑通了，我们可能会看到一个比 Hermes 更重、比 BitFun 更全的 Agent 产品形态浮出水面。