1. 项目概述：从语音到文字的实时桥梁

最近在做一个需要实时语音转文字功能的项目，比如在线会议记录、实时字幕生成或者语音助手。传统的方案要么延迟高得让人抓狂，要么准确率堪忧，部署起来还特别麻烦。经过一番折腾，我最终选定了 Deepgram 和 Next.js 这套组合拳，搭建了一个既稳定又高效的实时语音转文字流水线。简单来说，这个项目的核心就是：在浏览器里，用户一说话，声音就被实时捕捉、发送到云端的高精度语音识别引擎处理，然后几乎无延迟地将文字流推回前端展示。整个过程丝滑流畅，就像在看一场带实时字幕的直播。

Deepgram 这家公司的语音识别 API 在业内口碑不错，特别是在实时流式识别和准确率上表现突出，对各类口音、背景噪音的适应性很强。而 Next.js，作为 React 的全栈框架，其 API Routes 功能让我们能轻松地在服务器端安全地处理 API 密钥，前端用它的现代开发体验也能快速构建交互界面。这套方案特别适合需要快速集成高质量语音识别能力的产品，无论是教育、协作、无障碍访问还是媒体领域，都能找到用武之地。如果你也在为实时语音转文字的需求头疼，或者想了解如何将强大的云端 AI 能力与现代前端框架无缝结合，那接下来的内容应该能给你不少直接的参考。

2. 技术选型与架构设计思路

2.1 为什么是 Deepgram + Next.js？

选择技术栈，核心是看它能否精准、优雅地解决痛点。对于实时语音转文字，我们需要考虑几个维度： 识别精度与速度、客户端兼容性、开发效率、以及成本与安全 。

首先看 Deepgram 。市面上语音识别 API 不少，比如 Google Cloud Speech-to-Text、Azure Speech Services 等。Deepgram 吸引我的点在于它对实时流式传输的原生友好。它的流式 API 设计得非常简洁，建立 WebSocket 连接后，持续发送音频数据块（chunks），就能持续收到识别结果，延迟可以控制在几百毫秒级别。这对于实时字幕或对话场景至关重要。此外，它的模型针对电话、会议、媒体等不同场景有优化，在嘈杂环境下的表现是我测试过的几个服务中比较出色的。当然，它的定价模型也相对清晰，对于中小流量项目比较友好。

然后是 Next.js 。这个选择几乎是顺理成章的。我们需要一个既能快速开发丰富前端交互（录音、展示文字流），又能方便处理后端逻辑（代理 API 请求以隐藏密钥）的框架。Next.js 的 API Routes 功能完美解决了这个问题：你可以在 /pages/api 目录下创建一个文件（比如 deepgram.js ），它就是一个独立的服务器端点。前端向这个自己的端点发送请求，再由这个端点去调用 Deepgram 的 API，这样敏感 API 密钥就完全不会暴露给浏览器。同时，Next.js 对 React 的深度集成、文件路由系统、以及出色的开发体验，能极大提升项目构建速度。

整个架构的流程是这样的：

  1. 前端（Next.js 页面组件） ：使用浏览器 MediaDevices API 获取用户麦克风权限和音频流。
  2. 音频处理 ：将获取到的原始音频流（通常是 MediaStream ）进行加工，比如使用 Web Audio API 或 MediaRecorder 进行编码、分块。为了减少延迟和带宽消耗，我们通常会将音频编码为低比特率的格式，如 audio/webm; codecs=opus 。
  3. 建立代理连接 ：前端通过 WebSocket 连接到我们自己的 Next.js API Route（例如 ws://localhost:3000/api/deepgram ）。
  4. 后端代理（Next.js API Route） ：该 API Route 接收到前端的 WebSocket 连接请求后，使用 Deepgram 的 SDK 或直接建立 WebSocket 连接到 Deepgram 的流式识别端点（ wss://api.deepgram.com/v1/listen ），并在请求头中带上从服务器环境变量读取的 Deepgram API 密钥。
  5. 双向转发 ：此后，这个 API Route 就扮演了一个“管道”的角色。它将从前端收到的音频数据块转发给 Deepgram，同时将 Deepgram 返回的实时转录文本转发回前端。
  6. 前端展示 ：前端接收到转录文本流后，实时更新 UI 界面。

注意 ：直接从前端连接 Deepgram 在技术上是可行的，但绝对不推荐，因为这会暴露你的 API 密钥。任何用户打开浏览器开发者工具都能看到它，可能导致密钥被盗用和产生巨额费用。通过 Next.js API Route 进行代理是保障安全的标准做法。

2.2 核心组件与数据流拆解

为了让这个流水线跑起来，我们需要构建几个关键组件：

  1. 音频捕获与预处理模块（前端） ：负责获取麦克风输入。这里不能直接用原始的 MediaStream 发送，因为数据量太大且格式可能不被 Deepgram 支持。我们需要使用 MediaRecorder 或 AudioContext 进行编码和分块。一个常见的技巧是使用 MediaRecorder 并监听 ondataavailable 事件，定期（例如每 100-200 毫秒）将录制的音频数据块发送出去。同时，要注意处理采样率、声道数等参数，确保符合 Deepgram API 的要求。

  2. WebSocket 连接管理器（前端） ：管理与前端的 Next.js API 代理之间的 WebSocket 连接。它需要处理连接建立、重连逻辑、错误处理，以及定义如何发送音频数据和接收文本数据。

  3. Deepgram 代理服务（Next.js API Route） ：这是架构的核心。它需要同时处理 HTTP 升级为 WebSocket 的逻辑（因为前端通过 ws:// 连接它），以及建立到 Deepgram 的 WebSocket 连接。这里会用到像 ws 这样的 Node.js WebSocket 库。该服务必须高效、稳定，因为所有数据都经过它中转。

  4. 实时文本渲染组件（前端） ：接收流式文本并展示。这里的设计有讲究：是逐字追加显示，还是整句替换？是否需要保留历史记录？如何高亮当前正在识别的部分？通常，Deepgram 返回的数据中会包含每个词的时间戳和置信度，我们可以利用这些信息实现更丰富的交互，比如点击文字跳转到音频的对应位置。

数据流可以概括为： 麦克风 -> MediaRecorder (编码/分块) -> 前端WebSocket -> Next.js API Route (代理) -> Deepgram WebSocket -> AI识别 -> 原路返回文本 。每个环节的延迟累加决定了最终用户体验，因此优化音频分块大小、网络传输和连接稳定性是关键。

3. 实战搭建：从零到一的实现步骤

3.1 环境准备与项目初始化

首先，确保你有一个 Node.js（建议 LTS 版本）环境。然后，我们创建一个新的 Next.js 项目：

npx create-next-app@latest deepgram-realtime-stt
cd deepgram-realtime-stt

安装必要的依赖。我们需要 ws 库在 Next.js API Route 中创建 WebSocket 服务器，还需要 Deepgram 的官方 SDK（可选，用原生 WebSocket 也行，但 SDK 更方便）。

npm install ws @deepgram/sdk
# 或者使用 yarn
yarn add ws @deepgram/sdk

接下来，去 Deepgram 官网注册账号并创建一个项目，获取你的 API 密钥 。这个密钥是访问其服务的凭证。

在项目根目录创建 .env.local 文件，用于存放环境变量（该文件默认被 .gitignore 忽略，确保密钥安全）：

DEEPGRAM_API_KEY=你的_Deepgram_API_密钥

实操心得 ：在开发中，我习惯将 Next.js 的 next.config.js 中配置一下，确保环境变量在服务端和客户端能被正确读取。但注意，以 NEXT_PUBLIC_ 开头的变量才会暴露给浏览器，我们的 DEEPGRAM_API_KEY 绝对不能加这个前缀，它必须仅在服务器端运行。

3.2 构建 Next.js WebSocket 代理端点

这是后端安全通信的核心。我们在 pages/api 目录下创建一个文件，例如 socket.js 。在 Next.js 中，API Route 默认导出的是一个请求处理函数。但为了处理 WebSocket，我们需要做一些特殊处理。

由于 Next.js 的 API Route 运行在无服务器函数环境中，传统的长期 WebSocket 服务器写法需要调整。一个稳定且兼容性好的方案是使用 ws 库，并注意在 Vercel 等无服务器平台上的部署限制（可能需要使用类似 Socket.io 的适配方案，但为了简化，我们先以标准 Node.js 服务器为例，假设部署在可持久运行的服务器上）。

以下是 pages/api/socket.js 的一个简化但核心的逻辑骨架：

import { WebSocketServer } from 'ws';
import { Deepgram } from '@deepgram/sdk';

// 注意：此示例假设在可持久运行 WebSocket 服务器的环境中。
// 在 Vercel 等无服务器环境中，需要使用不同的适配模式（如使用第三方服务或升级到 Next.js 的 `experimental.serverActions` 等特性处理流）。
// 这里展示核心转发逻辑。

export default function handler(req, res) {
  // 检查是否为 WebSocket 升级请求
  if (req.headers.upgrade !== 'websocket') {
    res.status(426).send('请使用 WebSocket 连接');
    return;
  }

  // 初始化一个 WebSocket 服务器（在实际生产部署中，这部分初始化逻辑可能需要放在全局或单独的文件中，避免每次请求重复创建）
  // 此处为演示核心数据转发逻辑
  const wss = new WebSocketServer({ noServer: true });
  wss.handleUpgrade(req, req.socket, Buffer.alloc(0), (ws) => {
    ws.on('message', async (message) => {
      // 当收到来自前端（浏览器）的消息（音频数据块）
      try {
        // 1. 连接到 Deepgram
        const deepgramApiKey = process.env.DEEPGRAM_API_KEY;
        const deepgram = new Deepgram(deepgramApiKey);
        // 创建 Deepgram 实时连接。这里简化了，实际中连接应该复用。
        const dgConnection = deepgram.transcription.live({
          encoding: 'webm/opus', // 根据前端发送的音频格式调整
          sample_rate: 48000,
          channels: 1,
          interim_results: true, // 获取中间结果，实现“逐字打出”的效果
          punctuate: true,
          model: 'nova-2', // 选用合适的模型
        });

        // 2. 将前端发来的音频数据转发给 Deepgram
        dgConnection.send(message);

        // 3. 监听 Deepgram 返回的转录结果，并转发给前端
        dgConnection.addListener('transcriptReceived', (transcription) => {
          const data = JSON.parse(transcription);
          const transcript = data.channel.alternatives[0].transcript;
          if (transcript && ws.readyState === ws.OPEN) {
            ws.send(JSON.stringify({ type: 'transcript', data: transcript, is_final: data.is_final }));
          }
        });

        dgConnection.addListener('error', (error) => {
          console.error('Deepgram connection error:', error);
          ws.send(JSON.stringify({ type: 'error', message: '识别服务出错' }));
        });

        dgConnection.addListener('close', () => {
          console.log('Deepgram connection closed');
        });

        // 4. 当浏览器连接关闭时，也关闭 Deepgram 连接
        ws.on('close', () => {
          dgConnection.finish();
        });

      } catch (error) {
        console.error('Proxy error:', error);
        ws.send(JSON.stringify({ type: 'error', message: '代理服务内部错误' }));
      }
    });

    ws.on('error', console.error);
  });
}

重要提示 ：上面的代码是一个 概念演示 ，直接用在生产环境会有问题。主要问题在于，Next.js 的无服务器函数是短暂的，而 WebSocket 是持久连接。在生产中，你可能需要：

  1. 使用一个独立的 Node.js 服务器（如 Express + ws）专门处理 WebSocket，然后让 Next.js 前端连接这个独立服务器。
  2. 或者使用托管服务（如 Pusher, Ably, Socket.io 的云服务）来管理 WebSocket 连接，Next.js API Route 只负责与 Deepgram 通信并通过这些服务转发消息。
  3. 或者利用 Next.js 的 Edge Functions 和更新的流式响应 API 来模拟双向通信，但这更复杂。

为了项目快速启动和原型验证，我们可以先在开发环境下运行一个简单的独立 WebSocket 服务器，或者使用上述第三方服务。本文重点在于理清流程，生产部署方案需根据实际情况选择。

3.3 前端音频捕获与 WebSocket 集成

前端部分，我们创建一个页面组件，例如 pages/index.js 。它的核心任务是：

  1. 请求麦克风权限并获取音频流。
  2. 处理音频流，将其编码并分块。
  3. 连接到我们的 WebSocket 代理。
  4. 发送音频数据块，并接收/显示转录文本。

这里是一个高度简化的示例，聚焦于核心逻辑：

import { useState, useRef, useEffect } from 'react';

export default function Home() {
  const [isRecording, setIsRecording] = useState(false);
  const [transcript, setTranscript] = useState('');
  const [socket, setSocket] = useState(null);
  const mediaRecorderRef = useRef(null);
  const audioChunksRef = useRef([]);
  const socketRef = useRef(null);

  // 初始化 WebSocket 连接
  const setupSocket = () => {
    // 注意：这里连接的是我们自己的 Next.js API 代理端点（假设我们按上述方案调整了部署）
    const ws = new WebSocket('ws://localhost:3000/api/socket'); // 开发环境地址
    ws.onopen = () => {
      console.log('连接到代理服务器成功');
      setSocket(ws);
    };
    ws.onmessage = (event) => {
      const data = JSON.parse(event.data);
      if (data.type === 'transcript') {
        // 实时更新转录文本。如果 is_final 为 true，可以换行或做其他处理。
        setTranscript(prev => prev + ' ' + data.data);
      } else if (data.type === 'error') {
        console.error('服务器错误:', data.message);
      }
    };
    ws.onerror = (error) => console.error('WebSocket 错误:', error);
    ws.onclose = () => {
      console.log('WebSocket 连接关闭');
      setSocket(null);
    };
    socketRef.current = ws;
  };

  // 开始录音
  const startRecording = async () => {
    try {
      const stream = await navigator.mediaDevices.getUserMedia({ audio: true });
      // 配置 MediaRecorder，使用 Opus 编码的 WebM 格式，Deepgram 支持良好
      const options = { mimeType: 'audio/webm; codecs=opus' };
      const mediaRecorder = new MediaRecorder(stream, options);
      mediaRecorderRef.current = mediaRecorder;
      audioChunksRef.current = [];

      mediaRecorder.ondataavailable = (event) => {
        if (event.data.size > 0) {
          audioChunksRef.current.push(event.data);
          // 当有数据可用时，通过 WebSocket 发送
          if (socketRef.current && socketRef.current.readyState === WebSocket.OPEN) {
            // 注意：这里发送的是 Blob 数据。在实际中，可能需要转换为 ArrayBuffer 或 Base64。
            // Deepgram SDK 或 API 通常接收的是 ArrayBuffer。
            const reader = new FileReader();
            reader.onloadend = () => {
              const arrayBuffer = reader.result;
              socketRef.current.send(arrayBuffer);
            };
            reader.readAsArrayBuffer(event.data);
          }
        }
      };

      // 每 200 毫秒触发一次 ondataavailable 事件，发送一个数据块
      mediaRecorder.start(200);
      setIsRecording(true);
      console.log('开始录音...');
    } catch (err) {
      console.error('无法获取麦克风权限:', err);
    }
  };

  // 停止录音
  const stopRecording = () => {
    if (mediaRecorderRef.current && isRecording) {
      mediaRecorderRef.current.stop();
      mediaRecorderRef.current.stream.getTracks().forEach(track => track.stop());
      setIsRecording(false);
      console.log('停止录音');
    }
  };

  useEffect(() => {
    // 组件挂载时建立 WebSocket 连接
    setupSocket();
    return () => {
      // 组件卸载时关闭连接
      if (socketRef.current) {
        socketRef.current.close();
      }
    };
  }, []);

  return (
    <div>
      <h1>实时语音转文字演示</h1>
      <button onClick={isRecording ? stopRecording : startRecording} disabled={!socket}>
        {isRecording ? '停止录音' : '开始录音'}
      </button>
      <p>连接状态: {socket ? '已连接' : '连接中...'}</p>
      <div>
        <h2>实时转录文本：</h2>
        <p>{transcript}</p>
      </div>
    </div>
  );
}

这段前端代码实现了基本的录音、数据分块发送和文本接收显示。关键点在于 MediaRecorder 的配置和数据发送格式。 audio/webm; codecs=opus 格式在压缩率和质量之间取得了很好的平衡，并且被 Deepgram 广泛支持。发送时，我们将 Blob 转换为 ArrayBuffer 再通过 WebSocket 发送，这是二进制数据传输的常用方式。

4. 核心优化与生产环境考量

4.1 音频处理与网络传输优化

原型跑通后，要提升体验，必须在音频处理和网络层面下功夫。

音频参数优化 ： MediaRecorder 的启动参数和音频轨道约束很重要。更高的比特率和采样率意味着更好的音质和识别精度，但也带来更大的数据量和延迟。需要根据场景权衡。例如，对于语音对话，单声道、16kHz 采样率已经足够，可以显著减少数据量。

// 更优化的音频获取约束
const audioConstraints = {
  audio: {
    channelCount: 1, // 单声道
    sampleRate: 16000, // 16kHz 采样率，Deepgram 常用
    echoCancellation: true,
    noiseSuppression: true,
    autoGainControl: true
  }
};
const stream = await navigator.mediaDevices.getUserMedia(audioConstraints);

数据块大小与发送频率 ： mediaRecorder.start(200) 中的 200 表示每 200 毫秒生成一个数据块。这个值太小会导致网络包过多，增加开销；太大会增加端到端延迟。通常 100-500 毫秒是一个合理的范围。可以尝试动态调整，在网络状况好时用更小的块来降低延迟。

WebSocket 重连与状态管理 ：网络是不稳定的。必须实现健全的 WebSocket 重连逻辑，包括指数退避策略（例如，连接失败后等待 1秒、2秒、4秒...再重试）。同时，要管理好连接状态（连接中、已连接、断开、重连中），并在 UI 上给予用户明确反馈。

前端数据缓冲 ：在发送音频数据前，可以建立一个小的缓冲区。这样在网络瞬时波动时，可以暂存数据，待连接恢复后一并发送，避免数据丢失。但要注意缓冲区不能太大，否则会增加延迟。

4.2 错误处理与用户体验打磨

一个健壮的系统必须能妥善处理各种异常。

错误分类处理 ：

  • 权限错误 ：用户拒绝麦克风访问。需要清晰的引导文案和重试按钮。
  • 网络错误 ：WebSocket 连接断开或超时。除了自动重连，应提示用户“网络连接已断开，正在尝试重连...”。
  • 服务器/API 错误 ：Deepgram 服务不可用或返回错误（如无效的音频格式、配额用尽）。代理服务器应捕获这些错误，并向前端发送结构化的错误信息，前端根据错误类型展示友好提示。
  • 音频设备错误 ：麦克风被其他应用占用或突然不可用。需要监听 MediaStream 的 onended 事件，并提示用户检查设备。

UI/UX 细节 ：

  • 实时反馈 ：在录音时显示一个动态的声波动画，让用户知道系统正在工作。
  • 中间结果与最终结果 ：利用 Deepgram 返回的 is_final 标志。 is_final: false 是中间结果（正在识别的当前句子），可以高亮或放在一个临时区域； is_final: true 是最终确认的句子，可以移动到历史记录区域，并开始新的一行。这能有效改善“文字来回跳动”的体验。
  • 标点与格式化 ：虽然 Deepgram 开启了 punctuate: true ，但返回的文本可能仍需一些后处理，比如确保句首大写。可以写一个简单的后处理函数。
  • 历史记录与导出 ：提供区域展示所有已确认的转录文本，并支持一键复制或导出为文本文件。

性能监控 ：在开发中，可以记录关键指标：从用户说话到文字显示的平均延迟、WebSocket 重连次数、音频数据块大小分布。这些数据是进一步优化的依据。

5. 部署方案与进阶扩展

5.1 生产环境部署策略

如前所述，将包含持久 WebSocket 连接的 Next.js 应用部署到 Vercel 这样的无服务器平台会遇到挑战。以下是几种可行的生产部署方案：

  1. 独立 WebSocket 服务器 + Next.js 前端分离部署 ：

    • 使用 Node.js + Express + ws 库（或 Socket.io ）编写一个独立的 WebSocket 代理服务器。这个服务器专门负责维持与浏览器和 Deepgram 的双向连接。
    • 将 Next.js 前端应用部署到 Vercel 或 Netlify。
    • 将独立的 WebSocket 服务器部署到可以长期运行的平台，如 DigitalOcean Droplet、AWS EC2、Google Cloud Run（配置为常驻实例）或 Railway。
    • 前端连接时，WebSocket 地址指向这个独立服务器的域名或 IP。这是最传统但也最可控的方式。

  2. 使用托管 WebSocket 服务（推荐用于快速上线） ：

    • 使用 Pusher、Ably 或 Socket.io Cloud 等服务。它们提供了稳定、可扩展的 WebSocket 基础设施。
    • 架构变为：浏览器 <-> Pusher Channels；Next.js API Route (Serverless) <-> Pusher Channels；Next.js API Route <-> Deepgram。
    • Next.js API Route 接收到前端的 HTTP 请求（通过 Pusher 的客户端事件触发），然后去调用 Deepgram，再将结果通过 Pusher 推回前端。这样，Next.js 函数无需维持长连接，完美适配无服务器环境。虽然增加了第三方服务成本，但省去了服务器运维的麻烦。

  3. Next.js 自定义服务器（适用于对 Next.js 有深度控制的情况） ：

    • 在 next.config.js 中关闭默认的无服务器路由，使用自定义的 Node.js 服务器（如 server.js ），在其中同时启动 Next.js 应用和你的 WebSocket 服务器。
    • 然后将整个应用部署到可以运行持久进程的平台上（如 AWS EC2, Docker 容器部署到 Kubernetes）。这失去了 Vercel 的无服务器便利性，但获得了完全的控制权。

环境变量与安全 ：在生产环境中，确保 DEEPGRAM_API_KEY 等敏感信息通过部署平台的环境变量设置，而不是写在代码里。在 Next.js 中，通过 process.env.DEEPGRAM_API_KEY 访问。

5.2 功能扩展与场景化应用

基础流水线搭建完成后，可以根据具体业务场景进行功能扩展：

  1. 多语言识别 ：Deepgram 支持多种语言。可以在建立连接时通过 language 参数指定，如 language: 'zh' 用于中文普通话， language: 'en' 用于英语。甚至可以设计 UI 让用户动态切换。

  2. 说话人分离（Diarization） ：在会议转录场景中，区分“谁在说话”至关重要。Deepgram 的某些模型支持说话人分离。在请求参数中设置 diarize: true ，返回的结果中就会包含 speaker 字段，你可以用不同颜色或标签来区分不同说话人的内容。

  3. 关键词搜索与触发 ：设置 keywords 参数，让 Deepgram 特别关注某些词汇（如产品名、命令词），并提高其识别置信度或在结果中标记出来。这可用于构建语音指令系统。

  4. 实时翻译管道 ：将 Deepgram 识别出的文本，实时发送到另一个翻译 API（如 Google Translate API 或 DeepL API），形成“语音 -> 英文文本 -> 中文文本”的实时翻译流水线，用于跨语言会议。

  5. 与后端数据库集成 ：将最终确认的转录文本保存到数据库（如 PostgreSQL, MongoDB），并打上时间戳、会话 ID、用户 ID 等元数据标签，便于后续检索、分析和生成会议纪要。

  6. 音频流处理 ：除了麦克风输入，还可以扩展为处理来自网络音频流（如在线电台、直播流）的实时转录。这需要后端服务能够抓取和解码音频流，然后以类似的方式喂给 Deepgram。

这个由 Deepgram 和 Next.js 构建的实时语音转文字流水线，其核心价值在于将复杂的云端 AI 能力，通过清晰的前后端分工和安全的通信管道，变成了一个可以被现代 Web 应用轻松集成的模块。从技术验证到生产部署，每一步都需要在功能、性能、成本和复杂度之间做出权衡。我个人的体会是，起步阶段使用托管 WebSocket 服务来规避基础设施的复杂性，能让你更专注于核心业务逻辑和用户体验的打磨。当流量增长到一定规模后，再考虑优化和自建基础设施也不迟。最后，记得充分利用 Deepgram 提供的各种模型和参数进行测试，找到最适合你应用场景和音频特性的配置，这是提升识别准确率最直接有效的方法。

Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

大模型 API 聚合服务从工具走向基础设施：星链4SAPI的企业价值

它涵盖 GPT、Claude、Gemini 等主流模型，接入方式与 OpenAI 官方接口兼容，同时支持多模态数据处理、线路优化、人民币结算、企业级账务管理、国内备案主体等条件。迁移成本同样不可忽视。尤其是金融、教育、医疗、政企服务、ToB SaaS 等行业，供应商资质、备案状态、数据流向、费用凭证及合同主体都会被反复核查。从这个角度看，星链4SAPI 值得被重点评估，是因为它把国内企业真正关心的

avatar AI Agent技术社区
cover

每日AI新闻推送 | 2026年6月12日

avatar AI Agent技术社区
cover

阿里成立 Token Foundry 事业部，CEO 亲自挂帅：大模型进入商业化冲刺阶段

avatar AI Agent技术社区