哈喽，大家好，我是蝈蝈。 很多人用 Hermes 的方式是一个 Agent 包揽所有事，但用久了会发现一个问题：Agent 的记忆越积越杂，行为越来越难预测。写代码时学到的项目习惯，和写日报时积累的表达偏好，全混在同一个 MEMORY.md 里——导致 Agent 的记忆会变乱。 而 Hermes 里的 Profiles 就是解这个问题的。每个 Profile 是完全隔离的独立环境，有自己的配置、记忆、技能和 Gateway，各自成长，互不干扰。 我自己是用 Profiles 功能在同一台机器上同时跑两个完全独立的 Agent，一个负责每天自动拉数据、整理知识库、推飞书日报，另一个专门做编程任务。 下面我把整个搭建过程完整记录下来，直接可以照着做。
一、架构设计：两个 Profile，各司其职
coder Profile 是我们本次新增的代码任务调度员。它自己不写代码，只负责理解需求、拆解任务、调用本地 CodeX 或 Claude Code 执行，审查结果后汇报。这个设计的逻辑是：CodeX 已经积累了大量专业 coding skill，是真正擅长写代码的工具，Hermes 只需要做好“需求翻译”和“结果审查”就够了。 hermes 就是原来的主 Agent，负责日常的交互，包括获取新增制作每日简报，以及知识库整理。 目前这两个 Profile 职责清晰、互不依赖，所以暂时不需要第三个协调 Profile。等真正出现“coder 完成代码后自动触发 assistant 生成文档”这类流水线需求时再加，现阶段不要过度设计。
二、创建 Coder Profile
hermes profile create coder这一行命令做了两件事：在 ~/.hermes/profiles/coder/ 下创建完整的隔离环境，同时生成 coder 命令别名。从此 coder 等价于 hermes -p coder，所有子命令都可以直接用：
coder setup # 配置 API 密钥和模型
coder chat # 开始对话
coder gateway start # 启动 Gateway模型选择上，coder Profile 的核心工作是任务调度而非代码生成，用轻量模型就够，算力留给 CodeX。
三、用 SOUL.md 定义角色
每个 Profile 的 SOUL.md 是系统 prompt 的第一槽位，决定 Agent 的身份和行为倾向，路径是 ~/.hermes/profiles/coder/SOUL.md。 这里有一个容易混淆的区分：SOUL.md 管“这个 Agent 是谁”，项目根目录的 AGENTS.md 管“在这个项目里做什么”。两个文件职责不同，不要混了。 coder Profile 的 SOUL.md 核心是把“不自己写代码”这个行为倾向写清楚：
# 身份
你是一位代码任务调度专家。你自己不直接编写代码，
而是通过调用 CodeX 或 Claude Code 来完成所有编码工作。
# 工作方式
- 收到需求时，先分析任务类型和复杂度
- 将任务清晰描述后，委派给 CodeX 或 Claude Code 执行
- 审查返回的代码质量，必要时要求修改
- 向用户汇报结果，而不是自己动手写
# 风格
- 简洁直接，像技术项目经理
- 任务拆解精准，指令清晰无歧义
# 避免
- 自己生成大段代码
- 不加审查地直接转发工具返回结果修改完直接 coder chat 开新会话即生效，无需重启任何服务。
四、连通本地 CodeX
hermes 连接本地 codex 的完整调用链如下。 首先要为 codex 开通设备访问的权限，在你的 ChatGPT 里配置“安全”里做开启，如下图： 
然后让你的 coder agent 直接尝试连接你本地的 codex，coder 会给你一个验证码和 OpenAI 的连接入口来做配对，我们点进去连接，然后输入验证码就好。 
配置完成后，在飞书里向 coder Profile 发送一个编程任务，可以看到 Hermes 完整地执行了调度链路：先检查 CodeX 登录状态（codex login status），再通过 codex exec resume 把任务派发出去，等待执行，最后读取配置文件验证结果。 
执行结果显示：CodeX App 里可以看到新建了执行会话，目标任务完成，smoke 验证通过；而 Hermes 全程没有自己生成代码，只做了调度和验证。到此，Hermes 与本地 CodeX 链路打通。 
五、多 Agent 日常管理速查
hermes profile list # 查看所有 Profile 状态
hermes profile show coder # 查看 coder 的详细配置
hermes profile export coder # 导出备份为 coder.tar.gz
hermes profile rename coder dev # 重命名，同步更新别名和服务
hermes update # 更新代码并同步所有 Profile 的内置技能六、下一步
什么时候才真正需要第三个“协调 Profile”？ 目前两个 Profile 是并行独立的关系——你找 coder 就是找 coder，找 assistant 就是找 assistant，它们互不知道对方的存在。这在大多数场景下已经够用了。 但有一类需求会打破这个模式：当一个任务需要多个 Profile 按顺序协作完成的时候。 这种有依赖关系的多角色流水线，才真正需要一个 orchestrator Profile 来统筹调度。 但现阶段不要急着建它。过度设计是 Agent 工作流里最常见的坑——架构搭得很漂亮，实际上每天用到的只有两个 Profile 各自独立跑任务。等你真正感觉到“我需要有人来协调它俩”的那一天，再加这一层，不会太晚。
七、写在最后
今天这套配置走下来，核心的感受是：Hermes 的 Profile 系统本质上是在做“专业化分工”。 一个全能 Agent 听起来很美，但时间久了你会发现，它积累的记忆越来越杂，行为越来越难以预测。Profile 强制你在一开始就想清楚——这个 Agent 是干什么的，它的边界在哪里。 coder 只管调度代码，assistant 只管日常，各自积累各自领域的 skill 和 memory。用得越久，每个 Profile 越“专”，而不是越“乱”。这才是多 Agent 的长处所在。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
相关文章
暂无评论...