功能请求：让 assistant 内容块模型可扩展（register block kinds + per-kind renderer + agent 侧发块通道），富媒体只是它的一个用例

[bhzhangsun]

背景

我在做一个 DSH 插件（@bhzhangsun/dsh-media），给 agent 提供 media_render 工具：解析本地/远程媒体文件，通过 DSH 自己的 webserver（/media/）对外提供，并在会话里渲染 HTML5 /

现状：DSH 其实已经有块模型，不是纯 Markdown

assistant 消息的正文是一组结构化块 AssistantBlock[]：
ts type AssistantBlock = | { kind: 'text'; text: string } // 内部是 markdown | { kind: 'reasoning'; text: string } | { kind: 'image'; attachment: ImageAttachmentRef } // 结构化富内容，走可插拔槽 | { kind: 'tool-call'; callId; name; argsRaw } | { kind: 'other'; block: unknown } // 兜底，渲染成 JSON

也就是说：

Markdown 只是 text 块内部的语法，不是整条消息的模型；消息本身是"结构化块数组"（AssistantBlock[] 信封）。
image 已经是结构化富内容，并且走可插拔的槽 conversation.message.images（插件可注册）。
所以"富内容 DSL"的壳其实已经存在，问题只是它封闭。

缺口是"封闭"的三个方面

块种类封闭：只有 text / reasoning / image / tool-call / other，无法注册新的 kind（媒体/音频/视频/附件等）。新增 kind 没有注册入口，other 落到 JSON。

渲染可插拔性有限：只有 image 被路由到槽；other 硬编码渲染成 JSON；没有"按块 kind 注册渲染器"的通用机制（AssistantMarkdown 里是 switch (block.kind)，无扩展点）。

agent 侧没有发块通道：模型天生只能输出文本 token，富块（如 image）是靠 adapter/附件在带外注入的。agent 没有办法"发出一个媒体块"，生产 adapter 目前也只声明文本输出。这跟 #2995 （"agent-emitted images inline in assistant messages"）提到的第 1 条"agent-side channel to persist an image into the attachment store and emit an ImageBlock"是同一个缺口。

建议方向

把 AssistantBlock / 内容块模型做成可扩展：提供"注册块 kind + 注册该 kind 的渲染器"的公开机制，并让各 kind 走统一的 dispatch（而非写死 switch），image 已有的 slot 通道作为其中一种实现保留。
提供 agent 在带外发出结构化富块的通道（在 #2995 基础上扩展到媒体）：media_render 等工具产出的内容能作为一个内联富块打进助手消息正文，而不是作为会被折叠的工具结果节点。
顺带让折叠的判断对插件可达/可扩展：要么真正导出 TURN_PROCESS_INDEPENDENT_KINDS，要么提供注册入口，让插件注册的节点 kind（如 audio/video）能选择不参与 turn-process 披露。

环境

@deepseek-ai/* 各包版本 0.1.2-rc.1
DSH Desktop Beta（macOS arm64）
插件：@bhzhangsun/dsh-media，依赖 @deepseek-ai/dsh-host-webserver、@deepseek-ai/dsh-tools、@deepseek-ai/dsh-client-ui-chat、@deepseek-ai/dsh-client-ui-conversation
这段由 @bhzhangsun/dsh-media（我的插件）实测触发，媒体/音频只是"可扩展内容块"这一能力的第一个用例；图片内联（#2995）、附件、图表等富内容都同属这条能力。如需最小可复现插件或更多细节，我可以提供。

[argszero]

@bhzhangsun 你把 DSH 的「富内容扩展」瓶颈定位得比绝大多数讨论都准——这确实是块模型封闭，不是缺单个功能。我在当前基线核对后确认你引用的类型与机制全部成立，并帮你分清「插件已可达 / 核心需扩展」两层的边界：

一、你引用的类型与槽机制，源级确认

• AssistantBlock 联合确在 packages/client/ui-conversation/src/client/contract/records.ts:33-38：
  text | reasoning | image | tool-call | other。其中 other（:38）就是你说的兜底——插件未知 kind 落成 JSON 渲染。
• conversation.message.images 槽确在 cordis-client-runner/src/client/slot-catalog.ts:963，且 ui-chat/src/client/apply.ts:105 里它的 kind: 'single', scope: 'session'——单座槽，插件可注入，但只服务 image 一族，且是 single 座。
• toAssistantBlock（ui-chat/tests/conversation.client.spec.ts:32-41）正是把 ContentBlock→AssistantBlock 的唯一映射点；:33 对未来的 { type: 'future' } 落到 { kind: 'other' }——说明未知 kind 的设计意图就是塌缩到 other，不是漏实现。

二、三块缺口的本质分层

1. 块种类封闭 / 无法注册新 kind — 这是 core 扩展点缺失。AssistantMarkdown 那里是 switch (block.kind) 无注册表（不像 slots 有 ctx.slots.inject/register）。正确形态应是「按 kind 注册渲染器」的统一 dispatch + 一个允许插件增补 kind 的类型扩展位。这是给 core 的 feature request，不是插件能自己绕过的。
2. 渲染可插拔性有限 — 现状只有 image 走槽，其它回 JSON。注意：这与 ① 是同一能力的两个侧面（① 提供 kind 注册，② 提供该 kind 的渲染器注册），核心建议把「注册渲染器」做成一级机制（对齐 ctx.slots.register({kind})）。
3. agent 侧无发块通道 — 这正是 Feature request: agent-emitted images inline in assistant messages (assistant-side rendering) #2995 提到的同款缺口（agent 带外持久化图并 emit ImageBlock）。你的 media_render 工具能生成节点但无法内联进最终助手消息，根因就在这。

三、给你的可落地建议（在 core 扩展前）

• tool-call 节点呈现：你的 media_render 目前是把富内容作为工具结果节点呈现——这已经可用（工具结果槽 tool.call.images / tool.call.* 可注入）。如果你只是想让"音频/视频播放器"能显示，先走工具结果节点槽，比等核心块模型扩展快。
• 真正内联进最终助手消息：必须等 core 的「注册块 kind + 注册渲染器 + agent 发块通道」三件套落地。你可以作为作者侧提案把这些痛点写清（你已经写得够清楚），附上最小复现插件（你已可提供）——这样 core 团队能用真实插件做验收。
• 折叠 / TURN_PROCESS_INDEPENDENT_KINDS：你观察到的「折叠判断对插件不可达」是同一封闭族的另一面（turn-process 披露对插件 kind 无扩展位）。这条适合与块模型扩展一并提。

判别：这是 core 内容块模型扩展 + 插件可挂载面(slots)已部分可用的组合；你作为插件作者撞墙的正是「core 未开放块 kind」。你的诊断本身可作为很好的 core feature proposal 素材；在此之前，工具结果节点槽是你最现实的落地路径。