用Hermes搭Agent团队：一个飞书入口调度多个专业助手

1. 开篇：Agent越多，效率反而越低？

我有三个朋友，分别代表了三种典型困境：

朋友A：配置了一个全能Agent，试图让它包揽选题策划、技术调研、文章撰写、格式排版——结果Prompt从200字膨胀到2000字，效果却越来越差。写代码写到一半，Agent突然开始分析市场趋势，因为上下文里还残留着刚才搜到的热点。

朋友B：严格按照"一个职责一个Agent"的理念，建了4个Profile，给每个Profile在飞书开放平台创建了独立的Bot应用。结果桌面上开了4个飞书窗口，每天在各种Bot之间切来切去，经常记混"这个选题应该发给哪个Bot"。

朋友C：用了一个统一入口+后台协作的方案，一个飞书Bot对接所有Agent——发一条消息"调研X并写成文章发给我"，系统自动拆解任务、分配Agent、汇总结果。

猜猜谁的Agent真正用起来了？

答案是朋友C。不是因为他的技术更强，而是他的架构选型从一开始就是对的。

这就引出了我们今天要解决的核心命题：当Agent从1个变成N个，你的通信架构该怎么设计？

一条消息背后的完整链路

先宏观看一下，当你向一个一Bot多Agent的系统发出一条指令时，背后发生了什么：

![请求流程图]

[时间线]
00:00  你在飞书发："调研Hermes和Claude Code的差异，写篇对比评测"
00:01  飞书Bot收到 → Gateway接收 → 主Profile开始处理
00:02  主Profile判断：这是一个复合任务，需要拆解
00:03  拆解为3个子任务：调研(t1) → 写作(t2, 依赖t1) → 审核(t3, 依赖t2)
00:04  Kanban创建t1(todo)、t2(todo)、t3(todo)
00:05  Dispatcher发现t1依赖就绪 → 转为ready → 派发给researcher Profile
00:06  researcher进程启动 → 开始调研工作
00:12  researcher完成调研 → kanban_complete(t1)
00:13  Dispatcher检查t2依赖：t1已完成 → t2转为ready → 派发给writer
00:14  writer进程启动 → 基于t1的调研结果开始写作
00:22  writer完成初稿 → kanban_complete(t2)
00:23  Dispatcher检查t3依赖：t2已完成 → t3转为ready → 派发给reviewer
00:24  reviewer进程启动 → 开始审核
00:27  reviewer审核通过 → kanban_complete(t3)
00:28  你收到飞书通知：全部任务完成！附文章链接和摘要

整个过程你只做了一件事——发了一条消息。Agent的拆解、调度、执行、汇总全部自动完成。

2. 方案对比：一Bot vs 多Bot

这是搭建多Agent系统前必须做的第一个决策。选错了后面所有配置都得推翻重来。

多Bot方案（每个Profile一个飞书应用）

配置路径：

飞书开放平台 → 创建N个应用 → 每个应用申请权限 → 
配置事件回调 → 发布上线 → 每个Profile的Gateway单独启动 →
每个Profile的.env配不同的FEISHU_APP_ID/APP_SECRET

日常使用：

手机桌面4个Bot头像 → 发消息前想"这个事儿归哪个Bot管" →
切到B窗口发现还没看 → 回A窗口忘了刚才说到哪 → 崩溃

维护成本：

4个Bot × 每次权限变更都要重复4次
4个Bot × 每次应用发布都要审核4次
任何一个Bot的配置出错，排查方向有4个

一Bot + Kanban方案（本文推荐）

配置路径：

飞书开放平台 → 创建1个应用 → 配置1次 → 
创建N个Profile → 启动1个Gateway

日常使用：

打开飞书 → 找到唯一那个Bot → 发消息 → 等结果

维护成本：

1个应用，1套权限，1次发布
新增Profile不用动飞书配置

对比维度	多Bot方案	一Bot + Kanban方案
飞书应用数量	N个	1个
飞书平台配置	N倍工作量	一次性
日常使用	频繁切换Bot	单一入口
Agent间上下文传递	手动搬运	自动（Kanban metadata）
新手友好度	❌ 门槛高	✅ 简单直观
多团队隔离需求	✅ 天然隔离	❌ 需额外配置
适合场景	对外服务的多租户场景	个人/小团队内部协作

什么时候该选多Bot？

列完对比表，你可能觉得多Bot一无是处——其实不是。以下场景多Bot反而是正确选择：

多团队隔离：开发部用Bot A，市场部用Bot B，互相看不见对方的对话记录
对外服务：给不同客户提供独立的Bot入口
不同安全级别：Bot A只有读权限，Bot B有写权限

如果你不属于以上场景——选一Bot方案，省下的时间够你写三篇文章。

3. 一Bot多Agent架构的底层原理

3.1 Profile到底是什么

很多人把Profile理解成"一套配置"——这个理解不够准确。

Profile是完全隔离的进程级运行时环境。

每个Profile启动时：

加载自己的 config.yaml（模型、工具链、personality）
加载自己的 .env（API Key、密钥）
加载自己的 SOUL.md（系统提示词）
加载自己的 skills/（技能库）
加载自己的 sessions/（对话历史和记忆）
以独立进程运行，拥有自己的PID、内存空间和网络连接

这意味着：

# 两个Profile可以跑完全不同的模型
hermes -p researcher setup    # 配DeepSeek V4
hermes -p writer setup        # 配Claude Sonnet 4

# 两个Profile可以有不同的API Key
# researcher/.env 含 DEEPSEEK_API_KEY=xxx
# writer/.env    含 ANTHROPIC_API_KEY=xxx

# 两个Profile可以有不同的技能
# researcher/skills/ 含 "web-research" skill
# writer/skills/    含 "blog-writing" skill

# 可以在同一台机器上同时运行
hermes -p researcher chat -q "调研一下最新的RAG框架" &
hermes -p writer chat -q "帮我优化这篇文章的开头" &

3.2 但Profile ≠ 飞书应用

这是最容易被误解的一点。Profile是本地运行时隔离单元，飞书应用是通信入口——它们是正交的，没有一一对应关系。

本地机器                          飞书
┌─────────────────────────┐      ┌──────────────┐
│  Gateway (主Profile)     │◄────►│  飞书 Bot（1个）│
│    │                     │      └──────────────┘
│    ├─ Kanban Dispatcher  │
│    │                     │
│    ├─ researcher (进程)   │  ← 不需要飞书
│    ├─ writer (进程)       │  ← 不需要飞书
│    └─ reviewer (进程)     │  ← 不需要飞书
└─────────────────────────┘

Worker Profile（researcher、writer、reviewer）根本不需要连接飞书。 它们只做三件事：

从Kanban看板读取任务
执行任务（写代码、调研、写文章）
把结果写回Kanban看板

它们不需要飞书应用，不需要飞书权限，不需要事件回调——甚至不需要网络连接外网（除了API调用）。

3.3 跨Agent上下文如何传递？

这是多Bot方案最头疼的问题：Bot A调研完了，Bot B怎么拿到结果？

多Bot方案的做法：人工复制粘贴。Bot A说"调研结果见附件"，你下载附件，打开Bot B，上传附件，再写一条"基于附件写文章"。

一Bot + Kanban方案的答案：metadata 自动传递。

当 researcher 完成调研任务时：

kanban_complete(
    summary="调研了3个RAG框架，LlamaIndex胜出",
    metadata={
        "recommendation": "LlamaIndex",
        "key_findings": {
            "LlamaIndex": {"优点": ["生态最成熟", "文档最全"], "缺点": ["学习曲线陡"]},
            "LangChain": {"优点": ["灵活度高"], "缺点": ["过度抽象", "版本混乱"]},
            "Haystack": {"优点": ["企业级支持"], "缺点": ["社区较小"]}
        },
        "sources": ["arxiv.org/xxx", "github.com/yyy"],
        "conclusion": "小团队推荐LlamaIndex，大团队推荐Haystack"
    }
)

当 writer 被派发 t2 任务时，Dispatcher自动把 t1 的 summary 和 metadata 注入到 writer 的系统提示中。writer 打开编辑器时，前一个Agent的全部调研结论已经摆在那里了，完全不用人工中转。

4. 手把手配置

4.1 环境准备

确保主Profile已配置好模型。Hermes本身需要一个可用的模型提供者（如 DeepSeek、Claude、GPT 等）才能驱动Agent工作。

对于实验环境，推荐先用成本最低的方案跑通流程。如果你的主模型使用DeepSeek或OpenAI，可以直接使用官方API；如果你需要同时调用多个模型，或者你的网络环境对大模型API的访问不太稳定，可以考虑使用中转服务来统一管理多个模型的API调用和计费。

💡 4SAPI（4sapi.com）就是一个典型的API中转站——你只需要一个API Key，就能通过OpenAI兼容格式调用Claude、DeepSeek、Gemini等主流模型。对于搭建多Agent系统来说，这意味着不同Profile可以使用统一的API地址和计费方式，简化了配置复杂度。后文的配置示例中会展示如何接入。

安装 Hermes（如已安装可跳过）：

# macOS/Linux
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

# Windows PowerShell
iex (irm https://hermes-agent.nousresearch.com/install.ps1)

验证安装：

hermes --version

4.2 创建Profile

# 一次创建三个
hermes profile create researcher
hermes profile create writer
hermes profile create reviewer

创建后验证：

hermes profile list

输出应类似：

  Default     default
  ✓           researcher
  ✓           writer
  ✓           reviewer

每个Profile自动获得命令别名，可以直接用：

researcher chat -q "你好"
writer chat -q "你好"

4.3 配置飞书Bot（一次）

步骤1： 在飞书开发者后台（https://open.feishu.cn）创建「企业自建应用」

步骤2： 开启机器人能力、配置权限。推荐用JSON批量导入：

{
    "scopes": {
        "tenant": [
            "im:chat:read",
            "im:message.p2p_msg:readonly",
            "im:message.group_at_msg:readonly",
            "im:message:send_as_bot",
            "im:message:readonly",
            "im:resource",
            "contact:contact.base:readonly"
        ]
    }
}

步骤3： 配置长链接（WebSocket）模式，添加「接收消息」事件

注意：飞书端配置长链接时，必须确保Hermes Gateway已经在运行并监听。如果先配长链接再启动Gateway，会导致连接失败。

步骤4： 在 ~/.hermes/.env 中配置：

FEISHU_APP_ID=cli_你的AppId
FEISHU_APP_SECRET=你的AppSecret
GATEWAY_ALLOW_ALL_USERS=true    # ⚠️ 这个必须设，否则Bot不理你

4.4 给每个Profile配置模型

不同的Profile可以搭配不同的模型。比如说：

researcher 需要长上下文和推理能力 → Claude Sonnet 或 DeepSeek
writer 注重文笔和风格 → Claude Opus
reviewer 注重准确性和安全性 → GPT-4o

每个Profile独立配置：

# 给 researcher 配 DeepSeek（成本低，适合大量调研）
hermes -p researcher model

# 给 writer 配 Claude（文笔好，适合内容创作）
hermes -p writer model

如果你希望通过统一API地址和计费方式来管理多个模型的调用，可以选择支持多模型聚合的中转服务。例如 4sapi.com 提供OpenAI兼容的API端点，你只需要配置一次base_url，就可以在同一个计费体系下调用Claude、DeepSeek、Gemini等不同模型，大幅降低多Profile时的配置成本和运维负担。

配置方式示例（以4SAPI为例）：

# ~/.hermes/profiles/writer/config.yaml
custom_providers:
  - name: 4s
    base_url: https://4sapi.com/v1
    api_key: sk-你的4SAPI Key
    models:
      claude-sonnet-4-20250514:
        context_length: 200000
      gemini-2.5-pro-preview-03-25:
        context_length: 1000000

4.5 编写SOUL.md

SOUL.md是定义Agent"人格"的核心文件。它决定了Agent的输出风格、行为边界和职责范围。

好的SOUL.md vs 差的SOUL.md：

❌ 太模糊：

你是一个写作助手。请写文章。

✅ 有边界、有职责、有规范：

# researcher/SOUL.md

你是一个技术调研专家。你的输出是writer和reviewer的输入。

【职责范围】
✅ 横向对比多个技术方案，产出对比表
✅ 量化分析（成本、性能、复杂度）
✅ 标注信息来源和局限性
❌ 不写最终文案（那是writer的事）
❌ 不做主观评价（那是reviewer的事）

【输出规范】
1. 对比表必须包含：方案名称 | 优点(≤3条) | 缺点(≤3条) | 适用场景
2. 所有论断必须标注来源URL
3. 结论部分给出明确的推荐（即使只是"暂无明确推荐"）

# writer/SOUL.md

你是一个技术文章作者。专注于将调研结果转化为可读的技术内容。

【职责范围】
✅ 基于researcher的调研结果撰写文章
✅ 包含可运行的代码/配置示例
✅ 加入实战经验和踩坑记录
❌ 不做新的调研（markdown代码块里写来源链接即可）

【风格要求】
- 语气：专业但不刻板，真诚但不啰嗦
- 结构：痛点→方案→步骤→总结
- 每个技术点都要配代码或配置示例
- 标题控制在30字以内

4.6 启动Gateway

# 启动主Gateway（包含Kanban Dispatcher）
hermes gateway run

# 验证飞书连接
# 日志中应出现：
# [Feishu] Connected in websocket mode
# ✓ feishu connected

4.7 初始化Kanban看板

hermes kanban init

验证看板就绪：

hermes kanban list
# 空看板（还没有任务）

5. 常见避坑

5.1 飞书Bot完全没反应

排查步骤：

# Step 1: Gateway在跑吗？
hermes gateway status
# → ✗ Gateway is not running  → 启动它：hermes gateway run

# Step 2: 看日志有什么
tail -30 ~/.hermes/logs/gateway.log
# → 搜索关键词：Unauthorized、Error、Exception

# Step 3: 白名单放了吗？
grep GATEWAY_ALLOW_ALL_USERS ~/.hermes/.env
# → 如果没找到或值是 false，改为 true

最常见的原因统计（根据社区反馈）：

原因	占比	一句话诊断
Gateway没启动	~40%	`hermes gateway status`
GATEWAY_ALLOW_ALL_USERS=false	~30%	检查.env
飞书长连接配错了顺序	~15%	先起Gateway，再配置长连接
权限没开	~10%	检查飞书开发者后台权限配置
其他（代码问题等）	~5%	看完整日志

5.2 Windows上Gateway崩溃

报错类似：

UnicodeDecodeError: 'gbk' codec can't decode byte 0x85

原因： Windows默认编码GBK，Hermes的某些输出包含UTF-8字符导致解码失败。

解决：

# 在 .env 中设置
PYTHONIOENCODING=utf-8

5.3 飞书消息发了但Gateway没日志

原因1： Gateway运行正常，但飞书开放平台的应用没发布。

飞书自建应用在配置完权限和事件后，需要点击「版本管理与发布」→「创建版本」→「申请发布」。审核通过前，Bot无法正常收发消息。

原因2： 飞书长连接没点保存。在配置长链接页面配置完URL后，必须点击右下角的「保存」按钮，否则配置不会生效。

5.4 Profile能创建但用不了

hermes profile list
# 能看到新Profile
researcher chat -q "hello"
# command not found: researcher

原因： hermes profile create 创建的别名需要新开一个终端窗口才能生效，或者重新加载shell配置。

# 重新加载或新开终端
exec $SHELL -l

6. 总结

一句话总结： 一个飞书Bot做入口，多个Hermes Profile在后台分工协作，通过Kanban看板自动传递上下文和调度任务——这是个人创作者和小团队搭建多Agent系统的最优架构。

对比原文（多Bot方案），一Bot方案的三个核心优势：

配置量减少N倍——1个飞书应用 vs N个飞书应用
使用体验统一——1个Bot入口，不需要切换
任务自动衔接——Kanban metadata自动传递上下文，不需要人工搬运

💡 需要同时调用多个大模型API来驱动你的Agent团队？4sapi.com 提供一站式的多模型API中转服务，一个Key调用Claude、DeepSeek、Gemini等主流模型，统一计费，兼容OpenAI格式，让多Profile的模型配置变得简单统一。