核心用法
本技能为 OpenClaw 飞书（Lark）集成提供完整的消息发送与群聊管理方案，核心在于理解 Raw 模式（纯文本） 与 Card 模式（Markdown 富文本） 的双轨机制：
| 模式 | 触发方式 | 适用场景 | @ 格式 |
|------|---------|---------|--------|
| **Raw** | `message()` 工具调用 | 纯文本、简单 @ 提及 | `<at user_id="ID">nick</at>` |
| **Card** | 直接会话回复 | 代码块、表格、加粗斜体等富文本 | `<at id=ID></at>` |
关键规则：同一内容禁止混用两种发送方式，否则导致重复消息。含 Markdown 元素（代码块、表格、**加粗**、*斜体*、链接等）时必须使用 Card 模式的直接回复；纯文本则优先使用 message 工具。
@ 提及系统
- 人类成员：
ou_xxx格式的open_id，需先 @ 机器人才能被识别 - 机器人：
cli_xxx格式的 App ID，必须被 @ 才能接收消息 - @ 所有人：
user_id="all"，需群组权限
重要限制：机器人之间无法互通——机器人可发送消息并 @ 其他机器人，但后者无法接收来自机器人的消息，仅能被人类账户触发。
成员管理
机器人仅能访问 @ 提及自己的消息，无法读取历史记录或未提及的消息。获取成员 ID 的标准流程：让人类用户 @ 机器人发送任意消息，系统日志中会显示 [Feishu oc_xxx:ou_xxx timestamp] nickname: content，从中提取 ou_xxx。
显著优点
1. 双模式精准匹配：Raw/Card 分离避免格式混乱，Markdown 渲染完整支持代码高亮、表格、彩色字体等企业级展示需求
2. @ 提及体系完备：支持个人、机器人、全员三级通知，满足协作自动化场景
3. ID 管理透明化：通过系统日志暴露 open_id，无需管理员后台即可自助获取成员标识
4. 权限边界清晰：明确机器人可见性限制，降低信息泄露风险
潜在缺点与局限性
1. 格式兼容陷阱：Card 模式下不支持引用块（> quote）、水平线（---）、行内代码（` code `）不稳定，复杂嵌套可能解析失败
2. 机器人孤岛效应：机器人-机器人通信完全阻断，跨机器人工作流需人类中转
3. 可见性受限：机器人无法主动感知群组状态，必须被动等待 @ 提及，实时性依赖用户配合
4. @ 格式易混淆：Raw 与 Card 的 XML 标签属性差异（user_id vs id）缺乏运行时校验，配置错误静默失败
适合人群
- 企业自动化管理员：需将 OpenClaw 接入飞书群进行通知推送、告警分发的 DevOps/SRE 团队
- 内部工具开发者：构建群聊机器人、工单系统、审批助手的工程师
- 协作场景架构师：设计人机混合工作流，需精确控制消息格式与通知范围的产品/运营人员
常规风险
| 风险类别 | 具体表现 | 缓释建议 |
|---------|---------|---------|
| 消息重复 | 同时调用 `message` 工具并直接回复 | 严格遵守二选一决策树 |
| @ 失效 | 模式与标签属性不匹配 | 对照速查表复制标准格式 |
| Markdown 解析异常 | 使用不受支持的语法导致内容截断或乱码 | 限制为技能白名单内的语法子集 |
| 机器人无响应 | 目标机器人未收到人类触发消息 | 确认消息来源为人类账户，非另一机器人 |
| 权限不足 | @ 所有人失败或无群组管理权限 | 预先在飞书后台配置群组权限 |
来源说明
技能内容基于 OpenClaw 官方飞书扩展源码（bot.ts、reply-dispatcher.ts、mention.ts、send.ts）实测整理，测试时间为 2026-02-27 至 2026-02-28，属一手技术文档转译，未引用第三方经验帖。