Hermes Bot Mode让多个 AI Agent 真正“打配合”而不是各干各的如果你最近在关注 AI Agent 开发大概率已经意识到一个问题单个 Agent 越来越强但放到真实业务里它仍然像一个“单兵作战”的实习生——你让它查资料它能查你让它写周报它能写但如果你让它“查完资料后结合团队本月数据生成一份带图表的周报再按部门分发”它就很容易卡在某个环节或者把上下文搞丢。这不是模型能力不够而是缺少一种多 Agent 协作的编排机制。Hermes 的 Bot Mode解决的核心问题正是这个让多个 AI Agent 在无人值守、按流程触发、各自分工的前提下协同完成一个复杂任务。本文会从概念、适用场景、配置实操、排错思路几个角度把 Bot Mode 讲透并给出一套可以在本地跑起来的最小示例。先说结论Bot Mode 真正降低的开发成本不是“调用一次大模型 API”的成本而是把多个 Agent 组织成一条可复用、可监控、可回滚的工作流的成本。它适合已经从“单 Agent 玩具项目”走向“多 Agent 工程化”的团队也适合刚入门但想建立正确心智的开发者。1. 为什么单 Agent 不够用Bot Mode 是必然选择先看一个具体场景。假设你有一个运维需求每天凌晨分析线上日志发现错误率超过阈值就自动创建工单并通知值班人员。用单个 Agent 做流程是这样的Agent 被唤醒拿到日志查询权限Agent 要自己理解“分析日志”这个动作Agent 要决定调用哪个接口、怎么过滤、怎么判断阈值Agent 要自己完成“创建工单”和“发送通知”如果中间某一步失败要么整体重来要么卡死。单个 Agent 的问题不是“它不会做”而是上下文会膨胀日志分析需要大量原始数据这些数据进入对话上下文后Agent 在处理后续步骤时容易被干扰。职责不清晰一个 Agent 既管数据分析又管工单系统还管通知渠道。一旦某个外部系统改接口你很难单独替换那条链路。失败不优雅没有“步骤级”的重试和回滚只能整体重跑成本高且容易产生脏数据。Bot Mode 的思路是不要试图让一个 Agent 做完所有事而是把一个复杂任务拆成多个子任务交给多个专门化的 Agent 去执行。每个 Agent 有自己的角色、上下文窗口、工具权限和输出格式。Bot Mode 作为调度层负责决定“谁先跑、谁后跑、怎么传数据、失败怎么处理”。从工程角度看这更像从“单体架构”转向“微服务架构”的过程。单个 Agent 的能力是“进程内”的Bot Mode 的协同能力是“进程间”的。它让你可以用模块化的方式搭建 AI 应用而不是把大量逻辑塞进一个 prompt 里。2. Hermes 与 Bot Mode术语对比与基本定位在继续之前先把几个容易混淆的术语理清楚。Agent智能体一个能感知环境、做出决策、调用工具完成任务的最小执行单元。它可以基于大模型也可以基于规则但在 Hermes 这类框架里通常指“大模型 工具 上下文 角色设定”的组合。Skill技能Agent 可以调用的一组能力封装。举例来说“读取日志”“写文件”“调用外部 API”都可以做成 Skill。Agent 本身不关心 Skill 内部实现只关心输入输出。Bot Mode机器人模式从已有材料看这是 Hermes 提供的一种运行模式核心特征是无人值守、按流程触发、多 Agent 协作。它不同于普通交互式 Agent 会话——在交互式会话里每一次响应都由用户输入触发在 Bot Mode 下任务可以由定时器、事件、外部 Webhook 或任务队列触发Agent 按编排好的流程执行并把结果写入指定位置。从架构上来理解维度普通 Agent 会话Hermes Bot Mode触发方式用户对话触发定时、事件、Webhook、队列触发上下文管理单 Agent 上下文多 Agent 分段上下文任务拆分由用户自己拆框架层编排失败处理对话中直接报错步骤级重试、跳过、告警适用场景问答、辅助写作、代码生成定时任务、流水线、复杂业务流程这里有一个关键判断Bot Mode 不是把所有 Agent 塞进一个群里聊天而是通过定义好“输入-处理-输出”的契约让每个 Agent 只负责自己最擅长的部分。3. 多 Agent 协同的四个核心难点很多人第一次接触多 Agent 时会有一种错觉只要创建多个 Agent然后在 prompt 里写“你们协作一下”任务就能完成。实际跑起来会发现难点根本不在这。3.1 任务拆分把一个复杂任务拆成多个子任务拆到什么粒度最合适拆太粗每个 Agent 依然要处理大量逻辑拆太细调度开销和上下文传输成本会淹没收益。实践中更推荐“按职能边界拆”而不是“按步骤拆”。举例一个“生成周报”任务。按职能拆可以分为“数据收集 Agent”“数据分析 Agent”“报告生成 Agent”“报告审核 Agent”。而按步骤拆则是“第一步查数据第二步算平均值第三步写标题第四步写正文”——后者只会让流程变得极其僵硬。3.2 上下文传递多 Agent 之间如何传递中间结果这是最容易被忽略的坑。如果每个 Agent 都接收全量上下文那么词频统计、全文摘要、原始日志都会堆在一起很快超过模型窗口还会互相污染。更合理的做法是明确定义每个 Agent 的输入字段和输出字段。前一个 Agent 只把“精简后的结果”传给下一个 Agent而不是把原始数据全部塞进去。这个思想类似于管道命令中的|而不是进程间的共享内存。Bot Mode 的核心价值之一就是帮你把这种传递方式固化下来。3.3 状态管理多个 Agent 协同执行任务必然涉及“当前执行到哪一步”“这一步成功没有”“下一步需要哪些数据”。这些状态信息如果放在对话上下文里一旦容器重启、进程崩溃整个任务就断了。稳定的编排方式应该把状态外部化——记录到数据库、任务表、消息队列或持久化存储中。Bot Mode 的设计目标是无人值守所以状态管理必须可靠否则重启后无法恢复。3.4 冲突与一致性多个 Agent 如果操作同一个文件、同一个数据库表或者调用同一个外部接口可能产生冲突。比如一个 Agent 在写文件另一个 Agent 在删文件一个 Agent 在更新订单状态另一个 Agent 在读取旧状态。多 Agent 协同不是并发编程但工程上必须有基本的“锁”或“幂等”机制避免重复执行、重复写入。4. Bot Mode 的典型适用场景有人会问Bot Mode 是不是只适合运维和后台任务不是。它的适用面其实很广但有几个共同特征流程确定、执行时间长、需要无人值守、涉及多个外部系统或工具。4.1 定时数据流水线典型场景每天凌晨自动从多个数据源拉取数据清洗、聚合、生成报表并发送到钉钉/企微/邮件。数据源、处理逻辑、输出对象都是确定的用 Bot Mode 可以省掉人来盯流程的时间。4.2 多步骤内容生产典型场景从用户需求到成稿。第一个 Agent 收集资料并生成大纲第二个 Agent 针对大纲撰写正文第三个 Agent 做事实核查和润色第四个 Agent 按平台格式排版。每个环节的结果都存成文件下一个环节读取后就地迭代。4.3 运维告警与自动处理典型场景日志监控 Agent 发现错误率上升触发诊断 Agent 拉取相关日志并分析可能原因如果判断是磁盘空间不足则自动执行清理脚本如果判断是应用异常则提交工单并通知值班人。整个流程无人值守但每个动作都有日志。4.4 事件驱动的业务处理典型场景一个外部系统通过 Webhook 推送新订单事件Bot Mode 启动一个 Agent 验证订单信息另一个 Agent 更新库存再一个 Agent 发送确认通知。事件驱动加上多 Agent可以让业务逻辑保持模块化。如果要把这些场景落成一个可复用的模板最核心的动作是把任务里的每个“环节”抽象成 Agent 的输入输出契约。契约定了Bot Mode 的编排就只剩参数填写。5. 环境准备与前置条件在开始配置 Bot Mode 之前需要先确认你有以下基础环境。由于不同版本 Hermes 的安装方式可能存在差异这里不给出具体版本号以官方发布为准但核心依赖项通常是一致的。5.1 运行环境操作系统Linux / macOS / WindowsWindows 建议优先使用 WSL2部分 Shell 命令和权限行为更接近生产环境容器或进程管理器Docker 可选用于隔离 Agent 运行环境至少一个可用的基础模型服务可以是 OpenAI 兼容接口、本地模型或托管平台提供的模型服务命令行工具git、curl、任意版本的 Python 运行时如果涉及脚本扩展。5.2 准备模型服务的访问凭证让 Agent 工作没有模型服务等于没有大脑。你需要提前准备好API Base URL模型服务地址API Key访问凭证模型名称如 gpt-4o、qwen-max、deepseek-chat 或本地模型名称注意如果使用自建或内网模型服务要确认 Bot Mode 启动节点能够访问该地址同时不要在配置文件中明文存储生产环境的密钥。更稳妥的做法是使用环境变量注入。5.3 确认网络访问策略如果 Hermes 需要拉取技能市场、更新组件依赖或者调用外部 API需要保证目标访问地址可达。公司内网限制较严格的场景可能需要配置代理环境变量但请确保代理设置和访问行为符合公司安全规定。6. 核心流程拆解从单 Agent 到 Bot Mode 的迁移思路假设你现在已经有一个能正常工作的单 Agent 应用要把它改造成 Bot Mode 下的多 Agent 协同流程。建议按下面四个步骤来做而不是一上来就写配置。6.1 画出任务的全流程用纸笔或任意画图工具把任务从输入到输出画出来。每个方框是一个环节每个箭头是一个数据传递。例如“自动生成运维日报”[采集原始日志] - [分析错误分级] - [生成日报文本] - [推送消息到群]看起来很简单但每个环节背后都有隐藏输入输出。6.2 定义每个环节的输入输出这一步是核心。你不需要一开始就定义得很完美但必须有输入这个 Agent 需要什么数据这些数据从哪来输出这个 Agent 产出什么以什么格式输出JSON、纯文本、文件路径错误处理如果输入数据不合法是重试、跳过还是直接终止整个流程建议把输入输出定义在一个 JSON 或 YAML 文件里这样后续配置 Bot Mode 时可以直接映射字段。6.3 设计共享状态任务中间状态存储在哪里文件系统、Redis、数据库还是消息队列对小型任务文件系统足够对生产级任务建议用带持久化的消息队列或任务系统。状态里需要记录当前执行步骤、每个步骤的状态、最终结果位置。6.4 用 Bot Mode 做编排配置把第二步定义的输入输出映射到 Bot Mode 的配置文件中。每个 Agent 对应一个角色每个角色有明确的工具集和 Skill。这里真正容易踩坑的地方是不要把一个 Agent 要实现的所有逻辑都写进 prompt而是把逻辑拆到 Skill 里Agent 只负责决策和调用。这样 Bot Mode 编排的是 Skill 之间的依赖关系而不是大段 prompt 之间的隐式关联。7. 完整示例配置一个最小可运行的多 Agent 协同任务下面给一个最小示例。它不依赖任何特定云服务结构上模拟了“数据收集 Agent - 报告生成 Agent - 消息推送 Agent”的协同流程。所有配置和脚本可以在本地环境按需调整。7.1 目录结构建议把 Bot Mode 相关配置单独放到一个目录中方便管理和备份hermes-bot-demo/ ├── agents/ │ ├── collector.yaml │ ├── reporter.yaml │ └── notifier.yaml ├── skills/ │ ├── read_log.py │ └── send_message.py ├── flows/ │ └── daily_report.yaml ├── .env └── run_bot.sh7.2 定义数据收集 Agent文件agents/collector.yamlid: log-collector name: 日志收集器 description: 负责从指定日志文件中提取最近一小时的错误日志并输出为 JSON 数组。 model: provider: openai-compatible base_url: ${LLM_BASE_URL} api_key: ${LLM_API_KEY} model_name: ${LLM_MODEL_NAME} input: log_path: /var/log/app/error.log time_window: 1h output: format: json fields: - timestamp - level - message tools: - read_log说明${}表示从环境变量读取配置。tools列表声明这个 Agent 可以调用哪些 Skill。这里只给了read_log意味着这个 Agent 只能读日志不能发消息、不能写数据库。7.3 定义报告生成 Agent文件agents/reporter.yamlid: report-generator name: 日报生成器 description: 根据收集到的错误日志生成一份包含错误分类和趋势简述的日报。 model: provider: openai-compatible base_url: ${LLM_BASE_URL} api_key: ${LLM_API_KEY} model_name: ${LLM_MODEL_NAME} input: error_logs: ${collector.output} report_date: 2026-08-01 output: format: markdown file_path: /tmp/reports/daily_report.md tools: - write_file这里有两个关键点${collector.output}表示“读取 collector 这个 Agent 的输出”在 Bot Mode 中这种引用会被解析为前序步骤的产物这个 Agent 只能调用write_file不能读日志、不能发消息。7.4 定义消息推送 Agent文件agents/notifier.yamlid: message-notifier name: 消息推送器 description: 负责把生成的日报内容推送到群机器人。 model: provider: openai-compatible base_url: ${LLM_BASE_URL} api_key: ${LLM_API_KEY} model_name: ${LLM_MODEL_NAME} input: report_content: ${reporter.output} webhook_url: ${GROUP_WEBHOOK_URL} output: format: text result: sent tools: - send_message7.5 定义编排流程文件flows/daily_report.yamlid: daily-report-flow name: 每日运维日报 description: 每天凌晨自动收集日志、生成日报并推送通知。 trigger: type: cron cron: 0 1 * * * timezone: Asia/Shanghai steps: - id: collector agent: log-collector retry: 2 - id: reporter agent: report-generator input: error_logs: ${steps.collector.output} retry: 3 - id: notifier agent: message-notifier input: report_content: ${steps.reporter.output} retry: 1 on_error: - action: log - action: notify webhook: ${ALERT_WEBHOOK_URL}这个流程的语义是每天 1 点触发先运行log-collector把结果传给report-generator再把生成的日报传给message-notifier。任意步骤失败会按各自的重试次数重试最终仍失败则写入日志并发送告警。7.6 准备 Skill 脚本为了让示例在本地可运行还需要把 Skill 实现出来。这里用 Python 写两个简化版 Skill。文件skills/read_log.pyimport json import sys from datetime import datetime, timedelta def read_log(log_path: str, time_window: str) - list: 简化实现读取最近 time_window 内的 ERROR 日志。 logs [] now datetime.now() if time_window.endswith(h): hours int(time_window[:-1]) start_time now - timedelta(hourshours) else: start_time now - timedelta(hours1) with open(log_path, r, encodingutf-8) as f: for line in f: parts line.strip().split( , 3) if len(parts) 4: continue try: log_time datetime.strptime(parts[0] parts[1], %Y-%m-%d %H:%M:%S) except ValueError: continue if start_time log_time now and ERROR in parts[2]: logs.append({ timestamp: log_time.isoformat(), level: parts[2], message: parts[3] }) return logs if __name__ __main__: log_path sys.argv[1] time_window sys.argv[2] if len(sys.argv) 2 else 1h print(json.dumps(read_log(log_path, time_window), ensure_asciiFalse))文件skills/send_message.pyimport sys def send_message(webhook_url: str, content: str) - str: 简化实现只打印消息内容实际场景请使用 HTTP 请求调用机器人接口。 print( 推送内容 ) print(content) print( 推送结束 ) return sent if __name__ __main__: webhook_url sys.argv[1] content sys.argv[2] print(send_message(webhook_url, content))这两个 Skill 都没有真正访问外部系统目的是让你先理解“Agent 调用 Skill”时的输入输出链路。接入真实机器人时把send_message里的打印替换成requests.post即可。7.7 编写启动脚本文件run_bot.sh#!/usr/bin/env bash set -e # 加载环境变量 if [ -f .env ]; then export $(grep -v ^# .env | xargs) fi echo 启动 Bot Mode每日运维日报任务 # 这里仅演示启动流程实际请根据 Hermes 提供的 CLI 或 API 调整命令 hermes bot run --flow flows/daily_report.yaml echo Bot Mode 任务已结束请查看运行日志与输出文件。注意hermes bot run是示例命令具体命令以你使用的 Hermes 版本为准。核心思路是通过一个 CLI 或 API 入口把流程定义文件交给 Bot Mode 的调度器去执行。8. 运行结果与效果验证启动之前先准备一个测试日志文件mkdir -p /tmp/hermes-demo cat /tmp/hermes-demo/error.log EOF 2026-08-01 00:10:23 ERROR Database connection timeout 2026-08-01 00:30:11 WARN Slow query detected 2026-08-01 00:45:55 ERROR Disk usage over 90% 2026-08-01 01:05:00 INFO Service restarted EOF然后执行bash run_bot.sh预期你会看到类似下面的输出启动 Bot Mode每日运维日报任务 [collector] 读取日志完成共获取 2 条 ERROR 日志 [reporter] 日报生成完成保存到 /tmp/reports/daily_report.md [notifier] 消息推送完成判断成功的关键点有三个流程里的每个步骤都正常结束没有failed状态中间文件/tmp/reports/daily_report.md存在且内容非空推送 Skill 打印出了日报内容。如果运行失败第一步先看 Bot Mode 输出的日志。日志里通常会标记出哪一步失败、失败原因是什么、重试了几次。不要急着改代码先把失败步骤锁定位。9. 常见问题与排查思路问题现象可能原因排查方式解决方案启动时提示模型服务不可达API Base URL 配置错误或网络不通先 curl 一下模型服务地址检查连通性再看环境变量是否正确加载修正.env配置内网环境确认访问策略Agent 输出格式不符合预期模型返回格式不稳定或 prompt 里没有明确约束查看该步骤的原始输出和解析日志在 Agent 配置中增加输出格式说明必要时使用结构化解析步骤间的参数引用无效流程 ID 或步骤 ID 写错检查flows/daily_report.yaml里${steps.collector.output}的引用路径确保步骤 ID 与 references 完全一致任务执行成功但没生成文件Skill 脚本没有写权限或输出路径不存在查看运行日志中的写文件步骤确认目录存在手动创建输出目录并确认 Bot Mode 运行用户有写权限推送技能没有实际推送send_message.py目前只是打印查看 push Skill 日志将打印逻辑替换为真实 HTTP 调用任务重复执行没有做好幂等控制查看任务状态表或运行日志在记录表中增加唯一业务键重复触发时直接跳过Windows 上启动异常Shell 脚本兼容性问题确认使用的是 WSL2 或 Git Bash建议在 WSL2 中运行cloning repository 失败拉取技能或依赖仓库失败网络受限查看 git clone 报错信息使用国内镜像源或配置代理Bot Mode 回到主页面的命令不生效CLI 入口不同运行hermes bot --help查看参数按帮助信息调整命令从上表可以看到大多数问题集中在配置引用、网络连通和权限管理上。真正由“模型乱答”导致的问题反而少见。这说明多 Agent 协同的稳定性主要取决于工程设计和编排能力而不是模型单点能力。10. 最佳实践与工程建议10.1 每个 Agent 的职责要单一“让一个 Agent 只做一件事”这句原则从单 Agent 时代到多 Agent 时代都成立。如果一个 Agent 又要读日志、又要写报告、又要推送消息那它就不适合放进 Bot Mode而是应该在更上层拆开。判断标准很简单如果这个 Agent 需要三个以上不相关的工具且这些工具之间没有明确顺序就说明职责过重。10.2 用 JSON Schema 固定输入输出在 Agent 配置里尽量为输入输出定义 JSON Schema。这不是为了让模型理解而是为了让管道层能够可靠地校验数据。比如数据收集 Agent 的输出可以定义成{ type: array, items: { type: object, properties: { timestamp: { type: string }, level: { type: string }, message: { type: string } }, required: [timestamp, level, message] } }一旦输出不符合 schemaBot Mode 可以直接判定该步骤失败并触发重试而不是把脏数据传给下一个 Agent。10.3 中间结果必须持久化不要依赖内存传递中间结果。任务一旦被打断内存数据就丢了。中间结果建议写入文件、对象存储或数据库并记录对应的任务 ID。这样即使某个 Agent 崩溃重启也能从最近一次成功步骤恢复而不是重跑全流程。10.4 重试要幂等重试机制本身是把双刃剑。如果某个操作不是幂等的——比如“创建工单”“发送短信”——重试会导致重复执行。建议在 Skill 内部做幂等控制接收一个业务请求 ID处理前先检查是否已经处理过。10.5 日志和可观测性每个步骤开始和结束时都应当输出结构化日志包含任务 ID、步骤 ID、Agent ID、输入摘要、消耗时长、输出摘要。例如{ task_id: task_001, step_id: collector, agent_id: log-collector, input_summary: log_path/var/log/app/error.log, output_summary: 2 errors found, duration_ms: 320, status: ok }有了这些日志排查问题时才能快速定位是哪个 Agent、哪个步骤、哪次调用出了问题。10.6 安全边界最小权限原则这一点在 Bot Mode 里尤其重要。一个多 Agent 任务通常涉及多个工具权限范围应该按“最小够用”原则划分日志收集 Agent 只需要读日志文件权限不需要写权限报告生成 Agent 只需要写报告目录权限不需要访问生产数据库消息推送 Agent 只需要 Webhook 调用权限。不要把管理员的全部凭证传给所有 Agent。一旦某个 Agent 被 prompt injection 攻击影响范围可以被限制在单个 Skill 内。10.7 配置管理不要写死敏感信息模型服务的 API Key、Webhook 地址、数据库密码都应该通过环境变量或密钥管理系统注入而不是直接写在 YAML 文件里。上面的示例里使用了${...}引用这种做法的好处是配置文件可以入库敏感信息始终留在运行环境。11. 总结与后续学习方向这篇文章从“单 Agent 的局限性”出发讲了 Hermes Bot Mode 的核心定位它不是让一个 Agent 变强而是通过编排让多个 Agent 有序协作。然后从任务拆分、上下文传递、状态管理和冲突处理四个角度说清了多 Agent 协同的难点并给出一套最小可运行示例覆盖了 Agent 定义、Skill 实现、流程编排和启动命令。把这篇文章里的思想落地比记住任何具体命令都重要。你可以先做一个最简单的实验把之前用单个 Agent 完成的定时任务拆成“数据获取 - 处理 - 输出”三段分别用三个 Agent 跑通再逐步增加异常处理和旁路监控。后续值得深入研究的方向有任务队列与分布式调度、Agent 之间的安全认证、模型输出校验、以及更复杂的 DAG 编排模型。多 Agent 的工程化才刚刚开始与其等一个“万能 Agent”出现不如先把现有的 Agent 编排好。建议收藏备用。如果你正在研究 Hermes 的 Bot Mode或者正在做多 Agent 项目欢迎在评论区聊聊你目前卡在哪个环节。