技能介绍

要解决的问题

Hermes Agent 通常让每个 profile 待在独立的飞书群里，以获得隔离的 conversation context 和 SOUL.md。但真实的协作流程是跨角色的：PM 分发任务、Plan 输出设计、Dev 写代码、Test 验证并回报。如果每个角色一个群，信息就散了。

真正的需求是把这些角色拉进同一个群，让它们像同事一样 @对方、传递上下文。难点不在于"再装一个 bot"，而在于：

每个角色需要独立的 ~/.hermes/profiles/<role>/ 目录、config.yaml、SOUL.md、.env
每个 bot 必须知道自己的 FEISHU_BOT_OPEN_ID，否则无法正确路由 @消息
SOUL.md 需要内置其他 bot 的 open_id，并且用 XML 格式写 @mention，飞书不解析纯文本 @
多个网关同时运行时，要避免端口冲突和 app_lock 竞争

这个技能做什么

你提供 N 个飞书应用凭据和一个群 chat_id，剩下的由技能完成：

批量创建 profile —— scripts/setup.sh 在 ~/.hermes/profiles/<role>/ 下生成 config.yaml、SOUL.md、.env，覆盖 macOS launchd 和 Linux nohup/systemd 两种启动方式
自动获取 open_id —— 调用 /bot/v3/info 拉取每个 bot 的真实 open_id，写入对应 .env，无需手工查询
生成协作模板 —— 每个 SOUL.md 都包含其他所有角色的 @mention XML 结构，群内任意 bot 都能 @ 到正确对象
启动网关 —— 安装 launchd plist 或后台进程，逐个拉起各 profile 的 gateway

默认的 4 角色分工（PM / Plan / Dev / Test）只是起点。角色不是硬编码的，ROLES=pm,plan,dev,... 里的角色 key 决定 profile 数量与命名，最少 2 个，上限由飞书的 per-app / per-group bot 配额和你的 LLM context window 决定。

适用边界与注意点

飞书侧准备：每个应用必须已发布版本、开启机器人能力、授予 im:message / im:message.group_at_msg / im:message:send_as_bot 权限；所有 bot 必须被加入群且拿到 chat_id。缺任何一项，后面都会静默失败。

@mention 失效的排查顺序：先看应用是否已发布版本；再查 .env 里 FEISHU_BOT_OPEN_ID 是否存在；然后确认 channel_directory.json::feishu 数组不为空；接着检查 FEISHU_ALLOW_BOTS 是否设为 all、FEISHU_ALLOWED_USERS 是否包含发送者；最后确认 SOUL.md 用的是 XML 而非纯文本。

链式协作的纪律：任务分发走 delegate_task，不要依赖飞书消息"已送达"当确认；Dev 只在代码提交后 @Plan 评审；新增 bot 后必须更新所有已有 SOUL.md；不要同时跑 launchd 和手动启动的 gateway。

Linux 下的坑：如果 hermes-gateway.service 仍在运行，它会用默认 profile 抢同一个 app_id，触发 app_lock 冲突。要么停掉 systemd 服务，要么提前想清楚。