Fusion 评测：把 AI 软件工厂装进 git worktree 的多节点编排器

它解决的是任务编排，不是代码生成

Fusion 的定位不是又一个 AI 补全工具。它把「描述一个任务」到「代码合并」之间的所有环节都接管了：规划代理读项目、写 PROMPT.md，执行代理按步骤改代码，评审代理检查结果，最后才进入人工确认。README 里明确说，它构建在 dustinbyrne/kb 之上，所以它更像一个任务执行框架，而不是模型封装。目标用户是那些已经用 git 分支流程、但想让 AI 承担重复编码工作的团队。它把 Trello 式的任务板变成可执行、可交付的流水线，每个任务都有文件范围、验收标准和评审记录。

worktree 隔离是核心机制，也是最大卖点

每个任务都在独立分支和独立 worktree 里运行，分支名是 fusion/{task-id}。这意味着多个任务可以并行执行，互不碰对方的工作目录。README 声称「零冲突」，但严格说，这只在文件层面成立。如果两个任务改同一个文件，git 层面不会冲突，因为 worktree 是隔离的，但合并回主分支时仍然可能产生语义冲突。Fusion 的可选 worktrunk 委托机制，通过 worktrunk.enabled 配置切换后端，说明它承认不同后端有不同取舍。这个设计的价值在于，评审者可以看每个任务的完整 diff，而不被其他任务的改动干扰。

规划、评审、执行的多级循环

流程是：用户用自然语言描述任务，规划代理读取项目上下文，生成 PROMPT.md，包含步骤、文件范围、验收标准。然后进入「计划、评审、执行、再评审」的循环，每一步都有评审，直到通过或人工介入。README 里强调，合并和破坏性操作永远需要人工确认，这是安全底线。oversight 级别有 off、observe、steer、autonomous 四档，控制规划监督者的干预程度。这意味着你可以让 AI 全自动跑，也可以让它每步都停下来等你点头。这种设计把控制权交给用户，而不是让代理自行决定。

PostgreSQL 默认，SQLite 只是迁移输入

Fusion 用零配置的嵌入式 PostgreSQL 存本地运行时元数据，README 里特别注明，SQLite 只作为一次性迁移输入。这个变化值得注意，它意味着 Fusion 不再是轻量级单文件工具，而是需要一个数据库进程。对单机开发来说，嵌入式 PostgreSQL 确实零配置，但如果你想跑多项目或多节点，就必须用共享外部数据库。这增加了部署复杂度，但也换来了并发任务状态的一致性。如果你只想在笔记本上快速试一下，这个数据库依赖可能显得重，但如果你要跑多节点代理，它就是必要的基础设施。

快速启动：从 npx 到 dashboard

最直接的启动方式是 npx runfusion.ai，它会启动 dashboard。也可以用 npx @runfusion/fusion dashboard。命令行子命令可以直接转发，比如 npx runfusion.ai task create "fix X"。macOS 和 Linux 有安装脚本，自动选 Homebrew 或 npm，装完后用 fusion dashboard 或 fn dashboard 启动。从克隆仓库开发则用 pnpm dev dashboard。首次启动有 onboarding 向导，三步：配置 AI 提供商、连接 GitHub、创建第一个任务。向导可以跳过，不阻塞使用。dashboard 的 URL 会带一个 bearer token，浏览器存到 localStorage，服务端把 token 持久化到 ~/.fusion/settings.json，除非你用 --token 或环境变量覆盖。

一个真实的局限：依赖模型质量与人工闸门

Fusion 的整个流程建立在规划代理能写出合理的 PROMPT.md 之上。如果模型对项目上下文理解有误，后续执行和评审都会在错误基础上打转。README 没有提供任何关于规划准确率的数据，所以这一点只能靠用户自己验证。另一个局限是，worktree 隔离虽然避免了文件冲突，但多个任务并行时，如果它们依赖同一个外部服务或共享资源，比如数据库迁移、环境变量，仍然可能互相干扰。Fusion 的评审环节依赖人工确认，这意味着如果你完全放手，风险自担。它适合那些愿意在关键节点介入的团队，而不是完全无人值守的场景。

替代方案：对比直接调用模型 API 与 CI 机器人

一个直接的替代方案是写一个脚本，调用模型 API 生成代码，然后用 git 分支和 CI 做检查。这种方式灵活，但你需要自己处理任务分解、上下文注入、评审循环和并行隔离。Fusion 把这些都内置了，代价是你得接受它的流程和存储设计。另一个替代是使用类似 GitHub Actions 的自动化机器人，它们能做 lint 和测试，但不擅长理解自然语言任务。Fusion 的差异在于，它把规划代理放在最前面，让任务描述变成可执行的计划，而不是直接生成代码。如果你已经有成熟的 CI 流水线，Fusion 的价值在于补上「规划」和「评审」这两块，而不是取代 CI。

维护成本与许可证

Fusion 采用 MIT 许可证，这意味着你可以自由使用、修改、商用，没有 copyleft 义务。但维护成本不低：它依赖 PostgreSQL、git worktree、以及多个代理的协调逻辑。版本号是 v0.77.0-beta，说明还在快速迭代，beta 阶段可能有不稳定的 API 或配置项。README 里提到的 worktrunk 委托、插件门控的 Compound Engineering 工作流，都说明功能面在扩展，你需要跟踪文档变化。升级时，SQLite 迁移到 PostgreSQL 是一次性投入，之后如果换数据库，需要重新配置。整体上，如果你不介意跟着 beta 版本走，MIT 许可给了你足够的自由度；如果你需要稳定长期支持，可能得等正式版。

编辑结论

Fusion 适合已经用 git 工作流、愿意把任务拆成可验收步骤的团队，尤其是那些想减少人工编码但保留评审闸门的项目。它不适合只想要一个聊天式代码生成器的人，因为规划、评审、worktree 隔离这些机制本身有学习成本。也不适合完全不能接受 AI 改动代码的合规场景。在采用前，先验证三件事：第一，你的模型提供商是否在快速启动列表里，是否支持你需要的 oversight 级别；第二，你的项目是否适合 worktree 并行，比如大型单体仓库可能遇到合并冲突之外的资源竞争；第三，PostgreSQL 默认存储对你现有运维是否可接受，因为 SQLite 只作为一次性迁移输入，不是长期选项。Fusion 的边界很清楚：它把 AI 编码变成一条可观察、可中断的流水线，而不是一个黑盒。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes