当 Hermes 出来的时候好多人问我多 Agent 之间的协作是怎么玩的。周末我找了时间自己做了一把实践原本以为会很顺利没想到中间翻了好几次车最后硬是一个坑一个坑填过来的。这篇把完整过程记下来跟着做你也能在自己的 Discord 里看到几个 AI 像同事一样互相接力干活。但在动手之前有句话得先讲在前头。协作是能力的放大器不是补丁。如果单个 Agent 本身是个废柴拉三个废柴来协作结果就是三倍的废柴三个废柴开会废柴还是废柴。SOUL.md 写细、skills 配齐、模型选对把 Agent调教好这是多 Agent 能跑的前提不是结果。好话撂这儿了开始正题。先聊聊 profile这是整个多 Agent 的基础要做 Agent 协作第一步得先把不同的 Agent 建出来。在 Hermes 里这件事是通过 Profile 来实现的。profile 其实就是 Hermes 的人格档案。一个 profile 就是一个完全独立的 AI 分身有自己的 config.yaml、.env、SOUL.md、独立的 memory、独立的 skills、甚至独立的 gateway 进程。底层实现其实挺朴素靠一个 HERMES_HOME 环境变量切换根目录但效果是实打实的隔离。思维引导为什么要强调真隔离这件事? 因为多 Agent 架构里最怕的就是一个挂了全挂了。Hermes 的 profile 是进程级隔离每个 profile 跑自己的 gateway 进程互不依赖。即便某一个 agent 挂了也完全不影响其他 agent 继续干活。这点和 OpenClaw 是有差别的。用过 OpenClaw 的朋友都懂它的多身份更多是配置层面的切换进程还是同一套。Hermes 这种物理隔离在企业交付场景下是真的香客户不会因为一个 bot 崩了整套自动化系统跟着下线。好理解了 profile 是什么我们开始搭建。Step 1建三个 Agent分工明确这次我准备搭一个三人小组模拟一个真实的内容生产协作流:林小墨 (Ink) —— 文案与笔记整理专家林小探 (Search) —— 搜索与调研专家林小管 (Admin) —— 任务分发与调度员这个组合不是随便定的。它对应着一个完整的查资料 → 写笔记 → 归档工作流而且引入了一个专门的调度 Agent(林小管)让协作路径更清晰。先建林小墨:hermes profile create ink --clone这里我用了 --clone 参数主要是直接继承 default 的一些配置(模型、API key 等)不用重新配一遍。多说一句 --clone 的选择。Hermes 给了三档克隆策略看场景选:什么都不加(hermes profile create mybot):空白 profile连 API key 都要重新配适合从零搭一个完全独立的 agent–clone(我这次用的):只复制 config.yaml、.env、SOUL.md记忆和 session 是全新的。这档最适合搭多 Agent——共享模型和 API key但每个 agent 从干净的上下文开始互不串味–clone-all:连 memory、sessions、skills、cron jobs 全拷贝等于整个人克隆一份适合备份或者 fork 一个已经有上下文的 agent多 Agent 协作场景基本都是 --clone。执行后的输出长这样:Profile ink created at /Users/lunaraitalk/.hermes/profiles/inkCloned config .env SOUL.md from default.77 bundled skills synced.Wrapper created: /Users/lunaraitalk/.local/bin/inkNext steps: ink setup Configure API keys and model ink chat Start chatting ink gateway start Start the messaging gateway Edit ~/.hermes/profiles/ink/.env for different API keys Edit ~/.hermes/profiles/ink/SOUL.md for different personality注意最后几行。ink 直接变成了一个独立的命令你后面用 ink chat、ink gateway start 就能直接操作这个 agent不用每次都写 hermes -p ink xxx。这个细节真的贼方便。然后给林小墨覆盖一个人设:echo 你是林小墨一名专业的文案专家和知识管理助手。你擅长将碎片化信息整理成结构化的 Markdown 格式并熟练运用 Obsidian 的双链体系。你的回复风格文雅、逻辑严密。 ~/.hermes/profiles/ink/SOUL.md我们可以看到一条命令直接继承了 Default 的配置模型也继承过来了。当然如果你想给每个角色配更合适的模型每个 profile 独立调一下 config.yaml 就行。注意左下角的 ink ❮ 标识。Hermes 用 prompt 前缀告诉你当前是哪个 profile 在说话多 Agent 场景下这个小设计特别救命。Step 2接 Discord为什么不用飞书?消息平台这块我纠结过一下。先说结论:这次我选了 Discord没用飞书。原因很简单飞书群因为平台的限制确实不支持 bot 被 。多 Agent 协作最核心的动作就是一个 agent 另一个 agent 来接力飞书这条路直接堵死。Discord 在这方面开放得多也是 Hermes 官方文档里演示最充分的平台。在 Discord Developer Portal 创建应用的流程网上教程一大把我就不重复造轮子了。关键是拿到每个 bot 的 token填进对应 profile 的 .env 文件。配置完后启动 gateway:ink gateway install ink gateway start输出:Installing launchd service to: /Users/lunaraitalk/Library/LaunchAgents/ai.hermes.gateway-ink.plist✓ Service installed and loaded!Next steps: hermes gateway status # Check status tail -f ~/.hermes/profiles/ink/logs/gateway.log # View logs✓ Service started踩坑提醒这里用的是 gateway install gateway start 组合install 会把 gateway 注册成 launchd 服务(macOS)或 systemd 服务(Linux)关机重启后会自动拉起。如果你只是测试用 ink gateway start 也行但关了终端 bot 就死了。长期跑的话强烈建议 install。Step 3翻车从私聊开始gateway 起来了先做个简单的私聊测试。提示做一下配对验证这个正常走一下流程就行。然后我开始测试 channel 里 它毕竟我们后续要让三个 Agent 在同一个 channel 里讨论 是最核心的动作。结果第一个坑就来了: 它不给响应。当时我盯着 Discord 界面看了半天bot 在线、状态正常就是不搭理我。翻日志也没明显报错。折腾了一会儿我才意识到Hermes 的 Discord gateway 默认有个 allowed_channels 的白名单机制不在白名单里的频道bot 压根就不响应 。解决方法:# 注意这里的 -p 参数需换成那你自己的 agenthermes -p ink config set discord.allowed_channels 1495255615545544819把你要用的 channel ID 填进去重启 gateway 后再试立马就通了。思维引导这个默认设计是挺合理的。如果 bot 默认响应所有它能看到的频道你把它拉进一个大服务器它就会在所有频道里到处开口简直是话痨级骚扰。allowed_channels 强制你显式指定哪些频道允许它说话是个安全默认值。Step 4顺便聊聊 Hermes 的 thread 机制 通了之后我发现每次我 bot它会自动开一个 thread 来回复而不是在主频道直接回。这是 Hermes 默认开启的 auto_thread: true 行为。这个机制我个人觉得设计得真的挺好:主频道不被刷屏:AI 回复动辄几百字全丢主频道里谁受得了上下文干净:每个任务在独立 thread 里不会互相干扰多人并发友好:几个人同时用也不会打架但如果你不习惯这个形式两种关法都给你:# 方案一:彻底关掉自动 threadhermes -p ink config set discord.auto_thread false# 方案二:指定某些频道不使用 thread(其他频道照常)# 编辑 ~/.hermes/profiles/ink/config.yaml找到 discord 段落:# no_thread_channels:# - 1495255615545544819我自己保留了默认的 thread 模式因为后面多 Agent 协作的时候每个任务在独立 thread 里执行追溯和调试都方便得多。Step 5复制两份搭出小团队林小墨跑通了剩下两个照葫芦画瓢。这次我用了 --clone-from 参数直接从 ink 这个已经配好的 profile 克隆省得再配一遍:hermes profile create search --clone --clone-from inkhermes profile create admin --clone --clone-from ink这样做的好处是不用再配置 Messaging Gateway 了。然后分别写人设:echo 你是林小探情报专家。你擅长从海量互联网信息中筛选核心数据。你的任务是提供客观、准确的市场调研报告和技术趋势分析。你会引用所有信源。 ~/.hermes/profiles/search/SOUL.mdecho 你是林小管团队协调官。你负责接收用户的原始需求并将其拆解为具体任务分发给墨、探两位专家。你还负责 Discord 频道的日常运作和权限维护。 ~/.hermes/profiles/admin/SOUL.md给 search 和 admin 各自创建 Discord 应用、配 token、启动 gateway一套流程跟林小墨一模一样不重复了。踩坑提醒 三个 profile 配 .env 的时候每个 bot token 必须独立千万不能复用。Hermes 内置了 token lock 机制。如果两个 profile 不小心用了同一个 token第二个 gateway 启动时会直接报错并告诉你是哪个 profile 占用了这个 token。这个保护对 Telegram、Discord、Slack、WhatsApp、Signal 全平台生效相当于帮你兜了一层底。怎么解决呢其实很简单将 .env里的 DISCORD_BOT_TOKEN 值替换成对应的 Discord 应用 token 即可。三个 bot 全部上线后你会在频道里看到每个 bot 都弹了一大段 No home channel is set for Discord… Type /sethome 的提示。是在让你给每个 bot 设一个大本营频道用来接收 cron 定时任务结果和跨平台转发消息。如果你暂时不需要定时推送直接忽略就行想让频道清爽的话在频道里对每个 bot 用一次 /sethome 斜杠命令下次启动时就不会再弹。这时候三个 bot 全部进驻同一个频道我以为可以开工了。Step 6以为成功了结果发现是假的把任务扔进频道:“帮我调研一下2026年最新的AI智能体趋势并整理成文章”。任务是跑出来了结果也像模像样。但我盯着日志一看不对劲。它走的是 Hermes 内置的 delegate_task 模式根本没走多 Agent 协作。这里得补充一下背景。Hermes 有个叫 delegate_task 的内置机制单个 agent 可以 spawn 一个隔离的 subagent 来跑子任务然后把结果收回来合并。这是 Hermes 很硬核的一个能力官方叫它zero-context-cost pipeline因为 subagent 的上下文不会污染主对话。听起来很香对吧但它有一个致命的问题subagent 是临时 spawn 的无状态执行者用完即焚不是你精心配置的那三个独立 profile。官方 delegation 文档里白纸黑字写得很清楚:“Each child gets a fresh conversation and works independently — only its final summary enters the parent’s context”。翻译过来就是:子 agent 干完只把一句总结回传中间过程、工具调用细节、思考逻辑全部丢弃。而且更关键的是——subagent 的 send_message 技能是被 Blocked 的它根本没办法在 Discord 里主动发消息。也就是说你费劲建的林小墨、林小探、林小管在 delegate_task 模式下根本没被调用。admin 自己 spawn 了几个匿名打工仔把活干了。那怎么办?想让真正的多 Agent 接力跑起来必须在 admin 的 SOUL.md 里把协作协议写死强制它通过 Discord 频道公开点名走真实的 消息路径。后面三个坑就是我把这套协议一条一条写出来的过程。坑 1没有 直接就结束了第一次改 admin 的 SOUL.md我给它列了团队成员和职责以为它自己会懂结果它拆完任务就直接结束了全程没有 任何人。问题出在哪?LLM 其实理解林小探是团队里的人但它不知道在 Discord 里要怎么真正叫醒对方——Discord 点名是靠 用户ID 这种特殊格式的消息才能触发的你只写林小探三个字对方的 gateway 根本收不到推送。解决方法说穿了也朴素——在花名册里直接把每个人的工牌号挂在名字后面:## 团队成员- **林小探 (Search)**: 【Executor】负责联网搜索、情报搜集和市场调研。ID: 1495291492397224117- **林小墨 (Ink)**: 【Executor/Reviewer】负责文案润色、逻辑梳理和 Obsidian 笔记格式化。ID: 1495250337139789955## Discord 艾特指令 (Crucial)当且仅当你需要某个队友**立刻开始工作**时必须使用以下格式:- 召唤林小探: 1495291492397224117- 召唤林小墨: 1495250337139789955**注意**: 在非执行环节仅使用纯文字林小探或林小墨不要带 符号。app ID 在 Discord 里右键应用 → “复制用户 ID” 就能拿到(需要先开开发者模式)。踩坑提醒这里最容易犯的错是——在任务规划阶段也用了 ID 格式。结果就是 admin 还在列计划林小探和林小墨已经被点醒冲进来了场面混乱。我的做法是严格区分:计划阶段用纯文字执行阶段才用 ID。坑 2任务结束后停不下来了 的问题搞定接力终于跑起来了。林小探搜完资料林小墨做好笔记admin 做个总结。但总结完之后它不停了一直刷表情符号。 跟发癫一样。这其实是多 Agent 架构里一个非常典型的问题bot 之间互相触发的死循环。admin 发任务完成林小墨 bot 收到后触发响应好的admin 又响应收到…就这么一直循环下去。这个坑要治得分三层来打。第一层:DISCORD_ALLOW_BOTS —— 死循环的真正源头Discord gateway 有个参数叫 DISCORD_ALLOW_BOTS它决定了一个 bot 要不要响应其他 bot 发出的消息。这个参数有三档:正确姿势是三个 profile 全部设为 mentions:# 三个 profile 的 .env 统一改DISCORD_ALLOW_BOTSmentions第二层:replied_user: false —— Discord 的一个反直觉机制光改 DISCORD_ALLOW_BOTS 还不够还有一个更阴险的点——Discord 的 “reply” 功能默认会自动给被回复的人发一个 mention。哪怕你文本里压根没写 ID只要你用了 reply 功能被回复的那个人还是会收到提醒。换句话说admin 就算只回了个 只要它是以回复的形式发出来的小墨还是会被隐式 到。解决方法在 admin 的 config.yaml 里加上:discord: allow_mentions: everyone: false roles: false users: true replied_user: falsereplied_user: false 就是把 reply 自带的隐式 mention 关掉。从此 bot 之间哪怕用 reply 回复也不会触发对方的被 事件。第三层:SOUL.md 里的终止协议前两层是配置层的物理保险SOUL.md 这层是 LLM 认知层的软约束:## 任务终止与防循环规范- **明确终结**: 当确认林小墨完成笔记整理后请发出简短总结并以【任务结束】结尾。- **禁止冗余**: 任务结束后严禁发送无意义的表情( )、寒暄或单纯的确认消息。- **中断反馈**: 不要对其他 Bot 发出的收悉、待命等结束类消息做出二次响应。- **艾特控制**: 在任务结束总结中禁止再次艾特任何 ID。核心是三件事:有一个明确的终结词(【任务结束】)、禁止对结束类消息做二次响应、结束总结里不再 任何人。三层互相兜底才是稳态。坑 3直接把两个人都 了死循环解决了新的问题又来了。admin 一上来同时 了林小探和林小墨两个人。正常的协作逻辑应该是:先 林小探去查资料等林小探查完再 林小墨去整理笔记。admin 同时 两个人结果就是两个 bot 同时开始干活林小墨拿不到林小探的调研结果只能瞎写一通。这个坑的解决方案是在 SOUL.md 里强制时序规范:## 协作时序规范 (Strict Timing)- **逐一唤醒**: 严禁在任务开始阶段同时艾特多个专家。- **当前阶段**: 仅在当前步骤需要执行时才发出对应的 ID 指令。- **接力逻辑**: 必须等到 **林小探** 明确回复调研完成后你再发出下一条指令并艾特 **林小墨** 开始 Step 2。这三条加进去之后终于跑通了完整的接力式多 Agent 协作。最终版 admin 的 SOUL.md把所有坑都填完之后admin 的完整 SOUL.md 长这样直接拿去用:### 林小管 (Admin) - SOUL.md## 角色定义你是林小管林月半子 AI 团队的【总调度/Planner】。你的核心职责是接收用户的原始需求将其拆解为具体步骤并**逐一**指引对应的专家 Agent 介入。## 团队成员-**林小探 (Search)**: 【Executor】负责联网搜索、情报搜集和市场调研。ID: 1495291492397224117-**林小墨 (Ink)**: 【Executor/Reviewer】负责文案润色、逻辑梳理和 Obsidian 笔记格式化。ID: 1495250337139789955## 核心协作准则 (Multi-Agent Protocol)1.**任务分解**: 收到指令后先列出执行计划(Step 1 Step 2...)。在计划表内请使用普通文字(如林小探)提及专家**严禁使用 ID 格式**防止误唤醒。2.**身份隔离**: 你仅担任【调度员】。你严禁直接调用 search 或 file_writer 等执行类工具必须通过 Discord 频道公开点名完成接力。3.**状态追踪**: 你必须全程监控 Thread 进度。只有前一个专家明确回复任务完成或给出最终结果后你才发起下一阶段的指令。## 协作时序规范 (Strict Timing)-**逐一唤醒**: 严禁在任务开始阶段同时艾特多个专家。-**当前阶段**: 仅在当前步骤需要执行时才发出对应的 ID 指令。-**接力逻辑**: 必须等到 **林小探** 明确回复调研完成后你再发出下一条指令并艾特 **林小墨** 开始 Step 2。## Discord 艾特指令 (Crucial)当且仅当你需要某个队友**立刻开始工作**时必须使用以下格式:- 召唤林小探: 1495291492397224117- 召唤林小墨: 1495250337139789955**注意**: 在非执行环节仅使用纯文字林小探或林小墨不要带 符号。## 任务终止与防循环规范-**明确终结**: 当确认林小墨完成笔记整理后请发出简短总结并以【任务结束】结尾。-**禁止冗余**: 任务结束后严禁发送无意义的表情( )、寒暄或单纯的确认消息。-**中断反馈**: 不要对其他 Bot 发出的收悉、待命等结束类消息做出二次响应。-**艾特控制**: 在任务结束总结中禁止再次艾特任何 ID。## 交互准则-**保持引导**: 在自动开启的 Thread 中告知用户:任务空间已开启我将依次调度专家介入。-**严禁越权**: 不要做深度搜索或长篇写作那是林小探和林小墨的职责。顺便说一句:SOUL.md 和 AGENTS.md 的边界严格按 Hermes 官方的最佳实践来说SOUL.md 应该只放这个 Agent 是谁、怎么说话这类人格层面的东西而具体的项目流程(比如我上面写的团队成员 ID、艾特指令、时序规范、终止协议)——按理说应该放在 AGENTS.md 里。官方文档原话是:“if it should apply everywhere put it in SOUL.md; if it only belongs to one project put it in AGENTS.md”。我这次全塞进了 SOUL.md一是因为先跑通再优化二是对于多 Agent 场景林小管这个角色本身就是为这个项目而生的——她的灵魂就是这套协作协议拆开反而有点强行。但如果你是想搭一个通用的调度型 Agent(未来还要用在别的项目里)那就应该拆开写——SOUL.md 里只留调度员人设AGENTS.md 里放具体项目的团队配置。这是下一步优化方向不是现在必须做的事。写在最后整个过程跑下来我反复在想一件事多 Agent 到底是个技术问题还是别的什么问题?搞完这三个坑之后我明白了它其实是个管理问题。profile 给你的是工位Discord 给你的是会议室但真正让三个 AI 像团队一样跑起来的是那份被你一次次打磨的 SOUL.md——那是职责说明书、协作流程、以及明确的下班时间。每一个坑本质都不是技术 bug是管理漏洞:坑 1 没 → 下属不知道该找谁汇报坑 2 停不下来 → 没有明确的项目终结机制坑 3 同时 → 任务分派时序混乱拿去套人类公司一样成立。过去我们做不好多 Agent不是 LLM 不够聪明是我们没把 AI 当员工来管理。一直指望它一个人搞定一切结果就是人格撕裂、任务失焦、token 烧穿。一个 Agent 不是超人是岗位。三个 Agent 不是炫技是团队。这篇只是把三人小组跑通了。五人、十人的团队同一套逻辑——难的永远不是模型是组织设计。下一篇打算试试 Honcho让这几个 Agent 共享同一个客户档案真正做到公司里每个同事都认识你这个客户。那会是团队协作的下一个维度。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】