五马分工-hermes多profile协作经验分享
-
最近几个月, Hermes一直是我的主力Agent, 用起来还是比较顺手的. 但它也有缺点, Memory.md 容量有限, 且每次都要加载到会话里面.
之前一直是用一个主Agent, 它自己会启动一些sub-Agent协调干活, 或者我让它并行多开干活. 但记忆, 技能等只有一份.
后来改成了多个子Agent(profile) 协作, 运行了差不多一个月了, 感觉还是比较顺畅. 我用的是星型管理, 即通过一个主Agent, 管理所有其他的Agent, 以及外接Agent. 你也可以通过kanban之类的, 进行并行管理. 不过管理成本较高.
以下为AI整理:
经验分享:一个 Hermes 跑五匹马 —— 用多 profile 分工把"单马全能"拆成协作群
用 Hermes Agent 几个月,前期一直是一个 default profile 单打独斗:笔记、邮箱、找文件、远程机器运维,全在一个上下文里干。两个症状越来越明显:一是长任务上下文互相污染,跑着跑着质量就掉了;二是"协调员"总下场干杂活,自己顺手把该分工的活全干了。
后来把它拆成了五匹马:一个 Hermes 里开五个 profile,每匹马独立的 SOUL、记忆、技能、会话,按任务域分工:
马 职责 小马 (default) 前台协调:拆任务、派活、抽验、汇报,内容参谋;同时负责集群外智能体的管理 笔记马 Obsidian 库唯一写者:笔记/日记/归档/链接 邮箱马 Gmail / 日历 / 提醒 / 任务 文件马 全文件系统检索与整理 运维马 远程机群 + 内外网通信的唯一运维 owner 派活就一行:
hermes -p <name> chat -q "<任务>",子 agent 在隔离上下文里跑,结果返回给协调马验收。不需要多开进程,一台笔记本就是五个 agent。先说一个前提:这套系统是要持续清理的
多 agent 系统最大的隐性成本,是记忆、技能、规矩的膨胀与漂移——记忆不砍,各马越跑越贵还串味;技能不剪,加载越多越慢;规矩各改各的,过一个月五个 MEMORY 就是五个版本。所以建群不是终点,持续清理是这套架构能不能跑下去的前提:记忆逐马裁剪、公共规矩单一事实源 + 各马只存一行指针、每月末一次自动审计(记忆膨胀、技能膨胀、职责漂移、规矩同步状态),出报告给我看。建群那天做一遍没用,得当成日常在跑的事。
几个设计决策,都是踩出来的
1. 记忆不要全量克隆,要逐马裁剪。 建群时我是把协调马的全量记忆克隆给各子的,结果运维马的记忆里出现了跟它八竿子打不着的私人条目,又贵又串味。后来逐马裁剪,各马只留自己领域该知道的。
2. 定时任务全部挂在 default。 子 profile 的 cron 投递不进共享 bot 的私信,这是实测的坑。所以每天的工作日志、记账这些任务一律挂 default,执行时再派活给对应的马。
3. 公共规矩单一事实源。 删除一律进回收站、远程机默认只读(改动需明确授权且仅当次有效)、产物目录收口两处……这些公共约定集中写在一个文档里当唯一事实源,各马的记忆里只存一行指针指过去。不然五个 MEMORY 各改各的,过一个月就漂了。
4. 子马的"完成"不可全信。 有一次运维马改完配置,它的 verify 通过,但线上实际跑在错误的分支上——因为 verify 只比了数值,没看关键旗标。后来的规矩:模板/参数类改动,收尾必须由协调马做字节级复核;子马自报的成绩只作线索,关键数字自己抽验。
5. 派活别太碎。 一两步的小事协调马直接做,不为派活而派活——拆任务本身有成本,一次派活往返加验收,不是免费的。
跑起来是什么样
举两个真实任务:
- 银行对账单大整理(一天内):文件马全盘搜索 + 内容级核验出 80 份真件并出报告,再去重;笔记马两轮建目录、分 3 批入库 127 份(逐份校验带文字层);协调马只做拆任务、定命名规范、验收数字、汇报。当天笔记马跑了 10 个 session、文件马 2 个,各上下文干净互不污染。
- 家庭软路由彻底重装(全天):笔记马全库翻历史文档出方案素材,运维马做重置前全量备份(35 个配置 + 虚机快照)→ 回滚重装 → 定点修复 → 验收(两次整机重启全项自恢复);协调马汇总文档、写交接单、清过程文件。动手前走了"明确授权、仅当次有效"。
一个还没想清楚的位置:文件马
文件马目前的定位其实有点模糊。我真正想要的是向量检索式的自然语言找文件——比如直接问"找一下我最新的体检报告",它自己把语义对上、按时间排出来,而不是靠文件名关键词撞。但又不想让它过重:不想为此多养一个独立的向量数据库服务、不想把所有文件常驻索引。所以现在的折中是"系统级搜索 + 内容级抽查"(Spotlight/find 快筛,再逐个抽正文核验),能用,但离"自然语言语义检索"还差一截,轻量方案还在评估,有合适的会同步。
诚实讲取舍
我自己反复权衡过:一匹马最理想(维护工作最少),五匹马效率最高,代价是复杂度——每多一匹马多一份要维护的 SOUL、记忆、技能和规矩同步。我的结论:任务域天然分块、单 profile 上下文确实扛不住,这钱花得值;任务少或领域重叠大的,三马甚至一马更划算。 另外协调马是单点,它挂了派活链路就断,目前接受,因为它职责本身轻、故障面小。
顺带:集群外也能协作
协调马(小马)除了管集群内部,也顺带管理集群外的智能体。机制很简单:用一份共享目录当小黑板,另一个 AI 应用把成果和任务单放进去,我这边定时取件、按接收方分给对应的马,完成后归档。不需要共享上下文或对接 API,一块小黑板就实现了跨 agent 的协调、分工和通信。
一页结论
问题 我的答案 怎么分 按任务域天然分块切 profile,每域一个明确 owner,不按"能力"切 协调马干啥 拆任务、派活、抽验关键数字、汇报;兼管集群外智能体;不下场干子马专业领域 记忆怎么管 不克隆全量、逐马裁剪;公共规矩单一事实源 + 每月审计,持续清理是前提 定时任务挂哪 全挂 default,执行时再派 信任边界 远程机默认只读 + 当次授权;子马自报成绩需协调马抽验 -
-
-
-
-
-
-
你的情况和我几乎一模一样，而且我也是自建本地 VLLM。
我原来有好多个 profile。有维护的 有股票的 有写作的 还有一个是专门做音频视频流的。
光是维护这么多 Profile，我就已经受不了了。 这些构构架之间，它不是由一个统软件总体调度，而是由你这些提示词和一些人格设置和一些记忆库来维护的。 总体来说，等同于手搓了一个管理体系。
经过了一两个月的使用，我现在是放弃了。
我的 Hermes 基本上用法和老特是一样的。仅仅是部署在服务器上的 hermes ,用于服务器本身的维护，因为它稳定。
然后我现在主力工具全部 已经搬到 DSH 里面了。
一开始 DSH 各种不顺。 直到我装了一个腾讯的MemoryeDB. 的 dsh 简化版本. 这个插件呢，需要向量数据库.我本地是 3090 24G, 安装了 vllm 跑千文 3.8 27b 还有 ollma 跑一个几百兆的最小号的 104 维的向量数据库从此以后, dsh 里任何的聊天记录,都能瞬间找到. 还算勉强能用.
总结:我也是 5 马走过来的,现在就 不纠结聊天了
就开几个聊天.1 个管 系统维护, 1个文档, 1 个管写日记随笔,, 再开了一个 dsh im 手机入口.
最重要的股票 方面.我呢就有好多个项目. 但是,项目里面 需要系统配合的,也随时可以 口述 要求改系统, 都没有问题hermes 需要多profile 的, 被我用 d'sh +向量历史库,解决了,有全能助理的感觉了!
-
