Hermes Agent

一句话结论

Hermes Agent 是 Nous Research 做的一个“长期运行、跨平台、有记忆、会沉淀技能的个人/团队 AI Agent 操作层”。它不是只给开发者嵌入代码的 Agent SDK，而是更像一个可以部署在本机、VPS、容器、SSH 远程机、Modal/Daytona 云沙箱里的 AI 助手运行时：用户可以在 CLI、桌面端、Telegram、Discord、Slack、WhatsApp、Signal、Email、企业 IM、API Server、IDE 等入口跟它对话，它在背后调用模型、工具、MCP、终端、文件、浏览器、定时任务和子 Agent 完成工作。

对售前来说，它最值得关注的不是“又一个聊天机器人”，而是三件事：第一，跨渠道统一 Agent 入口；第二，Agent 通过 Memory、Session Search、Skills 形成可持续学习闭环；第三，它对工具、MCP、容器隔离、审批、安全边界、后台任务和定时任务的工程化程度比较高，适合拿来讲“企业级 Agent 从 Demo 走向常驻运行”的落地形态。

项目能做什么

1. 跨终端与跨消息平台的 AI Agent

Hermes 有两类主入口：一类是本地/远程工作入口，包括 CLI、TUI、桌面端、API Server、IDE/ACP 适配器；另一类是消息网关，包括 Telegram、Discord、Slack、WhatsApp、Signal、Email、Home Assistant、Mattermost、Matrix、钉钉、飞书/飞书国际版、企业微信、微信、QQ、Teams、LINE、ntfy、Raft、IRC 等。

这意味着用户不是必须打开某个 Web 应用才能使用 Agent，而是可以从自己已有的工作入口发起任务。例如：

在 Telegram 中发一句“帮我每天早上 8 点汇总竞品新闻”。
在 Slack 中让它查某个服务状态、整理日志、发日报。
在 CLI 中让它改代码、跑测试、读本地文件。
在 IDE 中把 Hermes 作为编辑器 Agent 使用。
在 API Server 或 Webhook 里把它接入企业自动化流程。

售前表达上，可以把它理解为“一个 Agent，多端入口，一个后台网关统一承接任务”。

2. 多模型与多服务商路由

Hermes 支持 Nous Portal、OpenRouter、OpenAI、自定义 OpenAI-compatible endpoint，以及文档中提到的多种模型提供商。用户可以通过 hermes model 或 /model provider:model 切换模型，而不是在业务代码里重写调用逻辑。

这对客户的价值在于：

避免被单一模型厂商绑定。
可以按任务切模型，例如编码、长文本、低成本后台任务使用不同模型。
可以接企业已有的模型网关或私有部署接口。
Nous Portal 还把模型、Web Search、图像生成、TTS、云浏览器等工具能力做成统一订阅入口，降低 API Key 配置成本。

3. 工具系统：从对话到真正执行

官方文档显示 Hermes 内置工具覆盖 Web 搜索、网页抽取、终端执行、文件读写、patch、浏览器自动化、视觉分析、图像生成、TTS、TODO、记忆、会话搜索、定时任务、子 Agent 委派、Home Assistant、MCP 外部工具等。架构文档提到内部是中心化 Tool Registry，约 70+ 工具、约 28 个 toolsets。

典型能力包括：

terminal：执行命令，支持后台进程。
read_file / patch：读取和修改文件。
web_search / web_extract：搜索和抽取网页内容。
browser_navigate / browser_snapshot / browser_vision：浏览器自动化。
delegate_task：委派子 Agent 并行处理任务。
cronjob：创建、运行、暂停、恢复定时任务。
memory / session_search：保存长期偏好与检索历史会话。
MCP 工具：接 GitHub、数据库、内部 API、文件系统、第三方 SaaS 等外部工具服务器。

售前要点：Hermes 不是“只会回复”，而是具备任务执行链路。它的关键价值在于把 LLM、工具、执行环境和消息入口串成一个可长期运行的 Agent Runtime。

4. 记忆与技能闭环

Hermes 的 README 把自己定位为 “self-improving AI agent”。它的学习闭环主要由三部分组成：

模块	作用	售前解释
Persistent Memory	保存用户偏好、环境事实、项目约定等	让 Agent 逐步理解用户和团队习惯
Session Search	基于 SQLite + FTS5 检索历史会话	让 Agent 能回忆过去讨论过的具体内容
Skills System	把重复流程沉淀为可复用技能	把一次性的经验变成下次可调用的 SOP

Memory 文档显示，Hermes 默认用 MEMORY.md 保存 Agent 自身工作笔记，用 USER.md 保存用户画像，且有字符上限，避免记忆无限膨胀。Session Search 则保存所有 CLI 和消息会话，可以按需搜索历史记录。Skills 则是按需加载的知识文档，兼容 agentskills.io 开放标准，并支持 /learn 从文档、目录、URL 或刚刚完成的工作流中生成新的技能。

这点对企业客户很容易形成价值故事：传统 Chatbot 每次都要重新解释上下文，而 Hermes 希望把“客户的偏好、组织流程、项目约束、常见修复方法”逐步沉淀下来，形成可复用知识资产。

5. MCP 集成与可扩展工具生态

Hermes 支持作为 MCP Client 连接 stdio 或 HTTP MCP Server，也可以反过来以 hermes mcp serve 形式作为 MCP Server，把它的消息会话能力暴露给 Claude Code、Cursor、Codex 等 MCP Client。

MCP 对售前的意义很大，因为它让 Hermes 不必为每个企业系统单独写原生工具。企业已有的 GitHub、Linear、Stripe、数据库、内部 API、文件系统、知识库等，只要通过 MCP 暴露，就能被 Hermes 自动发现并注册为工具。Hermes 还支持 per-server 工具过滤，例如只暴露 list_issues、create_issue，屏蔽删除、退款等高风险动作。

适合的客户话术：

如果客户已经在建设 MCP 工具层，Hermes 可以作为一个多渠道 Agent 入口，把 MCP 工具带到 CLI、IM、定时任务、桌面端和自动化流程里。

6. 后台任务、子 Agent 与定时自动化

Hermes 支持后台任务和子 Agent。最新 Release v0.17.0 中强调了 delegate_task(background=true)：主 Agent 可以把长任务派给后台子 Agent，并继续处理当前对话，任务结束后结果再回到会话。

消息网关也支持 /background ，例如在聊天里启动“检查所有服务器健康状态并汇报异常”，主聊天不中断。Cron 则把任务变成自然语言定时自动化，比如日报、夜间备份、周审计、竞品监控、会议纪要生成等。

这类能力适合展示“从问答助手到自动化员工”的过渡。

官方架构示意

项目文档中的架构图是文本图，核心结构如下：

Entry Points
  CLI / Gateway / ACP / Batch Runner / API Server / Python Library
        |
        v
AIAgent (run_agent.py)
  Prompt Builder
  Provider Resolution
  Tool Dispatch
  Compression & Caching
  Tool Registry
        |
        +--> Session Storage: SQLite + FTS5
        |
        +--> Tool Backends:
             Terminal: local / Docker / SSH / Singularity / Modal / Daytona
             Browser
             Web
             MCP
             File / Vision / Media

从这个图可以看出，Hermes 的设计是“平台入口和 Agent Core 分离”：CLI、消息网关、Cron、ACP、API Server 等入口最终都会进入同一个 AIAgent 核心，再由核心做 Prompt 构造、模型路由、工具调度、会话持久化和执行环境选择。这种架构比“每个平台一个 bot”更利于统一配置和统一治理。

适用场景

场景一：研发团队的常驻编码与运维 Agent

适合客户：研发团队、平台工程团队、DevOps/SRE 团队、AI 原生创业团队。

可以做：

在 CLI/桌面端中让 Agent 读代码、改代码、跑测试。
在 Slack/飞书/企业微信中触发检查、部署、日志分析、服务健康报告。
用 Cron 定时跑每日构建报告、依赖风险扫描、Issue 汇总。
通过 MCP 接 GitHub、Linear、Jira、内部监控系统。

售前价值：把研发和运维中的碎片化操作沉淀成自然语言可调度流程，减少“人肉查状态、人肉汇总、人肉重复脚本”。

场景二：企业内部多渠道 AI 助手网关

适合客户：已经有多个 IM 渠道、跨地区团队、希望把 AI 能力放到员工日常入口中的企业。

可以做：

一个 Agent 同时接入 Slack、Teams、飞书、企业微信、Email 等。
对不同平台设定不同 Toolset 和权限。
通过 allowlist、DM pairing 控制谁能访问。
把自动化结果投递回用户所在渠道。

售前价值：不用强迫员工切换到新平台，AI 能力直接进入已有协作环境。

场景三：个人或小团队的“长期私人 AI 助手”

适合客户：创始人、顾问、研究员、售前、技术负责人。

可以做：

记住用户偏好和工作方式。
搜索过往会话，找回之前讨论过的项目、客户、方案。
把常用流程学成 Skills。
在 VPS 上常驻运行，从手机消息软件远程调用。

售前价值：强调“AI 助手不再只是一页聊天窗口，而是一个长期跟随用户工作的个人工作层”。

场景四：Agent 工具生态与 MCP 落地试验田

适合客户：正在建设内部 Agent 平台、MCP Server、统一工具网关的团队。

可以做：

通过 Hermes 验证 MCP 工具暴露是否合理。
测试不同模型对工具调用的稳定性。
比较本地、Docker、SSH、Modal、Daytona 等执行后端。
用轨迹生成和压缩能力为工具调用模型训练准备数据。

售前价值：Hermes 可以作为 Agent 工具层的“体验终端”和“验证平台”，帮助客户更快看见 MCP/工具化的业务效果。

不适合的场景

Hermes 并不适合所有项目。以下场景要谨慎推荐：

只需要在产品里嵌入一个轻量聊天组件，Hermes 可能过重。
强监管环境要求明确的企业级 RBAC、审计、审批流、租户隔离，Hermes 当前更偏单租户/个人 Agent，需要额外封装。
不允许 Agent 执行命令、读写文件或调用外部工具的场景，会削弱 Hermes 最大价值。
客户希望采购开箱即用的商业 SaaS，而不是部署和维护一个开源 Agent Runtime。
对第三方 Skills、Plugins、MCP Server 没有审查机制的团队，不宜直接开放高权限工具。

如何使用

快速安装

Linux、macOS、WSL2、Termux：

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
source ~/.bashrc
hermes

Windows PowerShell：

iex (irm https://hermes-agent.nousresearch.com/install.ps1)

常用命令：

hermes              # 启动交互式 CLI
hermes model        # 选择模型提供商和模型
hermes tools        # 配置启用工具
hermes setup        # 完整设置向导
hermes gateway      # 启动消息网关
hermes update       # 更新 Hermes
hermes doctor       # 诊断环境问题

启动消息网关

hermes gateway setup
hermes gateway start

消息平台中常用命令：

/new 或 /reset        开启新会话
/model               切换模型
/skills              查看或调用技能
/background          启动后台任务
/stop                中断当前任务
/reload-mcp          重新加载 MCP 工具
/usage               查看用量

配置 MCP

最小 stdio MCP 示例：

mcp_servers:
  filesystem:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/projects"]

最小 HTTP MCP 示例：

mcp_servers:
  company_api:
    url: "https://mcp.internal.example.com/mcp"
    headers:
      Authorization: "Bearer ***"

工具过滤示例：

mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "***"
    tools:
      include: [list_issues, create_issue, update_issue]
      prompts: false
      resources: false

安全与部署要点

Hermes 的安全文档讲得比较坦诚：它把“操作系统级隔离”视为真正的安全边界，审批门、命令扫描、输出脱敏、Skills Guard 等都属于启发式防护，不应被当成强隔离。

售前必须提醒客户：

默认本地后端会在宿主机执行命令，不适合接入不受控输入源。
生产或多人场景建议使用 Docker、Modal、Daytona、SSH 远程机等隔离后端。
消息网关必须配置 allowlist 或 DM pairing，不要开放给所有用户。
MCP Server、Skills、Plugins 都可能带来供应链风险，需要审查来源和暴露工具。
对敏感系统应采用工具白名单，优先只开放读操作或低风险操作。
高安全场景应考虑整个 Agent 进程级别的容器/沙箱包装，而不是只隔离 terminal。

官方推荐的生产网关 Checklist 包括：设置明确 allowlist、使用容器后端、限制资源、妥善保存密钥、开启 DM pairing、审查命令 allowlist、限定工作目录、非 root 运行、监控日志、定期更新。

售前讲解框架

客户痛点

AI 助手目前停留在聊天窗口，不能进入真实工作流。
每个渠道都有单独机器人，知识和会话割裂。
Agent Demo 很容易，长期运行、权限、安全、记忆、工具治理很难。
内部工具很多，但缺少一个自然语言统一入口。
员工重复性工作多，例如查资料、整理报告、跑脚本、巡检、汇总、发通知。

Hermes 的价值主张

多入口：CLI、桌面端、IM、Email、API、IDE 都能接入。
多模型：支持多服务商和自定义 endpoint，降低厂商锁定。
多工具：内置 Web、终端、文件、浏览器、媒体、定时任务、子 Agent、MCP。
可学习：Memory、Session Search、Skills 让它逐渐沉淀用户和团队流程。
可部署：本机、VPS、Docker、SSH、Modal、Daytona、Singularity 都能跑。
可治理：危险命令审批、网关 allowlist、MCP 工具过滤、容器隔离、SSRF 防护、上下文注入扫描等。

与一般 Agent 框架的差异

对比维度	一般 Agent SDK	Hermes Agent
主要定位	给开发者写代码集成 Agent	给用户/团队运行一个常驻 Agent
入口	通常是 API 或应用内组件	CLI、桌面、IM、Email、API、IDE
长期记忆	需要自己做	内置 Memory 与 Session Search
工作流沉淀	需要自己设计	Skills 系统与 `/learn`
工具执行	依赖开发者接入	内置工具与 MCP
部署形态	通常服务端应用	本地、容器、远程、云沙箱、网关
售前卖点	开发灵活性	常驻运行与真实工作流落地

PoC 建议

PoC 目标一：企业 IM 中的研发助理

验证内容：

接入 Slack、飞书或企业微信。
配置 allowlist，只允许测试用户。
接一个 GitHub 或内部 Issue MCP。
让 Hermes 完成“查 Issue、总结 PR、生成日报、创建待办”的闭环。
开启 Docker 后端，验证命令执行隔离。

成功标准：

用户能在 IM 中发起任务并收到结果。
Agent 能调用至少一个外部工具。
危险命令会触发审批或被隔离。
一条定时日报能自动投递到指定频道。

PoC 目标二：售前研究与资料整理助手

验证内容：

使用 Web Search / Web Extract 搜索竞品和开源项目。
用 Skills 沉淀固定分析模板。
用 Memory 记录售前偏好，例如输出结构、客户行业、常用目录。
用 Cron 每周自动生成竞品监控。

成功标准：

同一个项目二次分析时，输出风格和结构更稳定。
可以搜索历史会话找回之前做过的项目分析。
能把一次流程学习成可复用 Skill。

PoC 目标三：MCP 工具网关验证

验证内容：

接入一个只读数据库 MCP 或内部 API MCP。
设置工具 include/exclude，屏蔽写操作。
在 CLI 与 IM 中分别调用同一 MCP 能力。
观察工具调用日志和失败处理。

成功标准：

Agent 能在自然语言下正确选择 MCP 工具。
权限过滤生效。
同一能力可以跨入口复用。

主要风险与问题清单

开源项目体量很大，功能面广，部署和维护需要技术团队投入。
GitHub API 当前显示 Issue 数量很高，售前展示前建议核实项目 issue 质量和维护节奏。
多平台网关意味着凭证和权限面扩大，客户需要明确谁能访问、能调用哪些工具。
Skills 和 Plugins 的安全边界依赖人工审查，不适合无治理地安装社区扩展。
对强合规客户，需要补充企业级审计、RBAC、审批流程、日志留存、数据隔离等方案。
如果客户只想做单一业务应用里的 Agent，Hermes 可能不是最轻的选择。

可用于售前的客户提问

你们希望员工从哪里使用 AI？Web、IM、IDE、CLI，还是多个入口都要？
你们的 AI 助手是否需要调用内部系统、执行脚本、读写文件？
是否已有 MCP Server 或内部工具 API？
是否需要 Agent 记住团队流程、客户偏好、项目约定？
是否有定时任务场景，例如日报、周报、巡检、竞品监控？
Agent 会接触哪些不可信输入源，例如公网网页、外部邮件、群聊消息？
对命令执行、文件访问、凭证管理有什么安全要求？
是偏个人效率工具、研发助手，还是企业级统一 Agent 网关？

我的售前判断

Hermes Agent 适合放在“Agent 落地从聊天走向执行”的方案里讲。它不是最轻量的 Agent SDK，但它把一个真实可运行 Agent 需要的很多工程问题都摆在台面上：多端入口、工具系统、记忆、技能、历史检索、后台任务、Cron、MCP、模型路由、容器/远程执行、安全审批、网关授权、部署服务化。

如果客户已经明确要做“企业内部 AI 助手入口”“研发/运维 Agent”“多渠道自动化助手”“MCP 工具生态验证”，Hermes 是很好的参考项目和 PoC 候选。如果客户只是想做产品内的一个聊天框，或者需要严格商业化的多租户后台管理，Hermes 更适合作为架构参考，而不是直接拿来交付。

一句话结论

项目能做什么

1. 跨终端与跨消息平台的 AI Agent

2. 多模型与多服务商路由

3. 工具系统：从对话到真正执行

4. 记忆与技能闭环

5. MCP 集成与可扩展工具生态

6. 后台任务、子 Agent 与定时自动化

官方架构示意

适用场景

场景一：研发团队的常驻编码与运维 Agent

场景二：企业内部多渠道 AI 助手网关

场景三：个人或小团队的“长期私人 AI 助手”

场景四：Agent 工具生态与 MCP 落地试验田

不适合的场景

如何使用

快速安装

启动消息网关

配置 MCP

安全与部署要点

售前讲解框架

客户痛点

Hermes 的价值主张

与一般 Agent 框架的差异

PoC 建议

PoC 目标一：企业 IM 中的研发助理

PoC 目标二：售前研究与资料整理助手

PoC 目标三：MCP 工具网关验证

主要风险与问题清单

可用于售前的客户提问

我的售前判断

参考资料