多机器人多 Agent 矩阵

解决什么问题

当所有需求都塞进一个机器人时，很快会遇到两类问题：一是模型和上下文要频繁切换，写作任务和代码排障混在一起，提示词与历史互相打架；二是单点故障明显，一个 Gateway 重启或配置出错，所有角色同时不可用。更麻烦的是上下文串台——技术问题的中间结论污染了内容创作的草稿，回溯时根本说不清哪段输出来自哪个角色。

这个技能的思路是用入口隔离替代上下文隔离：不再靠机器人内部切角色，而是让每个角色拥有独立的飞书机器人应用和独立 Gateway，用户直接私聊对应角色，从物理上分开会话与配置。

如何工作

核心能力有三部分：

• 多 Gateway 并行：内置多 Gateway 运行能力，每个 Agent 绑定独立代理实例，互不干扰。
• 角色配置：通过内置的 SOUL/USER 配置定义每个 Agent 的职责边界，而不是写在共用提示词里。
• 多入口对话：外部依赖飞书开放平台的多个机器人应用，一个应用对应一个角色入口。

关键落地步骤（稳定自动版）：

1. 在飞书开放平台创建 4 个机器人应用，分别对应主助理、内容创作助手、技术开发助手、AI 资讯助手。
2. 启动 4 个独立 Gateway（示例端口 18789-18792），每个 Gateway 绑定自己的 Agent 配置与模型配置。
3. 按角色私聊使用：复杂任务找主助理流转，写作找内容助手，代码问题找技术助手，行业动态找资讯助手。

实际部署时建议分两步走：先用一个任务或消息系统做闭环试跑，确认每个角色的输入输出符合预期，再扩展到更多工具接入。同时保留运行日志、输入样例和最终输出，便于复盘和交付验收。

适用边界

这个方案定位是高级难度、高风险、半自动，面向企业场景，不是拿来就能跑的个人玩具：

• 正式接入账号、数据源或自动化操作前，先确认权限边界。
• 涉及联系人、会议和个人数据时，遵循最小权限并保留人工确认环节。
• 高风险动作建议默认只生成建议或草稿，不直接执行。

验收口径也偏工程化：能用真实或模拟数据完整跑通一次；输出结构清晰，包含下一步动作或明确结论；连续运行 3 天保持稳定且结果可直接执行。成功标准是各机器人职责稳定不串上下文、单个 Gateway 故障不影响其他机器人、角色切换不再依赖手动命令。