1. 为什么单 Agent 写代码越用越乱如果你已经在本地跑 Hermes 一段时间大概率会遇到一个很具体的现象同一个 Agent 上午帮你写 Python 脚本下午帮你整理日报晚上又去改前端组件几天之后它的 MEMORY.md 里塞满了各种项目习惯、表达偏好、临时约定行为开始变得难以预测。你让它写代码它先跟你聊两句日报格式你让它整理文档它又突然想给你补一段测试用例。这不是模型变笨了而是记忆污染。一个 Agent 包揽所有事它的记忆、技能、系统提示全混在一个环境里写代码时学到的项目规范会和写日报时积累的表达偏好互相干扰。用得越久这种干扰越明显。Hermes 的 Profiles 就是解这个问题的。每个 Profile 是一个完全隔离的独立环境有自己的配置、记忆、技能和 Gateway各自成长、互不干扰。你可以把它理解成在同一台机器上开了几个互不串门的工位一个专门做代码调度一个专门做日常事务谁也不会把对方的习惯带进来。这篇要落地的场景是用 Hermes 的 Profiles 编排本地 CodeX搭一个能分工的多 Agent 团队。核心思路是让 Hermes 里的 coder Profile 当技术项目经理它自己不写代码只负责理解需求、拆解任务、调用本地 CodeX 执行、审查结果后汇报。真正写代码的活交给 CodeX因为 CodeX 已经积累了专业的 coding skillHermes 只需要做好需求翻译和结果审查就够了。适合谁看已经在本地用 Hermes 或 CodeX 写代码、想把单机编码助手升级成可分工 Agent 团队的开发者。下面从架构设计到配置骨架、从连通 CodeX 到多 Agent 任务分发一步步给可复制的操作。2. TaoToken 前置统一 Key 与 API 通道在搭多 Agent 之前先把 API 通道这件事理顺。多 Agent 场景下最容易踩的坑是每个 Profile 各自配一套 Key模型来源不统一出了问题不知道是哪个环节断的。我的做法是让所有 Profile 走同一个 API 通道Key 集中管理。TaoToken 在这里的作用是提供统一的 Key 和 API 通道。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 这个不加 UTM。你可以在控制台里创建 Key然后让 Hermes 的每个 Profile 都指向同一个 API 端点。具体操作路径先到控制台创建 API Key地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 。创建完 Key 之后在 API Keys 页面可以查看和管理地址是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。拿到 Key 之后配置 Hermes Profile 的时候把 base_url 指向 TaoToken 的 API 端点模型名按你实际要用的填。这样 coder Profile 和 assistant Profile 共用同一个通道Key 只需要维护一份换模型或者调额度的时候改一处就行。注意多 Agent 场景下建议给不同 Profile 用不同的模型档位。coder Profile 的核心工作是任务调度和结果审查不是代码生成用轻量模型就够把算力留给真正执行编码的 CodeX。assistant Profile 处理日常事务也可以用轻量档。这样整体成本可控。如果你还想在接入前先验证模型通道是否通可以直接用模型对话页面测一下地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。发一条简单请求确认返回正常再去配 Profile能省掉后面排查到底是 Key 问题还是 Profile 配置问题的时间。3. 可复制配置Profiles 骨架与 SOUL.md3.1 创建 Coder Profile第一步是创建独立的 coder Profile。在终端执行hermes profile create coder这一行命令做了两件事在~/.hermes/profiles/coder/下创建完整的隔离环境同时生成coder命令别名。从此coder等价于hermes -p coder所有子命令都可以直接用coder setup # 配置 API 密钥和模型 coder chat # 开始对话 coder gateway start # 启动 Gateway创建完之后先跑coder setup把 API Key 和模型配好。base_url 填 TaoToken 的 API 端点Key 填你在控制台创建的那一个。模型选轻量档原因上面说过调度和审查不需要重模型。3.2 用 SOUL.md 定义角色边界每个 Profile 的SOUL.md是系统 prompt 的第一槽位决定 Agent 的身份和行为倾向路径是~/.hermes/profiles/coder/SOUL.md这里有一个容易混淆的区分SOUL.md 管这个 Agent 是谁项目根目录的 AGENTS.md 管在这个项目里做什么。两个文件职责不同不要混。SOUL.md 是 Profile 级别的跟着 Agent 走AGENTS.md 是项目级别的跟着仓库走。coder Profile 的 SOUL.md 核心是把不自己写代码这个行为倾向写清楚。下面是我实际用的骨架# 身份 你是一位代码任务调度专家。你自己不直接编写代码 而是通过调用 CodeX 或 Claude Code 来完成所有编码工作。 # 工作方式 - 收到需求时先分析任务类型和复杂度 - 将任务清晰描述后委派给 CodeX 或 Claude Code 执行 - 审查返回的代码质量必要时要求修改 - 向用户汇报结果而不是自己动手写 # 风格 - 简洁直接像技术项目经理 - 任务拆解精准指令清晰无歧义 # 避免 - 自己生成大段代码 - 不加审查地直接转发工具返回结果修改完直接coder chat开新会话即生效无需重启任何服务。这一点很关键SOUL.md 是会话启动时读取的改完开新会话就行不用去折腾服务重启。3.3 多 Agent 的目录结构搭好之后你的~/.hermes/profiles/下大概是这样~/.hermes/profiles/ ├── coder/ │ ├── SOUL.md # 代码调度专家身份 │ ├── MEMORY.md # 只积累代码调度相关记忆 │ ├── config.yaml # API Key / 模型配置 │ └── skills/ # 代码调度相关技能 └── assistant/ ├── SOUL.md # 日常事务身份 ├── MEMORY.md # 只积累日常事务记忆 ├── config.yaml # 共用同一个 API 通道 └── skills/ # 日常事务技能两个 Profile 各自有独立的 MEMORY.md这是隔离的核心。coder 的记忆里只有代码任务拆解、CodeX 调用记录、审查结论assistant 的记忆里只有日常事务。它们不会互相污染。4. 连通本地 CodeX 与验证请求4.1 打通调用链Hermes 连接本地 CodeX 的完整调用链是这样的coder Profile 收到编程任务 → 检查 CodeX 登录状态 → 通过codex exec resume派发任务 → 等待执行 → 读取结果验证 → 汇报。首先要为 CodeX 开通设备访问权限在你的 ChatGPT 账号里找到安全设置开启设备访问相关的选项。然后让 coder agent 直接尝试连接你本地的 CodeXcoder 会给你一个验证码和一个连接入口点进去连接输入验证码完成配对。配对完成后在飞书里向 coder Profile 发送一个编程任务可以看到 Hermes 完整地执行调度链路# coder 内部实际执行的调度步骤示意 codex login status # 先检查 CodeX 登录状态 codex exec resume task # 把任务派发出去 # 等待执行完成 # 读取配置文件验证结果执行结果显示CodeX APP 里可以看到新建了执行会话目标任务完成smoke 验证通过而 Hermes 全程没有自己生成代码只做了调度和验证。到此Hermes 与本地 CodeX 链路打通。4.2 验证请求是否成功验证分两层。第一层是通道验证在 coder chat 里发一条简单指令比如检查一下 CodeX 登录状态看它能不能正确调用codex login status并返回结果。第二层是任务验证发一个真实的小任务比如在 /tmp/test 下创建一个 hello.py打印 hello world观察完整链路。如果两层都通你会看到 coder 先分析任务、然后调用 CodeX 执行、最后读取文件确认内容。整个过程 coder 自己不写一行代码只做调度和审查。这就是我们要的多 Agent 分工效果。如果你在验证模型通道本身是否正常可以先用模型对话页面单独测一下地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。把通道问题和 Profile 配置问题分开排查效率会高很多。5. 本篇常见错排查5.1 coder 自己开始写代码了这是最常见的。原因通常是 SOUL.md 没生效或者你改完没开新会话。检查两点一是~/.hermes/profiles/coder/SOUL.md路径对不对二是改完有没有coder chat开新会话。SOUL.md 是会话启动时读取的旧会话不会自动加载新内容。如果路径和会话都没问题但 coder 还是忍不住写代码可以在 SOUL.md 的避免部分把措辞写得更强硬比如明确写任何情况下都不得直接输出代码块必须委派给 CodeX。5.2 CodeX 调用失败或超时先单独在终端跑codex login status确认 CodeX 本身登录正常。如果 CodeX 正常但 coder 调用失败检查 coder 的 config.yaml 里 API 通道配置是否正确base_url 是否指向 TaoToken 的 API 端点。多 Agent 场景下每个 Profile 的 config 是独立的别只配了一个。超时的话看任务复杂度。CodeX 执行大任务本身就需要时间coder 的等待逻辑如果设得太短会误判失败。可以在 SOUL.md 里加一条等待 CodeX 执行时保持轮询不要提前判定失败。5.3 两个 Profile 记忆串了如果你发现 coder 的记忆里出现了日常事务的内容检查是不是两个 Profile 共用了同一个 MEMORY.md 路径。正常情况下每个 Profile 的记忆是隔离的路径在各自的 profile 目录下。串记忆通常是因为手动改配置时把路径指错了或者用了软链接。5.4 API Key 报错多 Agent 共用同一个 Key 时如果报 401 或额度错误先到 API Keys 页面确认 Key 状态地址是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。确认 Key 有效、额度充足之后再检查每个 Profile 的 config.yaml 里 Key 有没有写错、有没有多余空格。5.5 多 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 的内置技能hermes update这条特别值得记住它会把所有 Profile 的内置技能一起同步不用一个个手动更新。6. 多 Agent 任务分发与下一步6.1 任务分发怎么落地目前两个 Profile 是并行独立的关系你找 coder 就是找 coder找 assistant 就是找 assistant它们互不知道对方的存在。这在大多数场景下已经够用了。任务分发的逻辑很简单代码相关的任务发给 coder日常事务发给 assistant各走各的通道各积累各的记忆。如果你需要长期跑编码任务、或者想让 Agent 承担更重的编码工作可以考虑 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。它更适合持续性的编码场景和 coder Profile 的调度角色配合起来能把单机编码助手的产出稳定在一个比较高的水平。6.2 什么时候才需要第三个协调 Profile有一类需求会打破并行独立的模式当一个任务需要多个 Profile 按顺序协作完成的时候。比如coder 完成代码后自动触发 assistant 生成文档这种有依赖关系的流水线才真正需要一个 orchestrator Profile 来统筹调度。但现阶段不要急着建它。过度设计是 Agent 工作流里最常见的坑架构搭得很漂亮实际上每天用到的只有两个 Profile 各自独立跑任务。等你真正感觉到我需要有人来协调它俩的那一天再加这一层不会太晚。6.3 接入文档与后续如果你在接入过程中遇到配置层面的问题接入文档里有更细的参数说明地址是 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。Claude Code 相关的接入细节可以看 https://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecode-anthropicutm_campaignrewrite 。这套配置走下来核心感受是Hermes 的 Profile 系统本质上是在做专业化分工。一个全能 Agent 听起来很美但时间久了记忆越来越杂行为越来越难预测。Profile 强制你在一开始就想清楚这个 Agent 是干什么的、边界在哪里。coder 只管调度代码assistant 只管日常各自积累各自领域的 skill 和 memory。用得越久每个 Profile 越专而不是越乱。这才是多 Agent 真正的长处所在。