Profiles 与 CredentialPools —— 多环境隔离、Profile 创建、密钥池轮转
简介
在之前的系列文章中，你已经掌握了 Hermes Agent 的核心能力：从技能系统到多平台集成，从定时任务到多 Agent 编排。但这些都还停留在"能跑起来"的阶段。
当你真正要把 Hermes Agent 用到生产环境时，会面临一个棘手的问题：
如何安全地管理不同环境的配置和密钥？
想象一下这样的场景：
- 你有开发、测试、预发、生产四套环境，每个环境的 API 密钥、数据库连接串都不同
- 你的团队有 5 个开发者，每个人用的模型 Provider 不同（有人用 OpenAI，有人用 Anthropic，有人用本地 Ollama）
- 某个 API 密钥因为安全策略需要每 90 天轮转一次
- 某个 Skill 需要读取 AWS S3，但你不想把 AWS 密钥硬编码在 Skill 里
如果你手动管理这些，很快就会陷入配置混乱、密钥泄露的噩梦。
这就是 Hermes Agent 的 Profiles（配置文件） 和 CredentialPools（密钥池） 要解决的问题。
Profiles 让你隔离不同环境的完整配置，CredentialPools 让密钥自动轮转和安全分发。
读完本文后，你将能够：
- 创建和管理多个 Profile，实现开发/测试/生产环境完全隔离
- 使用 CredentialPools 集中管理密钥，支持自动轮转
- 在 Skill 中安全地引用密钥，无需硬编码
- 实现团队级别的配置共享和环境切换
目录
- Profiles 概述
- 环境隔离：为什么需要 Profile
- Profile 的创建与管理
- Profile 配置文件详解
- Profile 切换与继承
- CredentialPools 概述
- 密钥池的创建与管理
- 密钥轮转机制
- Skill 中引用密钥
- 安全最佳实践
- 实战案例
- 总结与下篇预告
Profiles 概述
什么是 Profile？
┌─────────────────────────────────────────────────────────┐
│ Profile 概念图 │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Hermes Agent │ │
│ │ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Profile │ │ Profile │ │ Profile │ ... │ │
│ │ │ dev │ │ test │ │ prod │ │ │
│ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │
│ │ │ │ │ │ │
│ │ ┌────┴────┐ ┌────┴────┐ ┌────┴────┐ │ │
│ │ │ Provider│ │ Provider│ │ Provider│ │ │
│ │ │ ollama │ │ openai │ │ openai │ │ │
│ │ │ Model │ │ Model │ │ Model │ │ │
│ │ │ qwen3 │ │ gpt-4o │ │ gpt-4o │ │ │
│ │ │ Tools │ │ Tools │ │ Tools │ │ │
│ │ │ all │ │ limited │ │ curated │ │ │
│ │ │ Skills │ │ Skills │ │ Skills │ │ │
│ │ │ dev-set │ │ test-set│ │ prod-set│ │ │
│ │ │ Creds │ │ Creds │ │ Creds │ │ │
│ │ │ dev-pool│ │ tst-pool│ │ prd-pool│ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ │ │
│ │ 一键切换环境，配置完全隔离 │ │
│ └─────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘Profile 是 Hermes Agent 中一套完整的配置集合，包含：
- Provider 配置：使用哪个模型服务、API 地址
- 模型选择：使用哪个具体模型
- 工具集（Toolsets）：启用哪些工具
- 技能（Skills）：加载哪些 Skill
- 凭证池（CredentialPools）：绑定哪些密钥池
- 工作目录：默认的工作路径
- 系统提示词：特定环境的系统级提示
每个 Profile 完全独立，切换 Profile 相当于切换了 Agent 的"身份"。
Profile 存储位置
~/.config/hermes/
├── profiles/
│ ├── default.yaml # 默认 Profile
│ ├── dev.yaml # 开发环境
│ ├── test.yaml # 测试环境
│ ├── prod.yaml # 生产环境
│ └── mobile.yaml # 移动端优化 Profile
├── credential-pools/
│ ├── dev-pool.json.enc # 加密的密钥文件
│ ├── test-pool.json.enc
│ └── prod-pool.json.enc
└── hermes.yaml # 全局配置（Profile 无关的部分）所有 Profile 配置文件都以 YAML 格式存储，密钥池文件经过加密保护。
环境隔离：为什么需要 Profile
没有 Profile 的痛点
┌─────────────────────────────────────────────────────────┐
│ 手动管理多环境的灾难 │
│ │
│ 开发者小王的日常： │
│ │
│ 上午： │
│ 1. 把 hermes.yaml 中的模型改成 ollama │
│ 2. 把数据库连接指向本地 PostgreSQL │
│ 3. 把 API 密钥换成开发环境的 key │
│ 4. 禁用所有"危险"工具 │
│ 5. 开始编码 │
│ │
│ 下午： │
│ 6. 接到任务：去测试环境部署并验证 │
│ 7. 把 hermes.yaml 中的模型改回 gpt-4o │
│ 8. 把数据库连接指向测试环境的 RDS │
│ 9. 把 API 密钥换成测试环境的 key │
│ 10. 启用额外的监控工具 │
│ 11. 开始部署 │
│ │
│ 灾难： │
│ 12. 部署时忘了改回模型，用了昂贵的 gpt-4o 跑了测试脚本 │
│ 13. 把开发环境的 key 误用到了生产脚本 │
│ 14. 同事小张改了配置文件，覆盖了小王的设置 │
│ │
└─────────────────────────────────────────────────────────┘没有 Profile 系统，你不得不反复修改配置文件，极易出错：
- 误操作风险：在测试环境误用了生产密钥
- 配置漂移：团队成员各自修改配置，环境不再一致
- 效率低下：每次切换环境都要改一堆配置
- 安全漏洞：密钥明文存储在配置文件中，容易被 git 提交
Profile 带来的改变
┌─────────────────────────────────────────────────────────┐
│ 使用 Profile 后的日常 │
│ │
│ hermes profile switch dev # 开发模式 │
│ 自动加载: ollama + 本地数据库 + 开发密钥 + 全量工具 │
│ │
│ hermes profile switch test # 测试模式 │
│ 自动加载: gpt-4o + 测试 RDS + 测试密钥 + 监控工具 │
│ │
│ hermes profile switch prod # 生产模式 │
│ 自动加载: gpt-4o + 生产 RDS + 生产密钥 + 严格审批工具 │
│ │
│ 零手动修改，一键切换，配置完全隔离 │
│ │
└─────────────────────────────────────────────────────────┘Profile 的创建与管理
查看现有 Profile
# 列出所有可用的 Profile
hermes profile list
# 输出示例:
# ┌──────────┬──────────────┬─────────────┬──────────┐
# │ 名称 │ 模型 │ Provider │ 状态 │
# ├──────────┼──────────────┼─────────────┼──────────┤
# │ default │ gpt-4o │ openai │ 当前激活 │
# │ dev │ qwen3.6 │ ollama │ 可用 │
# │ test │ gpt-4o-mini │ openai │ 可用 │
# │ prod │ gpt-4o │ openai │ 可用 │
# └──────────┴──────────────┴─────────────┴──────────┘
# 查看当前 Profile 详情
hermes profile current创建新 Profile
# 方式一：从零创建
hermes profile create dev
# 方式二：从现有 Profile 复制（推荐）
hermes profile create dev --from default
# 方式三：指定模板创建
hermes profile create prod --template production
# 查看创建的 Profile 文件
cat ~/.config/hermes/profiles/dev.yamlProfile 配置文件详解
# ~/.config/hermes/profiles/dev.yaml
name: dev
description: "本地开发环境 - 使用 Ollama 本地模型"
# Provider 配置
provider:
type: ollama
base_url: "http://localhost:11434"
api_key: null # Ollama 不需要 API key
# 模型配置
model: qwen3.6:8b
model_params:
temperature: 0.7
max_tokens: 4096
top_p: 0.9
# 工具集配置
toolsets:
enabled:
- terminal
- read_file
- write_file
- patch
- search_files
- vision_analyze
disabled: [] # 开发环境不禁用任何工具
# Skills 配置
skills:
enabled:
- code-review
- python-helper
- git-workflow
disabled:
- production-deploy # 开发环境不需要部署 Skill
# 凭证池绑定
credential_pools:
- dev-pool
# 工作目录
workdir: ~/projects/myapp
# 系统提示词（覆盖默认）
system_prompt: |
你是一个本地开发助手，使用 Ollama 本地模型。
你的主要任务是协助代码开发、调试和测试。
所有操作都在本地环境执行，不会影响生产系统。
# 安全设置
security:
# 开发环境允许危险命令
allow_dangerous_commands: true
# 命令执行前不需要审批
require_command_approval: false
# 文件写入不需要确认
require_write_confirmation: false
# 环境变量覆盖
env_overrides:
DATABASE_URL: "postgresql://localhost:5432/myapp_dev"
API_BASE_URL: "http://localhost:8080/api"
DEBUG: "true"
LOG_LEVEL: "debug"Profile 验证
# 验证 Profile 配置是否合法
hermes profile validate dev
# 输出示例:
# ✓ Profile 'dev' 配置验证通过
# ✓ Provider 配置有效
# ✓ 模型 'qwen3.6:8b' 在 Ollama 中可用
# ✓ 凭证池 'dev-pool' 存在且有效
# ✓ 所有启用的 Skill 已安装
# ✓ 工作目录存在
# 如果发现错误：
# ✗ Profile 'dev' 配置有问题:
# ✗ 模型 'qwen3.6:8b' 未在 Ollama 中下载，请先运行:
# ollama pull qwen3.6:8b
# ✗ 凭证池 'dev-pool' 未找到Profile 切换与继承
切换 Profile
# 切换 Profile（当前会话立即生效）
hermes profile switch dev
# 切换并显示变更摘要
hermes profile switch test --verbose
# 输出:
# 正在切换到 Profile 'test':
# 模型: qwen3.6:8b → gpt-4o-mini
# Provider: ollama → openai
# 工具集: 全量 → 受限（禁用 deploy, shell-script）
# 凭证池: dev-pool → test-pool
# 工作目录: ~/projects/myapp → ~/projects/myapp-test
# 切换完成。
# 切换后验证
hermes profile currentProfile 继承机制
Profile 支持继承，避免重复配置：
# ~/.config/hermes/profiles/staging.yaml
# 继承自 prod，只覆盖需要不同的部分
inherits: prod
description: "预发环境 - 继承生产配置，使用更便宜的模型"
# 只覆盖需要变更的部分
model: gpt-4o-mini # 生产用 gpt-4o，预发用 mini 节省成本
credential_pools:
- staging-pool # 替换为预发密钥池
env_overrides:
DATABASE_URL: "postgresql://staging-db.example.com:5432/myapp_staging"
# 其他 env 从 prod 继承# 查看 Profile 的完整配置（包含继承）
hermes profile show staging --resolved
# 显示解析后的完整配置，包含所有继承的配置项启动时指定 Profile
# 启动时指定 Profile
hermes start --profile dev
# 通过环境变量指定
HERMES_PROFILE=prod hermes start
# 在脚本中使用
hermes run --profile test --skill "run-tests" --input "all"CredentialPools 概述
什么是 CredentialPool？
CredentialPool（密钥池）是 Hermes Agent 中集中管理敏感凭据的机制。它解决了以下问题：
┌─────────────────────────────────────────────────────────┐
│ 密钥管理演进 │
│ │
│ 阶段一：硬编码（危险！） │
│ ├── Skill 代码中直接写 API_KEY = "sk-xxx" │
│ └── 配置文件里明文存数据库密码 │
│ │
│ 阶段二：环境变量（好一点，但有局限） │
│ ├── export DATABASE_URL="postgresql://..." │
│ └── 问题：多个 Skill 需要不同环境的密钥时很难管理 │
│ │
│ 阶段三：密钥池（推荐） │
│ ├── 集中管理、加密存储 │
│ ├── 按环境分组（dev/test/prod pool） │
│ ├── 支持密钥轮转 │
│ └── Skill 通过引用名获取，无需知道真实值 │
│ │
└─────────────────────────────────────────────────────────┘CredentialPool 的核心特性
- 加密存储：密钥在磁盘上以加密形式存储
- 环境隔离：不同 Profile 绑定不同的密钥池
- 轮转支持：支持自动和手动密钥轮转
- 细粒度访问控制：指定哪些 Skill 可以访问哪些密钥
- 审计日志：记录密钥访问和使用情况
密钥池的创建与管理
创建密钥池
# 创建新的密钥池
hermes credential-pool create dev-pool
# 添加密钥到池中
hermes credential-pool add dev-pool OPENAI_API_KEY sk-xxx-yyy-zzz
hermes credential-pool add dev-pool DATABASE_URL "postgresql://localhost:5432/dev"
hermes credential-pool add dev-pool AWS_ACCESS_KEY_ID AKIAxxxxxxxxxxxx
hermes credential-pool add dev-pool AWS_SECRET_ACCESS_KEY "wJalrXxxxxxxxxxxxx"
# 查看池中密钥列表（不显示值）
hermes credential-pool list dev-pool
# 输出:
# ┌──────────────────────────┬─────────┬─────────────┬───────────┐
# │ 密钥名 │ 类型 │ 最后轮转 │ 状态 │
# ├──────────────────────────┼─────────┼─────────────┼───────────┤
# │ OPENAI_API_KEY │ api_key │ 2026-05-20 │ ✓ 有效 │
# │ DATABASE_URL │ url │ 2026-05-15 │ ✓ 有效 │
# │ AWS_ACCESS_KEY_ID │ aws │ 2026-04-01 │ ⚠ 将过期 │
# │ AWS_SECRET_ACCESS_KEY │ aws │ 2026-04-01 │ ⚠ 将过期 │
# └──────────────────────────┴─────────┴─────────────┴───────────┘
# 查看某个密钥的值
hermes credential-pool get dev-pool OPENAI_API_KEY
# 更新密钥
hermes credential-pool update dev-pool OPENAI_API_KEY sk-new-key-123
# 删除密钥
hermes credential-pool remove dev-pool OLD_API_KEY从文件批量导入
# 从 .env 文件导入
hermes credential-pool import dev-pool .env.development
# 从 JSON 文件导入
hermes credential-pool import dev-pool credentials.json --format json
# credentials.json 示例:
# {
# "OPENAI_API_KEY": "sk-xxx",
# "DATABASE_URL": "postgresql://localhost:5432/dev",
# "REDIS_URL": "redis://localhost:6379/0"
# }密钥池导出（用于备份）
# 导出密钥池（加密）
hermes credential-pool export dev-pool --output dev-pool-backup.enc
# 导出为环境变量脚本（明文，谨慎使用）
hermes credential-pool export dev-pool --output dev-env.sh --format env
# 导出后设置权限
chmod 600 dev-env.sh密钥轮转机制
为什么需要密钥轮转？
┌─────────────────────────────────────────────────────────┐
│ 密钥轮转场景 │
│ │
│ 安全合规要求： │
│ ├── SOC 2: API 密钥每 90 天必须轮转 │
│ ├── PCI DSS: 数据库密码每 60 天必须更换 │
│ └── 公司内部政策：AWS 密钥每 30 天轮转 │
│ │
│ 安全事件响应： │
│ ├── 发现密钥泄露 → 立即轮转所有相关密钥 │
│ ├── 员工离职 → 轮转其可能接触过的密钥 │
│ └── 第三方泄露 → 轮转可能受影响的密钥 │
│ │
│ 自动化轮转的优势： │
│ ├── 无需手动修改配置文件 │
│ ├── 无需重启 Agent │
│ ├── 新密钥自动对所有绑定的 Profile 生效 │
│ └── 旧密钥自动失效 │
│ │
└─────────────────────────────────────────────────────────┘手动轮转
# 手动轮转单个密钥
hermes credential-pool rotate dev-pool OPENAI_API_KEY
# 系统会提示输入新密钥:
# 请输入新的 OPENAI_API_KEY: *************
# ✓ 密钥 'OPENAI_API_KEY' 已轮转
# 旧值已归档，新值已生效
# 轮转时间: 2026-05-22 18:30:00
# 轮转时查看历史
hermes credential-pool history dev-pool OPENAI_API_KEY
# 输出:
# ┌─────────────────────┬──────────────┬──────────┐
# │ 轮转时间 │ 操作 │ 状态 │
# ├─────────────────────┼──────────────┼──────────┤
# │ 2026-05-22 18:30:00 │ 手动轮转 │ 当前有效 │
# │ 2026-02-20 10:15:00 │ 自动轮转 │ 已过期 │
# │ 2025-11-18 09:00:00 │ 手动轮转 │ 已过期 │
# │ 2025-08-15 14:20:00 │ 初始创建 │ 已过期 │
# └─────────────────────┴──────────────┴──────────┘自动轮转配置
# 设置密钥的自动轮转策略
hermes credential-pool set-policy dev-pool OPENAI_API_KEY \
--rotation-interval 90d \
--auto-rotate true \
--notify-before 7d
# 策略说明:
# --rotation-interval 90d 每 90 天轮转一次
# --auto-rotate true 启用自动轮转
# --notify-before 7d 到期前 7 天通知
# 查看所有策略
hermes credential-pool policies dev-pool
# 输出:
# ┌──────────────────────┬──────────┬─────────────┬──────────┐
# │ 密钥名 │ 轮转周期 │ 下次轮转 │ 通知时间 │
# ├──────────────────────┼──────────┼─────────────┼──────────┤
# │ OPENAI_API_KEY │ 90 天 │ 2026-08-20 │ 2026-08-13│
# │ DATABASE_URL │ 60 天 │ 2026-07-14 │ 2026-07-07│
# │ AWS_ACCESS_KEY_ID │ 30 天 │ 2026-06-21 │ 2026-06-14│
# └──────────────────────┴──────────┴─────────────┴──────────┘使用外部密钥管理服务
# 从 AWS Secrets Manager 同步
hermes credential-pool sync dev-pool \
--source aws-secrets-manager \
--secret-prefix "hermes/dev/"
# 从 HashiCorp Vault 同步
hermes credential-pool sync dev-pool \
--source vault \
--vault-addr "https://vault.example.com:8200" \
--secret-path "secret/hermes/dev"
# 从 Azure Key Vault 同步
hermes credential-pool sync dev-pool \
--source azure-keyvault \
--vault-name "hermes-dev-vault"紧急撤销
# 紧急撤销密钥（立即失效）
hermes credential-pool revoke dev-pool AWS_ACCESS_KEY_ID
# 撤销并轮转到新值
hermes credential-pool revoke-and-rotate dev-pool AWS_ACCESS_KEY_ID
# 撤销后验证
hermes credential-pool get dev-pool AWS_ACCESS_KEY_ID
# ⚠ 此密钥已被撤销，请使用 rotate 命令重新设置Skill 中引用密钥
在 Skill 定义中声明依赖
# my-skill/skill.yaml
name: "aws-deploy"
description: "部署应用到 AWS"
# 声明需要的密钥
credentials:
required:
- name: AWS_ACCESS_KEY_ID
source: credential-pool # 从密钥池获取
- name: AWS_SECRET_ACCESS_KEY
source: credential-pool
- name: DEPLOY_S3_BUCKET
source: credential-pool
# 可选密钥
optional:
- name: DEPLOY_REGION
default: "us-east-1"在 Skill 脚本中使用密钥
# my-skill/execute.sh
#!/bin/bash
# Skill 执行时，声明的密钥会自动注入为环境变量
echo "正在部署到 AWS..."
# 直接使用，无需手动设置
aws s3 sync ./dist s3://${DEPLOY_S3_BUCKET}/latest \
--region ${DEPLOY_REGION:-us-east-1}
echo "部署完成！"在 Skill 模板中引用
# 在 Skill 的 prompt 模板中
prompt: |
请帮我分析数据库连接问题。
数据库连接信息:
- 连接字符串: {{credentials.DATABASE_URL}}
- 环境: {{profile.name}}
请检查连接配置并给出诊断建议。运行时密钥注入
# 运行时指定使用哪个密钥池
hermes run --profile prod --credential-pool prod-pool \
--skill "aws-deploy"
# 临时覆盖某个密钥
hermes run --profile prod \
--credential-override AWS_ACCESS_KEY_ID=AKIA-TEMP-KEY \
--skill "aws-deploy"安全最佳实践
Profile 安全
┌─────────────────────────────────────────────────────────┐
│ Profile 安全建议 │
│ │
│ ✅ 必做： │
│ ├── 生产 Profile 限制可用的工具集 │
│ ├── 生产 Profile 开启命令审批 │
│ ├── 不同环境使用不同的密钥池 │
│ ├── 生产 Profile 禁用不需要的 Skill │
│ └── 定期审计 Profile 配置变更 │
│ │
│ ❌ 禁止： │
│ ├── 在 Profile 文件中明文存储密钥（用 CredentialPool） │
│ ├── 把生产 Profile 配置文件提交到 Git │
│ ├── 在开发 Profile 中绑定生产密钥池 │
│ └── 在生产环境中使用 allow_dangerous_commands: true │
│ │
└─────────────────────────────────────────────────────────┘密钥池安全
# 1. 确保密钥文件加密
hermes credential-pool encrypt dev-pool
# 2. 设置文件权限
chmod 600 ~/.config/hermes/credential-pools/*.json.enc
# 3. 添加到 .gitignore
echo "credential-pools/" >> ~/.config/hermes/.gitignore
# 4. 启用访问审计
hermes credential-pool audit dev-pool
# 5. 设置密钥最小权限原则
hermes credential-pool set-access dev-pool AWS_ACCESS_KEY_ID \
--allowed-skills "aws-deploy,aws-backup" \
--denied-skills "*"环境变量注入安全
# 安全的环境变量注入（仅注入需要的变量）
hermes run --profile prod \
--inject-env DATABASE_URL,API_KEY \
--skill "run-migrations"
# 禁止注入的环境变量黑名单
hermes config set security.env_blocklist \
"PATH,HOME,USER,SHELL,TOKEN,SECRET,KEY,PASSWORD"实战案例
案例一：从零搭建多环境配置
# 第一步：创建开发环境
hermes profile create dev --from default
hermes credential-pool create dev-pool
hermes credential-pool add dev-pool OPENAI_API_KEY sk-dev-key-xxx
hermes credential-pool add dev-pool DATABASE_URL "postgresql://localhost:5432/myapp_dev"
hermes profile switch dev
# 第二步：创建测试环境
hermes profile create test --from default
hermes credential-pool create test-pool
hermes credential-pool add test-pool OPENAI_API_KEY sk-test-key-yyy
hermes credential-pool add test-pool DATABASE_URL "postgresql://test-db.example.com:5432/myapp_test"
hermes profile update test \
--model gpt-4o-mini \
--workdir ~/projects/myapp-test
# 第三步：创建生产环境（继承测试配置，更严格）
hermes profile create prod --from test
hermes credential-pool create prod-pool
hermes credential-pool add prod-pool OPENAI_API_KEY sk-prod-key-zzz
hermes credential-pool add prod-pool DATABASE_URL "postgresql://prod-db.example.com:5432/myapp_prod"
hermes profile update prod \
--model gpt-4o \
--workdir ~/projects/myapp-prod \
--security require_command_approval=true \
--security allow_dangerous_commands=false
# 验证所有 Profile
hermes profile list
hermes profile validate dev
hermes profile validate test
hermes profile validate prod案例二：团队共享配置
# 团队管理员导出配置模板（不含密钥）
hermes profile export dev --output team-dev-template.yaml --no-secrets
hermes profile export prod --output team-prod-template.yaml --no-secrets
# 团队成员导入并个性化
hermes profile import dev --from team-dev-template.yaml
hermes profile create dev --from-template team-dev-template.yaml
# 只修改个人相关的部分
hermes profile update dev \
--provider-type anthropic \
--model claude-sonnet-4
# 团队密钥池（通过 Vault 同步）
hermes credential-pool create team-dev-pool
hermes credential-pool sync team-dev-pool \
--source vault \
--vault-addr "https://vault.company.com:8200"案例三：CI/CD 中的 Profile 使用
# .github/workflows/test.yml
name: Test with Hermes Agent
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Hermes Profile
run: |
hermes profile create ci --from default
hermes credential-pool create ci-pool
hermes credential-pool add ci-pool OPENAI_API_KEY ${{ secrets.OPENAI_API_KEY }}
hermes credential-pool add ci-pool DATABASE_URL ${{ secrets.TEST_DB_URL }}
hermes profile switch ci
- name: Run Tests
run: |
hermes run --profile ci --skill "run-tests" --input "all"总结与下篇预告
总结
本文全面介绍了 Hermes Agent 的 Profiles 和 CredentialPools 系统：
核心要点：
Profile 是完整的配置隔离单元 —— 包含 Provider、模型、工具集、Skills、密钥池、工作目录等。切换 Profile 等于切换 Agent 的完整运行环境。
Profile 支持继承机制 —— 子 Profile 可以继承父 Profile 的配置，只覆盖需要不同的部分，大幅减少重复配置。
CredentialPool 集中管理密钥 —— 所有敏感信息集中存储在加密的密钥池中，Skill 通过声明式依赖获取密钥，无需硬编码。
密钥轮转支持自动和手动 —— 可以设置轮转策略（如每 90 天），到期自动轮转；也支持紧急撤销和立即轮转。
多环境完全隔离 —— 开发、测试、生产环境的配置和密钥完全独立，误操作不会影响其他环境。
最佳实践建议：
- 至少创建 dev/test/prod 三个 Profile，不要用同一个配置跑所有环境
- 生产 Profile 必须开启命令审批和危险命令限制
- 密钥永远不要硬编码，统一使用 CredentialPool
- 为密钥设置自动轮转策略，避免过期导致服务中断
- 定期审计 Profile 配置变更和密钥访问日志
下篇预告
安全配置与 Curator —— 命令审批、Secret 脱敏、技能自动维护
在下一篇文章中，我们将深入 Hermes Agent 的安全机制：
- 命令审批系统：配置哪些命令需要人工审批，如何自定义审批规则
- Secret 脱敏：输出中自动隐藏密钥、密码、Token，防止泄露
- Curator 系统：自动维护 Skills，检测过期 Skill，推荐更新
- 安全审计：完整的操作日志、异常检测、安全事件响应
- 沙箱执行：限制 Agent 的文件系统访问、网络访问、资源使用
从"能用"到"安全地用"，让 Hermes Agent 在受控的环境中可靠运行。
敬请期待！