Transcript
00:00:00大家好。
00:00:19欢迎来到新一期的 Vercel 社区会议。
00:00:22本周由 Malta 和 Matt 加入，提醒大家，如果您正在
00:00:27参与聊天，请遵守行为准则，我们欢迎任何
00:00:31关于 Chat SDK 的问题。
00:00:34欢迎你们。
00:00:35太棒了。
00:00:36谢谢邀请。
00:00:37大家好。
00:00:38我是 Matt。
00:00:39今天 Malta 也和我一起来聊聊 Chat SDK 的所有内容。
00:00:45如果您还不了解它，它是一个我们构建的开源 TypeScript 库，旨在让您
00:00:50无论用户在什么平台上，都能将智能体带给他们。
00:00:55首先，我想听听它的起源故事。
00:00:58这一切是怎么开始的呢？
00:01:00是的。
00:01:01嘿，再次大家好，我是 Malta。
00:01:03我既是 Vercel 的 CTO，也是 Chat SDK 的作者。
00:01:07所以我今天是以这个身份在这里。
00:01:11别问任何关于战略的问题。
00:01:14Chat SDK 的起源可以追溯到整个 2025 年。
00:01:23我们当时在 Slack 机器人上投入了越来越多的精力。
00:01:26大家总是问，我们能把这些发布到 Slack 以外的其他平台吗？
00:01:32最终的回答总是“不”，因为这需要做大量的工作，而带来的价值只有一点点。
00:01:39而且我们自己也不会为此而折腾。
00:01:40这会变得更加困难。
00:01:44所以我们从未真正那样做。
00:01:46当我观察这些应用时，我一直在想，我们能不能以一种好的方式
00:01:53一次性把这个构建出来？
00:01:57但当我研究所有这些 API 时，我真的感到非常害怕，因为要构建在它们之上，
00:02:04它们看起来太令人生畏且错综复杂了。
00:02:10快进到去年年底，Opus 4.5 发布了，我就想，时机到了。
00:02:16这就是我的机会。
00:02:17当时正是假期。
00:02:18确实是在假期。
00:02:19是的。
00:02:20我对 Malte 说，这看起来会是什么样？
00:02:23我们要怎么做呢？
00:02:25而你带回来的不是一个答案，而是一个真正的库来回答我的问题。
00:02:31没错。
00:02:32是的。
00:02:33所以我在进行黑客式开发。
00:02:37这类事情的问题在于，构建它实际上仍然非常痛苦，
00:02:43因为有真实的 API，而它们并不真正在训练数据中。
00:02:46所以你仍然必须自己去摸索很多东西。
00:02:50至少大部分工作已经被接管了。
00:02:55所以我还是决定试一试，并在假期期间构建了 Chat SDK 的初始版本。
00:03:01又花了一个月左右的时间才准备好发布。
00:03:02但这大概就是它的起源故事。
00:03:07所以我想，很明显这是必要的，但它也太难构建了。
00:03:08所以我觉得很明显这是必需的，但构建起来也确实让人望而却步。
00:03:12而人工智能帮我们突破了最后的难关。
00:03:15Vercel 的每个人都是构建者。
00:03:16Amy，你来开始我们的第一个问题吧？
00:03:17好的。
00:03:20你知道，每当我们有新的开源项目时，我觉得最常见的问题之一
00:03:21就是它有多开放？
00:03:26这是否仅限于 Vercel？
00:03:29我们需要使用 Vercel 的 AI 基础设施吗，还是我可以在任何地方使用它？
00:03:32绝对可以。
00:03:37我认为特别是对于 Chat SDK，它只是一个 TypeScript 库，它甚至不
00:03:38绑定到任何前端或后端框架。
00:03:44你可以在任何 JavaScript 应用程序中使用它。
00:03:48你可以在任何可以托管 JavaScript 的地方托管它。
00:03:53你可以使用 Chat SDK，除了处理 webhook 事件的无服务器函数外，
00:03:55你可以使用聊天 SDK，它与云服务的其他基元没有任何绑定，
00:04:03除了用于处理 Webhook 事件的无服务器函数之外。
00:04:07你觉得呢，Malta？
00:04:08我们甚至不是那个无服务器函数，对吧？
00:04:09它真的只是一个库。
00:04:10就像 React 一样，你可以在任何地方使用它，
00:04:13它在任何方面都不与结构绑定。
00:04:19你可以把它看作，Chat SDK 本身不是智能体。
00:04:23它只是一个层，用来接收 webhook 事件，并将其上下文传递给你用
00:04:27任何框架构建的智能体。
00:04:33我认为一个很好的例子是，最近我们构建了 Teams 适配器的第一个版本，
00:04:38我认为这有一个非常好的例子，就是最近，
00:04:42我们构建了第一个版本的 Teams 适配器，现在 Microsoft Teams 团队也已经接手了它。
00:04:52我真的很感激这一点，因为我之前一直在努力
00:04:53让 Teams 正常工作，而他们不仅接手了维护工作，还重写了
00:05:00适配器，因为他们当时发布了新的 API，他们基本上只是把现有的
00:05:05实现移植到了新的 API 上，我认为这对他们来说是一个胜利。
00:05:13所以他们在新 API 上获得了分发，希望比旧的东西有更少的用户。
00:05:15而且我们非常感激，因为在所有我们支持的平台上使其变得出色需要相当大的努力。
00:05:20这对开发者来说也是一个巨大的胜利，因为他们不需要去学习新的 Microsoft Teams
00:05:25API，但他们的应用程序或智能体现在受益于新的适配器。
00:05:27这对开发者来说是个巨大的胜利，因为他们无需学习新的微软 Teams
00:05:32API，但他们的应用程序或代理现在就能受益于这个新适配器。
00:05:37这实际上完全向后兼容。
00:05:38所以你除了升级 Chat SDK 之外什么都不需要做，就能利用
00:05:39新的 API。
00:05:41而且，你知道，他们可能遇到了一些边缘情况或其他什么，
00:05:47因为他们是实际的 Teams 团队，他们最清楚如何使用他们的 API。
00:05:48但作为 Chat SDK 的用户，你不一定需要知道这些。
00:05:51顺便说一下，我认为 Chat SDK 的价值之一显然是它是
00:05:56为了这种多平台模式而设计的。
00:06:00但我其实一点也不会惊讶，大多数用户实际上并不是那样使用的。
00:06:05他们只是在同一个时间为一个平台使用它。
00:06:08但是，你知道，所有这些 API 都太……它们通常要么设计得很烂，
00:06:11要么没有被设计成以一种惯用的 TypeScript 方式使用。
00:06:16所以人们在使用 Chat SDK 时感到更容易，即使它只用于其中一个适配器。
00:06:23是的。
00:06:28我们用 v0 做的就是这样。
00:06:29我们用 Chat SDK 为 Slack 构建了 v0。
00:06:35我认为最好的一点是，如果我们选择进入另一个平台，
00:06:36进入那个新平台的工程工作量非常小。
00:06:37大家经常问我的下一个问题是，JSX。
00:06:38所以在 Chat SDK 之前，我构建了很多 Slack 智能体，我不得不使用 BlockKit，
00:06:41而且我习惯了 React，我也热爱 JSX。
00:06:47这可能是 Chat SDK 带来的最大好处之一，也是我对此感到非常兴奋的原因。
00:06:51那是什么感觉？
00:06:56我在使用 Chat SDK 之前构建过很多 Slack 智能体，当时必须使用 BlockKit，而且我习惯了 React，所以我很喜欢 JSX。
00:07:04我显然想支持交互式元素，所以我首先在思考
00:07:06如何在 Chat SDK 内部正确地抽象这些元素。
00:07:11我脑子里一直在进行的两件事是，首先，
00:07:13应该有很好的 Markdown 支持，因为 Chat SDK 显然可以用于非 AI 应用程序，
00:07:15但它确实是意味着以这种方式使用，即你将其挂载到智能体上。
00:07:22所以对于这一点，Markdown 非常重要。
00:07:28另一件事是，我希望普通的 TypeScript 开发人员能有很好的体验。
00:07:36因此，这个想法基本上是说，好吧，我们确实有一个内部表示
00:07:42可以渲染到不同的聊天机器人的 UI。
00:07:48然后将该中间表示映射到底层 API，比如 BlockKit。
00:07:53另一方面，基本上拥有所谓的前端，这是作为工程师的你所使用的表示。
00:07:55另一个考量是，我希望用 TypeScript 就能有很棒的开发体验。
00:08:01所以思路本质上是，我们拥有一个内部 UI 表示层，
00:08:08你将 Markdown 解析为 AST，然后将其渲染为 BlockKit，或者你拥有 JSX，
00:08:16然后将该中间表示映射到底层 API，例如 BlockIt。
00:08:22对于那些不太了解 JSX 是如何工作的人，JSX 本质上是函数调用的语法糖。
00:08:30这个函数调用是 create element 的函数调用，它接受第一个参数作为
00:08:32元素名称，然后是 props。
00:08:33这是 H1、H2 段落。
00:08:35你将 Markdown 解析为抽象语法树（AST），然后将其渲染为 BlockIt，或者你使用 JSX，
00:08:42JSX 在很大程度上直接映射到中间表示。
00:08:47也许对于不太了解 JSX 是如何工作的用户来说，JSX 本质上是函数调用的语法糖。
00:08:55因为它只是一个函数调用。
00:08:58所以你可以覆盖该 create element 函数为任何你喜欢的样子，包括
00:09:03从 Chat SDK 的中间表示中创建元素。
00:09:07唯一让这变得有点复杂的地方在于，它需要在现有的 React 应用程序中工作。
00:09:10而且因为 JSX 不是命名空间的东西，你不以任何方式导入它，对吧？
00:09:11你必须确保你不会破坏，比如说 Next.js 或 Remix，对吧？
00:09:12但它同时也需要用于那些可能完全不知道什么是 React、什么是
00:09:17JSX 的应用程序。
00:09:18所以它支持这两种情况。
00:09:28它既能很好地与现有的 JSX 应用程序配合，又能在尚未支持的地方引入 JSX 作为语法。
00:09:33如果我能向社区发起挑战，我非常希望能看到带有
00:09:37JSX 的聊天平台版 Shad CN。
00:09:41我知道有人可能已经在构建它了，我迫不及待地想看到它。
00:09:47第一个社区问题是，我们在实现 SDK 时，作为开发者需要注意哪些特定于平台的边缘情况？
00:09:55我认为这也是一个很好的问题，因为 Slack 的 Block Kit 有很多
00:09:59丰富的交互式 UI，而其他平台没有完全相同的原生渲染。
00:10:00我知道当我们构建它时，我们支持了非常好的回退方案。
00:10:02所以如果你以另一种平台可能不支持的方式使用 Chat SDK，我们已经为你创建了
00:10:08很棒的默认设置和回退方案。
00:10:11是的，没错。
00:10:18所以我觉得有多个要素，对吧？
00:10:20其中之一是渲染层。
00:10:24但我认为最鲜明的区别其实是，最初 Chat SDK 是非常为那些拥有线程的平台设计的。
00:10:27现在显然即使在它们内部，也不是每个人都在使用这些线程，对吧？
00:10:34所以你确实需要稍微考虑一下这一点，但它非常旨在以这种方式使用。
00:10:37但随后人们真的想要 WhatsApp 和 Telegram，未来可能会添加 iMessage 和
00:10:44其他一切。
00:10:52所以对于那个世界，你必须明白使用聊天应用有不同的范式，
00:10:57而这不能在 Chat SDK 层被正确抽象，因为同样，你必须同时支持两者，对吧？
00:11:04所以如果你在 WhatsApp 上工作，你必须明白这种消息或多或少是
00:11:08无上下文的。
00:11:10这是一件事。
00:11:13总的来说，Chat SDK 的设计目的并不是为了完全偏向于整体的差异。
00:11:16而在 UI 上，我也肯定尝试提供一种反馈，这样你就可以编写相同的代码，并且在任何地方看起来都说得通。
00:11:23我认为在实践中，它运行得非常好，对吧？
00:11:28在实践中，你真正想要支持的东西都被很好地支持了，
00:11:33所以我觉得在某种程度上，你将不得不进行手动测试，看看一切是否
00:11:37按照你想要的方式运行，但我们还没有真正看到人们
00:11:39但后来人们真的很想要 WhatsApp 和 Telegram，未来可能还会加入 iMessage
00:11:43以及其他各种应用。
00:11:46因此在那个领域，你必须明白使用聊天应用有不同的范式
00:11:55而这在聊天 SDK 层面上无法被妥善抽象，因为你同样需要兼顾这两者，对吧？
00:12:01你必须两者都支持，对吧？
00:12:05所以如果你在开发 WhatsApp，你必须明白这类消息或多或少是
00:12:11似乎 Chat SDK 通过其范式中的轻量级和栈无关性，正在将聊天与智能体的其他部分分离开来。
00:12:14你是否预见到随着其他模态的进步，像视频聊天
00:12:15因此，聊天 SDK 的整体设计目的，并不是要完全偏袒某种特定差异。
00:12:21而在界面方面，我确实尝试过提供反馈机制，
00:12:26我首先要说你是正确的，这是我已经重复过好几次的事情，
00:12:31即 Chat SDK 不是 AI SDK，AI SDK 也不是 Chat SDK。
00:12:37AI SDK 帮你构建智能体。
00:12:43Chat SDK 帮你将该智能体带到多个平台。
00:12:50所以它是一种轻量级和栈无关的范式。
00:12:57你觉得视频聊天 SDK 怎么样？
00:12:59我觉得这真的很有趣。
00:13:04我认为在我们得到视频聊天 SDK 之前，我们会先得到音频聊天 SDK。
00:13:06而通常我的看法是，你只有在尝试了几次之后，才会添加像 Chat SDK 这样让构建过程真正变得美好的抽象。
00:13:07我们从未构建过视频聊天。
00:13:15...
00:13:16下一个问题。
00:13:18看起来 Chat SDK 通过轻量级和与技术栈无关的范式，
00:13:24将聊天功能与智能体架构的其他部分分离开来。
00:13:28你是否预见到，随着其他模态的进步，
00:13:34类似视频聊天 SDK 的东西将会成为可能？
00:13:36非常有趣的问题。
00:13:38我先说明，你的理解是正确的，这一点我已经重复过
00:13:45Chat SDK 不是 AI SDK，而 AI SDK 也不是 Chat SDK。
00:13:51AI SDK 旨在帮助您构建智能体。
00:13:55Chat SDK 则帮助您将该智能体引入到多个平台。
00:13:59因此，它是一种轻量级且与技术栈无关的范式。
00:14:05您觉得视频聊天 SDK 怎么样？
00:14:09我觉得这非常有意思。
00:14:13我认为在出现视频聊天 SDK 之前，我们会先看到音频聊天 SDK。
00:14:19我的观点通常是，只有在您多次构建某类应用后，才会真正需要添加像 Chat SDK 这样能让构建过程变得极其顺滑的抽象层。
00:14:31我们此前从未构建过视频聊天应用。
00:14:36实际上，我得回想一下。
00:14:38现在还不是时候。
00:14:44特别是因为必须非常底层。
00:14:45事实上，我认为这类应用面临的大多数挑战在于与 AI 模型之间的通信，
00:14:50其实我觉得这类项目的主要挑战在于与AI模型之间的通信
00:14:55而不是前端与实时交流的用户之间的通信
00:15:02即实时通信的用户那一端。
00:15:03下一个问题，我可以用 Opus 4.6 用标准答案进行训练，然后让它免费产生答案吗？
00:15:04也就是零成本？
00:15:05这个问题很好地突显了什么是 Chat SDK 以及什么不是 Chat SDK。
00:15:11您永远不需要训练 Chat SDK。
00:15:13您不必为 Chat SDK 创建响应而编写提示词。
00:15:20那是 AI SDK 或其他智能体框架的作用。
00:15:24智能体框架才是您编写工具、提示词和创建工作流的地方，
00:15:30而 Chat SDK 只是平台与您的智能体之间的中间层。
00:15:36希望这有助于解答这个问题。
00:15:44下一个来自 YouTube 的问题：Chat SDK 能用来跟踪和管理 Slack 和 JIRA 之间的功能吗？
00:15:51嗯，这是一个非常好的问题。
00:15:54既然提到了 JIRA，我们确实有一个 Linear 适配器。
00:16:00我们目前还没有 JIRA 适配器。
00:16:02嗯，这是一个非常好的问题。
00:16:04既然提到了JIRA，我们确实有Linear的适配器。
00:16:09但我想要补充一点，因为之前也有一些关于 Linear 以及 GitHub 的问题，
00:16:11它们属于相似的范畴，Chat SDK 是为了“聊天”而设计的。
00:16:13如果您仔细思考，Linear 和 JIRA 本质上也是一种以不同格式渲染的聊天应用。
00:16:14这就是它的用途所在。
00:16:20还有 GitHub 也是一样，本质上，聊天 SDK 就是用来聊天的。
00:16:28然后将其映射为 JIRA API 调用，在 JIRA 上执行您想做的任何操作。
00:16:33但 Chat SDK 本身并不关心您在 JIRA 上执行的操作，对吧？
00:16:37因为这些操作，我是说，显然有时候您会发消息，但您可能还想做一些其他事情，
00:16:40比如添加标签、更改任务状态或将其分配给正确的人。
00:16:49所有这些都不是 Chat SDK 能做的事，因为它真的只是用于通信。
00:16:58如果您想在平台上执行复杂的操作，只需使用该平台的原生 API 即可。
00:17:04因为那些，我的意思是，虽然有时候你会发条消息，但你可能还会
00:17:07比如，我不知道，添加一个标签或更改任务状态。
00:17:11把它分配给合适的人。
00:17:12下一个问题，它支持 Facebook Messenger 吗？
00:17:13这是什么？
00:17:16我想可能有一个 PR（拉取请求），或者自从我们发布以来，我们就收到了很多关注，
00:17:20许多很棒的拉取请求，也许现在是一个讨论社区适配器与我们选择构建并支持的适配器之间区别的好机会。
00:17:23是的。
00:17:24这是一个好问题。
00:17:25我们还有第三个类别，即“官方供应商支持”。
00:17:26是的。
00:17:32总的来说，我们对于 Chat SDK 自带内容的处理方式是，
00:17:33它应该包含像 Slack、Discord 这种拥有十亿级用户的产品。
00:17:39也许我们可以设定为一亿用户门槛，但它们应该是那种非常大型且适用范围广泛的平台。
00:17:46所以 Facebook Messenger 完全属于这一类。
00:17:53我也不指望他们会给我们提供官方供应商支持，但如果 Facebook 愿意这样做，那会很棒，对吧？
00:17:54我们是非常欢迎的。
00:17:56所以 Facebook 会被归入这一类。
00:17:59另外我们还经常看到一些公司提供某种消息服务或上下文管理服务。
00:18:00所以总的来说，关于那些随聊天 SDK 一起发布的内容，我们是这样考虑的：
00:18:07它应该面向那些拥有十亿级用户的产品，比如 Slack、Discord，或者类似的。
00:18:15我们可以单独讨论，但比方说，您拥有自己的 iMessage 服务。
00:18:20这种广泛适用的平台类型。
00:18:23Facebook Messenger 就完全属于这一类。
00:18:26Sendblue。他们会制作一个官方供应商适配器，对吧？
00:18:31我们会说，好的，这个适配器确实是由 Sendblue 为 Sendblue 制作的，它带有维护承诺。
00:18:32没错。
00:18:36第三类则是大家都可以自由制作适配器。
00:18:39花点小钱在某些东西上，没什么不可以的。
00:18:45这完全可行，您可以连接到任何您想连接的地方。
00:18:49也许是一些规模较小的应用，它们可能达不到 Chat SDK 的一亿用户门槛。
00:18:50或者也许有一个功能，我们因为某种原因没有将其加入 Teams 适配器。
00:18:51没人能阻止您 fork 它并制作自己的版本，对吧？
00:18:52因为适配器是完全松耦合的，所以您可以制作自己的版本。
00:18:56现在是讨论“如何开始”的好时机。
00:18:57也许我是开源新手。
00:18:58我从没给开源库提交过拉取请求，但我想要构建一个适配器。
00:18:59他们会做一个官方供应商版本，对吧？
00:19:01我们可以说，好的，这确实是 Sendblue 为 Sendblue 开发的，意味着
00:19:07我认为对于适配器，确实值得思考一下分类问题。
00:19:10如果这是一个拥有上亿用户的产品，那么正确的做法是向 Chat SDK 提交拉取请求。
00:19:11如果是为了更小众的应用，那么您可以直接去 GitHub，
00:19:15查看你的仓库，让你的智能体研究 Chat SDK 仓库中的适配器构建方式，然后动手做一个。
00:19:19所有的这些适配器基本都是继承自一个基类，然后实现，
00:19:23比方说，一个发送消息的函数，它最终总是会调用目标平台的 API，
00:19:29使用其原生 SDK 或者仅仅直接对它们的 API 发起请求。
00:19:35又或者有些功能，由于某种原因我们没有添加到聊天
00:19:41SDK 团队的适配器中。
00:19:44你可以，你知道的，没人真的会阻止你对其进行分叉并制作自己的版本，对吧？
00:19:48下一个我想谈的是，在使用多个提供商和应用的复杂项目中，
00:19:52有时候需要人工参与决策。
00:19:56在 Chat SDK 中，“人工回路”（Human-in-the-loop）是怎样的？
00:19:58我曾在 Reddit 上进行过 AMA，当时我用 AI SDK 回答了这个问题。
00:20:04假设我们正在使用 AI SDK 进行构建。
00:20:06它有一个名为“需要批准”（needs approval）的参数。
00:20:07如果您创建了一个需要人工批准的工具，您就会监听该流。
00:20:11它返回的类型会标识“需要批准”。
00:20:16这时 Chat SDK 就派上用场了，因为您可以使用 JSX 编写获取批准所需的 UI，
00:20:20如果是为了更小众的需求，那你就可以直接上 GitHub，
00:20:27所以，您只需构建一次获取批准的 UI，就可以在任何平台上使用。
00:20:33我觉得这可能是人们经常问的问题，因为当您构建智能体时，
00:20:37关键在于如何在给予智能体足够的能力的同时，又让用户能够决定操作何时发生。
00:20:43没错。
00:20:49我可以给出一个非常实用且通用的回答，然后再给出一个稍微带有前瞻性的回答。
00:20:55在 Chat SDK 中实现人工回路的通用方式是，委托给您的智能体，让它表明自己需要某种工具，
00:20:58比如去回答这个问题。
00:20:59对。
00:21:00同样，在某个点上，智能体进入需要您批准的状态。
00:21:04智能体将向 Slack 发送一条消息（即用户所处的平台）。
00:21:09或者无论您正在使用什么平台。
00:21:11“嘿，这位用户，智能体想要执行此操作。您批准吗？”
00:21:15例如，您可以使用两个 JSX 按钮作为“是”和“否”。
00:21:19我们有一个针对回调 URL 的拉取请求。
00:21:25是的。
00:21:28我不知道它是否已经合并了。
00:21:32它还没有合并，所以这是那个稍微带有前瞻性的回答。
00:21:38它会返回一个提示“需要审批”的类型。
00:21:42这时聊天 SDK 就派上用场了，因为你可以编写获取
00:21:49然后在服务器端，确认批准，并即刻恢复智能体操作。
00:21:57通用的模式是，您可以在聊天端绘制这些 UI，人们可以进行交互、获得批准，然后继续工作。
00:22:04我们目前正在努力实现的是，将此功能与每次点击按钮时触发 Webhook 的能力进行集成。
00:22:11对。
00:22:17发生。
00:22:18没错。
00:22:19是的。
00:22:27我不想再花五分钟来大谈工作流框架，但工作流框架是一种用于编写持久计算、
00:22:32允许您编写运行长达数小时的智能体的系统。
00:22:43工作流框架中最优雅的事情之一是，您可以编写代码，创建一个 Webhook，将 Webhook 发送到其他地方，
00:22:50然后等待该 Webhook，这看起来很疯狂，因为用户可能需要等上五周才会点击它，对吧？
00:22:51但您确实可以在工作流中实现这一点。
00:22:52所以，您可以获取这个 Webhook，并将其放入 Chat SDK 的 JSX 中。
00:22:55只要用户决定点击它，那个神奇的“await”就会解析，然后智能体继续执行。
00:22:56第一次见到这种神奇之处时，我感受很深，通常您与智能体的第一次交互是，“好的，您需要登录。”
00:23:02当我第一次尝试时，我不得不轮询并等待，查看是否登录成功。
00:23:03非常丑陋，充满了错误，但有了 Webhook，我只是等待登录成功，
00:23:08它可以等待 30 秒、一天、甚至几周。
00:23:09它就是神奇地起作用了。
00:23:14这可能是我遇到过的最棒的 Webhook 回调场景之一。
00:23:17好的。
00:23:18我不知道那个是不是已经合并了。
00:23:19还没有，还没合并，所以这只是一个比较有启发性的回答。
00:23:22我没什么特别要说的，但基本上，这只是一个开源库。
00:23:23我们制作它是因为我们自己需要它。
00:23:27从我们看到的反应来看，需求很大。
00:23:31我们绝对感谢贡献，特别是我们需要充实我们的大规模适配器库。
00:23:34我不确定我们是否能做 iMessage，但我们也希望能做 Arc 消息、微信，
00:23:38你可以把这些界面绘制在聊天一侧，人们可以在那里进行交互，他们
00:23:45可以获取审批请求，然后继续工作。
00:23:48我们目前正在做的事情——虽然还没发布——就是将此功能
00:23:54与每次点击按钮时都会调用 Webhook 的能力进行全面集成。
00:23:58谢谢大家。
00:23:59感谢你们的时间，我很期待看到你们用 Chat SDK 构建出什么。
00:24:03当然，这可以用于非常通用的场景，只要你有某种网络钩子系统，
00:24:08但更具体来说，大家可以关注的另一件事是工作流工具 Workflow Deficit 中的网络钩子概念。
00:24:14聊天里有很多关注。
00:24:15所以，请每一个尝试的人，给我们反馈。
00:24:20我们想了解更多，告诉我们您想添加什么适配器，想加入什么。
00:24:27提交那些拉取请求。
00:24:30Workflow Deficit 中有一个极其优雅的特性，就是你可以
00:24:35真的写点东西，创建一个 Webhook 并把它发送到别处，然后
00:24:39你等待这个 Webhook，这看起来是个疯狂的做法，因为它可能需要，比方说
00:24:44五周的时间，直到用户点击它，对吧？
00:24:47但你实际上可以在工作流中做到这一点。
00:24:51所以你就可以利用这个 Webhook，并将其放入 JSX 和聊天 SDK 中。
00:24:57每当用户决定点击它时，那个神奇的 await 就会解析并
00:25:03继续执行代理程序。
00:25:05我第一次看到这种魔法时，你知道，这非常典型，你与代理的第一次互动
00:25:10它会说，好了，你需要登录。
00:25:13当我第一次尝试时，我不得不不断轮询，看看是否已经成功
00:25:18...
00:25:19非常糟糕，有很多 Bug，但用了 Webhook 后，我只需要等待登录成功，
00:25:25它可以等待 30 秒、一天，甚至几周。
00:25:28那真是太神奇了。
00:25:29它就是能行。
00:25:30那可能是我遇到过最棒的 Webhook 回调场景之一了。
00:25:34...
00:25:36...
00:25:37时间差不多了。
00:25:38在结束之前，你还有什么想说的吗？
00:25:44没什么特别要说的，总之，
00:25:49这只是一个开源库。
00:25:51我们制作它是为了满足自己的需求。
00:25:55从目前的反应来看，市场需求很大。
00:25:58我们非常欢迎大家贡献代码，尤其是为了填充
00:26:05我们的大规模适配器资源库。
00:26:11我不确定我们是否能做 iMessage，但我们也希望能支持 RC 消息、微信，
00:26:21或者任何你所在国家常用的软件。
00:26:25只要有对话的地方。
00:26:26不，我们不需要再局限于线程了。
00:26:29只要有对话的地方就行。
00:26:30没错，只要有对话的地方。
00:26:32谢谢大家。
00:26:34感谢你们的时间，我很期待看到你们用这个聊天 SDK 构建出什么。
00:26:39谢谢各位。
00:26:41谢谢大家今天能来。
00:26:44聊天室里有很多兴趣点。
00:26:46所以，请每一位尝试过的人给我们提供反馈。
00:26:50我们想了解更多，并告知我们你们想要添加哪些适配器，或者还想添加什么功能。
00:26:57去提交合并请求吧。
00:26:58我们很期待。
00:26:59谢谢大家。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video