Fusion 软件工厂
用多智能体工作流把需求自动规划、实现、审查并交付为代码。
证据显示 CI 工作流使用只读 contents 权限并禁用持久化凭据，任务在独立 git worktree/分支中执行，支持计划审批、逐任务合并策略、暂停和提示词调整；面板令牌的保存位置、覆盖方式、撤销入口及禁用认证选项也有说明。扣分在于未提供代理运行时文件、网络、Shell 和第三方服务权限的完整最小权限模型；自动合并和长期自治会产生显著外部效果，但并非所有路径都明确要求确认；令牌存入 localStorage 和 settings.json，却未展示加密、日志脱敏或密钥轮换实现；依赖方面有精确版本检查和跨平台打包验证，但未展示漏洞扫描、供应链签名或关键漏洞处置政策；worktree 和分支提供一定回退基础，但没有完整的事务性回滚或恢复流程。README 归功于上游项目且许可证归属清楚，但发布者身份仍未知。
README、package 元数据、测试脚本和 CI 工作流对 Node/pnpm、跨平台打包、精确依赖版本及工作区检查形成较一致的叙述；测试也验证稳定 mock、路径无关读取以及明确的 ENOENT 信息。扣分在于这里只看到少量测试实现及声明式脚本，未静态展示核心编排、重试、断点恢复、模型降级和多节点故障处理代码；桌面打包检查明确是 advisory，依赖可用性仍受 npm、Homebrew、模型供应商和原生二进制影响；面向用户的失败消息主要由 README 描述，覆盖范围无法确认。
对个人开发者、多项目、多节点、桌面/移动/Web/CLI、本地与云模型以及自定义工作流的场景说明充分，安装和平台适配也很广，因此受众场景与环境适配得分较高。扣分在于产品仍标为 early preview，若干插件和多代理房间为 experimental；虽然工作流可逐任务选择并有审批策略，长期自治、研究、自动改进和环境工具调用的能力边界与触发条件没有被完整枚举。
README 具有清晰的信息层级、快速开始、流程图、功能说明、平台矩阵和文档交叉引用；提供 npx、安装脚本、Homebrew、npm、源码开发及认证注意事项。MIT 文本和 package 元数据一致，许可证可给满分。扣分在于 fn、fusion、runfusion.ai 与包名并存，且版本为 beta；未提供完整 FAQ；限制主要散落在 early preview/experimental 标签中；虽有 changesets、发布脚本、版本号、问题跟踪地址及“weekly”声明，但所给证据没有实际 changelog、支持期限、安全联系渠道或明确的个人维护责任。
计划、验收条件、实时差异、文件变更、审查门、任务聊天及独立 worktree 都能产出可直接用于软件交付的结果，输出可用性证据较强。扣分在于“零冲突”“节省人时”“自主运行数周”等边际价值主要是营销性声明，未由所给实现或测量结果支撑；虽展示令牌和生产力遥测及可选本地模型，仍未给出资源上限、预算控制细节或与人工流程比较的数据，因此成本收益只能评为适中。
部分主张可追溯到具体设置名、文件路径、工作流名称、版本字段和 CI 检查；README、package.json、测试与工作流之间也存在有限交叉印证。扣分在于核心功能的大量证据仅来自自动翻译 README，所引用文档和核心实现未包含在材料中；440+ 代理、70+ 主题、实时舰队统计、每周发布、零冲突及长期自治等说法缺乏独立佐证，而且事实、愿景和营销推断没有始终清楚分开。
- 这是仅基于所给文件的静态低置信度评估；未执行代码、安装包、测试或代理任务。
- 在授予真实仓库、Shell、网络或云凭据前，应核查代理运行时权限边界、命令审批、域名限制、日志脱敏和密钥撤销实现。
- 自动合并、长期自治、自我改进和多节点同步可能扩大影响范围；应先关闭自动合并并在隔离的非生产仓库中验证恢复流程。
- 一行 curl 安装和 npx 执行会获取远程代码；应固定并审查发布物、校验完整性，并确认实际依赖漏洞状态。
- README 中的规模、效率、零冲突和持续运行主张未被所给源文件充分佐证，不应作为采购或生产部署保证。
这个 Agent 能做什么，适合哪些场景？
Fusion 是一套 MIT 许可、自托管的软件开发编排系统，将自然语言任务转换为可审查的计划、代码修改和 Git 交付结果。它由 @fusion/core、@fusion/dashboard、@fusion/engine 和 @runfusion/fusion CLI 等组件组成，并提供网页看板、fn 命令行、Electron 桌面端、Capacitor 移动端与 PWA。规划智能体先读取项目并生成包含步骤、文件范围和验收标准的 PROMPT.md，执行过程再按照所选工作流进行规划、审查、实现和复审。每项任务运行在独立的 fusion/{task-id} 分支和 Git worktree 中，互不依赖的任务可以并行执行，最终通过 squash merge 或 PR 交付。系统默认使用零配置的嵌入式 PostgreSQL 保存本地运行元数据，也可连接共享外部数据库支持多项目和多节点部署。它支持 Anthropic、OpenAI、Ollama、Google Generative AI、Z.ai、Kimi K3、llama.cpp 以及自定义兼容端点，适合希望自行控制模型、代码库和审批边界的团队。
用户通过看板、聊天或 fn task create、fn task plan 等命令提交任务后，规划智能体读取项目上下文并生成 PROMPT.md，其中列出执行步骤、涉及文件和验收标准。任务可以选择 builtin:coding、builtin:quick-fix、builtin:review-heavy、builtin:stepwise-coding、builtin:compound-engineering 或 builtin:pr-workflow，也可以在 Workflow Editor 中复制并修改工作流图、列、质量门、模型通道和审查策略。@fusion/engine 在独立 Git worktree 中按工作流运行计划、审查、执行和返工节点；依赖任务串行执行，独立任务并行执行。系统实时展示计划、日志、差异、文件变化、PR/Issue 状态和智能体消息，并允许用户暂停、重新提示或使用 fn task steer 调整进行中的任务。完成质量门后，任务可直接 squash merge 或通过 PR 合并；合并、PR 推进以及破坏性或外部服务操作始终需要明确且有记录的人类确认。系统还提供 Mission 层级规划、研究任务、定时 automations/routines、智能体邮箱、任务聊天、实验性多智能体聊天室和多节点同步。
- 维护多个代码库的工程团队，希望在一个看板中让独立修复并行运行，同时以独立 worktree 避免文件冲突。
- 需要严格审查流程的团队，可选择 Review-heavy 或 Stepwise coding，并为规划、执行、验证和合并分别配置模型通道与人工审批。
- 个人开发者把常驻 Mac mini、Linux 服务器或云虚拟机作为执行节点，再从浏览器、桌面端或手机查看任务、日志和差异。
- 需要从 GitHub Issue 建立开发队列的维护者，可导入 Issue、生成计划、执行修改、创建 PR，并在看板上跟踪 PR/Issue 状态。
- 平台团队希望建立自定义软件交付流程，可在可视化 Workflow Editor 中定义节点、质量门、字段、列、模型回退和审批政策。
- 希望长期运行虚拟工程团队的组织，可导入 companies.sh 团队，并结合 Missions、邮箱、心跳和委派机制协调工作。
这个 Agent 有哪些优点和局限？
- 每个任务使用独立的 fusion/{task-id} 分支和 Git worktree，可并行处理互不依赖的工作并降低文件冲突。
- 内置多种可选工作流，并提供可视化 Workflow Editor，可配置节点、质量门、模型通道、字段、列和审批策略。
- 支持多个云端及本地模型提供商，也支持 OpenAI-compatible、OpenAI Responses、Anthropic-compatible 和 Google Generative AI 自定义端点。
- 同时提供网页、CLI、桌面、移动端和 PWA，并可在多项目、多节点环境中同步任务、日志和差异。
- 从计划、实时日志和文件差异到审查及合并均可追踪，且关键合并、PR 和破坏性操作保留强制人工确认边界。
- 项目明确标注为 early preview 且按周发布，采用前需要预期快速变化和升级验证成本。
- 自动开发依赖至少一个已认证的 AI 提供商或可用的本地模型服务；云端模型还会带来网络、凭据和模型使用成本。
- 默认运行存储已转向嵌入式 PostgreSQL；旧 SQLite 文件只作为一次性迁移输入，现有部署需要规划迁移。
- Hermes、Paperclip、OpenClaw 运行时插件以及多智能体聊天室被标为实验性，次要版本之间的 API 或线格式可能变化。
- 完整能力涉及 Git worktree、后台 daemon、模型配置、工作流策略和数据库；相比单一编码助手，部署与运维面更大。
- 即使 planner oversight 设为 autonomous，合并、PR 推进和破坏性或外部服务副作用仍需人工确认，因此不适合要求这些步骤完全无人值守的流程。
如何安装或部署这个 Agent？
最快方式是运行 npx runfusion.ai，它会直接启动网页看板；也可以在 macOS 或 Linux 上运行 curl -fsSL https://runfusion.ai/install.sh | sh，然后执行 fusion dashboard。Homebrew 用户可运行 brew install runfusion/fusion/fusion，再执行 fusion dashboard；npm 全局安装方式为 npm install -g @runfusion/fusion，随后运行 fn dashboard。从源码开发时运行 pnpm install，然后使用 pnpm dev dashboard。首次启动后打开终端输出的带 token 地址；服务端会把 dashboard/daemon token 保存到 ~/.fusion/settings.json。在引导界面至少配置一个受支持的 AI 提供商或本地模型运行时；GitHub 连接仅在需要导入 Issue 或管理 PR 时才需要。
如何使用这个 Agent？
启动 fusion dashboard 或 fn dashboard，在首次引导中选择或注册项目目录，并完成至少一个 AI 提供商的认证。随后可在看板创建任务，也可运行 fn task create "Fix the login bug" 让任务进入规划阶段，或运行 fn task plan "Build auth system" 进行 AI 辅助规划。用 fn task show FN-001 查看详情，fn task logs FN-001 --follow 跟踪日志，执行中可用 fn task steer FN-001 "Use TypeScript" 调整方向。需要导入 GitHub 工作项时运行 fn task import owner/repo --labels bug。在新建任务或任务详情中选择工作流、模型通道、planner oversight 等级以及自动或手动合并策略；审查计划、差异和质量门结果后，再明确确认合并或 PR 推进。
这个 Agent 与同类方案有什么区别？
Fusion 自己将看板体验类比为 Trello，但区别在于任务会被智能体自动细化、执行和交付，而不只是由人移动卡片；其看板也注明建立在 dustinbyrne/kb 的工作之上。与 Paperclip 相比，Fusion原生支持 companies.sh 团队格式，并可通过实验性插件把智能体运行交给 Paperclip。Hermes 和 OpenClaw 同样以实验性运行时插件接入，因此更接近可选执行后端，而不是 Fusion 看板、工作流和 Git 交付层的完整替代品。
常见问题
必须购买某一家模型服务吗？
它会在未经确认的情况下合并或执行破坏性操作吗？
能否同时处理多个任务和代码库？
远程使用时需要注意什么？
~/.fusion/settings.json，也可通过命令行参数或环境变量覆盖。远程节点、局域网地址或反向代理上的 OAuth 登录会通过 /api/auth/oauth-callback 桥接回当前浏览器会话。任务失败或执行方向不对时怎么办？
fn task logs FN-001 --follow 和 fn task steer FN-001 "Use TypeScript"。工作流可把审查失败路由回计划或执行节点进行返工。