飞书多机器人路由网关

问题：多个助理共用一个飞书入口，上下文必然串台

当主助理、编码助理、研究助理都需要接入飞书时，最直接的做法是共用同一个机器人入口和同一份会话存储。结果就是：同一个人给不同助理发消息时上下文互相污染，人格与记忆边界消失；多个账号的消息同时进来，也难以稳定区分该交给哪个 Agent 处理。

技能如何工作

这个 Skill 用多账号、多 Agent、可选多 Gateway 的方式解决这个问题：

• 账号与 Agent 解耦：在飞书开放平台为每个助理创建独立机器人应用，拿到各自的 App ID 和 App Secret，再用平台 CLI 的 ai-workflow agents add 创建独立 Agent 与 workspace。
• 路由靠 accountId 而非猜测：核心配置是 bindings[].match.accountId，它决定哪个飞书账号的消息路由到哪个 Agent；defaultAccount 保证未显式指定账号的出站动作有稳定默认值。
• 会话隔离：设置 session.dmScope = "per-account-channel-peer"，避免同一个人分别给两个机器人发消息时共用同一条 DM 会话。
• 隔离强度可调：单 Gateway 内做多账号路由即可满足一般需求；需要更强隔离时，用 --profile 在同一台机器上跑多个相互隔离的 Gateway，每个机器人绑定独立的 workspace、agentDir 和 session store。
• 配对验证：在两个机器人里分别发测试消息，收到 pairing code 后批准，即可确认路由生效。

适用边界与注意点

• 难度与风险都偏高，适合有明确权限边界的企业级场景；正式接入前先确认飞书侧应用权限范围。
• 涉及联系人、会议和个人数据时，采用最小权限并保留人工确认环节。
• 高风险动作默认只生成建议或草稿，不直接执行。
• 建议先跑通一个任务的完整闭环，保留运行日志、输入样例和输出，再扩展到更多工具；连续稳定运行 3 天是验收口径之一。