Transcript

00:00:00(欢快的音乐)
00:00:02- 大家好,我是 Malte,Vercel 的首席技术官。
00:00:16感谢各位今天加入我们。
00:00:18在一月初,我们给公司里的每个人下达了一项指令:
00:00:21想办法让你们的产出翻倍。
00:00:24大家所构建出的成果持续让我们感到惊叹。
00:00:27几乎每个团队都构建了一个代理来处理复杂的工作,
00:00:30而且大多数都是任何人都能使用的 Slack 机器人。
00:00:34但我们遇到了一个问题。
00:00:35每个人都在一遍又一遍地做着
00:00:38同样的重复性基础工作。
00:00:40当有人构建了一个代理后,
00:00:41你就必须去搞定 Slack 的复杂逻辑,
00:00:43这比听起来要难得多。
00:00:45你需要理解消息回复、表情反应,
00:00:47机器人如何匹配消息,以及如何处理状态。
00:00:50接着就会有人问:
00:00:51“嘿,能把那个代理连接到 GitHub 吗?”
00:00:53于是整个过程又要在 GitHub 的 API 上
00:00:55重新来过。
00:00:56逻辑是一样的,但平台代码完全不同。
00:00:59我们很快意识到,这些聊天 API
00:01:01表面上看起来很相似,
00:01:03但底层逻辑却截然不同。
00:01:05Slack 支持原生流式传输。
00:01:06你可以直接将生成的 Token
00:01:09随着 LLM 的生成实时推送到消息中。
00:01:10而在 Discord,你必须不断地发送、编辑、发送、编辑。
00:01:14GitHub 则根本不支持流式传输。
00:01:16Slack 有模态框,Discord 没有。
00:01:18Microsoft Teams 只提供只读的表情反应。
00:01:21这些不只是小瑕疵,而是每个平台
00:01:23运作方式的根本差异。
00:01:26所以,即使是一个简单的代理,
00:01:28你也最终需要编写大量的逻辑,
00:01:31仅仅是为了让它在不同的工具中可用。
00:01:33这简直是场噩梦。
00:01:34而且这不仅仅是 Vercel 面临的问题。
00:01:36每家公司都必须弄清楚
00:01:38如何将他们的代理推送到
00:01:40员工已经开展工作的各个界面。
00:01:42这意味着聊天、代码审查、问题跟踪等等。
00:01:45AI SDK 为模型提供商解决了类似的问题。
00:01:48你只需编写一次代码,它就能处理
00:01:50所有的 API 差异,
00:01:51无论你调用的是 GPT、Claude 还是 Gemini。
00:01:54Chat SDK 则为交互式代理实现了同样的功能。
00:01:58它是用于在 Slack、GitHub、Linear、Discord、Telegram、
00:02:01WhatsApp 等平台上进行代理交互的
00:02:04统一 API。
00:02:06你只需构建代理,Chat SDK 就会将其交付给
00:02:09用户已经在使用的应用程序中。
00:02:11Fernando 在过去几周里一直在构建
00:02:15v0 后台代理,
00:02:16他将告诉你为什么 Chat SDK
00:02:18是该技术栈中至关重要的一部分。
00:02:21(欢快的音乐)
00:02:24(音乐继续)
00:02:28当我开始构建 v0 后台代理时,
00:02:34我的目标是让你能从 Slack 中标记 v0
00:02:36来开启拉取请求(PR)。
00:02:38我想要一个通用的编码代理,
00:02:40它可以运行在后台,
00:02:42支持任何代码库和任何语言。
00:02:45于是我开始构建,
00:02:47并将第一个版本的 v0 Slack 应用
00:02:49发给了我的朋友们。
00:02:51他们问的第一件事就是:
00:02:53“我能在 Linear 的任务单里也用这个吗?”
00:02:56“我能在 GitHub PR 的评论里通过标签调用它吗?”
00:02:58这让我想起我第一次发布移动应用时,
00:03:02人们开始问是否也能在网页端使用它。
00:03:05很明显,v0 必须无处不在。
00:03:09用户预期已经发生了变化。
00:03:11所以我必须做出选择。
00:03:14我们是一个平台接一个平台地构建 v0 后台代理,
00:03:18还是通过一个跨平台的统一 API
00:03:22一次性完成构建?
00:03:24就像聊天代理领域的 React Native 一样?
00:03:27事实证明,我多年来一直
00:03:30在使用 React Native 构建跨平台应用。
00:03:34这个问题对我来说并不新鲜。
00:03:36这正是 Chat SDK 的用武之地。
00:03:39有了 Chat SDK,
00:03:40我可以专注于构建 v0 后台代理,
00:03:43而花更少的时间
00:03:45去操心每个平台独特的 API。
00:03:48那么,这在底层是如何运作的呢?
00:03:50下面由 Matt 为大家展示更多细节。
00:03:53(欢快的音乐)
00:03:55- 大家好。
00:04:11和 Fernando 一样,我们先从 Slack 开始。
00:04:14我提到了我的机器人,
00:04:16然后我得到了一个非常简单的 Hello World 回复。
00:04:21我知道,这简直改变了游戏规则。
00:04:23如果你看一下代码,
00:04:24你会发现创建这个机器人是多么容易。
00:04:28我所要做的就是创建一个新的聊天实例,
00:04:32并添加一个提及(on mention)监听器,
00:04:35然后将 Hello World 回复发回到线程中。
00:04:38就这么简单。
00:04:39但我们不希望开发者只构建纯文本机器人。
00:04:43我们想要丰富的原生体验,
00:04:45充分利用每个平台的特性。
00:04:48开发者热爱 JSX。
00:04:51所以我们将 JSX 引入了 Chat SDK。
00:04:55现在你可以像往常一样使用组件进行构建。
00:04:58我们来添加两个按钮。
00:04:59在下面这里你可以看到,
00:05:03我打算将我们的 Hello World 消息
00:05:05改为带有“继续”按钮的 Hello World 卡片,
00:05:10以及一个“取消”按钮。
00:05:11我们还要添加一个动作监听器,
00:05:14当点击按钮时,它会显示用户的全名,
00:05:17并提示已点击继续。
00:05:19回到 Slack,我再次提到了我的机器人。
00:05:24正如所料,我们得到了完全符合预期的结果。
00:05:29这些组件是以原生方式渲染的。
00:05:32我点击继续,机器人立即处理了该动作。
00:05:36但现在,有趣的地方来了。
00:05:41如果我想在 Discord 上获得完全相同的体验呢?
00:05:45我只需添加 Discord 适配器。
00:05:47就这样。
00:05:48现在,如果我回到我的 Discord 频道,
00:05:55我提到我的机器人,
00:05:57完全相同的 UI 就会在 Discord 中原生渲染。
00:06:02支持一个全新的平台,代码变更量为零。
00:06:07这很酷。
00:06:08但让我们来谈谈代理。
00:06:10这是我使用 AI SDK 构建的一个简单代理。
00:06:14代理需要流式传输。
00:06:17有了 Chat SDK,流式传输变得轻而易举。
00:06:20我创建一个流并将其发送到线程。
00:06:23就这样。
00:06:24我不需要去查 Slack 是如何处理流式传输的,
00:06:27也不需要看 Discord 是如何处理部分更新的。
00:06:30我只使用了一个 API。
00:06:32回到 Slack,如果我提到机器人,
00:06:35我们会看到它以原生流式的方式将响应返回给我们。
00:06:40但为什么止步于此呢?
00:06:42如果我想在 WhatsApp 或 Telegram 等平台上
00:06:45给我的代理发私信呢?
00:06:49有了 Chat SDK,这很简单。
00:06:52我添加一个私信(On Direct Message)监听器和所需的适配器。
00:06:56现在,任何私信给代理的人都能获得同样的体验。
00:07:02如果我在网页端打开 WhatsApp 并说:
00:07:06“嗨,你好吗?”
00:07:08我们会看到代理使用我们构建的逻辑
00:07:12来回复我们的私信。
00:07:14既然我们已经构建了一个代理,
00:07:16为什么不开启一个拉取请求(PR)呢?
00:07:18但在那之前,
00:07:20如果我在 WhatsApp 上聊天的那个代理
00:07:24也能审查我的代码呢?
00:07:25所需要的只是一个 GitHub 适配器。
00:07:28我来到这里,添加 GitHub 适配器,
00:07:32我就把我的代理带到了一个全新的平台。
00:07:35如果我打开 GitHub 并查看这个 PR,
00:07:39我可以在评论中提到该代理,
00:07:42它就会使用我们之前构建的私信监听器
00:07:45来进行响应。
00:07:46Slack、Discord、WhatsApp、Telegram、GitHub。
00:07:51想一想这些 API 之间有多大的差异。
00:07:56但只需一个文件和几行代码,
00:07:59我们就让代理支持了所有这些平台。
00:08:01有了 Chat SDK,你只需编写一次代理体验,
00:08:06就可以通过单一 API 将其部署到任何地方。
00:08:09访问 chat-sdk.dev 查看文档和模板。
00:08:14感谢收听。
00:08:15我非常期待看到你们构建的作品。
00:08:17(欢快的音乐)

Key Takeaway

Chat SDK 是一个用于构建跨平台交互式 AI 代理的统一 API 框架,让开发者能够编写一次代码并将其无缝部署到 Slack、Discord、GitHub 等多个协作工具中。

Highlights

Vercel 推出 Chat SDK,旨在解决在不同聊天平台部署 AI 代理时面临的重复性基础工作。

不同平台(如 Slack、Discord、GitHub)的 API 逻辑存在显著差异,例如流式传输支持和 UI 组件处理方式各不相同。

Chat SDK 提供统一的 API,允许开发者只需编写一次代码,即可在多个平台上运行代理,类似于聊天代理领域的 React Native。

支持使用 JSX 和组件化开发,让开发者能够利用原生平台特性构建丰富的交互式 UI,而非仅限于纯文本。

SDK 内置了对消息监听、流式响应、动作处理以及私信功能的跨平台支持。

通过适配器模式,开发者可以轻松地将代理扩展到 WhatsApp、Telegram 和 GitHub PR 评论等新环境。

Timeline

开发痛点与 Chat SDK 的诞生背景

Vercel CTO Malte 介绍了公司内部在提升产出过程中遇到的挑战,几乎每个团队都构建了代理但在跨平台适配上浪费了大量精力。他指出 Slack、Discord 和 GitHub 等平台的底层逻辑截然不同,例如 Slack 支持原生流式传输而 Discord 则需要不断编辑消息。开发者不得不为了每个平台重新编写复杂的逻辑来处理状态、消息匹配和表情反应。这种高度重复且困难的基础工作被形容为一场“噩梦”,阻碍了工具的快速分发。因此,Vercel 意识到需要一个类似于 AI SDK 的统一方案来屏蔽不同聊天平台的 API 差异。

Chat SDK 的定位与 v0 后台代理案例

本节介绍了 Chat SDK 的核心价值,即作为连接模型提供商与用户交互界面的统一桥梁。开发者 Fernando 分享了他在构建 v0 后台编码代理时的经历,最初用户希望在 Slack 之外的 GitHub 和 Linear 中也能使用该功能。他将 Chat SDK 类比为聊天领域的 React Native,强调了跨平台统一 API 的必要性。通过使用该 SDK,他能够将精力集中在完善 v0 代理的核心逻辑上,而不是浪费在调试各个平台的特定 API。这标志着 AI 应用开发范式的转变,即从“逐一适配”转向“一次构建,到处运行”。

技术演示:从基础机器人到 JSX 组件

工程师 Matt 通过实际代码演示了 Chat SDK 的易用性,首先展示了一个极其简练的 Slack “Hello World” 机器人实现。他引入了开发者熟悉的 JSX 语法,通过组件化的方式在聊天界面中渲染按钮和卡片等原生 UI 元素。代码中展示了如何添加提及监听器以及处理用户点击按钮后的动作反馈,确保交互体验流畅且具有原生感。演示证明了开发者不再受限于简单的文本交互,可以轻松构建复杂的交互流程。这种声明式的开发方式极大降低了构建富媒体 AI 插件的门槛。

跨平台扩展与高级功能实现

在最后的演示中,Matt 展示了如何在不修改逻辑代码的情况下,仅通过添加适配器就让代理在 Discord、WhatsApp 和 GitHub 上运行。他重点介绍了流式传输(Streaming)的实现,SDK 自动处理了不同平台对部分消息更新的兼容性。随后,他演示了如何通过私信监听器让代理在 WhatsApp 中回复消息,并将其扩展到 GitHub PR 的评论区进行代码审查。只需一个文件和少量代码,代理就能贯穿办公协作、即时通讯和代码管理等多个场景。视频最后鼓励开发者访问官网获取模板,共同探索 AI 代理的无限可能。

Community Posts

View all posts