Hermes Agent

「唯一带学习闭环的常驻个人助手」 —— 官方 README 这么写：

模型与开放条件

官方给了四种路径并强调无锁定，是本站收录对象里对模型自由度表述最直白的。 README 原文："Use any model you want — Nous Portal, OpenRouter, OpenAI, your own endpoint, and many others. Switch with hermes model — no code changes, no lock-in." 「your own endpoint」这一条对本站读者最有用 —— 自建网关/自托管推理可以直接接。 换模型的操作是运行时命令 /model [provider:model]（CLI 与消息平台共用， 见 CLI vs Messaging 对照表），不是改代码。 ⚠ 未核验：完整 provider 清单（官方 docs/integrations/providers 未取到正文）、 换模型后的能力对齐度、本地量化模型在多后端下的行为差异。

运行位置

这是本对象最强的一维：七种终端后端 + 两个入口。 README 原文列举："Seven terminal backends — local, Docker, SSH, Singularity, Modal, Daytona, and Vercel Sandbox." 官方特别指出 Daytona 与 Modal 提供 serverless persistence —— "your agent's environment hibernates when idle and wakes on demand, costing nearly nothing between sessions"。 两个入口（README 有专门的 CLI vs Messaging 对照表）： 终端 TUI 启动 hermes；或跑 gateway 后从 Telegram / Discord / Slack / WhatsApp / Signal / Email 以及 Home Assistant 聊天。 ⚠ 这对本站是最有价值的一格：它是唯一收录对象里明确说「agent 可以跑在云 VM 上、 你从 Telegram 指挥它」的 —— 与OpenHands 的「关掉笔记本后agent 仍在跑」是同一类诉求， 但它把这个能力做成了默认形态而不是可选部署项。

本地文件

本地文件能力通过终端后端间接获得，且有明确的隔离机制（见 permissions）。 它的工作区由所选后端决定（local 后端 = 本机，Docker/SSH/Singularity 等各有隔离）。 Context Files 是官方的一等概念（文档 features/context-files）： "Project context that shapes every conversation" —— 项目上下文文件会影响每一次对话。 ⚠ 未核验：context files 的确切格式与加载优先级、 工作区与「本地文件」的边界在哪（local 后端下的默认文件访问范围）。

关机后的任务

这一维它是全站最强的，而且有官方三重机制。 ① 内建cron 调度器：官方特性表写"Built-in cron scheduler with delivery to any platform. Daily reports, nightly backups, weekly audits — all in natural language, running unattended."（文档 features/cron）。 ② serverless 休眠后唤醒：Daytona / Modal 后端空闲时休眠、需唤醒 —— 本站未核验唤醒延迟。 ③ 常驻网关进程：gateway 一旦运行，就能从六个消息平台随时触发。 ⚠ 未核验：cron 未触发任务的补偿逻辑、网关断线后的任务补跑、 跨休眠/唤醒的状态一致性。

工具与扩展

官方说 40+ 工具，并且明确支持 MCP。 文档目录里有独立的 "Tools & Toolsets" 页，副标题原文 "40+ tools, toolset system, terminal backends"（文档 features/tools）。 MCP Integration 也是独立文档页："Connect any MCP server for extended capabilities" （文档 features/mcp）。 还有一项很特别的能力：子代理 RPC。 官方原文："Spawn isolated subagents for parallel workstreams. Write Python scripts that call tools via RPC, collapsing multi-step pipelines into zero-context-cost turns." ⚠ 「zero-context-cost」这个说法本站理解为「把多步管线移到上下文之外执行」 （即产物只回传结果），官方未给出具体的上下文节省量，本站标记为推断。 社区还维护了一个 Linux 桌面控制 MCP server（computer-use-linux， AT-SPI 无障碍树 + Wayland/X11 输入 + 截图），README 明确写了它是给 "Hermes and other MCP hosts" 用的。

上下文与记忆

⚠ 这是本站最看重的一维，而它恰好是本对象宣传力度最大的 —— 必须分开核实。 官方声明（README 特性表 "A closed learning loop" 一行原文）： "Agent-curated memory with periodic nudges. Autonomous skill creation after complex tasks. Skills self-improve during use. FTS5 session search with LLM summarization for cross-session recall. Honcho dialectic user modeling. Compatible with the agentskills.io open standard." 但只要把官方给的机制逐个归位，就会发现它不是一个维度而是三个： | 官方说法 | 本站归类 | 说明 | |---|---|---| | periodic nudges（自我提示） | 状态面 | 机制触发器，不是压缩算法 | | FTS5 session search + LLM summarization | 上下文面 ✅ | 检索 + 摘要，这是真正的上下文管理 | | Skills（自主创建 + 使用中自我改进） | 独立一层 | 程序性记忆，与对话上下文不同 | | Honcho dialectic user modeling | 独立一层 | 对用户的长期建模 | 关键区分点：它有明确的 /compress 命令（CLI 与消息平台都有， 对照表里与 /usage、/insights 并列），说明压缩是用户显式触发的， 而不是自动的。 能落到文件名的证据（来自 "Migrating from OpenClaw" 章节，这是少见的官方一手清单）： SOUL.md（persona）、MEMORY.md 与 USER.md（记忆条目）、AGENTS.md（工作区指令）、 以及 ~/.hermes/skills/openclaw-imports/（技能目录）。 这说明记忆是明文的 markdown 文件，可读可迁移 —— 对本站读者来说是重要优点。

权限与限制

官方文档目录里有一节独立的 "Security"，这是本站判断它权限面做得比较细的依据。 该节副标题原文（核验自 README 文档目录表）： "Command approval, DM pairing, container isolation"。 逐项解读： ① Command approval —— 命令级审批（与 OpenHands 的 API key、 Codex SDK 的 ApprovalMode 属不同层面的做法；本站未核验其粒度与默认值）。 ② DM pairing —— 私聊配对，即只有配对过的用户能指挥它。 这一点在六个消息平台入口的前提下极其重要 —— 一个能通过 Telegram/WhatsApp 接指令、还能在文件系统上动手的 agent， 「谁能给它下指令」就是最关键的安全问题。 ③ Container isolation —— 容器隔离。 ⚠ 未核验：三者的默认状态（默认开还是默认关）、 command approval 的粒度与是否可白名单化、 gateway 暴露面与端口安全。 ⚠ 另有一处需要注意：hermes claw migrate --preset user-data 之类的迁移会涉及 API keys（README 列出 Telegram / OpenRouter / OpenAI / Anthropic / ElevenLabs）， 迁移脚本本身接触密钥 —— 用 dry-run 预览是官方给的手段。

适合什么任务

适合：想要一个常驻的跨平台个人助手（Telegram/Discord/Slack/WhatsApp/Signal/Email）； 把它放在云VM / serverless 上而不绑在自己笔记本；需要定时任务无人值守跑； 需要跨会话记忆与技能自积累；想用自建 endpoint 或 OpenRouter 等多provider； 需要命令级审批与 DM 配对做安全边界。 不适合：只做编程任务（它是通用助手，编程只是其一）； 需要拿它当嵌入式 SDK（它是完整运行时，不是库）； 需要详细的「状态 vs 上下文」分层保证（它机制多但官方没按这两层分）； 需要企业级多用户与审计（本次未核验）。

本页由 ai-coding-agent-atlas 数据层生成（CC BY 4.0）。 方法论与坐标系定义见仓库内 METHODOLOGY.md。