Hermes Agent profiles：安全运行多个 Agent
嗨，我是 Lena。有个问题我一直拖着没想清楚。后来终于坐下来试着回答它。
几周前，我在同一台机器上切换两个 Hermes Agent——一个是我给个人实验用的，另一个绑定着一个小型客户项目。它们不小心共用了同一个 config 目录。一开始我没注意。后来，一个个人 agent 的 session memory 出现在了它不该出现的对话里。看到那一刻，我停了很久。这些 agent 其实并没有被真正隔离。它们只是看起来被隔离了。
也就是从那时开始，我更认真地去读 Hermes Agent profiles 到底在做什么——不是表面的命令，而是哪些东西被隔离了，哪些没有。下面是我目前拼出来的理解。我不觉得自己已经看到了全貌，但已经拿到的这些碎片，值得先写下来。
这篇写给那些已经不只运行单个 agent，而是开始运行多个 agent 的人。你意识到自己需要不止一个 agent 的那一刻，通常也是大多数隔离问题开始出现的那一刻。对一个 agent 有效的默认设置，到了两个 agent 就不再有效，而且它们往往是安静地失效。你不会马上发现，直到某些东西已经越过边界。
Hermes profiles 真正隔离了什么
按我现在的理解，一个 profile 是一个具名作用域，里面装着一个 agent instance 像"它自己"那样运行所需的一切：config、memory、sessions、注册过的 skills、gateway state，以及 environment variables。切换 profile 时，你不只是改了一个设置——你是在替换整个 agent 运行所处的上下文。这个区别，比我一开始以为的重要得多。
Config, memory, sessions, skills, gateway state, env
我后来又回头更仔细地看了这份列表，真正让我意外的是，有多少 state 都存在这个作用域里。如果你在任何严肃的 CLI tool 里用过 environment variables，这个模式会很熟。每个 profile 都带着自己的：
- Config — model selection、temperature、system prompt overrides、tool permissions
- Memory — agent 随时间积累下来的长期上下文
- Sessions — 活跃的对话线程，包括可以 resume 的线程
- Skills — 已注册的能力，以及它们作用域内的 credentials
- Gateway state — routing rules、MCP server registrations、network policies
- Env vars — API keys、endpoints、secrets
我想强调的是：这是一个安全边界，不只是一个组织方式。 OWASP 在描述如何加固 agent architectures 时，在 sessions 之间隔离 memory 和 context 是它列出的第一批防线之一。Profiles 就是 Hermes 在 per-agent 层面实现这个想法的方式。那份 cheat sheet 我读了两遍，才真正意识到这一点。
我到现在也不确定自己是否完全理解 gateway state 在某些边缘情况下会如何跨 profile 传播——比如两个 profiles 用不同 scopes 注册同一个 MCP server 的时候。这是我还想继续看的地方。我目前的猜测是，registration 是 per-profile 的，但底层 connection pool 可能不是。如果你在 gateway layer 做任何有状态的事情，这一点就会很重要。我还没有确认。所以这个问题先留着。
创建和管理多个 profiles
我第一次试的时候，把它想复杂了。基本流程比我预期的更简单，但你围绕它建立的约定，比命令本身更重要。
Naming, alias commands, switching, export and import
我现在采用的约定——这只是我自己的习惯，不是规则——是 <context>-<role>：personal-research、work-coding、client-acme-prod。命名比我一开始想的更重要。 当你有六个 profiles，而且已经很累时，一个叫 test2 的 profile 就是在等着变成未来事故。我犯过这个错。等到某一天你以为 test2 是 sandbox，结果在里面跑了 destructive command，那一天你就会开始认真命名 profile。
Switching 应该是一条命令就完成。Export 和 import 可以让你在不同机器之间移动 profiles，我曾经在一台新笔记本上测试过一次。Export bundle 会包含 config，但不包含 raw secrets——你需要在接收端重新注入这些 secrets。我觉得这是正确的默认行为，虽然它也最容易绊倒人。我聊过的几个人原本以为 secrets 会跟着 profile 一起迁移，结果 imported agent 认证失败时才发现不是这样。
我还注意到一个小事：在 shell 层给常用的 profile-switch commands 设 alias，会让这件事少痛苦很多。如果你一天要切三四次，摩擦会不断累积——而摩擦正是让人跳过切换、复用错误 profile 的原因。
profiles 的真实使用场景
到这里，我不得不停下来想：到底谁真的需要这个？不是每个运行 agent 的人都需要 profiles。但如果下面任何一种情况描述的是你，我觉得你确实需要。
Personal vs work, coding vs research, prod vs test
最清楚的场景是 personal vs work。不同的 memory、不同的 skills、不同的 credentials。你不会希望周末 side-project 用的 agent 能访问雇主的 database，也不会希望工作 agent 记住你的购物清单。心理上的隔离也是真实存在的——切换 profiles 像一个小仪式，帮助我切换的不只是 configuration，也是 context。
第二个场景是 coding vs research。Coding agent 会从更激进的 tool permissions 中获益——file writes、shell execution、repo access。Research agent 不需要这些，把这些 permissions 给它，只是在无意义地扩大 attack surface。也正是在这里，principle of least privilege 从抽象原则变成了实际做法：每个 profile 只拿它真正需要的 permissions，不多给。我以前会因为省事而宽泛授权。现在不会了。
第三个场景是 prod vs test，这也是大多数人在出事前最容易低估的场景。Test agent 不应该离 production credentials 只有一次按键的距离。Microsoft 关于 agent governance 的指南 把这件事描述为 project-level data isolation，用来避免不同 agent contexts 之间的交叉污染。Profiles 让这个要求在单台 workstation 上也可以执行，不需要为了一个本该轻量的隔离，去单独拉 VM 或 container。
最近我还开始遇到第四种场景，是之前没预料到的：stable vs experimental。一个 stable profile，里面是测试过的 skills 和已知可用的 configs；另一个 experimental profile，用来试新 tools、prompt variations，或者换 model。Experimental profile 经常坏。Stable profile 不会，因为没有东西被允许随手碰它。这个隔离省下的 debugging 时间，比我预期的多。
……这不完全是我一开始预想的方向，但 profiles 用得越多，我越觉得它们像是安全运行 agent 的基本单位，而不是可有可无的附加功能。
常见的 profile 错误
这些错误我大多都犯过。有些很快就发现了，有些过了几周才意识到。
在 profiles 之间共享 credentials。 这是最常见，也最危险的一个。人们创建了单独的 profile，却在所有 profiles 里复用同一个 API key。Profiles 是隔离的；credentials 不是。如果一个 profile 被攻破，每一个共享同一把 key 的 profile 都会一起被攻破。IBM 的 AI agent security tutorial 对这一点说得很直接——over-permissioning 和 shared credentials 是 agent systems 的主要失败模式。修复方式并不华丽：每个 profile 用单独的 key，并且 scope 到它真正需要的最小范围。
对 session continuity 的预期错误。 切换 profile 会结束当前 active session。有些人以为 sessions 会跟着他们跨 profiles 走。不会。如果你需要 continuity，就待在同一个 profile 里。如果你需要 isolation，就切换——同时接受自己正在开始一个新的 conversation context。我见过有人和这个假设较劲好几周，才真正内化它。
混用 tool configs。 把同一个 skill 加载到多个 profiles 里，但给它不同 scopes。这个 skill 会根据自己运行在哪个 profile 下表现得不一样，这会让 debugging 真的变得很混乱。我会建议从一开始就把 skills 当成 profile-scoped 来处理，即使这意味着一点重复。重复很便宜。调一个在不同 profiles 下行为不一致的 skill，不便宜。
最后这一点也许是我想太多了，但它已经坑过我两次，所以还是标出来。
profiles 如何改变 deployment 和 governance 决策
这一部分我还在想清楚，也想诚实地说，我在这里的理解并不完整。
当 profiles 被认真对待时，它们就不再只是个人整理工具，而会变成一个 governance primitive。团队可以要求 production agent profiles 使用特定的 gateway configurations。Auditor 可以问某个 action 是哪个 profile 生成的——并得到一个真实答案，而不是耸耸肩。这个方向和 NIST 的 AI Risk Management Framework 对 accountability 的理解是一致的：每个 action 都应该可以追溯到一个明确的 authority scope。Profiles 给了你这个 scope，而不需要临时发明一个。
NIST 2025 年关于 agentic AI 的更新走得更远。Cybersecurity AI Profile draft 把 single-agent 和 multi-agent deployments 视为不同的风险类别，每一类都有自己的 isolation requirements。Profiles 是满足这些要求的一种具体方式，而且不需要为每个 agent 单独搭一套 infrastructure。对小团队来说，这点很重要——大多数人没有预算或时间为每个 agent 跑独立环境，但他们可以为每个 agent 跑隔离的 profile。
我还不准备对 self-hosting setups 或更大规模 team deployments 意味着什么下强结论。我只在小规模上测试过，也还没跑到足够久，能看见更高负载下会坏在哪里。但方向感是对的：identity 和 isolation 应该存在于 agent level，而不是 machine level。 当这件事成立，agents 就会变成可组合的 building blocks，而不是必须被整体信任的 monolithic processes。
FAQ
profiles 会共享任何 state 吗？
Profile boundary 应该是硬边界。你唯一会看到重叠的地方，是底层的 Hermes binary 本身——同一个 version、同一套 global defaults——但据我观察，所有 stateful 的东西都是 profile-scoped。
我可以同时运行两个 profiles 吗？
可以，在不同 terminal sessions 里运行。就我看到的情况，它们不会互相干扰。我短时间同时跑过三个，没有明显问题。
新 profile 最安全的默认设置是什么？
Minimal permissions，不放 production credentials，不共享 API keys。只有在真正需要时才添加 capabilities。这建议很无聊，但也是我希望自己更早采纳的建议。
每个 project 都应该有自己的 profile 吗？
……我不知道。小实验大概不用。但任何接触 production、真实 client data，或者 sensitive credentials 的东西，都应该有。创建 profile 的成本很低。等到你需要它却没有它时，成本有时会非常高。今天先停在这里。我会继续观察随着 profiles 变多，它会如何表现。Agent infrastructure 正在开始成熟，这里确实发生了一些变化，但我还没完全看清它的形状。
Previous Posts:
👉 如果你还不清楚 Hermes memory 在不同 contexts 之间如何表现，读这篇：Hermes Agent Memory Limits & Tradeoffs Explained
👉 如果你想更深入理解用 external tools 扩展 agents 时如何避开隐藏风险：How to Use MCP Safely with Hermes Agent
👉 如果你正在跨 environments 运行多个 agents，这篇拆解会有帮助：Hermes Agent vs EvoMap: Memory Architecture Differences
👉 想理解 agent capabilities 和 stored knowledge 的差异，这对 profile design 很关键：Agent Skills vs GEP Assets: What Actually Persists
👉 如果你已经在思考 profiles 之外的长期 agent evolution：EvoSkills: Self-Evolving Agent Skills in Practice
