Hermes Agent 多智能体协作3 个机制把单 Agent 的长任务拆成并行流水线【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent一个 Agent 同时扛代码审查、文档生成和回归测试上下文很快会被塞爆。Hermes Agent 多智能体协作的思路直接得多把活拆给子 Agent各自拿着独立上下文去干主 Agent 只负责收结果、做汇总全程不用你写一行调度胶水代码。协作到底在干嘛主 Agent 只当项目经理想象一个不亲手写代码的项目负责人接到任务先拆包每个包丢给独立工作间的工匠工匠交付后负责人验收汇总。Hermes Agent 的主 Agent 就是这位负责人每个子 Agent 都是带独立工作间的工匠。派活这个动作本身只是一次工具调用。tools/delegate_tool.py 里的delegate_task有两种形态传一个goal派单人传tasks: [...]则每一项各起一个子 Agent 并行跑。子 Agent 默认继承隔离的上下文和终端会话它们中途翻日志、试错留下的痕迹都不会污染主对话。这就是 Hermes Agent 做多智能体任务分配的基本盘——拆包、并行、验收全部走同一个入口。三个机制看懂它怎么做到的子 Agent 怎么派出去一个冻结的请求结构插件体系派生子 Agent 的入口在 agent/subagent_lifecycle.py。它故意不暴露AIAgent对象只开放一份只读契约派出去的智能体角色、工具、超时全写在这一个结构里# agent/subagent_lifecycle.py派生子 Agent 的公开契约 SubagentLaunchRequest( goal审查 auth/ 目录的权限边界, context本次变更集中在 token 刷新逻辑, roleleaf, # 叶子角色专注干活不能再派生 allowed_toolsets(terminal, files), # 限定子 Agent 可用工具白名单 timeout_seconds600, )roleleaf值得留意子 Agent 默认不能再调delegate_task递归失控从根上被掐掉。确需子 Agent 继续拆任务时用roleorchestrator它会受深度上限约束。并行调度怎么限流config.yaml 里的几个数字并发上限和嵌套深度都收在~/.hermes/config.yaml的delegation段Agent 并行调度被这几个数字管得死死的# ~/.hermes/config.yaml delegation: max_concurrent_children: 3 # 并行子 Agent 上限默认 3 max_spawn_depth: 2 # 子派孙的最大深度默认 2 child_timeout_seconds: 900 # 单个子任务超时 orchestrator_enabled: true # 允许 orchestrator 角色继续拆任务数字偏保守是刻意为之每个子 Agent 都占一个模型会话并发放开太快成本和稳定性会一起失控。要跑更大规模的批量活走另一个入口 batch_runner.py它把提示词数据集按批并行处理还支持中断后从 checkpoint 续跑。结果怎么回到主对话状态机加回调队列子 Agent 干完活主 Agent 不需要轮询。同步模式下父方直接等子 Agent 的摘要再续跑自己的循环加backgroundtrue则立刻拿到 delegation id结果稍后经异步回调队列流回主对话。整个过程由一个状态机跟踪# agent/subagent_lifecycle.py子 Agent 生命周期状态 class SubagentState(str, Enum): PENDING PENDING RUNNING RUNNING SUCCEEDED SUCCEEDED FAILED FAILED CANCELLED CANCELLED底层消息格式遵循 OpenAI 约定assistant消息可携带tool_calls子 Agent 的交付物本质上就是一条tool消息回到主对话父子因此不需要互相读懂对方内部协议统一即可。主循环如何组装和交替这些消息可以看 run_agent.py 里的AIAgent类。3 步跑通最小协作流程先克隆仓库再让配置向导一次把模型和工具集配完git clone https://gitcode.com/GitHub_Trending/he/hermes-agent cd hermes-agent hermes setup # 向导模型、工具集、delegation 参数一次配完进入会话后不需要写任何代码用大白话把拆分讲清楚就行把这次发版拆成 3 个并行任务生成 changelog、审查 breaking change、跑测试并汇总失败项都完成后给我合并报告。主 Agent 会把它翻译成tasks批量派发等 3 个子 Agent 各自的摘要回来再输出汇总。想要长期挂任务、按看板分派仓库里的 plugins/kanban/ 插件把任务放上看板、由 worker 逐个认领适合跑一整天的流水线。哪些任务值得拆哪些别拆把 Hermes Agent 当 AI 团队协作框架用拆不拆任务就看两条标准子任务之间是否独立中间上下文是否臃肿。发版前同时生成文档、审查 breaking change、跑回归测试就是典型——三条线互不依赖各自有一大堆日志和 diff塞进同一个上下文纯浪费。代码评审跨多个仓库时同理每个仓库一个子 Agent并行跑完汇总。两种情况别拆。子步骤强依赖彼此输出的拆完就得等变回串行不如一个 Agent 从头干到尾。子 Agent 之间需要频繁互相确认的拆的粒度应该是交付物而不是步骤拆细了协调成本会吃掉并行省下的时间。还有一个边界要知道background子任务只活在当前进程里需要扛过进程重启的任务换cronjob或带完成通知的后台终端。想查完整的 delegation 参数和角色权限表翻 AGENTS.md 的 Delegation 章节想自己写插件管理一队子 Agent从agent/subagent_lifecycle.py的公开契约入手即可。【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Hermes Agent 多智能体协作3 个机制把单 Agent 的长任务拆成并行流水线【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent一个 Agent 同时扛代码审查、文档生成和回归测试上下文很快会被塞爆。Hermes Agent 多智能体协作的思路直接得多把活拆给子 Agent各自拿着独立上下文去干主 Agent 只负责收结果、做汇总全程不用你写一行调度胶水代码。协作到底在干嘛主 Agent 只当项目经理想象一个不亲手写代码的项目负责人接到任务先拆包每个包丢给独立工作间的工匠工匠交付后负责人验收汇总。Hermes Agent 的主 Agent 就是这位负责人每个子 Agent 都是带独立工作间的工匠。派活这个动作本身只是一次工具调用。tools/delegate_tool.py 里的delegate_task有两种形态传一个goal派单人传tasks: [...]则每一项各起一个子 Agent 并行跑。子 Agent 默认继承隔离的上下文和终端会话它们中途翻日志、试错留下的痕迹都不会污染主对话。这就是 Hermes Agent 做多智能体任务分配的基本盘——拆包、并行、验收全部走同一个入口。三个机制看懂它怎么做到的子 Agent 怎么派出去一个冻结的请求结构插件体系派生子 Agent 的入口在 agent/subagent_lifecycle.py。它故意不暴露AIAgent对象只开放一份只读契约派出去的智能体角色、工具、超时全写在这一个结构里# agent/subagent_lifecycle.py派生子 Agent 的公开契约 SubagentLaunchRequest( goal审查 auth/ 目录的权限边界, context本次变更集中在 token 刷新逻辑, roleleaf, # 叶子角色专注干活不能再派生 allowed_toolsets(terminal, files), # 限定子 Agent 可用工具白名单 timeout_seconds600, )roleleaf值得留意子 Agent 默认不能再调delegate_task递归失控从根上被掐掉。确需子 Agent 继续拆任务时用roleorchestrator它会受深度上限约束。并行调度怎么限流config.yaml 里的几个数字并发上限和嵌套深度都收在~/.hermes/config.yaml的delegation段Agent 并行调度被这几个数字管得死死的# ~/.hermes/config.yaml delegation: max_concurrent_children: 3 # 并行子 Agent 上限默认 3 max_spawn_depth: 2 # 子派孙的最大深度默认 2 child_timeout_seconds: 900 # 单个子任务超时 orchestrator_enabled: true # 允许 orchestrator 角色继续拆任务数字偏保守是刻意为之每个子 Agent 都占一个模型会话并发放开太快成本和稳定性会一起失控。要跑更大规模的批量活走另一个入口 batch_runner.py它把提示词数据集按批并行处理还支持中断后从 checkpoint 续跑。结果怎么回到主对话状态机加回调队列子 Agent 干完活主 Agent 不需要轮询。同步模式下父方直接等子 Agent 的摘要再续跑自己的循环加backgroundtrue则立刻拿到 delegation id结果稍后经异步回调队列流回主对话。整个过程由一个状态机跟踪# agent/subagent_lifecycle.py子 Agent 生命周期状态 class SubagentState(str, Enum): PENDING PENDING RUNNING RUNNING SUCCEEDED SUCCEEDED FAILED FAILED CANCELLED CANCELLED底层消息格式遵循 OpenAI 约定assistant消息可携带tool_calls子 Agent 的交付物本质上就是一条tool消息回到主对话父子因此不需要互相读懂对方内部协议统一即可。主循环如何组装和交替这些消息可以看 run_agent.py 里的AIAgent类。3 步跑通最小协作流程先克隆仓库再让配置向导一次把模型和工具集配完git clone https://gitcode.com/GitHub_Trending/he/hermes-agent cd hermes-agent hermes setup # 向导模型、工具集、delegation 参数一次配完进入会话后不需要写任何代码用大白话把拆分讲清楚就行把这次发版拆成 3 个并行任务生成 changelog、审查 breaking change、跑测试并汇总失败项都完成后给我合并报告。主 Agent 会把它翻译成tasks批量派发等 3 个子 Agent 各自的摘要回来再输出汇总。想要长期挂任务、按看板分派仓库里的 plugins/kanban/ 插件把任务放上看板、由 worker 逐个认领适合跑一整天的流水线。哪些任务值得拆哪些别拆把 Hermes Agent 当 AI 团队协作框架用拆不拆任务就看两条标准子任务之间是否独立中间上下文是否臃肿。发版前同时生成文档、审查 breaking change、跑回归测试就是典型——三条线互不依赖各自有一大堆日志和 diff塞进同一个上下文纯浪费。代码评审跨多个仓库时同理每个仓库一个子 Agent并行跑完汇总。两种情况别拆。子步骤强依赖彼此输出的拆完就得等变回串行不如一个 Agent 从头干到尾。子 Agent 之间需要频繁互相确认的拆的粒度应该是交付物而不是步骤拆细了协调成本会吃掉并行省下的时间。还有一个边界要知道background子任务只活在当前进程里需要扛过进程重启的任务换cronjob或带完成通知的后台终端。想查完整的 delegation 参数和角色权限表翻 AGENTS.md 的 Delegation 章节想自己写插件管理一队子 Agent从agent/subagent_lifecycle.py的公开契约入手即可。【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
