终极 Hermes 指南:构建 30 天后仍保持高内聚的多代理团队 ✍ Nyk🕐 2026-04-16📦 13.4 KB 🟢 已读 𝕏 文章列表 本文是一篇关于 Hermes 多代理系统的深度操作指南。作者指出,单个代理承担多种角色会导致声音模糊和上下文污染,而简单的角色划分也难以维持长期的一致性。文章提出了基于“隔离配置文件”的解决方案,详细介绍了构建包含编排者、研究员、作家和工程师的四人团队步骤。重点阐述了通过“交接契约”、内存 KPI 审计和策略门禁来建立“操作员层”,确保团队在运行 30 天后依然保持专业分工和清晰边界,避免多代理系统退化为单一混乱体。 多智能体HermesAgent系统架构LLM提示词工程工作流自动化团队协作AI运营 # The Ultimate Hermes Guide - from one agent to a 4-profile team that still feels coherent on day 30 **作者**: Nyk **日期**: 2026-04-15T17:46:34.000Z **来源**: [https://x.com/nyk_builderz/status/2044472463279710344](https://x.com/nyk_builderz/status/2044472463279710344) ---  I ran one hermes agent as researcher, writer, coder, and orchestrator for 14 days on a single claude-sonnet-4.6 profile before everything blurred into the same voice. Most operators blame the prompt when this happens, but it is not prompting and not the model - it is one agent carrying five roles on shared memory, and everyone says "better prompts" while nobody talks about the Hermes primitive that actually fixes it: isolated profiles. @neoaiforecast posted the team build last week: orchestrator + alan + mira + turing, four roles, clean handoffs, 1,317 bookmarks in a day. The build is correct, but it stops at day one. This guide picks up at day two and takes you through the operator layer that keeps a 4-profile team coherent on day 30 -handoff contracts, memory-kpi per profile, policy gates per role, and the four failure modes nobody posts screenshots of. If you ignore the operator layer, your team collapses into a single blurry agent within a month. Below: the mental model, the 4-role team, the 7-step build, the operator runbook, the day-30 failures, and a copy-paste team-agents.md template. Save this to your bookmarks. ## The mental model — roles, not personas The wrong mental model is: I need one genius AI that does everything. The better mental model is: I need a small team with distinct roles, clear handoffs, and less context pollution. Hermes profiles are the primitive that makes this real. They are not character skins. Each profile isolates seven pieces of state at once: - configuration - sessions - memory - skills - personality - cron state - gateway state That matters because multi-agent setups fail when everything shares the same memory and tone. Your coding agent should not inherit the defaults of your research agent. The research agent should not carry the writer's stylistic habits. Specialization becomes durable only when the state remains separated. ## The 4-role team Credit to @neoaiforecast for naming the canonical split. Four profiles, mapped to real functional work: - Hermes — orchestrator. plans, decomposes, routes, synthesizes. the traffic controller, not the bottleneck. - Alan — research specialist. source-first, skeptical, uncertainty-aware. protects the team from hallucinated confidence. - Mira — narrative architect. clarity, structure, and audience awareness. turns validated material into communication. - Turing — builder and debugger. implementation, logs, diffs, reproducibility. cares about tests, not narrative polish. This split works because it mirrors real work. The orchestrator never has to be a good writer. The writer never has to debug. The engineer never has to convince anyone. Each role gets cleaner every week because its memory stays on-topic. ## The 7-step build The table-stakes sequence. If you have already run this from @neoaiforecast's post, skip to the operator layer. Step 1 - start from a working Hermes Make sure your base Hermes installation is healthy before cloning. Model provider configured, auth working, normal session usable. You clone from this base, so anything broken here breaks four times. Step 2 - create the specialist profiles --clone copies config.yaml, .env, and SOUL.md from your working base. Each new profile still gets its own isolated memory and session history. Step 3 - verify on disk and in the CLI You should see alan/, mira/, turing/ under ~/.hermes/profiles/. Your main Hermes stays the orchestrator. Step 4 - write a real SOUL.md per role This is the step that turns profiles into agents. Edit each SOUL.md to carry a durable identity: tone, default behavior, strengths, priorities, and what the agent must avoid. A strong split: - Hermes (orchestrator): planning, delegation, synthesis, final qa. sounds structured and decisive. - Alan (research): evidence, verification, depth, uncertainty. sounds source-first and skeptical. - Mira (writer): clarity, structure, audience. sounds clear and audience-aware. - Turing (engineer): implementation, debugging, tests, reproducibility. sounds precise and test-oriented. If you only change the name and not the SOUL.md, you do not have a team -you have four clones with labels. Step 5 — keep project context in AGENTS.md, not SOUL.md SOUL.md defines who the agent is. AGENTS.md defines what project it is working on right now. Never mix the two. Project-specific context lives in AGENTS.md: repo structure, coding conventions, workflow rules, and current priorities. Identity stays stable; project context rotates. Step 6 - add a team reference file One shared file that documents the roster and how profiles hand off to each other. template at the bottom of this guide. Step 7 — run profiles separately Each runs in an isolated state. Alan does not inherit Mira's drafts. Turing does not inherit Alan's research sessions. The benefit only shows up if you actually use them separately. ## The operator layer - what Neo's guide stops at This is where the guide stops being a setup post and starts being an ops runbook. Most multi-agent teams look great on day one and feel blurry by day 30. The operator layer is the difference. handoff contracts between profiles profiles specialize, which means they also have to hand work off cleanly. A handoff without a contract becomes "Alan dumped 40kb of raw research into Mira's session, and now Mira is also a researcher again." A handoff contract is one file per role pair, stored at with four fields: - Input shape: what the receiving profile expects (e.g., Alan → Mira: A ranked list of validated claims with source URLs, not raw excerpts) - Output shape: what the receiving profile will return (Mira → Hermes: A drafted section with a change log, not a finished article) - Failure action: what happens if the input is malformed (block, require-human-review, retry with adjusted prompt) - Verification gate: one assertion that must be true before the handoff completes (for Alan → Mira: every claim carries a source URL; for Turing → Hermes: every fix has a passing test) With handoff contracts, you can watch the boundary and see when it rots. Without them, specialization dissolves in two weeks. memory-kpi per profile Hermes profiles isolate memory, which is necessary but not sufficient. Memory rots inside each profile the same way a single wiki rots past 100 pages. Alan's research notes go stale. Mira's draft fragments pile up. Turing's debugging sessions accumulate dead branches. Run a weekly memory audit per profile: If you run LACP alongside hermes, you get the same primitive at the control-plane layer:lacp memory-kpi --profile alan --json | jq. Either way, the number you watch is stale_notes. Once it crosses 15% of total notes in a profile, schedule a brain-resolve pass before that profile starts quoting itself from an obsolete context. policy gates per role Different roles carry different risks. Research reads. Writing drafts. Engineering executes. Orchestration decides. A single policy cannot be right for all four. per-role policy, in plain shape: - Alan (research): risk class safe. Can read web, read repo, write to research/ only. Cannot run shell commands. Cannot write outside its sandbox. - Mira (writer): risk class safe. Can read research outputs, write to drafts/ only. Cannot read secrets, cannot execute code. - Turing (engineer): risk class review. Can read repo, run sandboxed tests, write to a feature branch. Every commit to main requires explicit orchestrator approval. - Hermes (orchestrator): risk class critical. The only profile that can approve Turing's commits, merge branches, or trigger paid api calls above a budget ceiling. Encode this in each profile's config.yaml under a policy: block, or at the harness layer if you run lacp. The rule is: > No profile gets more permission than its role needs, and the orchestrator is the only one who can widen any other profile's scope. Gateway messaging for remote supervision The profile system is a local org chart. The gateway turns it into an operational system you can supervise from a phone. Wire each profile to its own messaging identity: - Alan posts research findings to a #research channel - Mira drops drafts to a #writing channel - Turing posts test results and pr links to #engineering - Hermes synthesizes into #ops and asks for human approval on critical actions Now you can walk to lunch and come back knowing which profile did what, in what order, and where it stopped. Messaging is what turns four local profiles into a live multi-agent control surface. ## Day 30 failure modes - the four things that break Every 4-profile team I have watched in the past months hits at least one of these. All four are preventable. Failure 1 - Profile drift SOUL.md edits accumulate. A week ago, Mira was "clear and audience-aware." Today, Mira is "clear, audience-aware, technically precise, and willing to draft implementation notes." Congratulations - Mira is slowly becoming Turing. Patch: diff each SOUL.md weekly against its day-one version. Any new responsibility gets an explicit approval log entry, or it gets reverted. Failure 2 - Handoff rot The contract file exists, but nobody enforces it. Alan starts sending raw transcripts to Mira again. Mira starts asking Turing to "just check this one thing." Boundaries dissolve. Patch: Wire each handoff file into the harness. If the input does not match the declared shape, fail the handoff and require human review. The contract is only real if it can block. Failure 3 - SOUL.md bloat Each role grows edge cases. Turing gets a paragraph about "how we handle Python 2 legacy code." Alan gets three paragraphs about "when to skip peer-reviewed sources." Within a month, each SOUL.md is 2kb of special cases, and the agent loses the original identity in the noise. Patch: Cap SOUL.md at 400 words. Anything beyond that goes into AGENTS.md or a per-domain reference file. identity stays stable; context rotates. Failure 4 - Cron collision Profiles run cron jobs. Alan pulls a weekly research digest. Mira regenerates a weekly draft. Turing runs nightly test sweeps. Hermes runs a daily orchestration pass. By week four, two of them are colliding at 3 am because nobody coordinated the schedule. Patch: one shared ~/.hermes/team/cron.md file listing every scheduled task across every profile with its exact time, duration, and dependency. stagger collisions. Check the file before adding a new cron to any profile. ## The team reference file - copy-paste template One file, one purpose: explain your team to yourself and anyone else using the system six months from now. Keep this file under source control. Every team member's edit goes through a commit. You will thank yourself on day 90. ## The agent extraction layer - Objective: run a 4-profile Hermes team that stays coherent past day 30 - Inputs: working Hermes base, profile cli, SOUL.md + AGENTS.md split, handoff contracts, per-role policy, gateway messaging - Process: build the 4 profiles with - clone, write a distinct SOUL.md per role, keep project context in AGENTS.md, encode handoff contracts at ~/.hermes/team/handoffs/ and per-role policy in each config.yaml run weekly memory-kpi per profile, diff each SOUL.md against day-one, stagger cron, enforce team-agents.md via commits - Outputs: Four isolated profiles, per-role policy blocks, handoff contract files, staggered cron schedule, messaging routes, versioned team reference - Guardrails: No SOUL.md edit without a logged reason - No handoff accepted without the declared input shape - No role widened without orchestrator approval - No cron added without checking the shared schedule ## Closing Most multi-agent setups fail quietly. Everything looks fine on day one, works well on day seven, and blurs together by day thirty. The profile system is not what fails - it is the operator layer on top of it that nobody writes about. @NeoAIForecast got the build right. The rest of this guide is the maintenance contract: handoff contracts that block when they rot, memory-kpi per profile, policy ceilings that match the role, and a team reference file that survives the next six months. Profiles are the feature. Boundaries are the moat. Reply with which day-30 failure your hermes team is walking into this week - profile drift, handoff rot, soul bloat, or cron collision? ## 相关链接 - [Nyk](https://x.com/nyk_builderz) - [@nyk_builderz](https://x.com/nyk_builderz) - [18K](https://x.com/nyk_builderz/status/2044472463279710344/analytics) - [@neoaiforecast](https://x.com/@neoaiforecast) - [@neoaiforecast](https://x.com/@neoaiforecast) - [@neoaiforecast](https://x.com/@neoaiforecast) - [#research](https://x.com/search?q=%23research&src=hashtag_click) - [#writing](https://x.com/search?q=%23writing&src=hashtag_click) - [#engineering](https://x.com/search?q=%23engineering&src=hashtag_click) - [#ops](https://x.com/search?q=%23ops&src=hashtag_click) - [@NeoAIForecast](https://x.com/@NeoAIForecast) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [1:46 AM · Apr 16, 2026](https://x.com/nyk_builderz/status/2044472463279710344) - [18.3K Views](https://x.com/nyk_builderz/status/2044472463279710344/analytics) - [View quotes](https://x.com/nyk_builderz/status/2044472463279710344/quotes) --- *导出时间: 2026/4/16 16:11:35*
H Hermes Agent 进阶指南:从架构原理到构建自进化的多智能体系统 本文深入介绍了 Nous Research 开源项目 Hermes Agent。文章详细解析了其独特的“学习闭环”架构,该架构结合了三层持久化内存、自进化技能系统以及 GEPA 优化引擎,解决了传统 Agent 随会话结束而遗忘的问题。文中还将 Hermes 与 OpenClaw 进行了对比,并提供了从零开始配置多个个性化 Agent(程序员、研究员、设计师)的实战教程,旨在帮助开发者打造能够 24/7 运行且持续学习的个人 AI 队伍。 技术 › Hermes ✍ Akshay🕐 2026-05-28 AgentHermes自进化LLM开发者工具系统架构教程Nous ResearchGEPA多智能体
H Hermes 高级用法:用多 Profile 协作搭建 OPC Agent 团队 本文探讨了如何利用 Hermes 的多 Profile 协作功能,将多个 Agent 组织成一支 OPC(一人公司)团队。文章指出,单一 Agent 存在幻觉、记忆污染和角色混乱等问题,因此建议引入类似公司架构的四角色模型:Coordinator(协调员)、Researcher(研究员)、Writer(作家)和 Builder(构建者)。文章详细阐述了 Profile、Subagent、Project 和 Wiki 四个核心概念的区别,并提供了构建稳定 Agent 工作系统的具体配置方法,旨在建立清晰的角色边界和可长期运行的协作体系。 技术 › Hermes ✍ 知野🕐 2026-04-30 HermesAgent多Profile协作OPCWiki知野LLM系统架构团队协作Skill
H Hermes Agent 大师课程:完整指南 本文是一份关于 Hermes Agent 的 12 部分系列课程汇总,涵盖了从工作流程、学习系统、技能管理到多平台集成、浏览器控制等核心功能,详细介绍了该系统的架构设计与最佳实践。 技术 › Hermes ✍ Tony Simons🕐 2026-07-20 AgentHermesLLM教程系统架构工具集成多代理自动化
H Hermes Agent多智能体群聊协作配置教程 这是一份关于如何利用 Hermes 的 Profile 机制构建多智能体协作群聊的实操教程。文章详细介绍了配置 1 个主 Agent(Leader)和 3 个辅助 Agent(数据、技术、市场研究员)的完整流程。内容涵盖了 Profile 创建、共享 API 密钥配置、角色 Prompt 编写、Discord 机器人对接以及发言顺序控制与成本优化策略。 技术 › Agent ✍ DeFi狙击手 | Ai🕐 2026-05-28 Hermes多智能体Agent配置教程提示词群聊协作成本控制LLMDeepSeek
单 单智能体与多智能体解决方案的选择指南 文章探讨了在大语言模型时代,如何权衡使用单智能体与多智能体系统。引用斯坦福及Google/MIT的研究指出,多智能体系统并非总是更优,往往伴随着更高的计算成本、延迟和通信开销,且在“思考预算”相当的情况下,优化后的单智能体常能胜出。文章建议将单智能体作为默认起点,仅当任务涉及大量工具、上下文退化严重、存在自然解耦边界或需严格合规验证时,才考虑引入多智能体架构。 技术 › Agent ✍ AlphaSignal AI🕐 2026-05-07 AgentLLM系统架构多智能体性能优化StanfordGoogleMIT决策框架
H Hermes 高级用法:多 Profile 协作搭建 OPC Agent 团队(上篇) 文章探讨了如何利用 Hermes 工具的多 Profile 协作功能来构建 OPC(一人公司)Agent 团队。作者指出单一 Agent 存在幻觉、记忆污染和角色混乱三大问题,并提出通过“长期员工”Profile 和“临时工”Subagent 的概念进行分工。文章详细拆解了四角色模型(协调员、研究员、作家、构建者)及各自的配置文件结构,旨在建立一套稳定、清晰的 Agent 工作系统。 技术 › Hermes ✍ 知野🕐 2026-04-30 OPCAgent多Profile团队协作工作流LLM自动化生产力工具HermesSubagent
构 构建协同工作的 AI Agent 团队指南 本文深入探讨了如何构建高效的多 Agent 协作系统。文章指出,单个 Agent 难以同时胜任多种复杂任务,而通过“中心辐射”架构,利用协调者管理多个专业化 Agent,可显著提升输出质量。文章详细解析了上下文传递的关键原则、常见的失败模式及预防措施,并提供了构建研究与报告团队的实战指南。 技术 › Agent ✍ Khairallah AL-Awady🕐 2026-04-18 多Agent系统系统架构团队协作LLM提示词工程AI应用技术教程Hub-and-Spoke工作流设计
从 从零基础到生产环境掌握人工智能代理——完整指南 这是一份关于构建生产级 AI 智能体的完整指南。文章详细阐述了智能体与聊天机器人的本质区别,涵盖了从工具设计、系统提示词、多智能体编排到生产环境部署、测试评估的全流程。重点介绍了如何利用 API 构建可靠的智能体循环,并指出了初学者常犯的错误及生产环境下的监控与成本控制策略。 技术 › Agent ✍ Khairallah AL-Awady🕐 2026-04-07 AI代理Agent系统架构Claude工具设计多智能体生产部署大模型应用开发指南LLM
H Herdr + Hermes: 多智能体配置中的三个日常技巧 文章介绍了作者使用 Herdr 和 Hermes Agent 构建的多智能体工作流。Herdr 作为类似 tmux 的多路复用器统一管理多个 AI 编程代理,Hermes 则作为开源的总部代理负责驱动其他代理。作者分享了三个实用技巧:基础编排、技能创建以及状态检查汇报,从而将混乱的终端窗口转化为高效的系统。 技术 › Agent ✍ tonbi🕐 2026-07-27 多智能体HermesHerdrClaude Code工作流自动化开源DevOps效率工具Agent编排
如 如何构建自动纠错 AI 循环 文章介绍如何构建一个 AI 自我纠错系统,通过分离生成、判断和管理三个角色,避免人工介入验证。关键在于利用独立的标准(如测试套件)进行结构化验证,而非简单的重复提问,从而实现自动化错误捕捉与修复。 技术 › Agent ✍ CyrilXBT🕐 2026-07-17 AI架构自我纠错Agent提示词工程自动化系统设计LLM流程优化
A Agent 的数据面概念扫盲-建立技术侧认知体系 本文深入解析了 Agent 数据面的核心概念,将其比作操作系统的内存管理单元。文章详细阐述了 Context Engineering 的演变、Session/Thread/Profile 的架构差异,以及 Session Memory 与 Long-term Memory 的区别。作者还重点介绍了 Hermes 中的 Memory 设计方案、SQLite FTS5 与 BM25 算法原理,以及向量检索与关键词检索在 RAG 中的混合应用,旨在为开发者建立一套完整的 Agent 数据面技术认知体系。 技术 › Agent ✍ MateMatt🕐 2026-07-12 AgentContext EngineeringRAGMemoryBM25SQLite FTS5向量检索HermesLong-term MemoryLLM
H Hermes Agent 架构详细拆解:工业级 Agent 框架底层运行时揭秘 本文详细拆解了 Hermes Agent 的底层架构,将其定义为工业级运行时而非简单的 LLM 循环。文章类比前端工程模式,阐述了 Agent = Harness + Model 的核心公式。重点解析了从平台入口、适配器层、事件总线、GatewayRunner 核心调度层到 AI Agent 执行层的五层架构,揭示了 Hermes 如何通过共享线程池、会话复用和生命周期管理,实现高并发、有状态且安全可靠的 Agent 运行环境。 技术 › Hermes ✍ MateMatt🕐 2026-07-07 AgentHermes架构设计LLM事件总线多线程源码解析运行时HarnessReAct