Hermes Agent Control Room 是一个面向多 Agent 管理的公开模板，从单台 VPS 上的一个 Hermes agent，一路扩展到专家团队和编排式工作流。它的命名规范要求：每个 Agent 使用一个稳定、自解释的统一标识（slug），比如hermes-seo，而不是agent1。这一规范贯穿容器名、数据目录、文档目录和 API 密钥，是整套管理体系的地基。

为什么名字是 Agent 管理的第一步

很多人搭完第一个 Agent 就直接开工，直到想加第二个、第三个时才发现：agent1、bot、main这类名字完全无法区分谁是谁。

而 Control Room 的思路是先建“指挥中心”，再让 Agent 接入。注册表、任务总线、运行手册全部靠名字来定位一个 Agent：

• 注册表 templates/task-bus/agents.yaml 用名字索引每个 Agent 的角色、文档路径、数据目录；
• 编排器（orchestrator）靠名字决定把任务派给谁；
• 任务总线靠名字划分工作队列，见 docs/task-bus.md。

名字不稳定，这套系统就转不起来。所以命名规范不是风格问题，而是工程约束。

核心规则：一个 slug，处处通用

docs/naming.md 给出的规则只有一条：Use one stable slug everywhere（同一个 slug 到处使用）。以hermes-seo为例，所有位置这样对应：

这套设计的妙处在于一致性带来的可预测性：

• 看到docker ps里的容器名，立刻知道是哪台 Agent 在跑；
• 想查日志、改配置、做备份，直接拼出/srv/hermes-seo/data，不用猜；
• 运维命令、脚本、文档全部使用同一套词汇，新人接手成本极低。

每个 Agent 独占一个 Docker 容器和数据目录（模板见 templates/agent/docker.md），名字就是隔离边界——不允许两个 gateway 进程共用同一个数据目录，而清晰的命名让这种冲突一眼可见。

推荐的基础名字：hermes- 前缀 + 角色

docs/naming.md 推荐了一批基础名，逻辑是hermes-前缀 + 职责关键词：

hermes-orchestrator # 编排器/前台入口 hermes-life # 个人助理 hermes-seo # SEO 专家 hermes-dev # 代码/站点 hermes-cmo # 市场 hermes-ops # VPS/备份/安全 hermes-finance # 财务

这种命名方式有四个好处：

1. 自解释：不用打开文档就知道它是干什么的；
2. 可扩展：新角色直接追加，如hermes-legal、hermes-hr，风格统一；
3. 兼容命令行：连字符（kebab-case）格式天然适配容器名、目录名、SSH 别名，不踩空格和特殊字符的坑；
4. 层级清晰：hermes-orchestrator与其他专家一眼可分，谁管谁很明确（角色划分见 docs/levels.md）。

这 5 个名字，请永远不要用 ❌

官方文档明确列出了应回避的模糊命名：

main / agent1 / bot / assistant / test

逐个说说它们为什么危险：

更麻烦的是改名成本：一旦注册表、任务队列、密钥名、目录都用了agent1，改名意味着同步修改 agents.yaml、/srv/agent-bus/tasks/下的队列目录、/srv/agent1/data数据目录、以及按agent1:<用途>命名的所有 API 密钥——最后你通常会选择“算了不改了”，从此背上技术债。

起好第一个名字，比改一百个地方便宜得多。

命名规范落地：三个真实场景

场景 1：注册表（Registry）

编排器靠注册表知道“有哪些 Agent、能干什么”。模板 templates/task-bus/agents.yaml 中，每个条目以 slug 为键：

agents: hermes-seo: role: SEO specialist data_dir: /srv/hermes-seo/data task_queue: /srv/agent-bus/tasks/seo allowed_work: [技术SEO审计, 内容简报, 搜索分析] forbidden_work: [未经批准的破坏性仓库操作]

名字就是外键。hermes-seo在注册表、队列路径tasks/seo、数据目录里一一对应，agent1则只能靠人脑记忆。

场景 2：API 密钥命名<agent-name>:<用途>

shared/api-keys-sop.md 规定密钥用Agent 名 + 用途命名，例如：

hermes-seo:github hermes-dev:deploy hermes-ops:monitoring

好处是：在服务商控制台一眼看出这把 key 属于谁、干什么用；轮换或吊销时不会误伤别的 Agent。密钥只记录“存在哪里、什么权限、何时轮换”，绝不记录值本身（模板见 templates/agent/env-map.md）。

场景 3：任务总线路径

编排器把任务文件写进专家收件箱，路径直接由名字派生（见 docs/task-bus.md）：

/srv/agent-bus/tasks/seo/inbox /srv/agent-bus/tasks/seo/outbox

任务模板里assigned_to: hermes-seo与队列目录tasks/seo互相印证，路由、审计、归档全靠这组稳定名字（模板见 templates/task-bus/task-template.md）。

如何快速选对名字：5 步清单 📋

1. 先写角色：用一句中文说清它干什么（“做 SEO 审计”→seo）；
2. 加前缀：组合成hermes-seo，保持 kebab-case；
3. 查重：在agents/目录和agents.yaml里确认没有重名；
4. 一次性铺开：容器名、/srv/hermes-seo/data、agents/hermes-seo/文档目录（含 inventory.md、runbook.md 等五份手册）全部用它；
5. 立誓不改：slug 一经使用就不再改名；聊天里的 Bot 显示名（如 “Hermes SEO”）可以随意，但 slug 永远稳定。

总结

Hermes Agent Control Room 的命名规范可以浓缩成一句话：一个 Agent，一个 slug，处处一致。

• hermes-seo这类名字自解释、可组合、命令行友好；
• 注册表、任务总线、密钥、备份全靠它串联，是 Agent 团队的“主键”；
• agent1、bot这类名字省下的几秒钟，会变成日后成倍的排查和改名成本。

先想清楚名字，再启动容器——这是从“一堆互不相连的 bot”走向“像操作系统一样运转”的第一步（完整上手流程见 docs/starter-guide.md）。