一个需求拆成 3 路并行跑Hermes Agent 多智能体协作与任务分配实战笔记【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent第一次用 Hermes Agent 时我把读需求、改代码、跑测试整件事丢给它结果它串行推进上下文越滚越长到后半程明显变慢。后来改成多智能体协作——主智能体把任务拆成 3 路、并行派给独立的子智能体同样的活干得更快主对话也干净了不少。这篇笔记讲清楚它是怎么分工、怎么传话的以及哪类任务值得这么干。一条长链路单智能体先撞上三堵墙先还原场景你希望把一份需求文档变成能跑的代码。交给一个智能体从头做到尾会遇到三个实际问题上下文越堆越满搜索结果的原文、编译报错、读文件的内容全部留在同一个消息窗口里到第 20 步时模型能记住的有效信息已经很少了。串行等待分析、编码、测试一步压一步任何一步卡住后面全部干等。失败要整段重跑某一步走偏后没有只重跑那一步的入口。智能体任务分配要解决的正是这三点把彼此独立、上下文很重、可以并行的部分拆出去让每个子智能体只背自己那一份上下文。任务怎么分、消息怎么传拆开看 delegate_taskHermes Agent 的协作没有群聊概念核心就一个工具delegate_task实现在tools/delegate_tool.py。主智能体调它时每个子智能体拿到三样东西goal这条线的目标一句话说清context必要的背景只给该给的部分toolsets工具白名单——分析线只给read_file、search_files编码线给patch、terminal测试线给terminal。这就是差异化工具集它决定了每个角色能干什么是有限制的。角色上分两种这个设计我一开始觉得多余后来发现是在防套娃失控角色能做什么限制leaf默认干活的工人保留execute_code不能再调delegate_task也不会发消息、写记忆orchestrator可以保留delegate_task自己再派工人受max_spawn_depth默认 2限制不会无限套娃消息交换的方式是目标进、摘要出这是理解 Hermes Agent 智能体协调的关键子智能体有隔离的上下文和独立的终端会话父智能体默认等它跑完、拿回一份摘要再继续自己的循环。也就是说子智能体产生的几百行工具输出不进入父对话只有一份浓缩结果回来。加backgroundtrue后是另一套节奏立刻返回一个 delegation id父智能体不等结果之后通过异步完成队列重新进入对话。适合先派出去、干别的的编排。桌面端能直观看到这种隔离每个工作流是独立会话互相之间靠摘要和队列交接而不是共享一整面聊天记录。三步让分工跑起来git clone https://gitcode.com/GitHub_Trending/he/hermes-agent第 1 步打开 delegation 工具集。用hermes tools的交互界面或config.yaml里的tools.平台.enabled列表加上delegation。不开这个工具集子智能体根本派不出来。第 2 步给团队定规矩。在config.yaml的delegation段落里配delegation: max_concurrent_children: 3 max_spawn_depth: 2 child_timeout_seconds: 600 subagent_auto_approve: false两个最该知道的参数参数作用建议max_concurrent_children同一时刻并行子 Agent 数上限默认 3按机器和 API 限额调并行不是越多越好超了会互相挤占max_spawn_depth智能体再智能体的层级上限默认 2保持默认即可防递归失控child_timeout_seconds控制单子智能体超时跑测试的任务给长一点subagent_auto_approve默认关着——子智能体动手前要走确认涉及敏感操作时建议保持关闭。第 3 步派活单发或批量。单发传goal批量传tasks: [...]列表里每项各起一个子 Agent 并发跑——这就是多 Agent 并行的入口并发数由上一步的max_concurrent_children封顶。如果你的任务比一次会话更长比如要跨天、要活过进程重启别用后台 delegation它只活在当前进程里改用KanbanSQLite 落盘的共享任务板hermes kanban create建卡、assign指派多个 worker 从同一块板上取任务做完complete再走评审流。这是把 AI 团队协作从一回合拉长成一条流水线的方式。细节可以看仓库根目录AGENTS.md的 Delegation 和 Kanban 两节。两个落地例子加一段什么时候别上例 1代码评审扇出。orchestrator 角色读一遍 diff按模块拆出 N 个子任务批量并行派给 N 个 leaf每个只审自己那个模块最后收回 N 份摘要合并成一份评审。主对话里只有拆任务和合并结论两段中间几百行 diff 分析全在子上下文里消化掉。例 2跨天的数据清洗流水线。建一张 kanban采集、清洗、校验各是一张卡不同 worker 轮换取卡执行每张卡自带隔离上下文。进程重启、worker 换代都不影响队列任务状态一直在板上。什么时候不必上多智能体任务是短链路一两次调用就结束协调成本——派生、等摘要、确认审批——比省下的时间还多步骤之间强顺序依赖B 必须等 A 的结果才能动并行化没有收益拆了反而丢信息只是想让回答更准那是换模型或补上下文的事跟协作无关。反过来只要你的任务能切出独立子任务 重上下文 可并行这三样里的两样就值得先试。下一步建议按这个顺序走每步都能独立验证先在单个任务上手动调一次delegate_task感受摘要回来的交互再打开tasks批量模式把max_concurrent_children从 3 往下或往上各试一次看自己环境的瓶颈在哪最后才引入 kanban把任务板当成跨会话的持久队列来用。顺序别反过来——直接用 kanban 排产但还没调顺过单个子智能体的上下文传递大概率先卡在交接质量上。【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 一个需求拆成 3 路并行跑：Hermes Agent 多智能体协作与任务分配实战笔记
一个需求拆成 3 路并行跑Hermes Agent 多智能体协作与任务分配实战笔记【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent第一次用 Hermes Agent 时我把读需求、改代码、跑测试整件事丢给它结果它串行推进上下文越滚越长到后半程明显变慢。后来改成多智能体协作——主智能体把任务拆成 3 路、并行派给独立的子智能体同样的活干得更快主对话也干净了不少。这篇笔记讲清楚它是怎么分工、怎么传话的以及哪类任务值得这么干。一条长链路单智能体先撞上三堵墙先还原场景你希望把一份需求文档变成能跑的代码。交给一个智能体从头做到尾会遇到三个实际问题上下文越堆越满搜索结果的原文、编译报错、读文件的内容全部留在同一个消息窗口里到第 20 步时模型能记住的有效信息已经很少了。串行等待分析、编码、测试一步压一步任何一步卡住后面全部干等。失败要整段重跑某一步走偏后没有只重跑那一步的入口。智能体任务分配要解决的正是这三点把彼此独立、上下文很重、可以并行的部分拆出去让每个子智能体只背自己那一份上下文。任务怎么分、消息怎么传拆开看 delegate_taskHermes Agent 的协作没有群聊概念核心就一个工具delegate_task实现在tools/delegate_tool.py。主智能体调它时每个子智能体拿到三样东西goal这条线的目标一句话说清context必要的背景只给该给的部分toolsets工具白名单——分析线只给read_file、search_files编码线给patch、terminal测试线给terminal。这就是差异化工具集它决定了每个角色能干什么是有限制的。角色上分两种这个设计我一开始觉得多余后来发现是在防套娃失控角色能做什么限制leaf默认干活的工人保留execute_code不能再调delegate_task也不会发消息、写记忆orchestrator可以保留delegate_task自己再派工人受max_spawn_depth默认 2限制不会无限套娃消息交换的方式是目标进、摘要出这是理解 Hermes Agent 智能体协调的关键子智能体有隔离的上下文和独立的终端会话父智能体默认等它跑完、拿回一份摘要再继续自己的循环。也就是说子智能体产生的几百行工具输出不进入父对话只有一份浓缩结果回来。加backgroundtrue后是另一套节奏立刻返回一个 delegation id父智能体不等结果之后通过异步完成队列重新进入对话。适合先派出去、干别的的编排。桌面端能直观看到这种隔离每个工作流是独立会话互相之间靠摘要和队列交接而不是共享一整面聊天记录。三步让分工跑起来git clone https://gitcode.com/GitHub_Trending/he/hermes-agent第 1 步打开 delegation 工具集。用hermes tools的交互界面或config.yaml里的tools.平台.enabled列表加上delegation。不开这个工具集子智能体根本派不出来。第 2 步给团队定规矩。在config.yaml的delegation段落里配delegation: max_concurrent_children: 3 max_spawn_depth: 2 child_timeout_seconds: 600 subagent_auto_approve: false两个最该知道的参数参数作用建议max_concurrent_children同一时刻并行子 Agent 数上限默认 3按机器和 API 限额调并行不是越多越好超了会互相挤占max_spawn_depth智能体再智能体的层级上限默认 2保持默认即可防递归失控child_timeout_seconds控制单子智能体超时跑测试的任务给长一点subagent_auto_approve默认关着——子智能体动手前要走确认涉及敏感操作时建议保持关闭。第 3 步派活单发或批量。单发传goal批量传tasks: [...]列表里每项各起一个子 Agent 并发跑——这就是多 Agent 并行的入口并发数由上一步的max_concurrent_children封顶。如果你的任务比一次会话更长比如要跨天、要活过进程重启别用后台 delegation它只活在当前进程里改用KanbanSQLite 落盘的共享任务板hermes kanban create建卡、assign指派多个 worker 从同一块板上取任务做完complete再走评审流。这是把 AI 团队协作从一回合拉长成一条流水线的方式。细节可以看仓库根目录AGENTS.md的 Delegation 和 Kanban 两节。两个落地例子加一段什么时候别上例 1代码评审扇出。orchestrator 角色读一遍 diff按模块拆出 N 个子任务批量并行派给 N 个 leaf每个只审自己那个模块最后收回 N 份摘要合并成一份评审。主对话里只有拆任务和合并结论两段中间几百行 diff 分析全在子上下文里消化掉。例 2跨天的数据清洗流水线。建一张 kanban采集、清洗、校验各是一张卡不同 worker 轮换取卡执行每张卡自带隔离上下文。进程重启、worker 换代都不影响队列任务状态一直在板上。什么时候不必上多智能体任务是短链路一两次调用就结束协调成本——派生、等摘要、确认审批——比省下的时间还多步骤之间强顺序依赖B 必须等 A 的结果才能动并行化没有收益拆了反而丢信息只是想让回答更准那是换模型或补上下文的事跟协作无关。反过来只要你的任务能切出独立子任务 重上下文 可并行这三样里的两样就值得先试。下一步建议按这个顺序走每步都能独立验证先在单个任务上手动调一次delegate_task感受摘要回来的交互再打开tasks批量模式把max_concurrent_children从 3 往下或往上各试一次看自己环境的瓶颈在哪最后才引入 kanban把任务板当成跨会话的持久队列来用。顺序别反过来——直接用 kanban 排产但还没调顺过单个子智能体的上下文传递大概率先卡在交接质量上。【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考