chore/runtime-version-file
2 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Hongming Wang
|
7e7871875c
|
fix(v2.1.0): startup bugs + full provider matrix — proven end-to-end (#6)
Stacked follow-up on the v2.0.0 rewrite. The merged v2.0.0 template
had three latent issues that only surfaced during local E2E testing:
1) sudo → gosu (python:3.11-slim ships neither; only gosu was in
the Dockerfile). start.sh was calling sudo which would have
broken every container boot.
2) PATH pointed at /home/agent/.hermes/bin which doesn't exist —
install.sh symlinks ~/.local/bin/hermes. Installer is also
interactive by default; needs --skip-setup to run in docker build.
3) start.sh wrote ~/.hermes/cli-config.yaml but hermes-agent reads
~/.hermes/config.yaml. cli-config.yaml.example is just a starter
file — install.sh copies it to config.yaml on first boot. Without
our overwrite the template inherited the example default
(anthropic/claude-opus-4.6 + provider: auto) instead of the
workspace's chosen model. We now rewrite config.yaml every boot
from HERMES_DEFAULT_MODEL + HERMES_INFERENCE_PROVIDER env.
Also:
- Added xz-utils + build-essential to the image (hermes installer
extracts a Node 22 .tar.xz and some Python deps in .[all] build
from source).
- Forward every provider key hermes-agent knows about, not just
the 6 from v2.0.0. All ~22 providers documented in the official
website/docs/integrations/providers.md are now wired:
HERMES_API_KEY, NOUS_API_KEY, OPENROUTER_API_KEY, OPENAI_API_KEY,
ANTHROPIC_API_KEY, GEMINI_API_KEY, GOOGLE_API_KEY, DEEPSEEK_API_KEY,
GLM_API_KEY, KIMI_API_KEY, KIMI_CN_API_KEY, MINIMAX_API_KEY,
MINIMAX_CN_API_KEY, DASHSCOPE_API_KEY, XIAOMI_API_KEY,
ARCEEAI_API_KEY, NVIDIA_API_KEY, OLLAMA_API_KEY, HF_TOKEN,
AI_GATEWAY_API_KEY, KILOCODE_API_KEY, OPENCODE_ZEN_API_KEY,
OPENCODE_GO_API_KEY, COPILOT_GITHUB_TOKEN, GH_TOKEN
- config.yaml models[] list expanded to 30+ entries covering every
provider family (Hermes 3/4, Anthropic direct, OpenAI via
OpenRouter, Gemini direct, DeepSeek, GLM, Kimi, MiniMax global+CN,
Qwen/DashScope, Xiaomi MiMo, Arcee Trinity, NVIDIA NIM, Ollama
Cloud, Hugging Face catch-all, Vercel AI Gateway, OpenCode Zen+Go,
Kilo Code, OpenRouter catch-all, custom/local).
- top-level required_env: [] — hermes supports too many providers
for a single hardcoded requirement; per-model required_env in
the canvas Config tab drives the real UX. hermes-agent itself
errors loud at request time if zero providers are configured.
- HERMES_CUSTOM_BASE_URL / HERMES_CUSTOM_API_KEY env support in
start.sh — lets operators point hermes at OpenAI direct, LM Studio,
LiteLLM, any OpenAI-compat endpoint without exec-ing into the
container.
- HERMES_INFERENCE_PROVIDER env — forces a specific provider,
overriding hermes' auto-detection (which routes OPENAI_API_KEY
to openai-codex OAuth path → 401 Missing Authentication header).
- docs/CONFIGURATION.md rewritten with the full provider matrix,
OAuth flow, forcing a provider, auxiliary model, persistence
layout, and the common routing gotchas surfaced during testing.
- docs/ARCHITECTURE.md adds "Provider routing (how keys become
inference)" section.
Proved end-to-end on local Docker:
[start.sh] hermes gateway ready on :8642 (pid 22)
Uvicorn running on http://0.0.0.0:8000
→ A2A message/send "Respond with HERMES BRIDGE WORKING END TO END"
← HERMES BRIDGE WORKING END TO END — (via OpenAI Responses API)
→ "Run uname -a && whoami && pwd using your terminal tool"
← Linux 094f72... aarch64 GNU/Linux / agent / /home/agent
(real tool call — not chat response)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Hongming Wang
|
1313694df2 |
feat(v2.0.0): replace provider shim with the real Nous hermes-agent
The old template was a thin OpenAI-compat multi-provider dispatcher that shared the name "hermes" with Nous Research's hermes-agent but had none of its actual capabilities (skills, memory, tools, learning loop, multi-platform gateway). Customers picking "Hermes" in canvas got a stateless chat shim instead of the agent framework they expected. This PR rewrites the template to run the real hermes-agent (github.com/NousResearch/hermes-agent) inside the workspace container: - Dockerfile installs hermes-agent via its upstream install.sh (same pattern template-claude-code uses for the claude CLI). - start.sh boots `hermes gateway` with the api_server platform on 127.0.0.1:8642, waits for /health, then exec's molecule-runtime on :8000. - adapter.py / executor.py collapse to a thin A2A proxy that forwards every incoming message to /v1/chat/completions on the local gateway and returns the response on the A2A queue. - providers.py + escalation.py deleted — hermes-agent owns provider selection (`hermes model`), its own skill/memory loop supersedes escalation. - Env vars unchanged: HERMES_API_KEY, OPENROUTER_API_KEY, ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, MINIMAX_API_KEY are all forwarded into ~/.hermes/.env at boot. All planning + rationale lives in this repo under docs/: - docs/PLANNING.md — why, scope, phases, risks, success criteria - docs/ARCHITECTURE.md — port map, boot sequence, request flow, what the bridge deliberately does NOT do - docs/MIGRATION.md — v1.x → v2.0.0 behaviour changes (no customer migration needed, v1.x was CI-canary-only) - docs/CONFIGURATION.md — model picking, persistence, gateway restart, inspection, timeouts Net -195 lines of code for a massive capability upgrade. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |