Tinyflow 深度解析：前端 100KB 嵌入式 AI 编排，让老旧 ERP/CRM 秒变智能体

2026年，企业 AI 转型面临一个尴尬现实：大多数 AI 编排平台（Dify、Coze、FastGPT）都是「推倒重来」型——你得把整个业务迁到它们的地盘上，用它们的用户系统、它们的数据存储、它们的部署方案。对于已经运行了5年、10年的 ERP/CRM 系统来说，这种迁移成本往往比 AI 本身还贵。

Tinyflow 走了一条完全不同的路：它不是「平台」，而是「组件」。你不需要迁移任何东西，只需要在你的现有系统里嵌入一个 100KB 的前端组件，接上后端 SDK，你的 ERP/CRM 就能拥有 AI 智能体编排能力。

这种「嵌入式」思路，可能比「平台式」更适合中国企业。

一、Tinyflow 是什么

Tinyflow 是一个轻量的 AI 智能体流程编排解决方案。核心定位是开发组件，不是产品。

GitHub 数据：

• 前端仓库：tinyflow-ai/tinyflow（662 Stars, 76 Forks）
• Java 后端：tinyflow-ai/tinyflow-java（83 Stars, 19 Forks）
• 开源协议：LGPL-3.0
• Gitee 认证：GVP（Gitee 最有价值开源项目）
• 最后活跃：2026-04-30（前端）/ 2026-05-07（Java 后端）

一句话概括： Tinyflow 不做「AI 平台」，只做「AI 能力注入器」——把智能体编排能力像打针一样注入到你的现有系统里。

二、技术架构：微内核 + 插件式扩展

2.1 前端：Web Component，100KB 的秘密

Tinyflow 前端的核心技术选型是 Web Component，而不是 React/Vue/Angular 的任何一种。这是一个深思熟虑的决定：

为什么选 Web Component？

Web Component 是浏览器原生支持的组件标准（Custom Elements + Shadow DOM + HTML Templates），它有三个关键特性恰好解决了 AI 编排组件的痛点：

1. 框架无关性：Web Component 可以在 React、Vue、Angular、Svelte 中直接使用，无需任何适配层。这就像 USB-C 接口——不管你用什么电脑，都能插。

2. 样式隔离：Shadow DOM 确保组件内部样式不会泄漏到外部，也不会被外部样式污染。在一个已有10年 CSS 历史的 ERP 系统里，这一点至关重要——你的 AI 编排界面不会被老系统的 !important 搞崩。

3. 体积极小：因为不需要打包任何框架运行时，整个组件只有约 100KB。对比 Dify 前端动辄数 MB 的 React + Next.js 全家桶，Tinyflow 的体积只有其 1/30。

npm 包矩阵：

@tinyflow-ai/ui        # 核心 Web Component 组件
@tinyflow-ai/vue       # Vue 封装（可选）
@tinyflow-ai/react     # React 封装（可选）
@tinyflow-ai/svelte    # Svelte 封装（可选）

即使是框架封装版本，核心逻辑依然走 Web Component，封装层只是一层薄薄的 Props 映射。

3 分钟集成示例（React）：

npm install @tinyflow-ai/ui

import { Tinyflow } from '@tinyflow-ai/ui';
import '@tinyflow-ai/ui/dist/index.css';
import { useEffect, useRef } from 'react';

export default function AIWorkflow() {
  const containerRef = useRef(null);

  useEffect(() => {
    const tf = new Tinyflow({
      element: containerRef.current,
      // 工作流数据
      data: {
        nodes: [],
        edges: []
      },
      // 后端交互回调
      onNodeRun: async (node) => {
        const res = await fetch('/api/ai/run', {
          method: 'POST',
          body: JSON.stringify(node.data)
        });
        return res.json();
      }
    });
    return () => tf.destroy();
  }, []);

  return <div ref={containerRef} style={{ height: '600px' }} />;
}

2.2 后端：三语言 SDK，JSON 协议连接

Tinyflow 后端的设计哲学是「不限制框架」。前后端通过标准化的 JSON 协议通信，后端只需实现协议约定的接口，不需要依赖任何特定框架。

Java SDK（已发布，最成熟）：

<dependency>
    <groupId>dev.tinyflow</groupId>
    <artifactId>tinyflow-java-core</artifactId>
    <version>1.0.0-rc.3</version>
</dependency>

Java SDK 是最成熟的，支持 Spring Boot、Quarkus、Micronaut 等任何框架。版本号已到 1.0.0-rc.3，说明核心 API 已经稳定。

Node.js SDK：

npm install @tinyflow-ai/nodejs

Python SDK： 开发中，社区已有多人贡献 PR。

2.3 节点契约：type + parameters/outputDefs

Tinyflow 的扩展性核心在于它的节点契约设计：

每个节点 = type + parameters + outputDefs

• type：节点类型标识符，如 llm、http-request、code、condition
• parameters：节点参数定义，JSON Schema 格式
• outputDefs：输出定义，声明节点会产出什么数据

这个契约的好处是新增节点类型无需修改核心代码。你只需要：

1. 定义一个新的 type
2. 声明它的 parameters 和 outputDefs
3. 实现对应的后端处理逻辑

前端引擎会根据 type 自动渲染对应的参数编辑界面，后端根据 type 路由到对应的处理器。这是一个典型的开闭原则实践。

三、Tinyflow vs Dify：两条路线的本质差异

这是社区最关心的问题。我用一张表说清楚：

一句话决策：

已有系统要加 AI → Tinyflow；从零做 AI 产品 → Dify。

这不是谁更好的问题，而是场景适配的问题。就像手术刀和瑞士军刀，各有各的战场。

四、实战场景：4 个典型的「嵌入式 AI」用例

场景一：ERP 智能审批流

痛点： 传统 ERP 的审批流是硬编码的，改一个审批节点需要走发版流程。

Tinyflow 方案： 用可视化编排设计审批流，每个审批节点可以接入 LLM 做智能判断（如根据金额、供应商历史自动决定审批级别），审批规则改了直接拖拽调整，无需发版。

场景二：CRM 智能客户分群

痛点： CRM 的客户分群依赖运营手动设置规则，覆盖率低，及时性差。

Tinyflow 方案： 编排一个「数据拉取 → LLM 分析 → 标签写入」的工作流，每天自动执行。LLM 可以理解自然语言的分群规则（"高价值且近期活跃的B端客户"），无需写 SQL。

场景三：OA 知识库问答

痛点： 企业内部知识散落在 Wiki、文档、邮件中，新员工问问题只能问人。

Tinyflow 方案： 编排一个「问题理解 → 知识检索 → RAG 生成 → 来源引用」的对话流，嵌入到 OA 系统的侧边栏，员工直接在 OA 里提问。

场景四：数据平台 ETL 智能化

痛点： ETL 流程出了问题，排查依赖人工，耗时长。

Tinyflow 方案： 在 ETL 流程中嵌入 AI 节点，当某个步骤失败时自动触发「错误分析 → 根因定位 → 修复建议」流程，减少人工介入。

五、架构深度：JSON 协议的设计细节

Tinyflow 前后端通过 JSON 协议通信，这个协议是整个系统解耦的关键。核心数据结构：

工作流定义

{
  "id": "workflow-001",
  "name": "客户智能分群",
  "nodes": [
    {
      "id": "node-1",
      "type": "llm",
      "position": { "x": 100, "y": 200 },
      "data": {
        "label": "客户分析",
        "parameters": {
          "model": "gpt-4o",
          "temperature": 0.3,
          "systemPrompt": "你是客户分析专家...",
          "userPrompt": "分析以下客户数据：{{input}}"
        },
        "outputDefs": {
          "segment": { "type": "string", "description": "客户分群" },
          "confidence": { "type": "number", "description": "置信度" }
        }
      }
    }
  ],
  "edges": [
    { "source": "node-1", "target": "node-2" }
  ]
}

这个协议的设计有三个值得注意的细节：

1. 节点间数据流：outputDefs 声明节点输出，下游节点通过 {{input}} 或 {{node-1.output.segment}} 引用上游数据。这是一种声明式数据流，而不是命令式传参。

2. 前端不关心后端实现：前端只负责渲染节点和收集参数，具体执行逻辑全部由后端处理。这意味着你可以把同一个 LLM 节点在后端路由到 OpenAI、Anthropic 或本地模型，前端完全无感。

3. 可序列化：整个工作流定义就是一个 JSON 对象，可以存数据库、存文件、甚至存 Git。版本管理、回滚、A/B 测试都是天然支持的。

六、与同类项目对比

Tinyflow 的差异化非常清晰：唯一一个走嵌入式路线、前端基于 Web Component、后端以 Java 为主的项目。这个定位在中国企业市场非常有价值——因为大量企业系统的后端是 Java，前端是各种框架的大杂烩。

七、局限性与风险

7.1 社区规模

662 Stars 对于一个 AI 编排项目来说不算高。对比 Dify 的 90K、LangFlow 的 60K，Tinyflow 的社区规模偏小，这意味着：

• 遇到问题能找到的社区帮助较少
• 预置的节点类型和模板不如大项目丰富
• 长期维护的风险略高（如果核心开发者离开）

7.2 LGPL-3.0 协议限制

LGPL-3.0 比 Apache-2.0 或 MIT 限制更多。如果你修改了 Tinyflow 的核心代码（而不是仅仅使用它），你需要开源修改后的代码。对于大多数「嵌入使用」场景，这不构成问题，但如果需要深度定制，法务团队可能需要介入。

7.3 功能完整度

作为一个轻量组件，Tinyflow 没有提供：

• 内置的用户权限管理
• 模型管理和计费
• 监控仪表盘
• 应用市场/插件市场

这些功能需要你自己实现或集成其他系统。这是「嵌入式」设计的代价——灵活但需要更多 DIY。

八、快速上手

前端集成（3 步）

# 1. 安装
npm install @tinyflow-ai/ui

# 2. 引入
import { Tinyflow } from '@tinyflow-ai/ui';
import '@tinyflow-ai/ui/dist/index.css';

# 3. 初始化
new Tinyflow({ element: '#tinyflow' });

后端集成（Java + Spring Boot）

<!-- pom.xml -->
<dependency>
    <groupId>dev.tinyflow</groupId>
    <artifactId>tinyflow-java-core</artifactId>
    <version>1.0.0-rc.3</version>
</dependency>

// 注册自定义节点处理器
@Component
public class CustomerSegmentHandler implements NodeHandler {
    @Override
    public String getType() { return "customer-segment"; }
    
    @Override
    public NodeOutput execute(NodeInput input) {
        // 调用 LLM 做客户分群
        String result = llmService.analyze(input.getData());
        return NodeOutput.of("segment", result);
    }
}

运行效果

启动后，你的 ERP/CRM 页面会出现一个可拖拽的 AI 工作流编辑器，用户可以通过拖拽节点来编排 AI 工作流，无需写代码。

九、为什么「嵌入式 AI」更适合中国企业

中国企业 IT 有几个鲜明特点，让「嵌入式」比「平台式」更具吸引力：

1. 历史包袱重

大量企业核心系统运行在 Spring Boot + Vue/React 技术栈上，迁移成本极高。Tinyflow 的「不迁移、只嵌入」策略直接绕过了这个障碍。

2. 数据安全敏感

很多企业不允许数据离开内网。Dify 等平台需要独立部署完整的后端基础设施，而 Tinyflow 只需嵌入一个前端组件 + 后端 SDK，数据流转完全在现有系统内完成。

3. 定制化需求强

中国企业的业务逻辑往往非常定制化，标准化平台很难满足。Tinyflow 的节点契约设计允许开发者自由定义节点类型和参数，适应各种定制场景。

4. 渐进式投入

不是每个企业都准备好了 All-in AI。Tinyflow 允许你从一个节点、一个流程开始试水，而不是一次性搭建整个 AI 平台。

十、总结

Tinyflow 的核心价值不在于它有多强大的功能，而在于它选择了一条被忽视但至关重要的路线：嵌入式 AI 编排。

在所有人都在做「AI 平台」的时候，Tinyflow 做了「AI 组件」。这个选择让它天然适合中国企业 IT 的现实——不需要推倒重来，不需要大规模迁移，不需要新建平台，只需要在现有系统里打一针 AI 疫苗。

662 Stars 也许不算多，但对于一个2025年2月才创建的项目来说，这个增速说明市场确实需要这样的方案。随着 Java SDK 1.0 正式版的发布和 Python SDK 的完善，Tinyflow 有望成为中国企业 AI 转型的一个务实选择。

不是每个企业都需要一个 AI 平台。但每个企业都需要 AI 能力。Tinyflow 帮你把后者装进前者。

GitHub: tinyflow-ai/tinyflow（662★）/ tinyflow-ai/tinyflow-java（83★）| Gitee GVP | LGPL-3.0 | 前端 npm: @tinyflow-ai/ui | 后端 Maven: dev.tinyflow:tinyflow-java-core:1.0.0-rc.3