mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-05-29 06:31:32 +00:00
* remove Vercel AI Gateway provider and Vercel Sandbox terminal backend Both Vercel-hosted integrations are removed end-to-end. Users on the AI Gateway should switch to OpenRouter or one of the other aggregators (Nous Portal, Kilo Code). Users on the Vercel Sandbox backend should switch to Docker, Modal, Daytona, or SSH. What's removed: - `plugins/model-providers/ai-gateway/` provider plugin - `hermes_cli/vercel_auth.py` Vercel-Sandbox auth helper - `tools/environments/vercel_sandbox.py` terminal backend - `ai-gateway` provider wiring across auth, doctor, setup, models, config, status, providers, main, web_server, model_normalize, dump - `vercel_sandbox` backend wiring across terminal_tool, file_tools, code_execution_tool, file_operations, approval, skills_tool, environments/local, credential_files, lazy_deps, prompt_builder, cli, gateway/run - `AI_GATEWAY_BASE_URL` constant, `_AI_GATEWAY_HEADERS` auxiliary-client header set, run_agent base-URL header/reasoning special-cases - `[vercel]` pyproject extra and `vercel`/`vercel-workers` from uv.lock - env vars: `AI_GATEWAY_API_KEY`, `AI_GATEWAY_BASE_URL`, `VERCEL_TOKEN`, `VERCEL_PROJECT_ID`, `VERCEL_TEAM_ID`, `VERCEL_OIDC_TOKEN`, `TERMINAL_VERCEL_RUNTIME` - Tests: deletes test_ai_gateway_models.py and test_vercel_sandbox_environment.py; scrubs references across 23 surviving test files (no entire tests deleted unless they were dedicated to AI Gateway / Sandbox) - Docs: provider tables, env-var reference, setup guides, security notes, tool config, terminal-backend tables — English plus zh-Hans i18n parity - `hermes-agent` skill: provider table entry and remote-backend list What stays (intentional): - `popular-web-designs/templates/vercel.md` — CSS design reference, unrelated to Vercel-the-AI-product - `x-vercel-id` in `stream_diag.py` headers — generic Vercel CDN response header, useful diag signal on any Vercel-hosted endpoint - `vercel-labs/agent-browser` URL in browser config — lightpanda browser project, different OSS effort - `userStories.json` historical contributor entry mentioning Vercel Sandbox — archive, not active docs Validation: - 1153 tests in the 22 targeted files pass (`scripts/run_tests.sh`) - Full repo `py_compile` clean - Live import of every touched module + invariant check (no `ai-gateway` in `PROVIDER_REGISTRY`, no `_AI_GATEWAY_HEADERS`, no `vercel_sandbox` in `_REMOTE_TERMINAL_BACKENDS`) * test: convert profile-count check from change-detector to invariant The hardcoded "== 34" assertion broke when ai-gateway was removed. Per AGENTS.md change-detector-test guidance, assert the relationship (registry count >= number of plugin dirs) instead of a literal count. Counts shift when providers are added/removed; that's expected.
178 lines
7.8 KiB
Markdown
178 lines
7.8 KiB
Markdown
---
|
|
sidebar_position: 1
|
|
title: "Tools & Toolsets"
|
|
description: "Overview of Hermes Agent's tools — what's available, how toolsets work, and terminal backends"
|
|
---
|
|
|
|
# Tools & Toolsets
|
|
|
|
Tools are functions that extend the agent's capabilities. They're organized into logical **toolsets** that can be enabled or disabled per platform.
|
|
|
|
## Available Tools
|
|
|
|
Hermes ships with a broad built-in tool registry covering web search, browser automation, terminal execution, file editing, memory, delegation, RL training, messaging delivery, Home Assistant, and more.
|
|
|
|
:::note
|
|
**Honcho cross-session memory** is available as a memory provider plugin (`plugins/memory/honcho/`), not as a built-in toolset. See [Plugins](./plugins.md) for installation.
|
|
:::
|
|
|
|
High-level categories:
|
|
|
|
| Category | Examples | Description |
|
|
|----------|----------|-------------|
|
|
| **Web** | `web_search`, `web_extract` | Search the web and extract page content. |
|
|
| **X Search** | `x_search` | Search X (Twitter) posts and threads via xAI's built-in `x_search` Responses tool — gated on xAI credentials (SuperGrok OAuth or `XAI_API_KEY`); off by default, opt in via `hermes tools` → 🐦 X (Twitter) Search. |
|
|
| **Terminal & Files** | `terminal`, `process`, `read_file`, `patch` | Execute commands and manipulate files. |
|
|
| **Browser** | `browser_navigate`, `browser_snapshot`, `browser_vision` | Interactive browser automation with text and vision support. |
|
|
| **Media** | `vision_analyze`, `image_generate`, `video_generate`, `video_analyze`, `text_to_speech` | Multimodal analysis and generation. `video_generate` and `video_analyze` are opt-in (add `video_gen` / `video` toolsets via `hermes tools` or `--toolsets`). |
|
|
| **Agent orchestration** | `todo`, `clarify`, `execute_code`, `delegate_task` | Planning, clarification, code execution, and subagent delegation. |
|
|
| **Memory & recall** | `memory`, `session_search` | Persistent memory and session search. |
|
|
| **Automation & delivery** | `cronjob`, `send_message` | Scheduled tasks with create/list/update/pause/resume/run/remove actions, plus outbound messaging delivery. |
|
|
| **Integrations** | `ha_*`, MCP server tools, `rl_*` | Home Assistant, MCP, RL training, and other integrations. |
|
|
|
|
For the authoritative code-derived registry, see [Built-in Tools Reference](/reference/tools-reference) and [Toolsets Reference](/reference/toolsets-reference).
|
|
|
|
:::tip Nous Tool Gateway
|
|
Paid [Nous Portal](https://portal.nousresearch.com) subscribers can use web search, image generation, TTS, and browser automation through the **[Tool Gateway](tool-gateway.md)** — no separate API keys needed. Run `hermes model` to enable it, or configure individual tools with `hermes tools`.
|
|
:::
|
|
|
|
## Using Toolsets
|
|
|
|
```bash
|
|
# Use specific toolsets
|
|
hermes chat --toolsets "web,terminal"
|
|
|
|
# See all available tools
|
|
hermes tools
|
|
|
|
# Configure tools per platform (interactive)
|
|
hermes tools
|
|
```
|
|
|
|
Common toolsets include `web`, `search`, `terminal`, `file`, `browser`, `vision`, `image_gen`, `moa`, `skills`, `tts`, `todo`, `memory`, `session_search`, `cronjob`, `code_execution`, `delegation`, `clarify`, `homeassistant`, `messaging`, `spotify`, `discord`, `discord_admin`, `debugging`, `safe`, and `rl`.
|
|
|
|
See [Toolsets Reference](/reference/toolsets-reference) for the full set, including platform presets such as `hermes-cli`, `hermes-telegram`, and dynamic MCP toolsets like `mcp-<server>`.
|
|
|
|
## Terminal Backends
|
|
|
|
The terminal tool can execute commands in different environments:
|
|
|
|
| Backend | Description | Use Case |
|
|
|---------|-------------|----------|
|
|
| `local` | Run on your machine (default) | Development, trusted tasks |
|
|
| `docker` | Isolated containers | Security, reproducibility |
|
|
| `ssh` | Remote server | Sandboxing, keep agent away from its own code |
|
|
| `singularity` | HPC containers | Cluster computing, rootless |
|
|
| `modal` | Cloud execution | Serverless, scale |
|
|
| `daytona` | Cloud sandbox workspace | Persistent remote dev environments |
|
|
|
|
### Configuration
|
|
|
|
```yaml
|
|
# In ~/.hermes/config.yaml
|
|
terminal:
|
|
backend: local # or: docker, ssh, singularity, modal, daytona
|
|
cwd: "." # Working directory
|
|
timeout: 180 # Command timeout in seconds
|
|
```
|
|
|
|
### Docker Backend
|
|
|
|
```yaml
|
|
terminal:
|
|
backend: docker
|
|
docker_image: python:3.11-slim
|
|
```
|
|
|
|
**One persistent container, shared across the whole process.** Hermes starts a single long-lived container on first use (`docker run -d ... sleep 2h`) and routes every terminal, file, and `execute_code` call through `docker exec` into that same container. Working-directory changes, installed packages, environment tweaks, and files written to `/workspace` all carry over from one tool call to the next, across `/new`, `/reset`, and `delegate_task` subagents, for the lifetime of the Hermes process. The container is stopped and removed on shutdown.
|
|
|
|
This means the Docker backend behaves like a persistent sandbox VM, not a fresh container per command. If you `pip install foo` once, it's there for the rest of the session. If you `cd /workspace/project`, subsequent `ls` calls see that directory. See [Configuration → Docker Backend](../configuration.md#docker-backend) for the full lifecycle details and the `container_persistent` flag that controls whether `/workspace` and `/root` survive across Hermes restarts.
|
|
|
|
### SSH Backend
|
|
|
|
Recommended for security — agent can't modify its own code:
|
|
|
|
```yaml
|
|
terminal:
|
|
backend: ssh
|
|
```
|
|
```bash
|
|
# Set credentials in ~/.hermes/.env
|
|
TERMINAL_SSH_HOST=my-server.example.com
|
|
TERMINAL_SSH_USER=myuser
|
|
TERMINAL_SSH_KEY=~/.ssh/id_rsa
|
|
```
|
|
|
|
### Singularity/Apptainer
|
|
|
|
```bash
|
|
# Pre-build SIF for parallel workers
|
|
apptainer build ~/python.sif docker://python:3.11-slim
|
|
|
|
# Configure
|
|
hermes config set terminal.backend singularity
|
|
hermes config set terminal.singularity_image ~/python.sif
|
|
```
|
|
|
|
### Modal (Serverless Cloud)
|
|
|
|
```bash
|
|
uv pip install modal
|
|
modal setup
|
|
hermes config set terminal.backend modal
|
|
```
|
|
|
|
### Container Resources
|
|
|
|
Configure CPU, memory, disk, and persistence for all container backends:
|
|
|
|
```yaml
|
|
terminal:
|
|
backend: docker # or singularity, modal, daytona
|
|
container_cpu: 1 # CPU cores (default: 1)
|
|
container_memory: 5120 # Memory in MB (default: 5GB)
|
|
container_disk: 51200 # Disk in MB (default: 50GB)
|
|
container_persistent: true # Persist filesystem across sessions (default: true)
|
|
```
|
|
|
|
When `container_persistent: true`, installed packages, files, and config survive across sessions.
|
|
|
|
### Container Security
|
|
|
|
All container backends run with security hardening:
|
|
|
|
- Read-only root filesystem (Docker)
|
|
- All Linux capabilities dropped
|
|
- No privilege escalation
|
|
- PID limits (256 processes)
|
|
- Full namespace isolation
|
|
- Persistent workspace via volumes, not writable root layer
|
|
|
|
Docker can optionally receive an explicit env allowlist via `terminal.docker_forward_env`, but forwarded variables are visible to commands inside the container and should be treated as exposed to that session.
|
|
|
|
## Background Process Management
|
|
|
|
Start background processes and manage them:
|
|
|
|
```python
|
|
terminal(command="pytest -v tests/", background=true)
|
|
# Returns: {"session_id": "proc_abc123", "pid": 12345}
|
|
|
|
# Then manage with the process tool:
|
|
process(action="list") # Show all running processes
|
|
process(action="poll", session_id="proc_abc123") # Check status
|
|
process(action="wait", session_id="proc_abc123") # Block until done
|
|
process(action="log", session_id="proc_abc123") # Full output
|
|
process(action="kill", session_id="proc_abc123") # Terminate
|
|
process(action="write", session_id="proc_abc123", data="y") # Send input
|
|
```
|
|
|
|
PTY mode (`pty=true`) enables interactive CLI tools like Codex and Claude Code.
|
|
|
|
## Sudo Support
|
|
|
|
If a command needs sudo, you'll be prompted for your password (cached for the session). Or set `SUDO_PASSWORD` in `~/.hermes/.env`.
|
|
|
|
:::warning
|
|
On messaging platforms, if sudo fails, the output includes a tip to add `SUDO_PASSWORD` to `~/.hermes/.env`.
|
|
:::
|