Agent框架 更新于 2026-04-14

六大执行后端解析：从本地终端到 Serverless

#Hermes Agent #执行后端 #Docker #SSH #Serverless

目录

  1. Agent 的命令在哪里执行
  2. Local：最直接的方式
    1. 什么情况用
    2. 配置
    3. 适用场景
    4. 风险
  3. Docker：推荐的安全选择
    1. 什么情况用
    2. 配置
    3. 安全隔离效果
    4. 镜像管理
  4. SSH：远程服务器操作
    1. 什么情况用
    2. 配置
    3. 多服务器场景
    4. 安全考量
  5. Daytona：开发环境即服务
    1. 什么情况用
    2. 适用场景
    3. 配置
  6. Singularity：HPC 场景
    1. 什么情况用
    2. 适用场景
    3. 配置
  7. Modal：Serverless 执行
    1. 什么情况用
    2. 适用场景
    3. 配置
    4. 成本考虑
  8. 六种后端对比
  9. 混合使用
    1. 自动路由
    2. 手动指定
  10. 自定义后端
  11. 选择建议
  12. 延伸阅读：OpenClaw 社区资源

Agent 的命令在哪里执行

当 Hermes Agent 说「我来执行一下 ls -la」，这条命令具体在哪台机器、哪个环境里跑？

答案是：取决于你配置了什么执行后端（Backend）。

执行后端是 Hermes Agent 架构中的关键一层——它决定了 Agent 操作的边界和安全等级。你可以让 Agent 直接操作你的本地终端，也可以把它限制在 Docker 容器里，甚至让它在远程服务器或 Serverless 平台上执行命令。

Hermes Agent 目前支持六种后端：Local、Docker、SSH、Daytona、Singularity、Modal。每种有不同的适用场景和安全特性。这篇文章逐个讲清楚。

Local：最直接的方式

什么情况用

这是默认后端。Agent 的命令直接在你当前登录的终端环境中执行，和你自己手动敲命令没区别。

配置

不需要配置，开箱即用。如果要显式指定：

1
2
backend:
  type: local

适用场景

  • 个人开发机上的日常使用
  • 你完全信任 Agent 要执行的操作
  • 需要访问本地资源（文件、进程、网络）

风险

Agent 拥有和你一样的权限。如果你用 root 账号跑，Agent 也是 root 权限。这意味着一条错误的 rm -rf 可能造成灾难性后果。

我个人在本地后端下会开启操作确认：

1
2
3
backend:
  type: local
  confirm_dangerous: true  # 执行危险命令前需要用户确认

开启后，涉及删除、权限修改、服务管理等操作，Agent 会先问你确认。稍微打断一下工作流，但多了一层安全网。

Docker：推荐的安全选择

什么情况用

你想让 Agent 干活，但不想让它碰你的宿主机环境。Docker 后端把 Agent 的执行环境限制在一个容器里，容器内搞什么都不影响外面。

配置

1
2
3
4
5
6
7
8
9
backend:
  type: docker
  image: "hermes-sandbox:latest"
  auto_remove: true
  volumes:
    - "/home/user/projects:/workspace"  # 按需挂载
  network: "bridge"
  memory_limit: "512m"
  cpu_limit: 1.0

几个关键配置：

  • image：使用的 Docker 镜像。官方提供了 hermes-sandbox 基础镜像，包含常用开发工具
  • auto_remove：任务完成后自动删除容器
  • volumes：把需要 Agent 操作的目录挂载进容器。不挂载的目录 Agent 看不到
  • memory_limit / cpu_limit：资源限制，防止 Agent 把机器拖垮

安全隔离效果

Docker 后端提供了进程级隔离：

  • Agent 无法访问宿主机的文件系统（除了你挂载的部分）
  • Agent 无法影响宿主机的进程
  • 网络访问可以通过 Docker 网络策略限制
  • 资源使用有上限

这对于不太可控的任务特别有用。比如你让 Agent 分析一份来源不明的代码——在 Docker 里跑，即使代码有恶意行为也出不去。

镜像管理

官方基础镜像比较精简。如果你的任务需要特定工具，建一个自定义镜像：

1
2
3
4
5
FROM hermes-sandbox:latest
RUN apt-get update && apt-get install -y \
    nodejs npm \
    postgresql-client \
    redis-tools

不同类型的任务用不同的镜像，做到环境隔离的同时不丢功能。

SSH：远程服务器操作

什么情况用

你想让 Agent 操作一台远程服务器，而不是本地机器。运维场景下用得最多。

配置

1
2
3
4
5
6
7
backend:
  type: ssh
  host: "192.168.1.100"
  port: 22
  user: "deploy"
  key_file: "~/.ssh/id_ed25519"
  keepalive_interval: 60

配置项和你平时用 SSH 连服务器一样。建议用密钥认证，不要用密码。

多服务器场景

如果你管理多台服务器，可以配多个 SSH 后端，在使用时指定：

1
2
3
4
5
6
7
8
9
10
11
backends:
  web-server:
    type: ssh
    host: "10.0.1.10"
    user: "deploy"
    key_file: "~/.ssh/web_key"
  db-server:
    type: ssh
    host: "10.0.1.20"
    user: "dbadmin"
    key_file: "~/.ssh/db_key"

使用时指定后端：

1
2
hermes --backend web-server "检查 Nginx 状态"
hermes --backend db-server "查看 MySQL 慢查询日志"

这在日常运维中非常实用。你不需要自己 SSH 上去一台台看，让 Agent 帮你串行或并行检查多台服务器。

安全考量

SSH 后端的安全取决于你给 Agent 用的那个账号的权限。强烈建议：

  1. 给 Agent 创建专用账号，不要用 root
  2. 通过 sudoers 精确控制这个账号能执行哪些 sudo 命令
  3. 限制账号的文件访问范围

具体的安全配置方案，可以参考 Hermes Agent 安全指南。

Daytona：开发环境即服务

什么情况用

Daytona{rel=”nofollow”} 是一个开发环境管理平台，能快速创建标准化的开发环境。Hermes Agent 的 Daytona 后端让 Agent 在 Daytona 创建的开发环境中执行命令。

适用场景

  • 团队需要统一的开发环境
  • 你想让 Agent 在一个干净的、可重现的环境中工作
  • 项目有 devcontainer 配置

配置

1
2
3
4
5
backend:
  type: daytona
  server_url: "https://你的daytona地址"
  api_key: "你的 API key"
  workspace_template: "python-dev"

Daytona 后端的优势是环境一致性。不管 Agent 在什么机器上运行，它操作的开发环境都是从同一个模板创建的，消除了「在我机器上能跑」的问题。

Singularity：HPC 场景

什么情况用

Singularity{rel=”nofollow”}（现在叫 Apptainer）是高性能计算（HPC）领域常用的容器技术。和 Docker 不同，Singularity 不需要 root 权限运行，更适合共享计算集群。

适用场景

  • 在大学或研究机构的计算集群上使用 Agent
  • 需要访问 GPU 等硬件资源
  • 集群管理员不允许用 Docker

配置

1
2
3
4
5
6
7
backend:
  type: singularity
  image: "hermes-sandbox.sif"
  bind_paths:
    - "/data:/data"
    - "/scratch:/scratch"
  gpu: true

Singularity 的 bind_paths 类似 Docker 的 volumes，指定宿主机目录映射。gpu: true 开启 GPU 直通，适合需要 GPU 计算的场景。

说实话这个后端比较小众，主要面向 HPC 用户。如果你不在学术或科研环境，大概率用不到。

Modal：Serverless 执行

什么情况用

Modal{rel=”nofollow”} 是一个 Serverless 计算平台。选择 Modal 后端意味着 Agent 的命令不在任何固定服务器上执行，而是在 Modal 的云端按需分配的容器里执行。

适用场景

  • 你不想维护任何服务器
  • 任务执行频率不高，按需付费更划算
  • 需要弹性伸缩（比如偶尔需要大量计算资源）

配置

1
2
3
4
5
6
backend:
  type: modal
  api_key: "你的 Modal API key"
  image: "hermes-sandbox"
  gpu: false
  timeout: 300

成本考虑

Modal 按实际使用的计算时间收费。如果你每天只是偶尔让 Agent 跑几个命令，费用可能比维护一台 VPS 便宜。但如果你频繁使用，VPS 的固定月费可能更划算。

另外 Modal 有冷启动延迟——第一次调用需要几秒钟启动容器。后续调用如果间隔不长，会复用已有容器。

六种后端对比

后端 隔离性 延迟 成本 适合谁
Local 无 极低 无额外成本 个人开发者
Docker 容器级 低 无额外成本 安全意识强的用户
SSH 取决于账号 网络延迟 需要远程服务器 运维人员
Daytona 环境级 中等 Daytona 费用 团队开发
Singularity 容器级 低 集群资源 HPC 用户
Modal 容器级 冷启动较高 按用量 无服务器用户

混合使用

你不一定只用一种后端。Hermes Agent 支持配置多个后端，根据任务类型自动或手动选择。

自动路由

1
2
3
4
5
6
7
backend_routing:
  default: docker
  rules:
    - pattern: ".*服务器.*|.*远程.*"
      backend: ssh-prod
    - pattern: ".*本地.*文件.*"
      backend: local

这样当你说「检查服务器的 Nginx 状态」，Agent 自动走 SSH 后端；说「修改本地的配置文件」，走 Local 后端。

手动指定

任何时候都可以在命令中覆盖：

1
hermes --backend docker "跑一下这段 Python 脚本"

自定义后端

如果六种内置后端都不满足你的需求，Hermes Agent 支持自定义后端插件。你需要实现一个标准接口：

1
2
3
4
5
6
7
8
9
10
class CustomBackend:
    def execute(self, command: str, timeout: int) -> ExecutionResult:
        # 你的执行逻辑
        ...

    def file_read(self, path: str) -> str:
        ...

    def file_write(self, path: str, content: str) -> bool:
        ...

注册后就能和内置后端一样使用。cocoloop 社区有人写了 Kubernetes 后端插件，让 Agent 直接在 K8s Pod 里执行命令。

选择建议

如果你刚开始用 Hermes Agent，我的建议是：

  1. 先用 Local，快速上手，不需要额外配置
  2. 然后切到 Docker，加一层安全网，尤其是你开始让 Agent 做不太可控的操作时
  3. 有远程服务器需求再加 SSH
  4. 其他三个按需选择

不管用什么后端，技能系统和记忆系统的工作方式都是一样的。后端的选择只影响命令在哪里执行，不影响 Agent 的推理和学习能力。

延伸阅读：OpenClaw 社区资源

本文由 CocoLoop 中文社区出品。如果你在研究 AI Agent 与主流模型的工程化落地，姊妹站 OpenClaw 中文社区 也许会有帮助：

参与讨论

对这篇文章有疑问或想法？cocoloop 社区有不少开发者在讨论 Hermes 相关话题，欢迎加入交流。

前往 cocoloop 社区 →