最近在梳理“一人公司”的自动化业务流时我把注意力放到了 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 13Windows 可通过 Docker 方式运行Python3.10 或 3.11Node.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_KEYyour_api_key \ -e HERMES_MODEL_BASE_URLhttps://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-agent4.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.15.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 连接池配置过小 - 整理了部署文档更新到内部 WikiBoss 角色接收到的业务目标是“根据工作记录生成一份简洁的工作周报格式规范适合发送到团队群”。它输出的结构化任务描述如下{ 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, datadata, headersheaders, methodPOST) with urllib.request.urlopen(req, timeout5) 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_tokenYOUR_TOKEN report_path workspace/output/weekly_report.md with open(report_path, r, encodingutf-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_PASSExecutor 反复返工规划阶段没有定义清楚验收标准加强 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。每增加一个角色就观察一次系统的稳定性变化而不是一次性把五个角色全部配齐。这样即使出现问题也能快速定位到底是在哪个环节。