基于Hermes Agent的五角色团队协作架构实践-平芜编程栈

最近在梳理“一人公司”的自动化业务流时，我把注意力放到了 Agent 团队协作方向，反复对比了多种方案后，最终基于 Hermes Agent 落地了一套五角色架构实践。网上关于 Hermes Agent 的资料比较零散，大部分停留在安装和单 Agent 演示层面，真正讲清多人协作、角色编排和业务链路的文章不多。这篇文章会完整整理我在 v3.1 版本下的架构设计与实操配置，包括五角色的职责拆分、协作流程、环境部署、配置示例、定时任务通知、常见问题与工程建议。无论你是刚接触 AI Agent 的开发新手，还是想用 Agent 团队替代部分重复协作的中小型项目负责人，都可以按这篇文章的思路推进。

1. 背景与核心概念

1.1 什么是一人公司模型

“一人公司”并不是一个新概念，它指的是以极小的核心团队，甚至一个人，借助自动化工具和外部资源，完成传统公司中多个岗位才能完成的业务流程。过去实现一人公司主要靠 SaaS 工具、低代码平台和外包协作，但这类方式存在两个明显瓶颈：

工具之间数据割裂，业务流转需要大量人工搬运。
决策环节仍然依赖人，无法形成自动闭环。

AI Agent 的出现改变了这种局面。Agent 不再只是一个“对话机器人”，而是能理解目标、拆解任务、调用工具、读取结果并继续推进的智能体。当一个系统中存在多个分工不同的 Agent 时，它们就可以组成一个虚拟团队，各司其职，围绕一个业务目标协同工作。

1.2 Hermes Agent 是什么

Hermes Agent 是一个开源的大模型 Agent 框架，重点解决“模型能力 + 工具调用 + 自动化流程”的整合问题。它支持将大语言模型封装为可执行任务的 Agent，并提供工具注册、任务编排、上下文管理和外部服务对接等能力。

与很多偏向“单轮对话增强”的 Agent 项目不同，Hermes Agent 更强调可运行、可编排、可投递，适合做成定时任务、消息通知、多角色协作等真实业务场景。比如在项目实践中常见的“定时任务通知投递钉钉通道”，就可以借助 Hermes Agent 的调度能力和通道配置来实现。

需要注意，Hermes Agent 仍然是一个迭代速度较快的开源项目，不同版本的 API、配置方式可能存在差异。本文以 v3.1 的五角色编排思路为主线，安装和配置命令属于通用示例，实际操作时请以你安装版本的官方文档为准。

1.3 为什么需要五角色架构

单个 Agent 在处理简单任务时表现不错，但一旦进入“需求分析 → 方案设计 → 执行 → 质检 → 发布”这类完整链路，单 Agent 容易出现两个问题：

上下文过长后丢失关键约束。
生成、执行、检查由同一个模型完成，缺少“把关”环节。

五角色架构就是针对这两个问题设计的。它把业务流程拆分为多个专业角色，每个 Agent 只负责一个相对聚焦的环节，通过明确的输入输出协议协作，让整个系统具备更接近真实团队的工作方式。

2. 五角色架构核心设计

2.1 角色总览与分工

在 v3.1 版本中，我搭建的五角色团队由以下角色组成：

角色	职责	核心能力
Boss（决策者）	接收业务目标，拆解优先级，分配任务，确认最终交付物	目标理解、任务拆解、决策输出
Planner（规划者）	将目标转化为可执行计划，明确步骤、依赖、验收标准	流程设计、排期、依赖分析
Executor（执行者）	执行具体任务，如写代码、写文案、调接口、生成文件	工具调用、代码生成、内容输出
Reviewer（审查者）	检查执行结果，识别问题，返回修改建议	代码审查、逻辑校验、安全检测
Operator（运营者）	发布结果、发送通知、归档记录、跟进后续迭代	消息投递、定时调度、数据归档

这五个角色并不是固定不变的。如果你的业务偏内容创作，可以把 Executor 拆成“图文执行者”和“视频脚本执行者”；如果偏研发，可以把 Reviewer 细化为“代码审查者”和“测试执行者”。关键是保持“决策、规划、执行、审查、运营”这五层逻辑完整。

2.2 角色间的协作流程

五角色之间的协作不是简单的一层层从上往下传递，而是形成一条带反馈环路的流水线。

Boss -> Planner -> Executor -> Reviewer -> Operator ^ | |----- 返工 ---|

完整流程可以拆成六步：

Boss 接收任务，确定业务目标和优先级。
Boss 把任务描述交给 Planner。
Planner 生成结构化执行计划，提交给 Executor。
Executor 按计划执行，产出结果。
Reviewer 检查结果，如果合格就放行，如果不合格则把修改意见返回给 Executor。
Operator 负责发布和通知，并把本轮数据归档。

这套流程看起来简单，但实际落地时关键点在于角色之间传递的“任务上下文”必须是结构化的，而不能是一段随意写的自然语言。比如 Boss 给 Planner 传递的应当是“目标 + 约束 + 优先级 + 验收标准”，而不是“你帮我做一下这个”。

2.3 相比单 Agent 的优势

单 Agent 模式是一人包办所有事，五角色模式更像真实团队。

对比维度	单 Agent	五角色架构
任务聚焦	上下文容易混乱	每个角色只关注自己负责的部分
质量保障	无独立审查	Reviewer 独立把关
分工协作	串行执行	可并行、可异步
可维护性	改一处牵全身	角色独立，可单独升级
稳定性	单点失效	角色可按需重试和替换

这里要说明一点：五角色架构并不是“银弹”。如果你的任务只是“翻译一段文本”或“写一个正则表达式”，用单 Agent 反而更高效。五角色更适合流程长、环节多、需要多次反馈的业务场景。

3. 技术底座与运行机制

3.1 Hermes Agent 的核心组件

从技术角度看，Hermes Agent 的架构可以拆成四个核心组件：

模型层：负责理解任务和生成结果，支持接入多种大语言模型。
Agent 层：封装角色行为，包含系统提示词、工具列表、执行循环。
工具层：以函数或 HTTP 接口形式暴露外部能力，比如执行命令、读取文件、调用 API、访问数据库。
调度层：负责角色之间的消息传递、任务队列、定时触发和结果归档。

对应到五角色架构中，每个角色就是一个独立的 Agent 实例，它们共享一个调度中心，但拥有不同的系统提示词和工具白名单。

3.2 任务编排与工具调用

Hermes Agent 的任务编排通常采用“事件驱动”或“工作流驱动”两种方式。

事件驱动：一个角色完成任务后，向调度中心发送事件，调度中心根据事件类型自动触发下一个角色。
工作流驱动：提前定义好完整的 DAG 流程，每个节点对应一个角色，前一个节点完成后自动进入下一个节点。

在实际使用中，推荐先使用工作流驱动方式，把关键链路固化下来，后续再逐步引入事件驱动，增加旁路分支和条件判断。

工具调用方面，Hermes Agent 遵循经典的“模型生成工具调用参数 → 系统执行工具 → 返回执行结果 → 模型继续推理”循环。这意味着每个工具必须有清晰的参数 schema 和返回结果格式，否则模型很容易生成错误的调用参数。

3.3 状态管理与记忆机制

多人协作最怕上下文丢失，多 Agent 协作同样如此。v3.1 版本需要注意三个层面的状态管理：

任务级状态：当前任务做到哪一步了，产物是什么。
会话级记忆：本轮协作中角色之间传递过哪些信息。
长期记忆：历史任务中有哪些经验可以复用，比如常见返工原因。

建议不要把全部上下文塞进每个角色的提示词里，而是通过状态存储，让每个角色只读取它当前需要的上下文片段。这样既能降低 token 消耗，也能减少上下文干扰。

4. 环境准备与安装部署

4.1 运行环境要求

在部署 Hermes Agent 之前，先把环境准备好。以下是我使用的环境，供参考：

操作系统：Ubuntu 22.04 / macOS 13+，Windows 可通过 Docker 方式运行
Python：3.10 或 3.11
Node.js：部分插件和工具链可能需要
Docker：如果选择容器化部署，建议 Docker 24+
模型服务：需要准备一个可用的 LLM API Key，或者本地部署的模型服务地址

如果你使用的是国内服务器，要注意网络策略对模型 API 或 Docker 镜像拉取的影响。如果镜像拉取不通，可以更换 Docker 镜像源，调整后重启 Docker 服务。

4.2 基于 Python 的安装方式

创建一个干净的工作目录，并使用虚拟环境隔离依赖。

mkdir hermes-agent-demo && cd hermes-agent-demo python3 -m venv .venv source .venv/bin/activate

然后安装 Hermes Agent 及相关依赖。具体包名以官方文档为准，示例命令如下：

pip install --upgrade pip pip install hermes-agent

安装完成后，可以检查版本号确认安装成功。

hermes --version

如果你只需要在 Python 中调用它的接口，也可以直接导入测试：

# 文件路径：hermes-agent-demo/test_import.py try: import hermes_agent print("hermes_agent import success") except ImportError as e: print("import failed:", e)

这里要提醒一点：Hermes Agent 对 Python 版本比较敏感，如果安装时出现依赖编译错误，建议优先检查 Python 版本是否为 3.10/3.11，避免使用过高或过低的版本。

4.3 Docker 方式部署

如果你不希望污染本机环境，Docker 是更省心的选择。Hermes Agent 的 Docker 部署通常需要两个步骤：

拉取镜像。
编写启动配置，把模型 API Key 和本地目录挂载进去。

拉取镜像的示例命令：

docker pull hermes-agent:latest

启动容器的示例命令：

docker run -d \ --name hermes-agent \ -e HERMES_MODEL_API_KEY=your_api_key \ -e HERMES_MODEL_BASE_URL=https://api.example.com/v1 \ -v $(pwd)/config:/app/config \ -v $(pwd)/workspace:/app/workspace \ -p 8080:8080 \ hermes-agent:latest

需要说明的是，镜像名称、环境变量名和端口可能因版本不同而变化，上面的命令是一个通用思路。在实际项目中，建议先拉取官方镜像，通过docker inspect或官方 README 确认环境变量后再启动。

启动后查看日志：

docker logs -f hermes-agent

4.4 配置模型服务

完成安装后，还需要在配置文件中指定模型服务。通常需要配置三个信息：

Base URL：模型 API 的地址。
API Key：模型服务的密钥。
Model Name：使用的模型名称，比如 gpt-4o-mini、deepseek-chat 或本地模型名称。

以配置文件为例：

# 文件路径：config/model.yaml llm: base_url: "https://api.example.com/v1" api_key: "${MODEL_API_KEY}" model: "gpt-4o-mini" temperature: 0.3 max_tokens: 4096

关于成本问题，很多初次使用者会问“Hermes Agent 部署完要花钱吗”。这里明确说明：Hermes Agent 本身是开源软件，代码使用不收费；但你调用大模型 API 会产生 token 费用，费用多少取决于你接入的模型供应商。如果你使用本地部署的开源模型，则主要消耗的是算力成本。实际使用中推荐通过配置 token 上限和控制并发任务数来约束成本。

5. v3.1 五角色配置实战

5.1 整体目录结构

为了让整个项目清晰易维护，我建议把配置、状态、产物、日志分离。

hermes-agent-demo/ ├── config/ │ ├── model.yaml │ ├── roles/ │ │ ├── boss.yaml │ │ ├── planner.yaml │ │ ├── executor.yaml │ │ ├── reviewer.yaml │ │ └── operator.yaml │ └── workflow.yaml ├── workspace/ │ ├── input/ │ ├── output/ │ └── archive/ ├── logs/ └── run.py

这个结构的好处是角色配置互相独立，后续扩展新角色时，只需要在roles目录下新增一个 YAML 文件，然后在workflow.yaml中注册即可。

5.2 角色配置示例

先看一个最简单的角色配置。以 Boss 角色为例：

# 文件路径：config/roles/boss.yaml name: boss description: 负责接收业务目标，拆解优先级，分配任务，并确认最终交付物 system_prompt: | 你是团队中的 Boss 角色。 你需要根据用户输入的业务目标，输出结构化的任务描述。 任务描述必须包含：目标、约束、优先级、验收标准。 不要尝试自己完成具体执行工作。 allowed_tools: - send_task_to_planner - get_task_status temperature: 0.2

关键配置项说明：

name：角色唯一标识。
description：角色的功能描述，会被调度器用于路由。
system_prompt：角色的核心提示词，决定角色的行为方式。
allowed_tools：允许该角色使用的工具白名单。
temperature：控制生成随机性，决策类角色建议设置低一点。

相应的，Reviewer 角色的配置重点放在“审查标准”上：

# 文件路径：config/roles/reviewer.yaml name: reviewer description: 负责检查执行结果，识别问题，返回修改建议 system_prompt: | 你是团队中的 Reviewer 角色。 你负责对 Executor 的产出进行审查。 审查范围包括：完整性、准确性、安全性、风格一致性。 如果结果存在不足，返回结构化修改建议；如果通过，返回 PASS。 allowed_tools: - read_workspace_file - submit_review_report temperature: 0.1

5.3 业务流编排

workflow.yaml是整条协作流水线的核心。它定义了任务的流转顺序和条件分支：

# 文件路径：config/workflow.yaml workflow: name: one_person_company_v3.1 nodes: - id: boss role: boss next: planner - id: planner role: planner next: executor - id: executor role: executor next: reviewer - id: reviewer role: reviewer next: operator condition: PASS: operator NOT_PASS: executor - id: operator role: operator next: END

这段流程表达的逻辑是：

Boss 处理完成后，任务进入 Planner。
Planner 输出计划后，任务进入 Executor。
Executor 执行完成后，任务进入 Reviewer。
Reviewer 如果审查通过，则进入 Operator；如果不通过，则返回 Executor 返工。
Operator 完成通知和归档后，流程结束。

这里的关键设计是给 Reviewer 增加了条件分支，避免不合格的产物直接进入发布环节。这也是五角色架构比单 Agent 更稳妥的核心原因。

5.4 一人公司业务流实战：自动生成周报

用一个具体场景来串联所有角色：自动生成周报并发送到钉钉。

我把本周的原始工作记录放入workspace/input/weekly_notes.md：

# 本周工作记录 - 完成了用户中心接口重构，涉及登录、权限、资料修改三个模块 - 修复了订单超时未关闭的问题，补充了定时任务补偿逻辑 - 编写了接口自动化测试用例 34 条，通过率 100% - 排查线上偶发 500 错误，定位为 Redis 连接池配置过小 - 整理了部署文档，更新到内部 Wiki

Boss 角色接收到的业务目标是“根据工作记录生成一份简洁的工作周报，格式规范，适合发送到团队群”。它输出的结构化任务描述如下：

{ "goal": "生成工作周报", "source": "workspace/input/weekly_notes.md", "constraints": ["语言简洁", "按模块分类", "突出结果数据"], "priority": "high", "acceptance_criteria": ["包含工作概述", "包含数据产出", "不包含敏感信息"] }

Planner 将目标拆成三步：

读取工作记录文件。
按“项目/模块 + 结果 + 数据”的结构生成周报。
输出最终文本。

Executor 负责实际生成内容，并把结果写入workspace/output/weekly_report.md。

Reviewer 对周报进行审查，重点检查是否有错别字、数据是否准确、是否包含敏感信息。审查通过后，Operator 调用钉钉机器人 webhook 发送消息。

5.5 定时任务与钉钉通知

在 v3.1 版本中，我将周报任务设置为每周五 18:00 自动触发。定时配置可以单独维护：

# 文件路径：config/schedule.yaml schedules: - name: weekly_report cron: "0 18 * * 5" workflow: one_person_company_v3.1 input: source_file: workspace/input/weekly_notes.md

定时触发由 Hermes Agent 的调度器负责。调度器到点后，会创建一条新的工作流实例，并把输入参数传递给 Boss 角色。

钉钉通知可以通过钉钉自定义机器人实现。提前在钉钉群中添加自定义机器人，复制 webhook 地址，然后编写一个通知工具脚本：

# 文件路径：tools/dingtalk_notify.py import json import time import urllib.request def send_dingtalk_message(webhook: str, content: str, secret: str = None): # 如果设置了加签，这里需要拼接 timestamp 和 sign # 具体签名算法以钉钉官方文档为准，这里仅演示普通消息发送 headers = { "Content-Type": "application/json" } payload = { "msgtype": "markdown", "markdown": { "title": "Hermes Agent 周报通知", "text": content } } data = json.dumps(payload).encode("utf-8") req = urllib.request.Request(webhook, data=data, headers=headers, method="POST") with urllib.request.urlopen(req, timeout=5) as resp: result = resp.read().decode("utf-8") print("DingTalk response:", result) return result if __name__ == "__main__": webhook = "https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN" report_path = "workspace/output/weekly_report.md" with open(report_path, "r", encoding="utf-8") as f: report_content = f.read() send_dingtalk_message(webhook, report_content)

这段代码的逻辑比较简单：读取周报文件内容，拼接成钉钉机器人支持的消息格式，通过 HTTP POST 发送。实际使用时，建议把 webhook 放在环境变量或配置中，不要硬编码在脚本里。

5.6 运行与验证

在项目根目录执行主入口文件：

python run.py --config config/workflow.yaml \ --trigger weekly_report \ --input workspace/input/weekly_notes.md

如果你的配置正确，会看到类似下面的输出：

[INFO] workflow one_person_company_v3.1 started [INFO] boss 角色处理完成 -> 任务已交接给 planner [INFO] planner 角色处理完成 -> 任务已交接给 executor [INFO] executor 角色处理完成 -> 任务已交接给 reviewer [INFO] reviewer 审查通过 -> 任务已交接给 operator [INFO] operator 已发送钉钉通知 [INFO] 任务产物已归档到 workspace/archive/

在验证阶段，重点关注四件事：

任务是否能完整跑通。
每个角色是否有正确的输入和输出。
Reviewer 的返工分支是否能正常工作。
钉钉通知是否真的送达。

6. 常见问题与排查思路

6.1 部署与依赖类问题

问题现象	常见原因	解决思路
pip 安装失败或编译报错	Python 版本不匹配	切换到 Python 3.10 / 3.11
启动容器后立即退出	环境变量缺失或配置错误	检查模型 API Key、Base URL 是否配置正确
Docker 镜像拉取失败	网络原因或镜像源不可达	更换 Docker 镜像源，重启 Docker
导入模块失败	虚拟环境未激活或依赖冲突	创建干净虚拟环境重新安装

6.2 模型与角色行为类问题

问题现象	常见原因	解决思路
角色输出不符合预期	系统提示词不够明确	在 prompt 中补充输出格式示例
任务上下文丢失	没有正确传递结构化状态	检查角色之间传递的参数是否完整
Reviewer 永远通过	审查标准太宽松	增加检查项，要求输出 PASS/NOT_PASS
Executor 反复返工	规划阶段没有定义清楚验收标准	加强 Planner 环节的约束输出
钉钉消息发送失败	webhook 失效或加签错误	重新生成 webhook，检查签名算法

6.3 排查建议清单

遇到问题时，建议按以下顺序排查：

先看日志。Hermes Agent 在运行过程中会输出每个节点的处理状态，日志是定位问题的第一入口。
确认输入输出。检查每个角色接收到的输入是否符合预期，输出是否完整。
单独测试工具。如果是工具调用失败，绕过 Agent，直接调用工具函数测试。
降低复杂度。先把五角色链路简化成“执行者 -> 审查者”两节点，跑通后再逐步增加角色。

7. 最佳实践与工程建议

7.1 成本控制策略

多 Agent 协作比单 Agent 更消耗 token，因为每个角色都需要读取任务上下文并生成输出。控制成本可以从四个方面入手：

上下文裁剪：只传递当前角色需要的字段，不把完整历史记录传给每个角色。
模型分级：决策和规划使用效果更好的模型，执行和通知使用更便宜的模型。
结果缓存：对于重复性任务，按输入 hash 缓存执行结果，避免重复调用。
并发限制：在调度器中限制同时运行的工作流数量，防止突发任务导致费用飙升。

7.2 安全与权限边界

多 Agent 系统的每个角色如果都能访问全部工具，风险会成倍增加。建议遵循最小权限原则：

决策角色默认不授予文件写入和命令执行权限。
执行角色只能访问指定的工作目录。
审查角色应具备读取权限，用于检查文件内容，但不建议直接修改文件。
运营角色的通知类工具应限制目标范围，避免误发给错误的人。

如果涉及服务器命令执行、数据库操作，必须先经过授权流程，最好在测试环境验证，并保留完整日志。

7.3 可观测性与工作流追踪

一个人维护多 Agent 团队时，可观测性就是你的“管理仪表盘”。建议在关键节点埋点，记录以下信息：

工作流实例 ID。
当前节点角色。
节点开始和结束时间。
输入输出摘要。
token 消耗。
是否触发了返工分支。

这些信息最终可以汇总为一份 JSON 结构，方便后续分析。

例如，每次节点处理完成后，统一生成一条运行记录：

{ "workflow_id": "wf_20250627_001", "node_id": "reviewer", "role": "reviewer", "status": "PASS", "input_summary": "review weekly report", "output_summary": "weekly_report.md reviewed", "duration_ms": 2350, "token_cost": 1250 }

积累一段时间后，你可以根据这些数据定位效率瓶颈，比如哪个角色耗时最长、哪个环节返工率最高。

7.4 单人使用多 Agent 团队的工作方式

在实际工作中，我建议不要把五角色当成完全独立于人之外的系统，而是把它看作一个可以随时接收指令、反馈进度的虚拟团队。

每周可以固定一个时间，把本周业务目标输入给 Boss 角色，让它驱动整个流程运转。期间，通过 Operator 的通知实时了解进度。只有遇到 Reviewer 连续返工或流程异常时，才需要人工介入。

这种工作方式的核心理念是“人管异常，Agent 管常规”。不要把精力浪费在重复的任务分发和进度催促上，而是把时间留给真正的决策和判断。

7.5 角色配置的版本管理

五角色系统中，角色配置和业务同样需要版本管理。建议把config/目录纳入 Git 仓库，每次修改角色 prompt 或工作流编排时，都提交一个明确的记录。

当任务结果变差时，可以快速回退到上一个稳定版本。这也解释了为什么在 v3.1 版本中，我特别强调配置文件的结构化和注释完整——配置即代码，配置也需要 review。

8. 总结与继续进阶方向

这篇文章从“一人公司”的业务背景出发，完整介绍了基于 Hermes Agent 的五角色架构 v3.1 版本。核心可以总结为以下几点：

五角色分别是 Boss、Planner、Executor、Reviewer、Operator，对应决策、规划、执行、审查、运营五个环节。
角色之间通过结构化上下文协作，审查环节增加返工分支，保证交付质量。
Hermes Agent 支持 Python 和 Docker 两种部署方式，配置模型服务后即可运行。
通过定时任务和钉钉机器人，可以把整套流程接入真实业务通知场景。
多 Agent 项目的成本和安全需要单独设计，不能只关注功能是否跑通。

接下来还可以继续研究的方向包括：

把五角色流程从固定工作流升级为动态规划模式，让 Agent 根据任务类型自动选择合适的角色组合。
为每个角色的历史表现建立评分体系，持续优化 prompt 和工具选择。
尝试引入本地部署的开源模型，降低 API 调用成本，同时保留数据在本地。
将 Hermes Agent 的定时任务与外部系统对接，比如数据库巡检、报表生成、自动化测试执行等。

建议你在实际项目中先从一个最小闭环开始：只配置 Executor 和 Reviewer 两个角色，选择一个小型任务跑通，再逐步加入 Planner 和 Operator。每增加一个角色就观察一次系统的稳定性变化，而不是一次性把五个角色全部配齐。这样即使出现问题，也能快速定位到底是在哪个环节。