Chat SDK 支持流式生成跨平台交互卡片

Chat SDK agent 现在可以用 json-render 流式生成卡片：模型输出 JSON 规格，组件目录约束可选内容，再由适配器转成 Slack、Teams 各自的原生消息格式。

这次更新的价值，是把卡片生成、流式更新和校验接到了一起。但跨平台展示仍有容量限制，模型输出也可能不合法。接入时，除了让卡片显示出来，还要处理校验失败和平台降级。

模型写规格，适配器负责平台格式

这套流程从一个带类型约束的组件目录（catalog）开始。目录里包含表格、图表、按钮等组件，agent 根据目录编写 JSON spec，json-render 再把它转换成 Chat SDK card。

可以把 JSON spec 理解成一份界面清单：用哪些组件、每个组件填什么属性，由模型决定；如何变成平台认可的消息结构，由后面的渲染和适配流程完成。

Slack 使用 Block Kit，Teams 使用 Adaptive Cards。业务侧因此不必为每一种消息形态单独构建和维护工具，可以围绕组件目录组织生成能力。

统一的是卡片生成入口，各平台的展示限制仍然存在。

下面这段代码解决了从「机器人被提及」到「向当前会话流式发送卡片」的接线问题：

import { defineCatalog } from "@json-render/core";import {  schema,  standardComponentDefinitions,  streamCard,} from "@json-render/chat";import { streamText } from "ai";
const catalog = defineCatalog(schema, {  components: standardComponentDefinitions,});
bot.onNewMention(async (thread, message) => {  const result = streamText({    model: "anthropic/claude-haiku-5.5",    system: catalog.prompt(),    prompt: message.text,  });  await streamCard(thread, result.textStream);});

重点看 system: catalog.prompt() 和 streamCard(thread, result.textStream)：前者向模型提供目录约束，后者消费文本流并更新卡片。示例使用 anthropic/claude-haiku-5.5，原文没有比较其他模型的生成效果。

流式展示之后，为什么还要校验和限额

streamCard 不会等整份内容生成完才发消息。当根元素有内容时，它就发布卡片，后续元素陆续到达，再更新同一条消息。

默认更新频率最多每 500 ms 一次，与 Chat SDK 的流式更新间隔一致。流结束后，消息展示最终经过校验的卡片。这里的流式体验是分批更新消息，并非模型每输出一个字符就刷新一次界面。

格式约束则由 toCard 负责：它会检查每个元素的 props 是否符合对应组件 schema。遇到不合法的 spec，会抛出 CardSpecError，并为每个问题提供可读的错误项。开发者可以把错误列表交回模型，让它修正规格。

但这只是可用于修复的反馈机制。原文没有展示自动重试代码，也没有说明重试次数、修复成功率或失败后的兜底方式。

另一道边界来自平台容量。Chat SDK 适配器会对超过限制的内容做降级，例如 Slack 适配器会把第二个表格转换成代码块。如果业务不能接受这种展示变化，可以传入 limits，直接拒绝超限规格。原文没有给出 limits 的具体字段和配置示例。

我的判断

我认可这套分工：模型选择内容和组件，schema 检查属性，适配器处理平台格式。对于已经使用 Chat SDK 的团队，它提供了比逐种消息形态维护工具更集中的入口。

不过，这是一次能力发布，没有提供生成成功率、延迟、成本或跨平台一致性的对照数据。不能据此断言，它一定比固定模板更可靠、更省维护。

固定模板适合结构稳定、展示要求严格的消息；生成式卡片适合内容组合需要变化的场景。取舍点在于，你愿意给模型多少布局选择，以及能否接受平台降级。schema 校验覆盖的是组件属性是否合法，原文并未声称它能判断内容是否正确。

能拿来做什么

• 已经用 Chat SDK 开发机器人的团队，可以从一种需要组合表格、图表和按钮的消息入手，验证组件目录能否覆盖实际需求。
• 在 Node 服务端处理 CardSpecError 时，可以把可读错误项接入模型修复流程，同时明确重试上限和最终失败时的回复方式。
• 面向 Slack 或 Teams 上线前，应检查真实平台的展示结果；如果第二个表格降级成代码块会影响阅读，就使用 limits 拒绝超限规格。
• 对结构长期固定的通知，继续使用模板也合理；先确认确实需要动态组合组件，再引入模型生成 JSON spec。