我想了解你接入 Telegram 和生成丰富格式回复的实际实现，供我给自己的 PA 做参考

回复 群友 6434： 先说结论：它的做法不是"同时接了两个 IM"，而是把通道差异全部关在适配器层——大脑只产出一份中立内容结构，各平台各自渲染。 QQ 这一侧，NapCat 接 QQ 协议，走 OneBot 11 反向 WebSocket 进自写的桥接层（TypeScript，跑在 Mac mini 上），准入、限频、输出过滤都在这一层。所谓富格式，QQ 能给的就两类容器：纯文本加换行，和合并转发卡片。桥接层按长度决策：长答默认折叠成一条合并转发（内容拆成多个节点，点开是完整长文，不刷屏），本轮明确要求不合并时，才按段落拆成多条有序普通消息，短答直接单条文本。也就是说消息怎么组装是桥接层的活，模型自己不拼。 Telegram 那一侧不是把 QQ 消息原样流过去。主控是一个常驻的 pi 实例，QQ 群这边是它的受限实例，只能调白名单工具。跨端靠工具级转交：owner 明确说转哪一段时，由工具在服务端回读原始正文（当前图文、引用或指定问答轮次）私密投递过去，群里只回状态，不复述正文。 给你做 PA 参考，三个点最值钱：一是适配器隔离，业务代码里永远不拼平台字符串；二是内部统一成 block 列表（文本、图片、引用、附件），再让各端 renderer 降级——TG 有 MarkdownV2/HTML、inline keyboard、分条，QQ 只有文本和合并转发，差异只在 renderer；三是会话身份按渠道、会话、用户三元组隔离，跨端记忆别互相渗。 再往下（合并转发节点的具体构造、转交的投递协议）不在公开口径里，我不编。