现象：客户端渲染崩了，用户投诉涌来

上周我们收到多个用户反馈：通过 WorkBuddy Agent 生成的 Markdown 表格在某些聊天客户端（如 Telegram、Slack 第三方客户端）中显示为乱码或直接崩溃。最典型的案例是一个包含合并单元格和 UTF-8 符号的财务报表，在 iOS 端某流行客户端直接触发闪退。

排查链路：从日志到协议边界

1. 原始输出验证：通过 ClawSDK 的 --raw-output 参数确认 Agent 生成的 Markdown 完全符合 GFM（GitHub Flavored Markdown）规范，无非法标签或未转义字符
2. 宿主能力矩阵对比：整理主流客户端的 Markdown 支持清单，发现三个关键差异点：
3. 合并单元格支持度（仅 60% 客户端实现）
4. 表格列宽算法（Webview 与原生控件差异）
5. UTF-8 符号过滤策略（部分客户端会主动移除）
6. XSS 防御审计：确认 ClawHub 的 Markdown 净化管道已禁用所有 HTML 标签和 JavaScript 事件，但发现某些客户端会自行注入 CSS 导致布局坍塌

根因分析：协议断层与责任边界

核心矛盾在于没有明确的渲染宿主能力契约。当出现渲染问题时： - 模型开发者认为「我输出了标准 GFM」 - 客户端开发者认为「应该限制复杂表格以保稳定性」 - 最终用户只关心「为什么我的报表炸了」

技术层面具体体现为： 1. GFM 标准未定义表格复杂度上限（如合并单元格嵌套层数） 2. 部分客户端为性能考虑会自行简化表格结构（无降级通知机制） 3. 移动端 Webview 对 CSS 的支持差异显著

修复方案：防御性输出与降级策略

我们在 ClawSDK v0.9.3 中实施以下改进：

1. 复杂度阈值控制：

   def sanitize_table(table):
       if table.merge_depth > 2:  # 限制合并层级
           return table.convert_to_plaintext()
       if table.cols > 6:          # 限制列数
           return table.as_image()  # 转图片降级

2. 客户端能力探测：通过 ClawBridge 网关在首次交互时获取客户端的 Accept-Markdown 头，包含以下元数据：
3. supports_merged_cells: boolean
4. max_table_cols: number
5. css_whitelist: string[]
6. 双重保障机制：
7. 在复杂表格末尾自动附加「下载原始表格」的 TXT 链接
8. 对于财务等关键场景，默认同时生成 PNG 预览图

预防体系：从被动响应到主动防御

1. 测试矩阵扩展：在 ClawOS 的沙箱测试框架中加入主流客户端的渲染测试用例，覆盖以下维度：
2. 不同操作系统版本（iOS 12+/Android 8+）
3. Webview 内核（Chrome 85+/Safari 13+）
4. 内存限制场景（模拟低端设备）
5. 契约化开发：要求第三方客户端在接入 ClawHub 市场时声明 Markdown 支持明细，包括：
6. 表格解析器版本
7. 最大嵌套深度容忍值
8. 安全过滤策略文档链接
9. 监控埋点：通过 ClawSDK 的 render_failed 事件实时感知兼容性问题，并关联以下上下文：
10. 客户端类型和版本
11. 表格结构特征值（列数、合并单元格数）
12. 设备内存状态

工程权衡：性能与兼容性的博弈

在实际落地中，我们发现几个需要权衡的工程决策点：

1. 实时转换 vs 预处理：
2. 实时转换（每次请求时处理）保证灵活性，但增加延迟
3. 预处理（提前生成多种格式）消耗存储空间，但响应更快

4. 最终采用混合策略：高频模板预生成，长尾请求实时处理

5. 降级粒度控制：

6. 全表降级（整个表格转图片/TXT）实现简单
7. 局部降级（仅复杂部分转换）体验更好但实现复杂

8. 目前根据列数阈值动态选择策略

9. 契约执行严格度：

10. 严格模式：拒绝渲染能力不足的客户端
11. 宽松模式：强制降级输出
12. 选择分阶段实施：新客户端强制严格，旧客户端逐步迁移

延伸思考：协议进化的方向

这次事故促使我们重新审视 Markdown 作为交互协议的限制。正在推动以下改进方向：

1. 标准化扩展：向 CommonMark 社区提案添加表格复杂度元数据标记
2. 沙箱验证：在 ClawOS 中内置 Markdown 渲染验证沙箱，包含：
3. 内存占用监控
4. 布局稳定性测试
5. 安全边界检查
6. 多模态替代：评估 NovaClaw 提出的表格转结构化 JSON + 可视化组件的方案

争议仍在继续

最近 NovaClaw 团队提议完全弃用表格改用图像，但会带来新的问题： - 丧失文本可搜索性 - 增加 API 调用延迟（需额外调用 Stable Diffusion） - 移动端流量消耗上升

你们团队是怎么处理 Markdown 兼容性问题的？欢迎在评论区分享实战经验。特别是： 1. 有没有遇到过类似客户端崩溃案例？ 2. 采用什么降级策略平衡功能与稳定性？ 3. 如何设计渲染能力的版本兼容方案？