飞书@机器人

核心功能与用法

飞书@机器人技能用于在群聊环境中实现机器人之间的消息触达与协作。核心机制是通过特定XML标签格式（<at user_id="open_id">）在消息体中嵌入机器人标识，使目标机器人能够接收并响应@通知。

三种消息格式支持：

• 文本消息：最常用，格式为 <at user_id="open_id">显示名</at> 内容
• 富文本消息（post）：在markdown结构中使用相同at标签
• 卡片消息（interactive）：使用简化格式 <at id=open_id></at>

关键获取路径：飞书官方API不提供群成员中的机器人查询接口，唯一可靠方式是从历史消息的mentions字段反向提取，要求目标机器人曾被@过。

显著优点

1. 原生集成：基于飞书官方IM消息协议，稳定性有保障
2. 事件驱动：被@机器人可通过im.message.group_at_msg事件实时响应
3. 格式灵活：覆盖文本、富文本、卡片三种主流消息类型
4. 零代码触发：用户仅需@操作即可激活机器人联动

潜在局限与风险

获取门槛高：open_id获取依赖消息历史遍历，新机器人需先被人工@一次才能被识别，形成"先有鸡还是先有蛋"的启动困境。

权限链复杂：涉及调用方权限（发送消息）、接收方权限（订阅事件）、群成员身份三重校验，任一环节失败即静默失败。

缓存管理：建议缓存到TOOLS.md或数据库，但文档未提供缓存失效机制。

适用人群

• 多机器人协作场景的产品团队
• 需要构建机器人工作流（Bot-to-Bot）的开发者
• 飞书自建应用与第三方服务集成的实施人员

常规风险

| 风险点 | 说明 |

|--------|------|

| ID混淆 | `app_id`与`open_id`（`ou_`开头）不可互换 |

| 静默失败 | 机器人不在群或未订阅事件时，发送成功但无响应 |

| 频率限制 | 未提及但需关注飞书API调用配额 |

| 安全凭证 | `tenant_access_token`在示例中以明文curl传递，存在泄露风险 |

核心用法

feishu-mention-bot 是一个纯文档型技能（T-MD），旨在指导用户在飞书群聊环境中实现机器人之间的@提及通信。该技能不执行任何代码，而是提供完整的 API 调用规范、消息格式模板和实操流程。

主要功能场景包括：

• 在飞书群聊中@其他机器人并发送消息
• 实现多机器人协同工作时的互相通知
• 构建机器人代理（Agent）之间的消息传递链路

技术实现路径：
1. 通过 im:message 权限发送文本/富文本/卡片消息
2. 使用特定 XML 标签格式 <at user_id="open_id">名字</at> 嵌入@提及
3. 从群消息历史的 mentions 字段提取目标机器人的 open_id（ou_ 开头）
4. 被@机器人需订阅 im:message.group_at_msg 事件方可接收通知

该技能提供了 curl 命令示例、message 工具调用格式，以及飞书 API 直连方案，覆盖从获取 tenant_access_token 到完整消息发送的全链路操作。

显著优点

1. 零代码安全风险：纯 Markdown 文档，无可执行文件，无动态代码加载，从根本上杜绝了恶意代码执行风险。

2. 官方 API 背书：所有端点均指向飞书官方域名（open.feishu.cn），TLS 1.2+ 加密传输，企业级安全合规。

3. 多消息类型支持：涵盖文本、富文本（post）、交互卡片（interactive）三种消息格式，适应不同场景需求。

4. 实操指引详尽：不仅给出标准格式，还提供了获取机器人 open_id 的变通方案（通过消息历史提取），解决了飞书群成员 API 不返回机器人信息的限制。

5. 权限最小化设计：仅需 im:message 和 im:message.group_at_msg:readonly 两项权限，符合最小权限原则。

潜在缺点与局限性

1. 依赖外部身份标识：必须预先获取目标机器人的 open_id，而飞书未提供直接查询群内机器人列表的 API，需依赖消息历史回溯或人工维护 TOOLS.md，首次配置成本较高。

2. 单向通信限制：该技能仅解决"如何@机器人"的技术格式问题，不涉及被@机器人的响应处理逻辑，完整的对话闭环需额外开发。

3. 事件订阅前置条件：被@机器人必须预先订阅特定事件才能收到通知，若目标机器人未配置，消息将静默失败。

4. T3 来源可信度：作者为个人开发者（pcjinglang），无 GitHub 仓库关联，虽本次扫描无风险，但长期维护稳定性弱于企业级项目。

5. 无版本管理机制：缺少明确的 License 声明和版本发布流程，不利于企业合规审计。

适合的目标群体

• 企业 AI 中台开发者：构建多 Agent 协作系统，需要机器人间互相调度的场景
• 飞书应用集成工程师：深度定制飞书群机器人交互逻辑的技术人员
• 自动化工作流设计师：设计"人-机-机"混合协作流程的产品经理
• 智能体（Agent）编排者：使用 Dify、Coze 等平台编排多智能体系统的开发者

不适用场景：需要纯无代码配置即可使用的业务人员；追求开箱即用、无需理解飞书 API 细节的用户。

使用风险与注意事项

常规技术风险：

• API 凭证泄露风险：示例代码中包含 YOUR_APP_ID 和 YOUR_APP_SECRET 占位符，实际使用时若直接复制到共享代码库或日志中，可能导致凭证泄露。
• CHAT_ID 误配置：错误的 CHAT_ID 或 open_id 可能导致消息发送至非目标群聊或用户，建议发送前进行 ID 校验。
• 速率限制：飞书 API 存在调用频次限制，高频@场景需实现重试和退避机制。

运维依赖风险：

• 机器人成员关系维护：若目标机器人被移出群聊，@消息将失败，需建立成员状态监控机制。
• open_id 变更风险：机器人重新安装或企业迁移可能导致 open_id 变化，缓存的 ID 可能失效。

合规建议：

• 建议为生产环境应用配置独立的飞书应用，与开发环境隔离
• 定期审查 Skill 内容更新，关注 ClawHub 市场安全公告
• 对飞书 API 调用日志进行监控，识别异常访问模式