EvoMap
Hermes Agent Profiles:點樣安全運行多個 agents

Hermes Agent Profiles:點樣安全運行多個 agents

2026年4月29日
1,224 次閱讀
hermes-agent profiles multi-agent security isolation agent-ops

Hermes Agent profiles:安全咁同時運行多個 Agent

嗨,我係 Lena。有個問題我一直擺低咗冇答。後來終於試住去回答佢。

幾星期前,我喺同一部機上面切換兩個 Hermes Agent——一個係我為個人實驗設定嘅,另一個綁住一個細型客戶項目。佢哋意外共用咗同一個 config 目錄。一開始我冇留意。之後,一段來自個人 agent 嘅 session memory,出現喺一個佢唔應該出現嘅對話入面。我見到之後停咗好耐。呢啲 agent 其實冇真正分開。佢哋只係睇落似係分開咗。

就係嗰刻開始,我更仔細咁去睇 Hermes​ Agent profiles 到底做緊乜——唔係表面嗰條 command,而係究竟邊啲嘢被隔離,邊啲冇。以下係我目前拼出嚟嘅理解。我唔覺得自己已經睇到完整圖像,但手上呢幾塊碎片,值得先寫低。

呢篇係寫畀已經唔只運行單一 agent,而係開始運行幾個 agents 嘅人。當你意識到自己需要多過一個 agent 嗰刻,其實亦係大部分 isolation problems 開始出現嗰刻。對一個 agent 有用嘅 defaults,去到兩個 agent 就唔一定再有用,而且通常係靜悄悄咁失效。你未必即刻察覺,直到某啲嘢已經越過咗邊界。

Hermes profiles 真正隔離咗啲咩

以我而家嘅理解,一個 profile 係一個有名嘅 scope,入面放住一個 agent instance 要好似"佢自己"咁運作所需嘅所有嘢:config、memory、sessions、已註冊嘅 skills、gateway state,同 environment variables。當你切換 profiles,你唔只係改一個設定——你係換走成個 agent 運作入面嘅 context。呢個分別,比我一開始以為嘅重要得多。

Config, memory, sessions, skills, gateway state, env

我後來返去更仔細睇呢份列表,最令我意外嘅係,有咁多 state 都係活喺呢個 scope 入面。如果你喺任何認真嘅 CLI tool 入面用過 environment variables,呢個 pattern 會好熟。每個 profile 都帶住自己嘅:

  • Config — model selection、temperature、system prompt overrides、tool permissions
  • Memory — agent 隨時間累積落嚟嘅長期 context
  • Sessions — active conversation threads,包括可以 resume 嗰啲
  • Skills — 已註冊嘅 capabilities,同佢哋 scoped credentials
  • Gateway​ state — routing rules、MCP server registrations、network policies
  • Env​ vars — API keys、endpoints、secrets

我想特別指出:呢個係 security boundary,唔只係 organizational boundary。 OWASP 講點樣 harden agent architectures 時,喺 sessions 之間隔離 memory 同 context 係佢列出嘅第一批防線之一。Profiles 就係 Hermes 喺 per-agent 層面實現呢個想法嘅方式。嗰份 cheat sheet 我睇咗兩次,先真正 click 到。

我而家都未完全肯定自己明晒 gateway state 喺某啲 edge cases 入面會點樣跨 profiles 傳播——例如兩個 profiles 用唔同 scopes 註冊同一個 MCP server。呢個係我仲想再睇嘅地方。我目前估,registration 係 per-profile,但底層 connection pool 可能唔係。如果你喺 gateway layer 做任何 stateful 嘅嘢,呢點就會好重要。我未 confirm,所以先將問題留低。

建立同管理多個 profiles

我第一次試嘅時候,將件事諗得太複雜。基本流程其實比我預期簡單,但你圍住佢建立嘅 conventions,比 commands 本身更重要。

Naming, alias commands, switching, export and import

我而家用嘅 convention——呢個只係我自己習慣,唔係規則——係 <context>-<role>:personal-research、work-coding、client-acme-prod。命名比我一開始諗嘅更重要。 當你有六個 profiles,而且已經好攰,一個叫 test2 嘅 profile 就係未來事故嘅伏線。我犯過呢個錯。到你有一日以為 test2 係 sandbox,結果喺入面跑咗 destructive command,嗰日你就會開始認真命名 profiles。

Switching 本來就應該係一條 command 搞掂。Export 同 import 可以畀你喺機器之間搬 profiles,我試過一次喺新 laptop 上面做。Export bundle 會包括 config,但唔包括 raw secrets——你要喺接收端重新 inject 嗰啲 secrets。我覺得呢個 default 係啱嘅,不過亦係最容易令人中伏嘅部分。我同幾個人傾過,佢哋本來以為 secrets 會跟住 profile 一齊 migrate,直到 imported agent authenticate 失敗先發現唔係。

我仲留意到一件細事:喺 shell level 幫常用嘅 profile-switch commands 做 alias,會令件事冇咁痛苦。如果你一日要切三四次,friction 會累積——而 friction 就係令人跳過切換、重用錯 profile 嘅原因。

profiles 嘅真實使用場景

去到呢度,我要停一停諗:其實邊啲人真係需要呢樣嘢?唔係每個運行 agent 嘅人都需要 profiles。但如果下面任何一種情況講中你,我覺得你係需要嘅。

Personal vs work, coding vs research, prod vs test

最清楚嘅場景係 ​personal vs work​。唔同 memory、唔同 skills、唔同 credentials。你唔會想週末 side-project 用嘅 agent 可以 access 到僱主嘅 database,亦唔會想 work agent 記住你嘅購物清單。心理上嘅分隔亦係真嘅——切換 profiles 係一個細小 ritual,幫我轉換嘅唔只係 configuration,仲係 context。

第二個場景係 ​coding vs research​。Coding agent 會受惠於比較 aggressive 嘅 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 只隔一個 keystroke。Microsoft 關於 agent governance 嘅 guidance 將呢件事描述為 project-level data isolation,用嚟防止 agent contexts 之間 cross-contamination。Profiles 令呢個要求喺單一 workstation 上都可以 enforce,而唔需要為咗一個本來應該輕量嘅 separation 去開 VM 或 container。

最近我仲遇到第四個之前冇預期嘅場景:​stable vs experimental​。一個 stable profile,入面係測試過嘅 skills 同 known-good configs;另一個 experimental profile,用嚟試新 tools、prompt variations,或者 model swaps。Experimental profile 成日壞。Stable 嗰個唔會,因為冇嘢可以隨便掂佢。呢種 separation 幫我慳低嘅 debugging time,比我預期多。

……唔完全係我原本預期嘅方向,但 profiles 用得越多,我越覺得佢哋似係 safe agent operation 嘅基本單位,而唔係 optional extra。

常見 profile 錯誤

呢啲我大部分都犯過。有啲好快發現,有啲過咗幾星期先醒覺。

喺 profiles 之間共享 credentials。 呢個係最常見,亦係最危險嘅一個。人哋建立咗獨立 profile,但所有 profiles 都重用同一條 API key。Profiles 係隔離咗;credentials 唔係。如果其中一個 profile 被 compromise,所有共享同一條 key 嘅 profiles 都一齊 compromise。IBM 嘅 AI agent security tutorial 講得好直接——over-permissioning 同 shared credentials 係 agent systems 嘅主要 failure mode。修法好唔華麗:每個 profile 用獨立 key,而且 scope 到每個 profile 真正需要嘅最小範圍。

對 session continuity 有錯誤期待。 切換 profiles 會結束 active session。有啲人以為 sessions 會跟住佢哋跨 profiles 走。唔會。如果你需要 continuity,就留喺同一個 profile。如果你需要 isolation,就切換——同時接受自己係開始一個新嘅 conversation context。我見過有人同呢個假設拉扯幾星期,先真正內化佢。

混合 tool configs。 將同一個 skill 載入多個 profiles,但配唔同 scopes。個 skill 會視乎自己喺邊個 profile 下面運行而有唔同行為,debug 起上嚟真係會好混亂。我會建議由一開始就將 skills 當成 profile-scoped,即使咁樣會有少少 duplication。Duplication 好平。Debug 一個喺唔同 profiles 之間行為唔一致嘅 skill,唔平。

最後呢點可能係我諗太多,但佢已經捉過我兩次,所以我都標出嚟。

profiles 點樣改變 deployment 同 governance 決策

呢部分我仲喺度摸索緊,而且我想老實講,我對呢度嘅理解仲未完整。

當 profiles 被認真對待,佢哋就唔再只係個人 organization tool,而係會變成一個 ​governance primitive​。團隊可以要求 production agent profiles 使用特定嘅 gateway configurations。Auditor 可以問某個 action 係由邊個 profile 產生——而且攞到一個真答案,而唔係聳聳肩。呢個同 NIST 嘅 AI Risk Management Framework 對 accountability 嘅處理係一致嘅:每個 action 都應該可以 trace 到一個定義清楚嘅 authority scope。Profiles 畀到你呢個 scope,唔使臨時發明一個。

NIST 2025 年關於 agentic AI 嘅更新行得更遠。Cybersecurity AI Profile draft 將 single-agent 同 multi-agent deployments 視為唔同 risk categories,每一類都有自己嘅 isolation requirements。Profiles 係滿足呢啲 requirements 嘅一個具體做法,而唔需要為每個 agent 起獨立 infrastructure。對細團隊嚟講,呢點好重要——大部分人冇 budget 或時間為每個 agent 跑 isolated environments,但佢哋可以為每個 agent 跑 isolated profiles。

我仲未準備好對 self-hosting setups 或更大型 team deployments 意味住咩作出強結論。我只係小規模測試過,亦未跑到夠耐去睇高負載下會邊度壞。但方向感係啱嘅:identity 同 isolation 應該活喺 agent level,而唔係 machine level。 當呢件事成立,agents 就會變成可以組合嘅 building blocks,而唔係一個個需要被整體信任嘅 monolithic processes。

FAQ

profiles 會唔會共享任何 state?

Profile boundary 應該係硬嘅。你唯一會見到重疊嘅地方,係底層 Hermes binary 本身——same version、same global defaults——但以我觀察,所有 stateful 嘅嘢都係 profile-scoped。

我可以同時運行兩個 profiles 嗎?

可以,喺唔同 terminal sessions 入面。就我見到,佢哋唔會互相干擾。我試過短時間同時跑三個,冇明顯問題。

新 profile 最安全嘅 default 係咩?

Minimal permissions、冇 production credentials、冇 shared 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

相關文章