从零搭建团队可共享的 Hermes Agent 开发环境

团队里想推广 Hermes Agent，第一道坎往往不是「怎么用」，而是「怎么让大家在同一个基础上跑」。本文聚焦团队级别的落地思路，覆盖环境统一、配置分层、上下文约定和安全基线四个方面。适合准备做小规模试点或内部推广的团队参考。

先把「在哪儿跑」定下来

部署 Hermes 之前，团队需要先对齐在什么平台上跑。Hermes Agent 支持 Linux、macOS 和 Windows WSL2，原生 Windows 不支持。如果团队成员混用多种平台，排查问题会非常费劲——不同平台的安装方式、依赖管理和行为表现可能有差异。提前统一平台，可以省去大量「在我那儿明明好好的」式对话。

选定平台后，下一步是决定安装方式。Hermes 依赖 Git、uv（Python 包管理器）、Python 3.11、Node.js v22、ripgrep 和 ffmpeg，这些都由安装脚本自动处理，你只需要确保 Git 已安装。

两种安装路径：

• 脚本安装：一行命令跑完，适合快速铺开。

  bash 复制

  curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
  

  团队成员技术背景不一时，这种方式能降低第一道门槛。

• 手动安装：更适合受控环境或需要走内网镜像的场景。如果公司对外部工具引入有合规要求，手动安装配合内部源可以满足审计需求。

安装完成后，运行 source ~/.bashrc（或 ~/.zshrc）加载环境变量，然后用 hermes 启动聊天。如果遇到 command not found，先检查 PATH 是否正确，或者运行 hermes doctor 获取诊断信息。

双层配置：全局管底座，项目管约束

Hermes 的配置体系设计成两层：全局配置和项目配置。这种分层的好处是，团队公共的部分放全局，项目特有的部分放项目目录，互不干扰又方便继承。

全局配置存放在 ~/.hermes/ 目录下：

• config.yaml — 主要配置文件，管模型、终端后端、TTS、压缩设置等
• .env — API 密钥等敏感凭据
• SOUL.md — Agent 身份和人格定制
• memories/ — 持久化记忆

配置优先级从高到低是：CLI 参数 > config.yaml > .env > 内置默认值。经验法则是：密钥（API 密钥、令牌、密码）放 .env，其他配置（模型、终端后端、压缩设置）放 config.yaml。

可以用 hermes config set KEY VAL 直接修改配置，这条命令会自动把密钥类值路由到 .env，其他值路由到 config.yaml。

项目上下文文件处理更细粒度的约束：仓库级的编码规范、模块说明、团队协作规则等。不同目录下的成员只会看到与自己相关的约束，不会被无关规则干扰。

用上下文文件让团队行为一致

Hermes 支持多种上下文文件：

优先级规则是：每个会话只加载一个项目上下文文件（首个匹配者胜出）：.hermes.md → AGENTS.md → CLAUDE.md → .cursorrules。SOUL.md 作为 Agent 身份始终独立加载，不在这个优先级体系内。

渐进式子目录发现是团队协作的关键特性：启动时从工作目录加载顶级上下文文件，会话期间当 Agent 通过工具导航到子目录时，会自动发现并注入该目录的上下文文件。比如读取 backend/src/main.py 时，会同时发现 backend/AGENTS.md，即使你当前在 backend/src/ 目录下。

上下文文件还内置了安全扫描机制，检测提示词注入攻击（"ignore previous instructions"）、隐藏 HTML 注释、凭据泄露（curl ... $API_KEY）、敏感文件读取（cat .env）等威胁。每文件最大 20,000 字符，超过的部分会自动截断。

对于多目录仓库，用递归上下文文件描述局部模块差异。这种设计让上下文文件成为团队规范的载体，而不是又一份「建议阅读」式的文档。规范落在工具里，落地成本最低。

安全是团队环境的底线

团队试点阶段最常见的坑是：开发环境跑通了，上线才发现权限没收紧、审批没配、隔离没做。Hermes Agent 内置了七层纵深防御安全体系，建议在试点初期就把这几项配好：

危险命令审批支持三种模式：

• manual（默认）：执行危险命令前提示人工确认
• smart：AI 辅助判断命令风险级别
• off：跳过所有审批检查（YOLO 模式）

系统通过模式匹配检测危险操作，包括 rm -r、chmod 777、SQL DROP/DELETE/TRUNCATE、curl | sh 远程脚本执行等数十种模式。审批时可以选择一次（once）、当前会话（session）、始终允许（always）或直接拒绝（deny）。

容器隔离方面，如果团队使用 Docker 后端，Hermes 默认启用严格加固：丢弃所有 Linux 能力、阻止权限提升、限制进程数为 256、tmpfs 隔离临时目录。配置文件还可以定义 CPU、内存、磁盘的资源限制。

网络访问始终启用 SSRF 防护，阻止对 RFC 1918 私网、127.0.0.0/8 回环、169.254.0.0/16 链路本地（含云元数据端点）和 100.64.0.0/10 CGNAT 地址空间的访问。

配置层需要与权限管理配合。不要让成员各自配置安全策略——统一的安全基线应该由管理员设定，成员默认继承。这才是「试点成功、上线不翻车」的正确姿势。

把经验固化成可复制的模板

走到这一步的团队，通常已经积累了一些「坑」和「经验」。把这些沉淀下来，比每次新人入职重新摸索要高效得多。

Onboarding checklist 是最基础的沉淀。把安装步骤、配置项、环境变量整理成一份清单，新成员照着跑一遍就能对齐团队基线。不用每次都靠口口相传，也不用担心不同成员配出不同的环境。

更进一步，可以把上下文约定和安全规范做成仓库模板。新项目直接基于模板创建，自动继承团队规范，不需要重复配置。这种方式特别适合团队同时维护多个仓库的场景——规范跟着模板跑，而不是靠成员自觉遵守。

Hermes 的上下文文件机制天然支持这种沉淀方式。把团队协作规则写成 AGENTS.md，放进模板仓库，后续所有项目都能复用这份规范。

团队级推广 Hermes Agent，本质上是把个人工具变成团队基础设施。这个过程比单人配置要复杂，但一旦跑通，团队里的每个人都能站在同一个基础上协作。剩下的，就是持续优化和积累经验了。