核心用法
本技能为 OpenClaw 与飞书（Lark）群聊集成的操作手册，系统梳理了两种互斥的消息发送机制：
Raw 模式（message 工具）：专用于纯文本消息与 @ 提及，通过 message() 调用实现，不支持 Markdown 渲染。适用于简单通知、自动化回复场景。
Card 模式（直接回复）：通过会话直接返回 Markdown 格式内容，支持代码块、表格、加粗斜体、彩色字体等富文本。触发条件包含代码块、表格、标题等 Markdown 元素，由系统自动识别切换。
关键决策原则：二者严禁混用，否则导致重复发送。纯文本选 Raw，富文本选 Card。
@ 提及的语法鸿沟
双模式采用完全不同的 XML 标签语法，极易混淆：
- Raw 模式：
<at user_id="ou_xxx">nickname</at> - Card 模式：
<at id=ou_xxx></at>
支持目标类型涵盖人类成员（ou_xxx）、机器人（cli_xxx）及全员（all），但需注意 @everyone 受群权限管控。
成员 ID 获取机制
飞书机器人存在严格的可见性限制：仅当用户 @ 提及机器人时，机器人才能接收并解析该消息。这意味着：
- 获取人类 open_id 必须依赖用户主动 @ 机器人
- 机器人 App ID 需用户从开发者控制台手动复制提供
- 建议维护内存文件存储群成员映射关系
机器人通信限制
飞书架构禁止机器人接收来自其他机器人的消息，即使发送方 @ 目标机器人也无法触发通知。跨机器人协作必须经由人类账户中转。
显著优点
1. 场景覆盖完整：从基础文本到复杂 Markdown 表格、代码高亮，满足技术团队多样化沟通需求
2. 权限模型清晰：明确区分人类与机器人的消息可见性边界，便于设计安全的交互流程
3. 故障排查指南详尽：列举 Raw/Card 模式混用、@ 语法错误、样式不支持等高频陷阱
潜在局限
1. 双模式割裂：用户必须在发送前预判内容类型，无法自动适配；Auto 模式存在误判风险
2. Card 模式样式残缺：不支持引用块、行内代码、分割线，复杂文档需降级处理
3. 机器人生态隔离：Bot-to-Bot 通信完全阻断，限制自动化链路设计
4. ID 获取依赖人工：缺乏群成员列表 API 查询能力，大规模群组管理成本高
适合人群
- OpenClaw 与飞书集成场景的开发运维人员
- 需在飞书群实现自动化消息推送的技术团队
- 构建多机器人协作工作流但受限于飞书架构的产品经理
常规风险
- 消息重复发送：Raw/Card 混用导致用户体验受损
- @ 失效：语法格式与当前模式不匹配，通知未触达
- 权限误配：@everyone 或机器人消息接收因群设置被静默拦截
- 数据残留：成员 ID 存储于内存文件，会话重启后需重新收集