最近在折腾 Agent 自动化工作流的时候我把团队日常的项目推进模式拆解成了五个角色再用 Hermes Agent 的 Team 模式把这套流程跑了起来。这个思路就是“一人公司模型”一个人、一套 Agent 团队、五类职责分工把原本需要小团队协作才能完成的研发交付链路压缩到一条可复用的自动化管道里。这套模型在我这边已经迭代到了 v3.1 版本整体结构比早期版本稳定不少尤其是在定时任务、通知投递和多角色上下文隔离这几个环节踩过的坑基本都填完了。本文就把这版架构的完整拆解、角色划分、配置思路和实际运行效果整理成一份教程适合想用 Agent 自动化提效的开发者也适合刚刚接触 Hermes Agent、想上手 Team 模式的读者。需要先说明的是Hermes Agent 本身还在快速迭代中具体命令、配置项和 API 参数会随版本变化。本文会给出通用可用的实现思路并标注哪些地方需要根据你本地的实际版本做调整。1. 背景与核心概念1.1 为什么需要“一人公司模型”传统研发交付流程有需求分析、技术方案、编码、代码评审、测试、发布部署等多个环节。小团队里这些环节由不同角色承担一个人全部做完不仅心智负担大而且在多个上下文之间来回切换时容易遗漏细节。把这一套流程映射到 Agent 上就是“一人公司模型”的核心思路一个主控 Agent 扮演统筹者负责接收需求、拆解任务、分发指令。多个专业 Agent 分别承担不同职责各自维护独立的上下文。任务在角色之间通过结构化的请求/响应流转而不是所有 Agent 共用一个大而全的提示词。最终由统筹者汇总各角色产出形成一份可供人工验收的交付物。这样做的好处是每个 Agent 只需要关注自己的领域Prompt 可以写得更加聚焦输出的稳定性和质量都更容易控制。即使某个环节失败也只需要重新执行对应角色而不是让整个流程从头再来。1.2 Hermes Agent 是什么Hermes Agent 是 NousResearch 推出的智能体项目核心定位是“一个人也能驱动一个完整团队”。它在经典的 ReAct 模式之上增加了多 Agent 协作、工具调用和任务调度能力。和普通单 Agent 自动化脚本不同Hermes Agent 的 Team 模式更强调角色分工和任务编排适合用来构建小型但完整的自动化工作流。需要注意 Hermes Agent 与 Nous 系列大模型的关系Hermes 系列模型是 NousResearch 基于 Llama 等开源模型微调出的助手模型而 Hermes Agent 是使用这类模型能力来驱动 Agent 行为的应用框架。简单理解就是模型负责“理解并生成”Agent 框架负责“拆解并执行”。1.3 v3.1 版本的核心变化从 v3.1 版本开始Team 模式被定位成主力场景围绕“一人公司模型”做了不少工程化增强。结合社区反馈和我自己的使用体验这一版最值得关注的方向有三个定时任务调度更加可靠支持接近 Cron 表达式的周期触发方式。通知投递通道更加丰富钉钉、飞书、邮件等 Webhook 方式都能接入方便把 Agent 执行结果主动推送出来。多角色上下文的管理更加清晰避免多个角色之间互相污染记忆出现“上一个任务的结果被下一个任务错误引用”的问题。后面我会针对这三个方向分别展开讲。2. 环境准备与安装2.1 安装 Hermes AgentHermes Agent 的安装推荐使用 Python 环境和虚拟环境管理工具。不同操作系统下的步骤略有区别但整体流程一致。以常见环境为例步骤如下# 克隆仓库 git clone https://github.com/NousResearch/Hermes-Agent.git cd Hermes-Agent # 创建虚拟环境推荐使用 uv也可以使用 python -m venv uv venv source .venv/bin/activate # Windows 环境激活方式 # .venv\Scripts\activate # 安装项目依赖 uv pip install -e .如果你更倾向于使用 Docker 部署Hermes Agent 也提供容器镜像方式。Docker 方式的好处是环境隔离、依赖干净适合部署在服务器上作为常驻服务运行。# 构建 Hermes Agent 镜像 docker build -t hermes-agent . # 启动容器并将宿主机配置目录挂载进容器 docker run -d \ --name hermes-agent \ -v $(pwd)/config:/app/config \ -v $(pwd)/output:/app/output \ hermes-agent关于版本建议根据实际项目需求调整。如果你在 Windows 上使用 Docker需要特别注意路径挂载格式和换行符问题避免配置文件在容器内解析异常。这部分我放到常见问题里详细说明。2.2 配置模型与 API 密钥Hermes Agent 需要调用大模型 API 来完成决策和生成。一般情况下需要准备模型供应商提供的 API Key并在环境变量中配置。export ANTHROPIC_API_KEYsk-xxxx如果你是使用 OpenAI 兼容接口或本地推理服务需要额外指定接口地址和模型名称export OPENAI_API_KEYsk-xxxx export OPENAI_BASE_URLhttp://localhost:8000/v1 export HERMES_MODEL_NAMEyour-model-name这一步很关键。很多同学安装完 Agent 后启动报错排查到最后发现只是 API Key 没有正确写入环境变量或者模型名称和供应商实际支持的名称不一致。2.3 验证安装是否成功安装完成后先运行一个最简单的命令验证环境是否就绪。hermes --version如果版本信息能正常打印说明依赖安装成功。接下来可以尝试一次最简单的单轮对话测试确认模型 API 调用链路是通的。如果这一步失败先不要继续配置五角色架构先把 API Key、网络连通性和模型名称三个问题排查干净。3. 五角色架构详解3.1 角色总览Hermes Agent Team 模式下的“五角色架构”是一套经过实践检验的分工体系。这五个角色并不是随意定义的而是对应了传统软件研发团队中最核心的五个职能角色名称职责定位对应传统团队角色核心产出Orchestrator统筹者接收需求、拆解任务、分发指令、汇总结果项目经理/技术负责人任务拆解清单、最终交付报告Product Manager产品经理澄清需求、明确验收标准、拆分用户故事产品经理需求文档、验收清单Solution Architect架构师技术选型、方案设计、风险识别架构师技术方案、架构图Developer开发者编写代码、修复缺陷、执行具体实现开发工程师代码、构建产物、测试报告Reviewer评审者代码审查、质量检查、回归验证测试/技术评审审查意见、质量报告这五个角色覆盖了一个小型研发任务从“想法”到“可交付成果”的完整链路。在一人公司模型中使用者的角色是“老板”只需要提出需求和最终拍板中间过程交给这五个 Agent 协作完成。3.2 Orchestrator统筹者Orchestrator 是整个 Team 模式的核心它类似于一个总调度器本身不直接写代码而是负责把大目标拆成子任务分发给其他角色并在各角色返回结果后判断下一步动作。在实际配置中Orchestrator 的 Prompt 需要特别强调只负责任务拆解和分发不替代其他角色完成专业工作。每次分发任务时要明确输入、期望输出和截止条件。当某个子任务失败时要自动判断是重新分发、换一种方式处理还是向上层请求人工介入。最终把所有角色的产出汇总成一份完整交付报告。你是一个软件研发团队的技术负责人。你需要把用户提出的需求拆解为可执行的子任务分配给对应的专家角色并在各角色返回结果后进行整合与验收。你的输出结构必须包含任务说明、目标角色、输入材料、验收标准。3.3 Product Manager产品经理Product Manager 角色的作用是承接用户模糊的想法把它变成清晰的需求描述。很多 Agent 项目跑偏根本原因不是编码能力不行而是需求一开始就没理清楚。PM 角色可以大幅减少这种问题。PM 角色的核心能力是提问和归纳。当用户说“帮我做一个数据统计工具”时PM 角色应该主动澄清数据的来源和格式是什么统计维度有哪些输出形式是网页、命令行还是 Excel 报表需要支持多用户还是单机使用这些澄清结果会以结构化文档的形式传给后续角色作为 Architect 和 Developer 的输入。3.4 Solution Architect架构师Architect 角色负责技术方案设计。它拿到 PM 产出的需求文档后会给出技术选型建议、模块划分、接口设计和风险点分析。这一环节的价值在于避免 Developer 直接“拿到需求就写代码”从而导致技术债积累。Architect 角色的 Prompt 应当包含这些约束优先选择成熟稳定的方案避免引入不必要的复杂技术栈。明确每个模块的输入输出边界。标注可能出现的性能和安全隐患。给 Developer 提供足够清晰的编码指引。3.5 Developer开发者Developer 是实际干活最多的角色负责把需求文档和技术方案转变成可运行的代码。在 Team 模式下Developer 的工具权限通常包括代码生成、命令执行、文件读写和测试运行。需要特别注意的是Developer 角色应该被限制在明确的代码目录范围内工作不要让它随意操作系统级文件。Agent 虽然能执行命令但如果不做路径和权限限制很容易在自动操作时产生意外影响。3.6 Reviewer评审者Reviewer 是容易被新手跳过但绝对不能省的角色。它负责从代码质量、逻辑完整性、安全性和测试覆盖度几个角度审查 Developer 的产出。Reviewer 的输出是一个审查报告包括发现的问题列表按严重程度划分。对每个问题的具体修改建议。本次交付是否可以进入验收环节的结论。在 v3.1 版本中Reviewer 的上下文与其他角色做了隔离这意味着它能够以“独立专家”的视角审查代码而不是被 Development 过程中的信息带着走。这一点在自动化流程中非常重要否则评审容易流于形式。4. 一人公司模型的运行流程4.1 任务流转链路在五角色架构下一个典型任务的流转链路如下用户输入 ↓ Orchestrator 拆解需求 ↓ Product Manager 需求澄清 ↓ Solution Architect 技术方案 ↓ Developer 编码实现 ↓ Reviewer 审查与回归 ↓ Orchestrator 汇总交付这个链路可以用一个有序列表来描述用户向 Orchestrator 提交原始需求。Orchestrator 判断需求是否足够清晰如果不清晰则退回给用户补充。需求清晰后Orchestrator 将任务分发给 PM 角色产出需求说明和验收标准。需求文档确认后Orchestrator 将文档转发给 Architect产出技术方案。技术方案评审通过后Developer 开始编码并运行测试。Developer 提交结果后Reviewer 进行代码审查和回归验证。Orchestrator 汇总所有产物生成最终交付报告返回给用户。4.2 上下文隔离与共享在多 Agent 协作中上下文管理是最容易出问题的地方。常见做法有两种全共享上下文和分角色独立上下文。全共享上下文实现简单但随着任务推进历史信息会越来越长不仅浪费 token还会让 Agent 抓不住重点。分角色独立上下文则要求 Orchestrator 在任务分发时主动整理摘要把需要传递的信息压缩成“任务简报”而不是把原始全部对话历史丢给下一个角色。在 v3.1 版本中我采用的做法是每个角色维护自己的对话历史文件。Orchestrator 在分发任务时使用“输入材料摘要 任务要求”的结构化格式传递上下文。每个角色完成后将产出物写入一个共享目录并通过索引文件登记产出物路径。这种“共享目录 独立上下文”的方式既保证了数据流通又避免了上下文串扰。4.3 失败重试与人工介入自动化流程不可避免地会遇到失败。我的策略是设置三级处理机制第一级单个角色执行失败时自动重试一次。如果重试成功流程继续。第二级重试仍然失败时Orchestrator 会修改子任务描述尝试换一种方式重新分发。比如 Developer 连续两次生成代码都报语法错误Orchestrator 可能要求先输出代码结构再填充实现细节。第三级再次失败时流程暂停等待人工介入。人工可以修正输入材料、调整配置或者直接终止任务。定时任务场景下三级处理机制尤其重要。白天人工介入没问题夜里自动运行时如果一直重试不仅浪费资源还可能产生错误的产出物。5. v3.1 版本核心特性实践5.1 定时任务调度一人公司模型的典型使用场景是“晚上自动跑一套任务第二天早上看结果”。这就需要 Agent 支持定时调度。在 v3.1 版本中定时任务的基本思路是配置一个任务调度器按 Cron 表达式触发指定工作流。示例配置如下# config/schedule.yaml jobs: daily_report: cron: 0 20 * * * workflow: report_workflow timeout: 3600 on_timeout: notify这个配置的含义是每天晚上 8 点执行一次名为daily_report的工作流如果执行超过 3600 秒未结束则发送超时通知。建议新手先用间隔较长的调度测试比如“每 10 分钟执行一次”并配合明细日志确认任务可以稳定跑通后再调整为真正需要的周期。5.2 钉钉通知投递定时任务如果只是“跑完就结束”对使用者的价值会打折扣。真正有用的自动化任务应该把结果主动推送给使用者。v3.1 版本的一个落地重点就是通知投递通道其中钉钉通道是很多国内开发者会优先选择的方式。钉钉通知的核心是 Webhook。在钉钉群中添加自定义机器人后会得到一个 Webhook 地址Agent 执行结果可以通过这个地址推送文本、Markdown 或链接卡片到群里。一个简化的钉钉通知配置如下# config/notify.yaml notify: channel: dingtalk dingtalk: webhook: https://oapi.dingtalk.com/robot/send?access_tokenxxxx secret: SECxxxx msg_type: markdown对应发送通知的核心实现思路import requests import time import hmac import hashlib import base64 import urllib.parse def send_dingtalk_message(webhook, secret, title, content): timestamp str(round(time.time() * 1000)) string_to_sign f{timestamp}\n{secret} hmac_code hmac.new( secret.encode(utf-8), string_to_sign.encode(utf-8), digestmodhashlib.sha256 ).digest() sign urllib.parse.quote_plus(base64.b64encode(hmac_code)) api_url f{webhook}timestamp{timestamp}sign{sign} payload { msgtype: markdown, markdown: { title: title, text: content } } response requests.post(api_url, jsonpayload) response.raise_for_status() return response.json()这里有三点需要特别注意如果钉钉机器人配置了加签安全设置发送时必须携带timestamp和sign参数否则会报invalid sign。Webhook 地址中包含access_token参数。拼接签名后的地址时要用连接不要替换掉原有参数。通知内容不要包含敏感信息。Agent 的产出物可能涉及源码、日志或内部数据推送到群聊前要做脱敏处理。if __name__ __main__: result send_dingtalk_message( webhookhttps://oapi.dingtalk.com/robot/send?access_tokenxxxx, secretSECxxxx, titleHermes Agent 定时任务完成, content## 报表生成成功\n- 输出文件: output/report.csv\n- 耗时: 128秒 ) print(result)上述代码是一个独立可运行的 Python 脚本用于测试钉钉 Webhook 是否正确配置。建议先单独运行这段代码确认消息能发出去再把它接入 Hermes Agent 的任务流程。5.3 Docker 部署与 Windows 注意事项如果你选择用 Docker 部署 Hermes Agent需要额外注意几个细节。第一Windows 宿主机和 Linux 容器之间的路径格式不同。挂载目录时建议使用相对路径或统一的环境变量避免 Windows 盘符路径被 Linux 容器错误解析。第二配置文件换行符在 Windows 下默认是 CRLF而 Linux 容器中的解析器可能只识别 LF。如果启动容器时提示配置解析异常优先把配置文件转换为 LF 换行符。第三容器内时间时区默认是 UTC定时任务如果不主动设置时区会和本地时间产生偏差。建议在容器启动参数中设置docker run -d \ --name hermes-agent \ -e TZAsia/Shanghai \ -v $(pwd)/config:/app/config \ -v $(pwd)/output:/app/output \ hermes-agent# 查看容器日志确认定时任务是否按时触发 docker logs -f hermes-agent这一步可以帮助你快速确认时区、配置和任务调度是否正常。6. 完整实战搭建一个每日自动报表工作流6.1 需求描述假设我们需要一个自动化工作流每天定时拉取业务数据库的订单数据统计当天的成交金额和订单量生成一份 Markdown 报表并通过钉钉群推送结果。如果把需求直接丢给一个普通 Agent它可能会写出一个能用的脚本但后续维护和扩展会变得混乱。下面使用五角色架构把这一整套流程拆解开。6.2 任务分拆在 Hermes Agent Team 模式下Orchestrator 会把任务分发给各角色PM明确数据来源、统计口径、报表字段和推送时间。Architect确认使用 Python 数据库连接库设计脚本模块结构。Developer编写数据查询脚本、Markdown 生成逻辑和推送逻辑。Reviewer检查 SQL 是否正确、统计口径是否一致、推送是否包含敏感信息。6.3 核心脚本示例以 Developer 角色产出的数据统计脚本为例核心逻辑如下# scripts/generate_report.py import sqlite3 from datetime import date DATABASE_PATH ./data/orders.db OUTPUT_PATH ./output/report.md def fetch_order_statistics(db_path): conn sqlite3.connect(db_path) cursor conn.cursor() today date.today().isoformat() cursor.execute( SELECT COUNT(*), COALESCE(SUM(amount), 0) FROM orders WHERE DATE(created_at) ? , (today,)) order_count, total_amount cursor.fetchone() conn.close() return order_count, total_amount def render_markdown(order_count, total_amount): today date.today().isoformat() return f# 每日订单报表 - 统计日期{today} - 订单数量{order_count} - 订单总金额{total_amount:.2f} 元 def main(): count, amount fetch_order_statistics(DATABASE_PATH) markdown render_markdown(count, amount) with open(OUTPUT_PATH, w, encodingutf-8) as f: f.write(markdown) print(f报表已生成{OUTPUT_PATH}) if __name__ __main__: main()这个示例使用 SQLite 演示数据统计逻辑实际业务中你可以替换为 MySQL、PostgreSQL 等数据库连接方式核心思路是一致的。# 运行脚本 python scripts/generate_report.py运行正常时output/report.md会生成当天的订单统计报表。6.4 接入通知通道脚本生成报表后还需要接入钉钉通知。可以在主流程中继续调用前面写好的send_dingtalk_message函数。# scripts/run_daily_workflow.py from generate_report import fetch_order_statistics, render_markdown from notify import send_dingtalk_message def run(): count, amount fetch_order_statistics(./data/orders.db) markdown render_markdown(count, amount) with open(./output/report.md, w, encodingutf-8) as f: f.write(markdown) send_dingtalk_message( webhookhttps://oapi.dingtalk.com/robot/send?access_tokenxxxx, secretSECxxxx, title每日订单报表, contentmarkdown ) if __name__ __main__: run()然后通过 Hermes Agent 的定时任务配置把run_daily_workflow.py设置为每天固定时间执行。6.5 运行结果说明完成以上配置后每天定时时间点会依次发生调度器启动run_daily_workflow.py。脚本查询数据库生成 Markdown 报表。钉钉 Webhook 把报表推送到群聊。如果执行失败则触发失败重试或人工介入流程。这套流程跑通之后你可以继续扩展增加多个数据源、加入异常告警、汇总多份报表到一张总看板等。所有扩展都不需要推翻现有的五角色架构只需要在具体脚本或配置中增加内容。7. 常见问题与排查思路7.1 问题对照表问题现象常见原因解决思路启动时报 API Key 错误环境变量未配置或配置错误echo $ANTHROPIC_API_KEY检查环境变量确认模型名称正确钉钉消息发送失败Webhook 拼接错误、签名缺失、机器人被移除先单独运行发送脚本确认timestamp和sign拼接顺序定时任务未按预期执行时区不一致、Cron 表达式错误检查容器时区用更小的间隔做测试角色之间上下文串扰所有角色共用同一个上下文改为分角色独立上下文由 Orchestrator 传递任务摘要Agent 任务陷入循环重试失败重试策略不当设置最大重试次数并加入人工介入机制Review 流于形式Reviewer 被 Development 上下文影响隔离评审上下文给 Reviewer 独立的审查清单7.2 钉钉通知失败的高频原因钉钉通知失败是接入时最容易遇到的问题。常见错误码和对应原因如下errcode: 310000签名错误或 timestamp 与服务器时间相差超过 1 小时。检查系统时间和签名生成逻辑。errcode: 310000且提示keywords not in content机器人配置了自定义关键词而消息内容中没有包含该关键词。在消息正文中加上关键词即可。连接超时或 SSL 错误企业内网环境可能有网络限制需要确认目标接口可达。7.3 排查 Agent 任务卡住的通用步骤当 Agent 任务长时间没有进展时按以下步骤排查查看当前任务的执行日志定位卡在哪一个角色环节。手动验证该角色对应的工具命令是否可以独立执行成功。检查传给该角色的输入材料是否完整、格式是否正确。确认最大重试次数是否耗尽以及失败后是否有通知。如果问题无法定位手动暂停任务并导出上下文摘要避免浪费 token。8. 最佳实践与工程建议8.1 角色 Prompt 设计要点五角色架构的效果很大程度上取决于每个角色的 Prompt 设计。我的经验是每个角色的系统提示词必须包含以下结构角色定义说明这个角色是什么、擅长什么。工作边界明确哪些事情不做。输入说明定义接收的任务格式。输出说明定义返回结果的固定结构。注意事项列出该角色最容易犯的错误。你是日常开发团队中的资深产品经理。你的职责是把用户模糊的需求转化为清晰、可验收的需求文档。 你不负责编写代码也不负责技术选型。 输入用户原始需求描述。 输出包含背景、目标用户、功能清单、验收标准的需求文档。 注意所有功能描述必须可验证不要使用模糊表达。8.2 成本控制一人公司模型本质上是“用 token 换生产力”。五角色协作跑一次完整任务token 消耗通常比单角色高不少。控制成本的关键点是每个角色的上下文要尽量精简不要把全历史都传给下一个角色。定时任务中增加超时和最大执行次数限制避免死循环。Review 环节设置抽检模式只有在代码复杂度较高时才做全量审查。使用本地推理服务或更小的模型处理低风险子任务降低单位成本。8.3 安全边界Agent 自动化执行命令的能力是把双刃剑。生产环境中必须把安全边界划清楚给 Agent 指定工作目录禁止其访问目录之外的文件。数据库操作使用只读账号特殊写操作必须二次确认。通知内容做脱敏处理避免内部信息外泄。涉及生产环境的变更在测试环境先完整跑通一遍流程。API Key 和 Webhook 密钥不要写在代码仓库中使用环境变量或密钥管理服务。8.4 可观测性与审计自动化流程跑多了以后最怕的是“不知道发生了什么事”。所以我建议从第一天就建立日志和审计机制每个角色的每次执行都记录开始时间、结束时间、输入摘要、输出摘要和 token 消耗。定时任务开启执行记录失败时自动留存现场日志。关键操作如文件删除、命令执行、数据更新必须有结构化日志方便事后追溯。这样即使某天任务凌晨执行失败第二天早上也可以快速定位原因而不是对着一个黑盒干瞪眼。9. 总结Hermes Agent Team 五角色架构和一人公司模型的组合本质上是用一套低成本的自动化流程替代传统小团队的重复性协作。这套模型的价值不在于让 Agent 写多少代码而在于它把复杂的研发交付过程沉淀成了稳定、可复用、可观测的流水线。如果你现在正准备开始实践我的建议是先不要一次性上五角色完整流程。可以先用一个 Orchestrator 加一个 Developer 跑通最小闭环确认安装、模型调用、工具权限、日志输出都正常然后逐步加入 Product Manager、Solution Architect 和 Reviewer 角色。每一步都验证后再叠加排错成本会低很多。v3.1 版本的定时任务和通知投递通道可以看作这套流程的基础设施。把“定时触发 钉钉推送 失败重试 人工介入”这条链路先跑通后续无论你接什么业务逻辑都只是往这个管道里增加具体的任务脚本而已。钉钉 Webhook 的配置、Cron 表达式的调度、角色的上下文隔离这几块都值得在一开始就做好记录后面的迭代会顺利不少。