Lark Integration

核心用法

Lark-Integration 是 OpenClaw 与 Lark（国际版）/飞书（中国版）的官方集成桥接方案，实现双向消息互通。部署后，用户可在 Lark 中@机器人或发送特定触发词，消息经 Webhook 进入 OpenClaw 处理，AI 回复自动返回 Lark 会话。支持纯文本、富文本（图文混排）及单图片消息的接收，回复支持纯文本（卡片样式需配合 feishu-card skill）。

部署流程简明：配置 FEISHU_APP_ID 与密钥文件，启动 Node.js 桥接脚本，在 Lark 开发者控制台填入 Webhook URL 完成验证。桥接服务自动识别平台域名（larksuite.com/feishu.cn），自适应调用对应 API 端点。

显著优点

1. 官方 SDK 保障：基于 @larksuiteoapi/node-sdk 官方 SDK 开发，API 调用规范，Token 自动刷新机制完善，降低维护成本。
2. 富媒体完整支持：不仅传输文字，还能解析 post 类型消息中的图文混排内容，下载图片并转为 base64 附件送入 AI，信息保真度高。
3. 企业级部署友好：提供 systemd 服务安装脚本，支持后台常驻、自动重启、日志轮转，适配 Linux 服务器生产环境。
4. 文档生态打通：可选扩展 feishu-doc skill，直接读取 Lark 文档、Wiki、多维表格（Bitable）内容，实现"聊即查"的办公自动化场景。

潜在缺点与局限性

• 平台锁定：深度依赖 Lark/Feishu 生态，迁移至其他 IM（如企业微信、钉钉）需重写桥接层。
• 自托管运维：需自行维护 Node.js 运行时及公网可访问的服务器（或内网穿透），无 SaaS 托管选项，技术门槛较高。
• 消息触发策略局限：群聊中仅通过@、问号或特定关键词触发，无法做到全量监听，复杂对话流需额外开发。
• 图片仅单向支持：目前仅支持接收图片，发送图片回 Lark 需借助其他 skill，双向图文交互不完整。

适合人群

• 已使用 Lark/Feishu 作为主力 IM 的企业技术团队
• 需要 AI 助手介入办公文档查阅、知识问答的场景
• 具备 Linux 服务器运维能力、追求数据自主可控的私有化部署用户

常规风险

1. 凭证泄露风险：App Secret 以文件形式存储于 ~/.openclaw/secrets/，若服务器被入侵或权限配置不当，可能导致密钥泄露。建议严格限制目录权限（600）。
2. Webhook 暴露：公网可访问的 Webhook 端点若未配置 Lark 的 Encrypt Key，存在被伪造请求攻击的风险。建议生产环境启用消息加密。
3. 资源耗尽隐患：富文本解析未对消息大小、图片数量做硬限制，极端情况下超大消息可能引发内存占用过高。

核心功能

Lark/Feishu 双向消息集成 是该技能的核心定位。作为 OpenClaw 生态中的官方 IM 桥接组件，它实现了：

• 消息双向同步：通过 Webhook + WebSocket 架构，支持从 Lark 接收消息并转发至 OpenClaw 处理，同时将 AI 回复回传至 Lark 会话
• 富内容完整支持：涵盖纯文本 (text)、富文本图文混排 (post)、单张图片 (image) 三种主要消息类型，图片自动下载并 base64 编码后作为附件传输
• 智能群组响应：在群聊中，仅当 @提及、消息含问号、或匹配触发词（help/帮/分析等）时响应，避免消息轰炸
• 文档生态打通：配合 feishu-doc 技能，可读取 Lark 文档、Wiki、多维表格、电子表格，支持 URL 自动识别与权限校验
• 双平台兼容：自动识别国际版 Lark (larksuite.com) 与中国版飞书 (feishu.cn)，切换对应 API 端点

显著优点

1. 架构设计清晰：Webhook 接收 → 本地桥接 → WebSocket 网关的三层架构，职责分离明确，便于调试与扩展
2. 部署运维友好：提供 systemd 服务安装脚本 (setup-service.mjs)，支持日志查看、状态监控、自动重启等企业级运维需求
3. 安全实践到位：

4. 功能-行为一致性：安全认证报告确认代码实际行为与声明功能完全匹配，无隐藏行为或权限升级诱导

• 敏感信息（app_secret）分离存储于 ~/.openclaw/secrets/，支持文件权限隔离
• 零危险函数调用（无 eval/exec/system），无 SQL 注入风险
• 依赖极简且官方可信：仅 @larksuiteoapi/node-sdk 和 ws 两个包，无供应链攻击面

潜在局限

• 回复格式受限：向 Lark 发送仅支持纯文本，卡片消息需依赖额外的 feishu-card 技能
• 图片单向限制：当前仅支持接收图片，不支持从 OpenClaw 向 Lark 主动发送图片
• 网络依赖单一：Bridge 与 OpenClaw Gateway 采用本地 WebSocket (ws://127.0.0.1)，跨机部署需额外网络配置
• T3 来源等级：虽代码质量优秀，但维护者为个人开发者/社区项目，非顶级开源基金会背书

适合人群

• 企业 IT 管理员：需要将 Lark/Feishu 接入内部 AI 工作流，实现员工在 IM 中与 AI 助手交互
• 开发者/集成工程师：构建基于 Lark 的客服机器人、智能问答、文档助手等企业应用场景
• 已有 Lark 生态的组织：已深度使用飞书文档、Wiki、多维表格，希望打通 AI 能力做知识问答与数据分析

常规风险

• Webhook 暴露风险：Bridge 默认监听 3000 端口接收 Lark 回调，若部署于公网需确保防火墙规则限制来源 IP 或启用 Lark 的加密/签名验证
• Token 生命周期：tenant_access_token 虽有自动刷新机制，但若刷新失败可能导致服务中断，需监控日志
• 文档权限依赖：读取文档功能要求显式授权或共享，大规模部署时需协调文档所有者完成权限配置
• 配置脱敏不足：生产环境建议增强日志脱敏，避免打印完整的 access_token 或 message_content