Hermes Agent 的 Profile 机制：如何让一个 agent 服务多个部门
📖 摘要：同一个 AI 助理，先给市场部做了知识问答机器人，技术部也说「我们也要一个」——两个部门共用助理，答案会不会串？客户 A 的上下文出现在客户 B 的回答里这种事，是怎么发生的，又是怎么从结构上杜绝的？本文用「两个部门两个机器人」的真实业务场景贯穿，讲清 Hermes Agent 的 Profile 多档案机制：一份档案 = 一套完全独立的数据（记忆/技能/会话/配置），机器人各接各的档案，各配各的应用入口——隔离靠物理分档案，不靠权限配置、不靠 AI 自觉。文章覆盖档案机制、落地接线、操作命令速查、分线时机判断、与双实例的选型边界。适用人群：Hermes 用户、需要分业务线管理 AI 助理的个人与交付团队。
一、业务故事：一个助理，两个部门
先讲一个我们遇到过的问题。
一个 AI 助理先给市场部做了知识问答机器人——市场资料、产品手册、报价口径，回答自带出处。跑顺了之后，技术部找过来说：「我们也想要一个，能不能让助理也答技术文档？」
听起来简单：同一个助理，多加一份资料的事。
但这里藏着一个被大多数人忽略的问题：一个大脑同时服务两个业务线，记忆会串味。市场部同事问「咱们的报价口径是什么」，助理答对了；第二天技术部同事问「接口超时怎么排查」，助理却答出「建议按报价口径与客户确认」——市场话术混进了技术回答。不是模型笨，是它记得太多：同一个人的记忆里，市场资料和技术资料没有墙。客户 A 的上下文出现在客户 B 的回答里，在单档案场景下不是「会不会」的问题，是「迟早」的问题。
我们当时的第一个想法也是常规思路：给助理配权限——市场部的问题只检索市场资料，技术部的问题只检索技术资料。但这条路在 AI 助理的场景里不好走，原因后面讲。真正解决问题的是另一个思路：不给一个大脑分权限，给它分档案。
这套机制在 Hermes Agent 里叫 Profile。本文把它讲透：它是什么、怎么用、什么时候该分、和「再装一套」有什么区别——全程用「市场部 + 技术部」这个场景串着讲。
二、档案是什么：一个大脑的几套独立记忆
Hermes Agent 的数据默认住在一个叫 default 的档案里（Linux/macOS
默认在 ~/.hermes，Windows 桌面环境在安装目录下的 data
数据目录）。里面装着一整套东西：
| 档案内容 | 是什么 |
|---|---|
| config | 配置与模型接入（含各业务的应用入口/Key 绑定） |
| memories | 长期记忆——记住的用户偏好、业务事实、历史结论 |
| skills | 技能库——这个助理会干什么 |
| sessions | 会话历史——聊过什么 |
| cron | 定时任务——它会主动做什么 |
一个档案 = 上面这一整套，完整独立。
Profile 机制 = 在同一套 Hermes 里可以开多个档案，每个档案有自己完整的一套 config / memories / skills / sessions / cron，档案之间完全隔离——A 档案的技能、记忆、会话，B 档案看不到。
目录上长这样：
~/.hermes/ # default 档案（数据根目录）
├── config.yaml
├── memories/
├── skills/
├── sessions/
└── cron/
~/.hermes/profiles/<名字>/ # 其他档案，多一层 profiles/
├── config.yaml
├── memories/
└── ...关键认知：记忆的隔离是结构性的。A 档案的记忆存在 A 档案的目录里，B 档案运行的时候根本不读那个目录——不是「不让 B 看 A 的记忆」，是 B 的世界里不存在 A 的记忆。这个「够不着」而不是「不让碰」的原则，是整套隔离思路的地基，后面还会出现两次。
容易混淆的一个点：一个档案 ≠ 一个入口。 同一个档案有三个入口——命令行直连、消息机器人、HTTP API——它们共享同一份档案数据。也就是说「一个档案」=「一个大脑」，命令行里聊过的记忆，机器人回答时也用得上；反过来，如果一个大脑接了市场部和技术部两个机器人，两个部门共享的是同一份记忆——这正是开头那个串味问题的根源。
三、落地：市场部一个档案，技术部一个档案
回到开头的场景。解法现在很直接：
市场部机器人 ──→ 档案 market：记忆/技能/会话全独立，只配市场应用的入口
技术部机器人 ──→ 档案 tech：记忆/技能/会话全独立，只配技术应用的入口两个机器人背后是两个独立的档案。每个档案只配自己业务的应用入口（市场档案里没有技术应用的接入配置，反之亦然）。落到配置上就是：市场档案里接的是市场问答应用 A 的 API Key，技术档案里接的是技术问答应用 B 的 API Key——入口只认自己的应用，市场机器人想调技术应用，连 Key 都没有。gateway 按档案分别启动，各接各的机器人。
到这里，开头问题的答案就完整了：
- 市场部同事的会话、记忆，全部落在 market 档案里
- 技术部同事的会话、记忆，全部落在 tech 档案里
- 市场档案的运行环境里不存在技术档案的数据和入口
隔离不是靠「助理收到技术问题时提醒自己别用市场记忆」——那种靠自觉的隔离是软约束，早晚失效。隔离靠的是：技术上它就没有对方的档案。市场机器人想答出技术库的内容，它连技术应用的入口都没有，无从答起。
知识库那一侧同理：每个业务的知识库在 Dify 里是独立应用、独立资料库，机器人只接自己的应用——「应用里没有别的库，机器人的档案里没有别的入口」，两层都是物理的。这是另一篇文章展开的主题（第七节收口时会再点一次），本文聚焦档案这一层。
四、操作速查：怎么开档案、怎么接线
实际命令（Hermes Agent v0.21.0，机制自 v0.20.0 起实测稳定）：
| 想做什么 | 命令 |
|---|---|
| 查看现有档案 | hermes profile list（含模型/gateway 状态/别名） |
| 建档案（复制当前配置起步） | hermes profile create market --clone |
| 从指定档案复制 | hermes profile create tech --clone-from <源档案> |
| 加业务描述 | hermes profile create ops --description "商务运营" |
| 指定档案干活 | hermes-market -z "..."（建档案自动生成别名命令） |
| 看档案详情 | hermes profile show market |
| 改名 / 删除 | hermes profile rename <旧> <新> /
hermes profile delete <名> |
| 搬档案（换机/备份） | hermes profile export market → 新机
hermes profile import <归档> |
| 默认切换 | hermes profile use market |
几个要点：
--clone起步最省事：会带上当前档案的配置、模型接入、技能——新档案直接能用，不用重新配模型。档案名建议小写字母数字（如 market/tech/dev/ops）。- 别名命令最方便：建档案时自动生成
hermes-<档案名>命令，不用切换上下文，直接指定档案干活。 - gateway 按档案分别启动：每个档案可以单独起机器人服务、接各自的机器人（bot），互不干扰。
- 业务数据搬家用 export/import：档案打包带走，换机器、备份、给客户交付初始档案都走这条。
五、什么时候该分：业务分线信号表
不是所有情况都要分档案。判断信号看四条：
| 信号 | 该分 | 不必分 |
|---|---|---|
| 记忆该不该互通 | 市场记忆和技术记忆不该互相影响 | 记忆互通有好处（共享企业级公共认知） |
| 技能面是否不同 | 一个档案管问答、一个档案管自动化，技能完全不同 | 技能几乎一样，只是话题不同 |
| 凭据要不要隔离 | 各业务用自己的模型 Key / 应用入口，不能混 | 共用同一套接入，无需分开 |
| 会话能不能混 | 客户 A 的上下文绝不能被客户 B 看到 | 内部闲聊与工作，串一点无伤大雅 |
凭据那条的实际判断依据通常是计费归属与合规边界——Key 要按业务独立核算、或某业务的数据不能走另一业务的通道，就得分。四条里中两条以上，就值得分档案；只中一条可以先不分——Profile 的 export/import 支持后期再拆，分档案不是一步到位的决定，随时可以补。
这个判断不限于「部门」——同一个人管两摊业务也一样。我们的典型建议场景是：
hermes profile create dev --clone # 开发助手：Dify 交付、验收
hermes profile create ops --clone # 商务运营：需求跟进、方案投标一个 AI 助理，白天跟你做项目交付，晚上帮你盯客户需求渠道——两摊活的记忆、会话、定时任务各在各的档案里，互不污染。部门隔离和个人分线，用的是同一套机制、同一条判断线。
不想读全文时，用这条快速判断链：
需要机器级隔离（跨机部署/独立资源/独立版本）？ ──是──→ 双实例
否 ↓
数据需要物理隔离（记忆/会话/凭据不互通）？ ──否──→ 一个档案够用
是 ↓
分档案：一个业务线一个档案六、分档案还是再装一套：隔离光谱
有个问题几乎必被问到：分档案和「再装一个 Hermes」有什么区别？答案是四个维度的隔离程度不同：
| 维度 | 多档案（Profile） | 双实例（再装一套） |
|---|---|---|
| 数据 | 完全隔离 | 完全隔离 |
| 程序/安装 | 同一份安装 | 各自安装 |
| 机器资源 | 同机共享 CPU/内存 | 通常跨机独立；同机装两套则仍共享 |
| 版本 | 一起升级 | 可各自升级 |
部门隔离、个人分线这类场景，档案就够了——隔离的实质是数据，档案已经把数据物理分开，共用的只是同一份程序和机器资源，没有数据风险。
真正需要「再装一套」的是更硬的场景：机器级故障隔离（一台挂了另一台不受影响）、资源强隔离（一个业务跑满 CPU 不拖累另一个）、部署环境隔离（一个在客户内网、一个在云上，物理到不了对方网络）、版本要分开升级。
一句话：按数据隔离选档案，按机器隔离选双实例——多数业务分线需求落在档案这一档，双实例是少数派。
七、为什么不是「配权限」：一个完整的答案
回到开头那个被否掉的常规思路：给一个大脑配权限，市场问题只放行市场资料。这个思路在传统系统里成立，在 AI 助理 + 知识库的形态里走不通（以下基于 Dify 社区版与 Hermes 当前版本的能力现状——产品演进可能引入更细的权限位，选型以当时版本为准），原因要分两层说：
- 知识库侧：Dify 这类知识库平台的权限单位到「应用」为止——一个应用 = 一套知识库 + 一套检索配置 + 一个独立入口，库内的文档不分级，没有「这个用户只能看库里部分文档」的配置位
- 助理侧：Hermes 的隔离单位到「档案」为止——一个档案一套记忆和入口，没有「这条记忆对市场会话可见、对技术会话不可见」的运行时过滤
两侧的结构决定了：细粒度权限没有配置位，物理拆分是唯一可靠的路。知识库按业务拆应用，助理按业务拆档案——两层都是「结构上不存在对方的通道」，不是「有通道但设了门禁」。门禁可以被配置错、被绕过、被忘记；结构上没有通道，就不存在这些问题。
（知识库侧「拆应用」的完整论证见本站姊妹篇《把企业手册变成会答话的机器人：企业知识库问答怎么做》——那篇讲 Dify 应用层，本文讲档案层，合起来是「业务隔离 = 两层物理拆」的完整答案。）
八、边界：档案隔离解决什么、不解决什么
如实说边界，别等踩到再发现：
档案不隔离的：
- 机器资源与程序版本：同机档案共用 CPU/内存，升级一起升——要隔离这些，走双实例
- 同一档案内的会话：一个档案里开多个机器人，会话仍共享该档案的记忆——所以「一个档案接两个部门 bot」不是隔离方案
一个灰色地带：记忆想共享、知识想隔离——目前只有软边界，没有硬方案。比如两个部门 bot 共用助理的公共记忆（企业级认知），但各自只答各自的库——这种「一个大脑 + 按会话路由」的形态，记忆确实是共享的，知识边界只能靠路由约束维持，是软边界。如果业务对隔离是硬要求，就别选这个组合；能接受软边界，它换来的是记忆共享的便利。选型时把这条摆到桌面上谈清楚。
常见问题
分档案之后，原来的记忆会丢吗？
不会。default 档案的数据原样保留，新档案用 --clone
从现有档案复制配置和技能起步，记忆类数据按需带或不带（--clone
带配置/模型/技能，--clone-all
才带全量状态）。分线是「加一套新档案」，不是「迁移旧档案」，旧数据不动。
两个档案能同时跑吗？会不会抢资源？
能。同一台机器上多个档案可以同时运行（gateway 按档案分别启动、各接各的机器人），档案间数据互不可见。资源层面共用机器，日常一问一答互不影响；如果两边同时跑重度任务（长文档处理、大批量生成），会抢 CPU——重度并行场景考虑双实例。
给客户交付时，档案能直接打包带走吗？
能。hermes profile export 把整个档案打包成归档，目标机器
hermes profile import
还原——交付初始档案、换机迁移、定期备份都走这条。这也意味着给客户交付「一个业务一个档案」的初始状态是标准操作，不是手工搭的。
分档案之后，两个档案之间的知识能互相引用吗？
不能——档案间数据不互通正是隔离的目的。需要两边都用的公共知识，只能各档案维护一份（--clone
建档案时带着配置和技能起步，公共知识按需复制过去）；「公共知识共享 +
业务各自分线」的半共享形态目前没有原生机制，属于第八节说的灰色地带。选型时把这个限制算进去：共享需求越强，分档案的代价越高。
本文基于 Hermes Agent v0.21.0 实测（Profile 机制自 v0.20.0 起实测）。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实实测记录。
