第十二课：Slash 命令（下）：高级功能
/mcp/skills/plugins/memories/apps/agent/ide
1. 概述
本课是 Slash 命令系列的最后一课，聚焦高级功能命令。这些命令主要用于扩展 Agent 的能力边界——接入外部工具、管理插件、连接第三方应用、操作 IDE 集成等。掌握这些命令后，你将能够将 Hermes Agent 从一个通用助手定制为适合你特定工作场景的专业工具。
| 命令 | 功能 | 适用场景 |
|---|---|---|
/mcp | 管理 MCP 工具服务器 | 扩展工具能力 |
/skills | 浏览和管理技能 | 使用/开发任务模板 |
/plugins | 浏览和管理插件 | 系统级扩展 |
/memories | 管理长期记忆 | 跨会话知识管理 |
/apps | 管理应用连接器 | 第三方服务集成 |
/agent | 切换代理线程 | 多 Agent 管理 |
/ide | IDE 上下文集成 | 编辑器联动 |
2. /mcp — MCP 工具管理
2.1 什么是 MCP
MCP（Model Context Protocol）是 Anthropic 提出的一种标准化工具接入协议，允许 LLM 通过统一接口调用外部工具服务器。Hermes Agent 完整支持 MCP 协议，可以接入任何兼容 MCP 的工具服务器。
2.2 基本用法
/mcp # 列出所有已配置的 MCP 工具
/mcp add <server> # 添加 MCP 工具服务器
/mcp remove <server> # 移除 MCP 工具服务器
/mcp status # 显示 MCP 服务器连接状态
/mcp refresh # 刷新工具列表（重新连接）
2.3 MCP 架构
MCP 在 Hermes Agent 中的架构如下：
┌──────────────────────────────────────────┐
│ Hermes Agent │
│ ┌─────────────────────────────────────┐ │
│ │ ToolRegistry │ │
│ │ ┌──────────┐ ┌──────────────────┐ │ │
│ │ │ 内置工具 │ │ MCP 工具 │ │ │
│ │ │(30+个) │ │ ┌─────────────┐ │ │ │
│ │ │ │ │ │ MCP Server 1 │ │ │ │
│ │ │ │ │ │ (filesystem) │ │ │ │
│ │ │ │ │ ├─────────────┤ │ │ │
│ │ │ │ │ │ MCP Server 2 │ │ │ │
│ │ │ │ │ │ (database) │ │ │ │
│ │ │ │ │ ├─────────────┤ │ │ │
│ │ │ │ │ │ MCP Server 3 │ │ │ │
│ │ │ │ │ │ (custom API) │ │ │ │
│ │ └──────────┘ │ └─────────────┘ │ │ │
│ └─────────────────────────────────────┘ │
└──────────────────────────────────────────┘
MCP 工具在 ToolRegistry 中与内置工具并列，对 Agent 而言是透明的——它不需要知道一个工具是内置的还是来自 MCP 服务器。
2.4 常用 MCP 服务器
| MCP 服务器 | 功能 | 典型用途 |
|---|---|---|
@modelcontextprotocol/server-filesystem | 文件系统操作 | 安全的文件读写 |
@modelcontextprotocol/server-github | GitHub API | PR 管理、Issue 追踪 |
@modelcontextprotocol/server-slack | Slack API | 消息发送、频道管理 |
@modelcontextprotocol/server-postgres | PostgreSQL | 数据库查询和管理 |
@modelcontextprotocol/server-puppeteer | 浏览器自动化 | 网页测试和爬取 |
@modelcontextprotocol/server-memory | 知识图谱 | 结构化记忆管理 |
2.5 MCP 配置
MCP 服务器在 config.yaml 中配置：
mcp:
servers:
- name: "filesystem"
command: "npx"
args: ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"]
env:
NODE_ENV: "production"
- name: "github"
command: "npx"
args: ["-y", "@modelcontextprotocol/server-github"]
env:
GITHUB_TOKEN: "${GITHUB_TOKEN}"
2.6 MCP 安全考量
MCP 工具服务器运行在独立进程中，与 Agent 进程隔离。但需要注意：
- 权限继承：MCP 服务器继承启动它的用户的权限
- 环境变量传递：敏感信息（如 API Key）通过环境变量传递，确保 MCP 服务器可信
- 工具描述注入：MCP 服务器返回的工具描述会被注入到系统提示词中，需警惕 Prompt Injection
- 网络访问：MCP 服务器可以发起网络请求，确保服务器来源可信
3. /skills — 技能浏览与管理
3.1 基本用法
/skills # 浏览所有可用技能分类
/skills <category> # 浏览指定分类下的技能
/skills search <query> # 搜索技能
/skills install <name> # 安装技能（从 Skills Hub）
/skills create <name> # 创建新技能
3.2 技能系统架构
Hermes Agent 的技能系统采用**渐进式披露（Progressive Disclosure）**架构，分为四层：
| 层级 | 内容 | Token 消耗 | 触发时机 |
|---|---|---|---|
| Tier 0 | 分类名 + 描述 | 极低 | 每次系统提示 |
| Tier 1 | 技能名 + 描述 | 低 | 用户请求浏览 |
| Tier 2 | SKILL.md 完整内容 | 中 | 用户请求查看/执行 |
| Tier 3 | 关联文件（模板、脚本等） | 高 | 技能执行中按需加载 |
这种设计的核心价值是Token 效率：Agent 不需要在每次对话中加载所有技能的完整内容，只有在用户明确需要时才按需加载。
3.3 技能目录结构
~/.hermes/skills/
├── deployment/
│ ├── cloud-deploy/
│ │ ├── SKILL.md # 技能定义文件
│ │ ├── references/
│ │ │ └── nginx.md # 参考文档
│ │ ├── templates/
│ │ │ └── service.conf # 配置模板
│ │ └── scripts/
│ │ └── health-check.sh
│ └── docker-deploy/
│ └── SKILL.md
├── development/
│ ├── api-scaffold/
│ │ └── SKILL.md
│ └── test-generator/
│ └── SKILL.md
└── operations/
├── log-analyzer/
│ └── SKILL.md
└── incident-response/
└── SKILL.md
3.4 SKILL.md 格式
每个技能的核心是 SKILL.md 文件，使用 YAML Frontmatter + Markdown 正文：
---
name: cloud-deploy
description: 标准化云服务器部署流程，包括 Nginx 配置、systemd 服务、健康检查
version: 1.2.0
platforms: [linux]
prerequisites:
environment_variables: [SERVER_HOST, SERVER_USER, SSH_KEY_PATH]
---
# Cloud Deploy 技能
## 铁律（不可违反）
1. **绝不修改 Nginx listen 指令** — 可能导致端口冲突和服务中断
2. **部署前必须备份** — 所有被覆盖的文件必须先备份
3. **健康检查失败必须回滚** — 不允许"先部署再修复"
## 标准化流程
1. 备份当前部署
2. 拉取最新代码
3. 构建项目
4. 更新 Nginx 配置
5. 重启服务
6. 执行健康检查
...
3.5 Skills Hub
Skills Hub 是官方的技能市场，用户可以浏览、安装社区贡献的技能：
/skills hub # 浏览 Skills Hub
/skills hub search deploy # 搜索部署相关技能
/skills install @nous/cloud-deploy # 安装指定技能
安装的技能会自动下载到 ~/.hermes/skills/ 目录，并在下次 Agent 对话中生效。
4. /plugins — 插件管理
4.1 基本用法
/plugins # 列出所有已安装的插件
/plugins enable <name> # 启用插件
/plugins disable <name> # 禁用插件
/plugins install <name> # 安装插件
/plugins info <name> # 查看插件详情
4.2 插件 vs 技能
| 特性 | 技能（Skill） | 插件（Plugin） |
|---|---|---|
| 作用层 | Agent 行为层 | 系统基础设施层 |
| 触发方式 | 用户主动请求 | 自动运行 |
| 安装位置 | ~/.hermes/skills/ | ~/.hermes/plugins/ |
| 修改范围 | 单次任务的执行流程 | 系统级行为（如记忆提供者） |
| 示例 | 部署技能、文档生成技能 | 记忆持久化插件、i18n 插件 |
4.3 插件系统架构
插件通过 Hook 机制与 Agent 生命周期集成：
┌────────────────────────────────────────┐
│ Plugin System │
│ │
│ ┌──────────────┐ ┌─────────────────┐ │
│ │ Memory Plugin│ │ i18n Plugin │ │
│ │ (外部记忆 │ │ (消息翻译) │ │
│ │ 提供者) │ │ │ │
│ └──────┬───────┘ └────────┬────────┘ │
│ │ │ │
│ └───────┬───────────┘ │
│ │ │
│ ┌───────┴───────┐ │
│ │ HookRegistry │ │
│ │ (事件分发) │ │
│ └───────────────┘ │
└────────────────────────────────────────┘
4.4 内置插件
| 插件 | 功能 | 配置 |
|---|---|---|
memory | 外部记忆提供者（如 Honcho） | config.yaml 的 memory 节 |
boot-md | BOOT.md 启动指令执行器 | 自动加载 ~/.hermes/BOOT.md |
i18n | 消息国际化翻译 | hooks/i18n/ 目录下的翻译文件 |
5. /memories — 记忆管理
5.1 基本用法
/memories # 显示当前记忆内容
/memories add <text> # 添加记忆条目
/memories remove <text> # 移除记忆条目
/memories clear # 清空所有记忆
/memories export # 导出记忆到文件
/memories import <file> # 从文件导入记忆
5.2 记忆系统架构
Hermes Agent 的记忆系统采用双文件模型：
| 文件 | 内容 | 大小上限 | 维护者 |
|---|---|---|---|
MEMORY.md | Agent 自身笔记（环境事实、项目约定、经验教训） | 2200 字符 | Agent 自主 + 用户手动 |
USER.md | 用户画像（姓名、角色、偏好、习惯） | 1375 字符 | Agent 自主 + 用户手动 |
5.3 记忆的冻结快照机制
MEMORY.md 和 USER.md 采用冻结快照设计：
- 加载时快照：会话启动时读取文件内容，作为快照注入系统提示词
- 中途写入：Agent 在对话中写入新记忆时，立即持久化到磁盘
- 不更新快照：但不会更新当前会话的系统提示词中的快照
- 下次刷新：新记忆只在下次会话启动时的快照中生效
这种设计的目的是保证 Prompt Cache 稳定性。如果中途更新快照，会导致 Anthropic 的 Prompt Caching 失效，增加成本和延迟。
5.4 记忆条目格式
记忆条目使用 § 分隔符分隔，每条记忆是一个独立的知识单元：
# MEMORY.md
§ 用户偏好使用 VS Code 作为主编辑器
§ 项目使用 Python 3.12 + FastAPI 框架
§ 数据库为 PostgreSQL 16，连接串在 .env 中
§ CI/CD 使用 GitHub Actions，部署到 AWS ECS
§ 上次部署时间：2026-06-15，版本 v2.3.1
5.5 记忆管理最佳实践
- 定期清理：过时的记忆条目应该及时移除，避免误导 Agent
- 具体而简洁：每条记忆应该是一个具体、明确的知识点
- 区分类型：环境信息放 MEMORY.md，个人偏好放 USER.md
- 敏感信息：不要在记忆中存储密码、密钥等敏感信息（记忆文件不加密）
- 备份：定期备份
~/.hermes/memories/目录
6. /apps — 应用连接器管理
6.1 基本用法
/apps # 列出所有可用的应用连接器
/apps connect <name> # 连接到应用
/apps disconnect <name> # 断开应用连接
/apps status # 显示所有连接状态
/apps config <name> # 配置应用连接参数
6.2 应用连接器概念
应用连接器（App Connector）是 Hermes Agent 与第三方服务的桥接层。通过连接器，Agent 可以：
- 读取第三方服务的数据（如 GitHub Issues、Slack 消息、Jira 工单）
- 写入数据到第三方服务（如创建 PR、发送消息、更新工单）
- 监听第三方服务的事件（如新 Issue、新消息、工单状态变更）
6.3 支持的应用
| 应用 | 连接方式 | 能力 |
|---|---|---|
| GitHub | OAuth / Personal Token | PR、Issue、代码搜索、仓库管理 |
| Jira | API Token | 工单查询、创建、更新、流转 |
| Notion | Integration Token | 页面读写、数据库查询 |
| Google Workspace | OAuth2 | 日历、文档、Gmail |
| Confluence | API Token | 知识库搜索和编辑 |
| Linear | API Key | 项目管理和工单追踪 |
6.4 连接器配置
# config.yaml
apps:
github:
enabled: true
auth_type: "token"
token_env: "GITHUB_TOKEN"
default_org: "my-org"
jira:
enabled: true
auth_type: "basic"
url: "https://myteam.atlassian.net"
email_env: "JIRA_EMAIL"
token_env: "JIRA_TOKEN"
7. /agent — 代理线程管理
7.1 基本用法
/agent # 显示当前活跃的 Agent 线程
/agent switch <id> # 切换到指定 Agent 线程
/agent new # 创建新的 Agent 线程
/agent kill <id> # 终止指定 Agent 线程
7.2 多 Agent 线程
在 Gateway 模式下，一个用户可能同时有多个 Agent 线程在运行：
┌─────────────────────────────────────┐
│ User Session │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Agent 1 │ │ Agent 2 │ │
│ │ (主线程) │ │ (子任务) │ │
│ │ GPT-4.1 │ │ Mini │ │
│ │ 编码任务 │ │ 文档任务 │ │
│ └──────────┘ └──────────┘ │
│ │
│ ┌──────────┐ │
│ │ Agent 3 │ │
│ │ (委派) │ │
│ │ Flash │ │
│ │ 搜索任务 │ │
│ └──────────┘ │
└─────────────────────────────────────┘
7.3 使用场景
场景一：并行任务管理 当 Agent 在后台执行一个长时间任务时，你可以创建新线程处理其他事情。
场景二：不同模型分配 将需要强推理的任务分配给 GPT-4.1 线程，将简单任务分配给 Mini 线程。
场景三：任务隔离 不同的项目或上下文使用不同的 Agent 线程，避免相互干扰。
8. /ide — IDE 上下文集成
8.1 基本用法
/ide # 显示 IDE 集成状态
/ide connect # 连接到 IDE
/ide share # 分享当前编辑器上下文给 Agent
/ide goto <file>:<line> # 让 IDE 跳转到指定位置
8.2 IDE 集成能力
/ide 命令启用 IDE 上下文后，Agent 可以：
- 感知当前编辑状态：知道你在编辑哪个文件、光标在什么位置
- 读取选中文本：你可以选中代码片段，让 Agent 针对性分析
- 跳转到位置：Agent 可以让 IDE 跳转到特定文件和行号
- 应用编辑：Agent 的文件修改可以直接在 IDE 中反映
8.3 支持的 IDE
| IDE | 连接方式 | 功能完整度 |
|---|---|---|
| VS Code | Extension（Language Server Protocol） | 完整 |
| JetBrains | Plugin | 完整 |
| Neovim | LSP Client | 基本 |
| Cursor | 内置 | 完整 |
8.4 IDE 集成配置
# config.yaml
ide:
enabled: true
auto_connect: false # 是否自动连接
share_context: true # 是否自动分享编辑上下文
lsp_mode: "stdio" # stdio / socket
9. /import — 导入外部配置
9.1 基本用法
/import claude-code # 导入 Claude Code 的配置
/import cursor # 导入 Cursor 的配置
/import <file> # 从文件导入自定义配置
9.2 Claude Code 配置导入
Hermes Agent 支持从 Claude Code（Anthropic 的代码 Agent）导入配置，包括：
- CLAUDE.md：项目级指令文件 → 导入为上下文文件
- 工具权限：Claude Code 的工具白名单 → 映射为 Hermes 的权限设置
- 自定义指令：Claude Code 的自定义指令 → 融入系统提示词
9.3 导入映射规则
| Claude Code 概念 | Hermes Agent 映射 |
|---|---|
| CLAUDE.md | Context Files（context_files 配置） |
| Allowed Tools | Permissions（/permissions 设置） |
| Custom Instructions | System Prompt 追加 |
| Project Rules | Skills（~/.hermes/skills/） |
| MCP Servers | MCP 配置（mcp.servers） |
10. 命令组合实战
10.1 完整开发环境搭建
# 1. 接入 GitHub
/apps connect github
# 2. 安装开发技能
/skills install @nous/api-scaffold
/skills install @nous/test-generator
# 3. 配置 MCP 工具
/mcp add filesystem
/mcp add postgres
# 4. 连接 IDE
/ide connect
# 5. 设置任务目标
/goal 搭建一个完整的 REST API 项目，包括 CRUD、测试、CI/CD
10.2 多工具协同分析
# 使用技能进行代码分析
/skills search code-review
/skills use code-review
# 同时使用 MCP 数据库工具查询相关数据
(通过 MCP PostgreSQL 工具查询表结构)
# 记录分析结论
/memories add 项目使用 Repository 模式，数据层通过 SQLAlchemy ORM 访问
思考题
-
MCP 工具服务器的工具描述会被注入到系统提示词中，这意味着什么安全风险？Hermes Agent 如何缓解这种风险？
-
技能系统采用渐进式披露设计，为什么不让 Agent 在每次对话中加载所有技能的完整内容？从 Token 成本和上下文质量两个角度分析。
-
/memories管理的记忆文件（MEMORY.md 和 USER.md）使用冻结快照机制。如果取消冻结，改为实时更新快照，会对 Prompt Caching 产生什么影响？在什么场景下这种改变是值得的？ -
应用连接器（
/apps）和 MCP 工具服务器（/mcp）都能让 Agent 访问外部服务。它们的设计理念有什么不同？在什么场景下应该选择哪种方式？ -
设计一个完整的工作流：使用
/mcp、/skills、/apps、/agent、/ide五个命令组合，实现一个从 GitHub Issue 分析到代码修改到 PR 提交的自动化流程。