Hermes profiles 最容易被低估。很多人把它当成“多个配置文件”，但在长期运行的 Agent 里，profile 更像身份边界。
一个 profile 可能带着自己的 session、memory、skills、cron jobs、plugins 和运行习惯。把所有场景都放在 default 里，短期省事，长期混乱。
什么时候需要新 profile
遇到这些情况，就应该考虑新建或拆分 profile：
| 场景 | 为什么需要隔离 |
|---|---|
| 个人助手和工作助手 | 用户偏好、项目上下文、权限不同 |
| 测试环境和生产环境 | cron、API、secrets 风险不同 |
| 研究 Agent 和执行 Agent | 一个探索，一个稳定执行 |
| 内容写作和代码维护 | memory 与 skill 目标不同 |
| 外部 API 调用 | 需要更明确的权限和日志 |
如果两个场景的失败后果不同，就不要让它们共享同一套长期记忆和技能。
先把环境拆成 3 层，而不是一开始拆 10 个
很多人第一次上手 profiles 会过度细分，结果 profile 数量比任务还多。更稳的做法，是先从三层开始：
| 层级 | 典型用途 | 是否建议长期保留 |
|---|---|---|
| personal / research | 个人试验、资料整理、草稿探索 | 是 |
| work / team | 团队协作、稳定工作流、常用 skills | 是 |
| prod / readonly | 生产检查、对外接口、严格审计 | 是 |
先把责任边界做清楚，再决定是否继续细分成 team-a、team-b、api-test、api-prod。多数混乱不是来自 profile 不够多，而是来自 profile 名称和 owner 不清楚。
推荐命名方式
名称要短，但要说明用途：
personal-default：个人日常对话。work-dev：工作项目开发。work-prod-readonly：生产只读检查。content-research：资料收集和写作。api-internal-test：内部 API 测试。automation-cron：长期定时任务。
不要只叫 test1、new、backup。三周后你会忘记它们分别做什么。
如果团队里不止一个人会碰 Hermes，命名里最好显式带上用途或权限边界，例如 prod-readonly、ops-daily-report、content-research，而不是靠口头约定。
clone 时怎么选
如果你只是想复用模型、工具或基础配置，可以克隆配置。 如果你想复制完整状态、session、memory 或 skills，就要更谨慎，因为旧上下文也会一起过去。
一个保守做法是：先 clone config，再手动补必要 memory。这样慢一点，但更不容易把旧项目的偏好和风险带进新环境。
哪些东西应该跟 profile 绑定
当你决定把一个 profile 长期保留时，建议连同这些边界一起记录：
- 主要 owner 是谁。
- 默认 workdir 指向哪个项目。
- 可以读取哪些本地目录或远端资源。
- 是否允许调用特定 skills、tools、gateway 或 API。
- 是否允许写入 memory。
- 是否承担 cron、消息入口或外部系统调用。
只有把这些说清楚，profile 才不只是“另一个名字”，而是稳定的运行身份。
profile 和 memory 的关系
memory 不生效时，第一件事就是检查 profile。你可能不是忘了写入，而是在另一个 profile 里调用 Hermes。
建议每个 profile 的 memory 都只写本场景长期有效的信息。不要把个人偏好、生产限制、研究笔记和内容写作标准塞进同一个地方。
可以用一个简单判断：
- 未来三周还会稳定成立的信息，才考虑写进当前 profile 的 memory。
- 只和当前任务相关的信息，应该留在会话或项目文档里。
- 涉及生产限制、审批要求、密钥边界的内容，应该既写进 profile 相关约定，也写进团队可见文档。
profile 和 cron / API 的关系
cron 和 API 都会让 Agent 离开当前聊天窗口，进入长期或外部系统调用。它们更需要固定 profile。
上线前写清：
- 这个 cron / API 用哪个 profile。
- 这个 profile 能读写什么。
- 哪些 skill 可以被调用。
- 哪些动作必须人工确认。
- 日志和失败提醒发给谁。
profile 不是安全的全部，但它是治理的起点。
一个可直接照搬的多环境模板
如果你今天就要开始拆 profile，可以先用这种保守模板：
| profile | 用途 | 不该做什么 |
|---|---|---|
personal-default | 日常问答、个人试验 | 不接生产 API，不跑高风险 cron |
content-research | 教程写作、资料整理、SEO 研究 | 不写生产系统，不发外部消息 |
team-ops-readonly | 监控、日报、只读检查 | 不改配置，不触发部署 |
api-internal-test | 内网 UI 或自动化联调 | 不直接承接真实客户流量 |
prod-readonly | 生产排障与状态解释 | 不执行不可逆写操作 |
这套模板的重点不是名字，而是每个 profile 都有明确的“不该做什么”。
切 profile 前的可执行清单
- 当前任务是否真的需要独立 memory 和权限。
- profile 名称是否能让三周后的你一眼看懂。
- owner、workdir、skills、gateway、cron 责任是否写清。
- clone 时是否避开了不该复制的旧 session 和旧记忆。
- API 或生产相关 profile 是否默认只读。
- 是否准备了停用、归档或清理无主 profile 的办法。
完成检查
- 你列出了当前所有使用场景。
- 你知道哪些场景失败后果不同。
- 你为高风险或长期任务拆出了独立 profile。
- 你没有把生产 API 和个人聊天共用同一 profile。
- 你知道 clone config 和 clone everything 的风险差异。
下一步建议继续看 Hermes API Server 集成边界、Hermes Memory 排障指南 和 Hermes Cron 自动化，把多环境隔离真正落到接口、记忆和后台任务上。