第十一课：Slash 命令（中）：模型与权限

/model/fast/permissions/approve/plan/goal

1. 概述

在上一课中，我们学习了会话控制相关的 7 个 Slash 命令。本课将聚焦另一类核心命令——模型与权限管理。这些命令直接影响 Agent 的推理能力、安全策略和任务执行模式，是日常使用中最关键的配置工具。

命令	功能	典型使用频率
`/model`	切换 LLM 模型	中等
`/fast`	切换 Fast 服务层级	较低
`/permissions`	查看/修改审批权限	较低
`/approve`	批准被安全系统拦截的操作	按需
`/plan`	切换计划模式	较低
`/goal`	设置/管理任务目标	较高

2. /model — 切换模型

2.1 基本用法

/model                          # 显示当前模型和可用模型列表
/model gpt-4.1-mini            # 切换到 GPT-4.1 Mini
/model gpt-4.1                 # 切换到 GPT-4.1
/model anthropic/claude-sonnet-4-20250514  # 指定 provider/model 格式

/model 命令用于运行时切换当前会话使用的 LLM 模型。这是一个即时生效的命令，下一次 Agent 调用 LLM 时就会使用新模型。

2.2 模型选择策略

不同的任务适合不同的模型。以下是常见的选择策略：

场景	推荐模型	原因
简单问答/闲聊	gpt-4.1-mini	快速、低成本
代码生成/调试	gpt-4.1 / Claude Sonnet	更强的推理能力
复杂架构分析	Claude Opus / GPT-4.5	最强推理，适合深度分析
快速文件操作	gpt-4.1-mini	工具调用不需要强推理
长文写作	Claude Sonnet	长输出质量稳定
多模态任务	GPT-4.1	视觉理解能力好

2.3 Provider 格式

Hermes Agent 支持多种 Provider 格式，/model 命令兼容以下写法：

/model gpt-4.1                              # 短名称（使用默认 provider）
/model openai/gpt-4.1                       # provider/model 格式
/model openrouter/anthropic/claude-sonnet-4-20250514  # 通过 OpenRouter 代理
/model ollama/llama3:70b                     # 本地 Ollama 模型

2.4 模型切换的影响

切换模型后，以下方面会发生变化：

推理能力：更强的模型能更好地理解复杂指令和进行多步推理
工具调用质量：高级模型在工具参数构造上更精确
响应速度：小模型通常更快，大模型更慢
Token 成本：不同模型的价格差异可达 10-100 倍
Context Window：不同模型支持的最大上下文长度不同
压缩行为：Context Window 变化会改变压缩触发阈值

2.5 模型切换的源码实现

/model 命令在内部调用 AIAgent 的模型更新逻辑：

# 简化的模型切换流程
def handle_model_command(self, model_name):
    # 1. 解析 provider/model 格式
    provider, model = self._parse_model_string(model_name)
    # 2. 验证模型可用性（API Key 存在等）
    if not self._validate_model(provider, model):
        return "Model not available. Check API key configuration."
    # 3. 更新当前会话的模型配置
    self.current_model = model
    self.current_provider = provider
    # 4. 重新初始化 LLM 客户端
    self._reinitialize_client()
    # 5. 返回确认信息
    return f"Switched to {provider}/{model}"

3. /fast — Fast 服务层级

3.1 基本用法

/fast           # 显示当前 Fast 层级状态
/fast on        # 启用 Fast 模式
/fast off       # 禁用 Fast 模式

/fast 命令控制 Agent 的服务层级（Service Tier）。Fast 模式启用后，Agent 会：

优先使用响应速度最快的模型变体
减少不必要的工具调用（只做核心操作）
缩短输出长度（简洁回复）
跳过某些可选的质量检查步骤

3.2 使用场景

场景一：快速查询 当你只需要一个简单的答案（如"今天的日期是什么"、"这个文件有多大"），Fast 模式可以显著减少等待时间。

场景二：高频交互 在调试过程中需要反复执行简单命令时，Fast 模式可以减少每轮的延迟。

场景三：节省成本 Fast 模式通常使用更小、更便宜的模型变体，适合预算敏感的场景。

3.3 Fast 模式的行为变化

行为	正常模式	Fast 模式
模型选择	使用 `/model` 设置的模型	使用该模型的 Fast 变体（如有）
输出长度	自由发挥	简洁模式，减少冗余
工具调用	全部可用	跳过可选工具
质量检查	完整检查	简化检查
错误重试	多次重试	快速失败

4. /permissions — 审批权限管理

4.1 基本用法

/permissions              # 显示当前权限设置
/permissions auto         # 自动模式（自动批准非危险操作）
/permissions read-only    # 只读模式（禁止所有写操作）
/permissions full         # 完全模式（所有操作需确认）

/permissions 命令控制 Agent 的命令审批策略，即在执行哪些操作时需要用户确认。

4.2 权限模式详解

Auto 模式（推荐）

在 Auto 模式下，Agent 自动批准大部分操作，只有被安全系统标记为"危险"的操作才需要用户确认：

rm -rf 类删除命令 → 需要确认
git reset --hard → 需要确认
cat package.json → 自动批准
python3 app.py → 自动批准
写入 /etc/ 目录 → 需要确认

Read-Only 模式

在 Read-Only 模式下，Agent 只能执行读取操作，所有写操作（文件写入、命令执行、网络请求等）都被禁止。适合以下场景：

审查代码时不想让 Agent 修改文件
让 Agent 分析日志但不执行修复
安全敏感环境中限制 Agent 行为

Full 模式

在 Full 模式下，所有操作（包括读取）都需要用户确认。这是最安全但最慢的模式，适合：

首次使用 Agent 的用户
高安全要求的环境
调试 Agent 行为

4.3 权限与安全系统的关系

/permissions 设置的模式是顶层策略，它与底层安全系统（DANGEROUS_PATTERNS、Tirith）协同工作：

用户命令 → 权限模式过滤 → DANGEROUS_PATTERNS 检测 → Tirith 扫描 → 审批确认 → 执行

Read-Only 模式在最前端拦截所有写操作
Auto 模式让大部分操作通过，但仍受 DANGEROUS_PATTERNS 和 Tirith 的二次检查
Full 模式在最前端要求所有操作确认

4.4 Gateway 模式下的权限隔离

在 Gateway（多用户）模式下，权限设置是会话级别的，不同用户的权限互不影响。管理员可以通过配置文件设置全局权限策略：

# config.yaml
permissions:
  default_mode: "auto"          # 新会话的默认权限
  allow_user_override: true      # 允许用户通过 /permissions 切换
  max_mode: "auto"              # 用户可以设置的最高权限（不能切到 full）

5. /approve — 批准被拒操作

5.1 基本用法

/approve              # 批准最近一次被拒绝的操作
/approve all          # 批准当前会话中所有被拒操作
/approve always       # 永久批准该类操作（写入配置文件）
/approve deny         # 拒绝（默认行为，通常不需要显式输入）

当安全系统拦截了一个操作时，Agent 会向用户展示被拦截的操作详情。用户可以通过 /approve 命令批准该操作的执行。

5.2 审批流程

当 Agent 要执行一个被标记为危险的操作时，交互流程如下：

Agent: 我要执行以下命令：
       rm -rf ./build/
       ⚠️ 此操作被安全系统拦截（原因：递归删除目录）
       
       请选择：
       /approve       — 批准这次执行
       /approve always — 永久批准此类操作
       /approve deny   — 拒绝（默认）

User: /approve

Agent: ✅ 操作已批准，正在执行...
       (执行结果)

5.3 审批级别

级别	命令	持久性	适用场景
once	`/approve`	仅本次	不确定的操作，只批准一次
session	`/approve session`	会话内	本次会话中反复用到的操作
always	`/approve always`	永久（写入配置）	确认安全的常用操作
deny	`/approve deny`	仅本次	拒绝执行

5.4 Smart Approval（智能审批）

Hermes Agent 支持 Smart Approval 模式，使用辅助 LLM 评估命令的实际风险，自动批准明显的误报：

# config.yaml
approvals:
  mode: "smart"          # off / on / smart
  timeout: 60            # CLI 审批超时
  gateway_timeout: 300   # Gateway 审批超时

Smart 模式下：

python3 -c "print('hello')" → 自动批准（虽然包含 "python3 -c" 但无危险操作）
git commit -m "fix: remove deprecated API" → 自动批准（虽然包含 "remove" 但只是 commit message）
rm -rf / → 仍然需要手动确认

6. /plan — 计划模式

6.1 基本用法

/plan              # 切换计划模式的开关
/plan on           # 启用计划模式
/plan off          # 禁用计划模式
/plan show         # 显示当前计划

/plan 命令切换 Agent 的计划模式（Plan Mode）。在计划模式下：

Agent 不会执行任何工具调用
Agent 只会分析任务、制定计划、列出步骤
用户审查计划后，可以关闭计划模式让 Agent 执行

6.2 使用场景

场景一：复杂任务预审 面对一个复杂的重构或部署任务，先用计划模式让 Agent 列出所有步骤，确认后再执行。

场景二：学习 Agent 思路 新手用户可以通过计划模式了解 Agent 会如何处理一个任务，建立信任后再启用执行模式。

场景三：安全审计 在生产环境中，先用计划模式审查 Agent 打算执行的所有命令，确认无误后再切换到执行模式。

6.3 计划模式的行为

行为	正常模式	计划模式
文件读取	✅ 允许	✅ 允许（只读分析）
文件写入	✅ 允许	❌ 禁止
终端命令	✅ 允许	❌ 禁止
浏览器操作	✅ 允许	❌ 禁止
Web 搜索	✅ 允许	✅ 允许（信息收集）
子 Agent 委派	✅ 允许	❌ 禁止

6.4 计划输出格式

在计划模式下，Agent 会输出结构化的计划：

## 任务分析

**目标**：将项目的 Python 版本从 3.10 升级到 3.12

**影响范围**：
- pyproject.toml（版本约束）
- Dockerfile（基础镜像）
- CI/CD 配置（测试矩阵）
- 3 处使用了 3.10 特性的代码

**执行计划**：

1. [分析] 读取 pyproject.toml，确认当前版本约束
2. [分析] 搜索项目中使用 Python 3.10 特性的代码
3. [修改] 更新 pyproject.toml 中的 python_requires
4. [修改] 更新 Dockerfile 基础镜像
5. [修改] 更新 CI/CD 配置中的 Python 版本矩阵
6. [修改] 适配 3.10 特有的语法到 3.12 兼容写法
7. [测试] 运行完整测试套件
8. [验证] 确认所有 CI 检查通过

**风险评估**：
- 中风险：依赖库可能不兼容 3.12
- 低风险：f-string 语法变更（3.12 支持更多嵌套）

输入 `/plan off` 让我开始执行。

7. /goal — 任务目标管理

7.1 基本用法

/goal                           # 查看当前目标
/goal <描述>                     # 设置新目标
/goal pause                     # 暂停目标追踪
/goal resume                    # 恢复目标追踪
/goal clear                     # 清除当前目标

/goal 命令用于设置和管理 Agent 的任务目标。设置目标后，Agent 会：

将目标注入系统提示词中，作为持续的上下文引导
在每轮工具调用后评估目标的完成进度
主动提示下一步行动，而不是等待用户指令
目标完成后主动报告结果

7.2 目标与普通指令的区别

特性	普通指令	/goal 目标
持久性	单轮，执行后结束	跨多轮持续追踪
自主性	被动响应	主动推进
上下文影响	影响当前轮	持续影响所有后续轮次
进度追踪	无	有，Agent 主动报告进度
优先级	按顺序执行	目标始终在 Agent 的"视野"中

7.3 使用场景

场景一：大型重构任务

/goal 将项目从 Express 迁移到 Fastify，包括所有路由、中间件和测试

设置目标后，Agent 会持续工作，逐步完成每个路由的迁移、中间件的适配、测试的更新，而不需要你每一步都下达指令。

场景二：持续监控

/goal 监控 production 日志，每 30 分钟检查一次错误率，如果超过 5% 就告警

在 Gateway 模式下，结合 Cron 任务，Agent 可以持续追踪这个目标。

场景三：学习探索

/goal 理解这个项目的认证系统，包括 JWT 生成、验证、刷新流程，最后给我写一份技术文档

Agent 会自主阅读代码、分析流程、整理文档，你只需要在它提问时回答。

7.4 目标的生命周期

设置目标 → 追踪中 → 可能暂停 → 恢复 → 完成/清除
  /goal     (每轮)    /goal pause  /goal resume  /goal clear
  <描述>                                          或自然完成

7.5 多目标管理

Hermes Agent 目前支持单目标模式。如果你有多个并行目标：

方案一：使用 /goal 设置一个包含所有子目标的复合目标

/goal 完成以下三个任务：1) 修复登录 Bug 2) 更新 API 文档 3) 优化数据库查询

方案二：使用 /new + /goal 在不同会话中分别设置目标

/new + /goal 修复登录 Bug
/new + /goal 更新 API 文档
/new + /goal 优化数据库查询

8. 命令组合实战

8.1 安全探索工作流

/permissions read-only    # 先设为只读模式
/plan on                  # 开启计划模式
(让 Agent 分析任务并输出计划)
(审查计划)
/plan off                 # 关闭计划模式
/permissions auto         # 切回自动模式
(让 Agent 执行)

8.2 高效调试工作流

/fast on                  # 启用快速模式
/model gpt-4.1-mini      # 使用小模型（快速）
(执行一系列简单命令)
/fast off                 # 关闭快速模式
/model gpt-4.1            # 切回大模型（精确）
(执行复杂分析)

8.3 大型项目工作流

/goal 重构认证系统，支持 OAuth2 + JWT 双模式
(观察 Agent 的计划)
(Agent 自主执行中...)
/approve                  # 批准安全系统拦截的 git 操作
(Agent 继续...)
(目标完成后)
/archive                  # 归档该会话
/new                      # 开始新任务

思考题

/model 切换模型后，之前会话中与旧模型的对话历史是否会影响新模型的行为？为什么？
/permissions 的三种模式（auto/read-only/full）与安全系统的 DANGEROUS_PATTERNS 是什么关系？如果设置为 auto 模式，是否意味着所有操作都不需要确认？
/plan 模式下 Agent 可以读取文件但不能写入。这种设计背后的思考是什么？如果允许写入会有什么风险？
/goal 设置的目标如何影响 Agent 的上下文压缩行为？如果目标描述很长，是否会影响可用的上下文空间？
设计一个完整的审批策略：一个生产环境的部署场景，从 /plan 计划审查到 /approve 操作批准，如何组合这些命令实现安全高效的部署流程？