最近几个月, 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,执行时再派
信任边界	远程机默认只读 + 当次授权;子马自报成绩需协调马抽验