配置文件是智能体的身份证
每个AI智能体都需要一个独立的家。在Hermes里，这个家就叫配置文件。每个配置文件都是一个独立的目录，里面放着它自己的config.yaml、.env、SOUL.md、记忆、会话、技能和定时任务。你可以把它想象成手机里的工作模式和生活模式，数据完全隔离，互不干扰。
创建一个专门写代码的智能体，就用下面这串命令。然后进入它的目录配置好API密钥，就能直接开始聊天了。
bash
# Create a coding agent
hermes profile create coder
coder setup # configure API keys, model
coder chat # start chatting
如果你想从现在的配置克隆一个做研究的，加个--clone参数就行。连记忆和技能都能一起复制，非常方便。
bash
# Create a research agent cloned from your current config
hermes profile create researcher --clone
# Create a full clone (everything: config, memories, skills, cron)
hermes profile create backup --clone-all
配置文件会隔离所有关键数据。配置文件A的聊天记录不会出现在配置文件B里，它们各自的环境变量和定时任务也是独立的。但有个坑要记住：配置文件不是虚拟机，它们共享你电脑的文件系统。一个配置文件能删掉你的文件，另一个也能。
text
What profiles actually isolate | Shared
----------------------------------------|----------------------------
config.yaml | Hermes installation (single codebase)
.env (API keys, tokens) | Python venv
SOUL.md (personality) | System tools
Sessions & conversations | Node.js / npm packages
Memory store | Playwright cache
Skills | GPU / hardware
Cron jobs |
Gateway state (bot token, PID) |
每个配置文件会自动生成快捷命令，放在~/.local/bin/目录下。你可以直接用配置文件名加子命令来操作，不用每次都指定配置文件路径。
bash
coder chat # = hermes -p coder chat
coder gateway start
coder skills list
coder config set model.default anthropic/claude-sonnet-4
给不同配置文件设置不同的机器人令牌也很简单。直接编辑每个配置文件目录下的.env文件就行。
bash
# Edit coder's tokens
nano ~/.hermes/profiles/coder/.env
# Edit personal agent's tokens
nano ~/.hermes/profiles/default/.env
安全方面有个贴心的设计。如果两个配置文件不小心用了同一个机器人令牌，第二个网关启动时会直接报错，告诉你哪个配置文件冲突了。
配置文件不等于沙箱。这一点必须反复强调。配置文件隔离的是Hermes自己的状态数据，不是操作系统的访问权限。如果你的智能体被黑了，或者你给了它删除文件的权限，它照样能删你电脑上的东西。
如果你需要每个配置文件有独立的命令行身份，比如不同的SSH密钥和Git配置，可以这样设置：
yaml
# In the profile's config.yaml
terminal:
home_mode: profile # Hermes uses {HERMES_HOME}/home as $HOME
然后你需要在每个配置文件自己的home目录里，分别初始化~/.ssh、~/.gitconfig、gh认证等等。
看板是团队的任务白板
当你有多个智能体时，最大的问题就是它们怎么协作。官方推荐的方式是看板。这是一个由SQLite数据库支撑的共享任务列表，所有智能体都能看到、认领和更新任务。哪怕你的电脑死机重启，看板上的任务也不会丢。
创建一个任务很简单：
bash
# Create a task for the coder profile
hermes kanban create "Fix login timeout bug in auth.py" --assignee coder
# Agent picks it up, works, updates status
hermes kanban show # see comments, status, workspace
# Human intervention
hermes kanban comment "Check the edge case at line 47"
hermes kanban block --reason "Waiting for staging deploy"
hermes kanban unblock
看板比直接分任务强在它很耐用。直接分任务像打电话，对方挂了就断了。看板像留言板，谁有空谁来看，谁都能接着干。
| 对比维度 | delegate_task | Kanban | |
研究员把查到的资料写在评论里，程序员根据评论写代码，测试员再接手跑测试，整个流程清晰且不会丢失进度。
text
- Research agent reads docs, writes findings as comments
- Coder agent picks up the task, implements based on findings
- Review agent claims next, runs tests, comments review notes
- Human approves or sends back with a comment
直接分任务适合短平快
除了看板，还有一种叫delegate_task的方法，适合快速求助。这就像你正忙着，突然想起来个事儿，直接扭头问旁边的专家一嘴，等他回答完你接着干。它适合做并行研究或者代码审查。
比如你需要同时调研WebAssembly和RISC-V芯片，你可以一次性分两个任务出去。
python
delegate_task(tasks=[
{
"goal": "Research WebAssembly outside the browser",
"context": "Focus on: runtimes (Wasmtime, Wasmer), cloud/edge use cases",
"toolsets": ["web"]
},
{
"goal": "Research RISC-V server chip adoption",
"context": "Focus on: shipping server chips, cloud providers adopting",
"toolsets": ["web"]
}
])
两个子智能体同时上网查资料，然后把结果汇总给你。这比你自己一个一个查快多了，而且不会搞乱你主会话的上下文。
但这种方法的缺点是它不持久。如果你的电脑突然没电了，或者主会话中断了，子智能体的工作成果就全没了。而且整个过程人类插不上手，它更像是一个问完就消失的临时工，不适合需要反复沟通的长期项目。
一个机器人顶多个用
很多人不想为每个智能体申请一个独立的聊天机器人令牌，那样太麻烦了。Hermes支持利用Telegram的话题功能，用一个机器人令牌，通过不同的话题路由到不同的配置文件上。
你在BotFather那里开启话题功能后，可以在配置里设定：话题1（生活）走默认配置，话题2（工作）走工作配置，话题3（编码）走程序员配置。这样你在同一个聊天窗口里，切换话题就是在切换不同的AI智能体。
社区里有用户分享说，这个方法在私聊里也有效，非常流畅。相比管理一堆机器人令牌，这要清爽得多。
但要注意，在Discord上，机器人默认忽略其他机器人的消息，你得手动改网关配置才能让它们互相看见。在Telegram上，机器人需要管理员权限才能完整工作，非管理员机器人只能响应斜杠命令或被@提及。
用宪法管住你的智能体团队
当你的智能体多起来，谁来负责分配任务就成了新问题。社区里流行一个宪法模式。你写一份constitution.md文档，在里面规定清楚：程序员负责Python和调试，研究员负责上网查资料，审查员负责找代码漏洞。
markdown
# constitution.md
Agent: coder
- Specialty: Python, JavaScript, system scripts
- Tools: terminal, file, github
- Route: any coding, debugging, or implementation task
Agent: researcher
- Specialty: web research, docs reading, API exploration
- Tools: web, file
- Route: any research, documentation, or discovery task
Agent: reviewer
- Specialty: code review, security audit, test coverage
- Tools: terminal, file, github
- Route: any review, audit, or quality task
然后你给总指挥智能体的性格设定里加上一句：在分配任何任务前，先读宪法文档。根据任务匹配度，把活儿派给对应的配置文件。这样一来，你就不用手动指挥了，总指挥会自己看文档做决定。
甚至有人把这个模式玩得更溜。他们觉得创建那么多配置文件太重了，干脆在一个配置文件里塞进多个性格。每个技能文件夹就是一种性格，然后总指挥根据宪法决定启动哪种性格来处理任务。这就像一个人格分裂的超级专家，切换自如。
社区里还有个开源的多智能体上下文插件，能把聊天历史注入到每个智能体的上下文里，让它们知道共享频道里正在发生什么。
bash
# Install on each profile:
git clone https://github.com/kaishi00/hermes-community-plugins
关键配置是一定要设置强制提及。没这个限制，智能体会互相聊到天荒地老。有用户反馈过，早上醒来发现两个智能体互相抱怨了一整夜，就因为忘了限制必须被@才能回复。
别让你的智能体聊一整夜
让智能体之间直接对话听起来很酷，但有个巨大的风险：它们会陷入无限循环。有用户就分享过，早上醒来发现自己的两个智能体互相抱怨了一整夜，就因为忘了设置必须提到我才回复的规则。
所以，在设置智能体对话时，必须启用强制提及模式。也就是说，如果A智能体发的消息里没有@B智能体，B就根本不搭理它。这就好比在群里说话不@别人，别人就当没看见，能有效避免浪费钱的死循环。
高级玩家还开发了共享内存和上下文总线。有人搞了一个A2A上下文总线插件，智能体往总线上发更新，其他智能体订阅并拉取相关内容。还有人用看板评论做智能体间的通信协议，每个评论都让下一位接手的智能体看到。
text
- A2A Context Bus: A message-passing system where agents publish context updates to a shared bus
- Shared Kanban board with comments: Agents use Kanban comments as an inter-agent protocol
- Honcho memory + profiles: Profile clones automatically create dedicated AI peers sharing the same user workspace
- NAS Shared Log: Uses append-only .log files with fcntl.flock() advisory locking over CIFS/NFS
有人试过用网络共享上的SQLite做跨机器同步，结果失败了。文件锁在网络上只是建议性的，不可靠。用文本日志加正确的锁定才是正道。还有agent-socket.dev这种基于WebSocket的通信服务，可以创建群聊让智能体加入。
社区实战配置参考
最常见的配置是一个总指挥带着一群专家。总指挥负责读宪法和派活，程序员、研究员、个人助理各司其职。
text
┌─────────────┐
│ Orchestrator │ (default profile)
│ (FRIDAY) │ Reads constitution, routes tasks
└──────┬──────┘
┌─────────────┼─────────────┐
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ Coder │ │ Researcher│ │ Personal │
│ profile │ │ profile │ │ profile │
└───────────┘ └───────────┘ └───────────┘
每个专家都有自己的性格设定和专属工具集，比如程序员有终端和Git权限，研究员只能上网看文档。
社区大神总结了一个四层扩展模型：
text
Tier Setup When to Use
-------- ------------------------------------------- --------------------------------
Tier 1 One agent, one gateway, delegate_task 保护上下文，不加复杂度
Tier 2 Orchestrator + specialist profiles 多角色，隔离记忆，一个聊天界面
Tier 3 Domain orchestrators with separate bots 不同业务领域(投资/编程/家庭)
Tier 4 Separate instances (same machine or VPS) 客户项目、生产环境、严格隔离
但多数人停在第二层就够了。关键是从单个智能体开始，按需创建。别想一步登天。
第一周就搞两个配置文件，关掉所有不用的技能，先纯聊天。第二周如果发现上下文乱了，再加新的配置文件。有人分享说，Hermes大概需要一周才能真正适应它的角色，急不得。
还有个更邪门的玩法：让你的主智能体去创建专门用来创建其他配置文件的配置文件。这个专家智能体会审查SOUL.md、禁用不相关的工具和技能，帮你把新配置优化到最佳状态。你的智能体在帮你组建智能体团队，这太离谱了。
看板调度器是幕后管家
看板系统背后有个调度器在默默工作。它运行在Hermes网关内部，每隔N秒（默认60秒）扫一次看板。
text
1. Reclaims stale claims (agent died mid-task)
2. Promotes ready tasks (all parent tasks done → promote)
3. Spawns assigned profiles as workers
4. Workers get kanban_* tools to interact with the board
它会回收那些被认领但超时的任务，把依赖全部完成的任务升级为就绪状态，然后启动对应的配置文件来干活。被启动的智能体会获得kanban开头的工具集，用来操作看板。
看板的工作空间有三种类型：
text
Type Use Case Persistence
---------- ------------------------------------------ ----------------
scratch 一次性任务 完成任务即删除
dir: 真实目录中的持续工作 保留
worktree Git工作树，用于编码 保留
你可以给不同的项目创建不同的看板，互不干扰。
bash
hermes kanban boards create project-alpha --name "Project Alpha"
hermes kanban --board project-alpha create "Add payment integration" --assignee coder
记住，看板适合需要持久化和多角色参与的工作，而直接分任务适合一次性的、需要立刻拿到结果的推理任务。比如并行查资料用分任务，但做一个需要审批和反复修改的功能，就必须上看板。
直接分任务的正确用法
官方文档提供了几个典型场景。并行研究可以一次性分三个任务，让三个智能体同时查三个不同方向。
python
delegate_task(tasks=[
{"goal": "Research topic A", "toolsets": ["web"]},
{"goal": "Research topic B", "toolsets": ["web"]},
{"goal": "Research topic C", "toolsets": ["web"]}
])
代码审查可以让一个智能体专门审查某个目录下的安全问题。
python
delegate_task(
goal="Review src/auth/ for security issues",
context="Project at /home/user/webapp. Python 3.11, Flask. Files: src/auth/login.py, src/auth/jwt.py. Test: pytest tests/auth/ -v",
toolsets=["terminal", "file"]
)
做多文件重构时，可以把不同文件分给不同的子智能体。每个子智能体有独立的终端会话。但要小心，别让两个子智能体同时修改同一个文件。
正确的做法是先用execute_code这种便宜的工具收集数据，最后再用一次分任务做昂贵的推理分析。
这里有个致命问题：子智能体对你之前的对话一无所知。所以你必须在分任务时把所有上下文都写清楚，比如完整的文件路径、具体的报错信息、以及你需要它遵守的约束条件。别指望它能猜到你指的是哪个文件。
常见错误与解决方案
最大的误解就是配置文件等于沙箱。错了，它只是隔离了AI的状态，没隔离你的文件。解决办法是用Docker，或者在配置里开启terminal.home_mode: profile，让每个配置有自己的独立主目录去放SSH和Git配置。
智能体互相聊天聊死机也很常见。一定要在配置文件里开启硬停止。
yaml
tool_loop_guardrails.hard_stop_enabled: true
hard_stop_after.exact_failure: 5
同时看板也要设置失败限制，防止智能体在一个坏掉的任务上反复折腾。
yaml
kanban.failure_limit: 3
还有就是千万别让两个配置文件用同一个机器人令牌，否则第二个网关启动时会报错。检查每个配置文件目录下的.env文件。
修改SOUL.md只对新会话生效。如果你在对话中途改了性格设定，智能体不会立刻变，得输入/new命令重置会话才行。最后，terminal.cwd设置的工作目录和HERMES_HOME这个配置文件主目录是两码事，别搞混了。
常见疑问解答
问：工作和个人智能体怎么分开？答：建两个配置文件，给它们各自的机器人令牌。或者用Telegram话题功能，用同一个令牌路由到不同配置。
问：智能体能直接聊天吗？答：不能直接像群聊那样内置支持。最接近的方案是用看板评论当传话工具，或者拉个群让它们互相@。直接对话不是内置功能。
问：能用一个机器人服务多个配置吗？答：能，就是Telegram话题。在BotFather里开启话题，然后在网关里配置路由规则。
问：能把任务直接派给另一个配置文件吗？答：目前官方不支持。delegate_task只能创建无名无姓的临时子智能体。至少四个PR请求加了profile参数，但到2026年6月都没合并。你可以用看板，或者用宪法模式手动路由。
问：怎么让智能体共享记忆？答：Honcho记忆提供商会默认共享同一个用户工作区。你也可以用共享的Obsidian笔记库或者直接在文件里传递信息。
问：配置文件不适合做什么？答：不适合做严格的文件系统隔离。要隔离用Docker或虚拟机。
问：智能体协调时卡在循环里怎么办？答：启用硬停止和Kanban失败限制。
终极结论
Hermes的配置文件和看板，本质上就是一个简易的多智能体操作系统。它不是一个带团队模式噱头的聊天机器人，而是真正能让你拥有一个各司其职、记忆独立的AI员工团队的底层框架。
社区已经从玩单个AI进化到玩AI团队了。从总指挥带专家，到智能体自己管理看板，玩法越来越复杂也越来越强大。关键就是先动起来，创建一个新配置，给它写个不同性格，然后连上看板观察。
别担心出错，翻车也是学习的一部分。只要记住核心原则：用配置文件隔离身份，用看板同步任务，用宪法分配职责。你的AI小分队，现在就可以开张了。