Feishu Agent Mesh

Blueprint for wiring multiple OpenClaw agents (running on different servers) into the same Feishu group chats so they can hold autonomous multi-turn discussi...

Security Scan

The skill appears to implement the advertised Feishu relay behavior, but there are inconsistencies (metadata doesn't declare environment variables the code needs) and it centralizes sensitive secrets and message content in ways that require careful operational controls before use.

Purpose & Capability

The name/description (wiring multiple OpenClaw agents into the same Feishu chat) matches the included instructions and code: the relay/callback server, config templates, and workflow docs are coherent with that purpose. However, the registry metadata claims no required environment variables while the runtime script and SKILL.md explicitly require Feishu credentials and Bitable tokens — a packaging/documentation mismatch.

Instruction Scope

SKILL.md explicitly instructs operators to collect full Feishu app credentials (app_id/app_secret/verification token/encrypt key), bots' open_id/sessionKey, and to log full message content into a shared log store (Bitable/DB/JSON). Those actions are necessary for the described relay functionality, but they involve collecting and centralizing user messages and credentials; the instructions do not mandate secure storage, encryption-at-rest, or least-privilege limits for those artifacts and even suggest writing configuration templates that could be accidentally committed.

Install Mechanism

No automated install spec is provided (instruction-only plus a single Node.js webhook script). This is the lowest-risk install pattern: nothing is downloaded or executed by the registry itself. The script uses common libraries (express, node-fetch, crypto) and only calls Feishu open APIs.

Credentials

The functionality legitimately requires multiple sensitive values (APP_ID, APP_SECRET, ENCRYPT_KEY, VERIFICATION_TOKEN, BITABLE_APP_TOKEN/BITABLE_TABLE_ID, and tokens for bots' /tools/invoke endpoints). Those are proportionate to the purpose but the skill metadata does not declare them, and the guidance for storing them is minimal. Centralizing message content and tokens increases blast radius if the Relay host or Bitable table is compromised.

Persistence & Privilege

The skill does not request 'always: true', does not modify other skills, and has no install hooks—it will only run when an operator deploys the Relay service. It therefore does not demand unusual platform persistence privileges.

What to consider before installing

This skill is functionally coherent with its description but handles highly sensitive data and its registry metadata omits required environment variables. Before installing or deploying the Relay: (1) verify and declare the required env vars (APP_ID, APP_SECRET, ENCRYPT_KEY, VERIFICATION_TOKEN, BITABLE_APP_TOKEN, BITABLE_TABLE_ID, and any bot invoke tokens) in your deployment manifest; (2) never commit secrets or templates with real credentials to source control—use a secret manager; (3) restrict the Feishu app permissions to the minimum needed and rotate keys after testing; (4) host the Relay in an isolated, monitored environment (HTTPS, firewall rules, audit logging); (5) limit who can read the Bitable/DB logs and consider redacting or minimizing message content stored; (6) validate all invoke URLs in relay-config.json (ensure you trust each target service) and require per-bot auth tokens with least privilege; and (7) if you need to proceed but lack security expertise, ask a sysadmin or security reviewer to vet credential handling and deployment practices. If these operational safeguards cannot be met, treat the deployment as high-risk and do not enable it in production.

把多个 OpenClaw 机器人（不同实例/服务器）接入同一个飞书群：用户依旧 @ 本来的机器人，后台通过共享 Relay/队列同步上下文、日志和审批。

0. At-a-glance

1. 选择模式 —— 先读 references/architecture.md，确定是 MVP（共享表/JSON）、推荐架构（双 Bot + Relay 服务）还是高级模式（含审批/异步）。
2. 部署 Relay —— 根据模式完成 references/deployment-checklist.md：配置飞书订阅、共享存储、HTTP/CLI 调用方式。
3. 注册机器人能力 —— 复制 scripts/relay-config.example.json 并填入每个机器人的能力、回调 URL、所在服务器。
4. 落地 Workflow —— 参照 references/workflow-templates.md 运行「指派协作」或「无领导讨论」两类模板。
5. 日志 & 审批 —— 按 references/logging-schema.md 设计日志字段、审批节点，确保所有跨机器人消息都有据可查。

必须先向用户索取的信息

在启用本 Skill 之前，务必向真人用户明确索要以下数据（缺一不可）：

信息	用途
每个飞书机器人的 app_id、app_secret、verification token、encrypt key	配置事件订阅、验证消息来源
机器人在目标群聊中的 open_id / sessionKey	让 Relay 正确 @ 到各机器人
可写入的飞书多维表格（日志存储）Base ID / Table ID / 字段名	Phase 1 默认把日志落在该表格，满足“日志存储在飞书表格”的要求
机器人自身的调用入口（HTTP /tools/invoke URL 或 CLI 命令）及鉴权方式	让 Relay 能够执行具体能力
任务审批/白名单配置（哪些群、哪些节点需要人类确认）	限定机器人只针对授权任务行动

详细字段说明和示例表格见 references/info-collection-template.md。

没有拿到这些信息前，不要启动协作流程；与用户确认后再投入使用。完成收集后，把数据写入 templates/accounts.example.json 并保存为实际配置文件。

1. 关键原则

• 前台不变：群里仍是现有机器人（例如 Coordinator Bot、Specialist Bot …），任何扩展只发生在后台。
• 共享上下文：所有机器人通过同一个 Relay/队列同步讨论内容与任务状态。
• 多群隔离：以 chat_id 维度存储上下文、日志、审批规则，避免串线。
• 渐进式演进：先跑 MVP，再升级到推荐架构，最后再加高级特性。
• 任务优先：机器人之间的沟通必须围绕真人用户当前指派的任务展开，禁止跑题或多余互动；任务结束后立即停止动作，并向任务发起者汇报结果。

2. 快速启动（MVP ≤ 1h）

一次性自建回调服务（推荐）

为所有机器人统一收集 open_id / chat_id，只做一次配置即可：

1. 部署 scripts/feishu-callback-server.js（Node.js + Express）。
   • npm i express body-parser node-fetch crypto
   • 把 APP_ID、APP_SECRET、Encrypt Key、Verification Token、Bitable app/table、列名写到环境变量。
2. 把服务挂到自己的 HTTPS 域名（如 https://relay.example.com/feishu/callback）。
3. 在飞书开发者后台给每个机器人配置事件订阅 im.message.receive_v1，回调地址都指向该服务。
4. 让目标群的成员各 @ 一次机器人，服务会自动把 open_id/消息写进飞书表格。
5. Relay 周期性从表格拉取记录 → 一次性建立 open_id + sessionKey 映射；后续无需再手动收集。

若暂时无法部署服务，可使用飞书“事件日志”导出 JSON，再按相同字段手工写入表格，但推荐尽早启用统一回调，这样每个用户只需授权一次。

1. 共享存储：建一个飞书多维表格或 SQLite/JSON 文件，字段至少包括 chat_id、thread_id、message, actor, task_state。
2. 机器人轮询：在每个机器人实例里添加一个定时任务（60s 内），读取共享存储中“自己未处理”的记录。
3. 写回策略：机器人在群里发言后，同时写入共享存储，供其他机器人读取。
4. 审批钩子：人工定义关键字段（如 phase="ready_for_approval"），当检测到该字段时，机器人自动 @ 人类确认。

适合验证能否「在同一群里互相接力」，但对延迟要求高的场景不适合长期使用。

3. 推荐架构（双 Bot + Relay 服务）

1. Feishu 事件：为每个机器人配置事件订阅，把回调统一指向 Relay 服务；Relay 按 bot_id + chat_id 写入共享上下文。
2. 消息分发：Relay 根据 scripts/relay-config.example.json 中的 routes 决定是通知另一个机器人，还是写入队列等待异步处理。
3. 能力调用：优先使用 HTTP /tools/invoke（或你们自定义 API）触发对方机器人；CLI 仅作兜底。
4. 日志：Relay 所有操作都写入 logs 表，字段参考 references/logging-schema.md。
5. 审批：在配置里声明 approval_hooks。当任务状态达到某个 hook，Relay 汇总信息，并由相应机器人账号 @ 人类确认。

4. 高级特性（可选）

• 无领导讨论：按 references/workflow-templates.md 的流程，自动分配发言顺序、观点收敛、行动项指派。
• 异步任务队列：为长耗时任务配置 Redis / 消息队列；队列项最少包含 task_id、chat_id、origin_bot、assignee_bot、payload。
• 意图识别：Phase 1 使用关键词/显式 @；Phase 2 加入 LLM 分类或正则 DSL，并允许人工 fallback。
• 多群策略：在 Relay 配置中加入 chat_whitelist/blacklist、每群的审批和限流规则。

5. 运维 & 故障

1. 消息未到达：检查飞书订阅是否指向 Relay、签名是否一致；核对 chat_id 是否在白名单。
2. 机器人重复响应：查看共享上下文中 last_actor 是否正确，避免双写；必要时启用分布式锁或乐观锁。
3. 日志膨胀：以时间或条数阈值定期归档到对象存储；短期日志保留在主库即可。
4. 审批超时：在 Relay 中为审批 hook 设置超时策略（例如 10 分钟未确认则自动降级为提醒）。

6. 交付物

• 技能文件：本 SKILL.md + references + scripts，定义流程、配置、日志、审批、常见问题。
• 配置模板：scripts/relay-config.example.json，作为机器人注册与路由的起点。
• 部署模板：references/deployment-checklist.md，含 MVP → 推荐架构 → 高级特性 3 级清单。
• 动作模板：references/workflow-templates.md，覆盖指派协作 / 无领导讨论。

Follow the references to implement the actual Relay/队列；有了这套 skill，任何新的 OpenClaw 机器人都能按统一流程被纳入 Feishu 群聊协作网络。