十三多Agent协同 — 112系列第13篇作者挖AI金矿截至上一篇文章我们一直在讨论单个Hermes Agent的能力。单个Agent已经很强了——它可以访问工具、调用Skill、管理记忆、切换模型。但在真实的大型项目中单个Agent往往力不从心。想想看你要同时做三件事——调研数据库选型、写初版API代码、设计部署方案。如果只有一个Agent它会顺序处理要么你干等着要么上下文被不同任务的内容撑爆。多Agent协同就是解决方案。单个Agent是一个人的团队多Agent是你指挥的一个团队。1.什么时候需要多Agent大任务拆解不是所有场景都需要多Agent。单Agent能搞定的事情强行拆成多Agent反而增加复杂度。那什么时候该用1.1适合多Agent的场景场景1高度平行的子任务比如你要同时评估Three.js、WebGL和Canvas2D三个前端图形方案。用单Agent你得一个个问效率很低。用多Agent三个子Agent同时去调研你在主会话中汇总结果。场景2角色分工不同的任务比如开发一个API接口A Agent负责写handler和业务逻辑B Agent负责写单元测试C Agent负责写集成测试。每个Agent只需要关注自己的角色。场景3上下文敏感的复杂流程比如你修复一个bug先让A Agent分析问题根因B Agent基于分析结果写修复代码C Agent验证修复是否正确。每个Agent收到的上下文是精简的——A只需看错误日志B只需看A的输出和代码库C只需看B的变更。场景4需要独立工具权限的任务假设你需要同时查询生产环境日志和开发环境配置。单Agent切换上下文很麻烦。两个子Agent各持有不同的工具集——一个只读生产数据库一个只读开发配置——互不干扰。1.2不适合多Agent的场景不需要拆的场景简单问答、格式化输出、快速代码生成——Agent一轮对话就能搞定拆成多Agent纯粹是过度设计。不适合拆的场景高度依赖前后文连续性的任务——比如逐步调试一个复杂bug每一步都依赖上一步的精确结果。这种情况下单Agent的完整上下文窗口比多Agent的碎片化上下文更有用。1.3决策原则如果两个任务之间需要频繁同步中间结果用单Agent。如果两个任务可以独立运行到底只在最后合并用多Agent。在实际工作中我通常这样判断如果需要创建的中间文件超过3个或者需要访问的工具权限差异很大或者需要并行获取多个信息源就考虑用多Agent。2.delegate_task把任务分配给子AgentHermes的多Agent协作核心命令是delegate_task。你可以把它理解成委托——把一项子任务派发给另一个Agent实例去独立完成。2.1基本用法delegate_task--name调研-PostgreSQL-vs-TiDB\--instruction对比PostgreSQL 16和TiDB 8.1在以下维度的差异\n1. 一致性模型\n2. 水平扩展能力\n3. 事务支持\n4. 运维复杂度\n5. 适用场景\n\n输出一个markdown格式的对比表。\--toolsdatabase_search,web_search参数说明–name子任务名称用于后续引用–instruction给子Agent的完整指令越详细越好–tools子Agent可以使用的工具集逗号分隔–model可选指定子Agent使用的模型不指定则用默认模型–context可选传给子Agent的附加上下文比如相关代码片段2.2子Agent的执行过程当你执行delegate_task后Hermes创建一个新的Agent实例子Agent子Agent收到你的指令和工具集子Agent独立运行使用自己的上下文窗口子Agent完成任务后结果返回给主Agent主Agent将结果展示给你或继续处理整个过程是异步的——你不需要等待。子Agent在后台运行你可以继续和主Agent对话。2.3查看子任务状态# 列出所有活跃的子任务delegate_task list# 输出# 任务ID │ 名称 │ 状态 │ 进度 │ 耗时# t-001 │ 调研-PostgreSQL │ 运行中 │ 65% │ 2m30s# t-002 │ 写API代码 │ 已完成 │ 100% │ 1m15s# t-003 │ 写测试 │ 待分配 │ 0% │ -# 查看某个子任务的详细进展delegate_task status t-001# 获取已完成任务的结果delegate_task result t-0022.4在一个任务中引用另一个任务的结果这是多Agent协同的关键能力——子任务之间可以传递结果# 子任务A分析日志delegate_task--name分析错误日志\--instruction分析以下日志找出错误根因\--context$(cat/var/log/app/error.log)# 等待A完成后delegate_task--name写修复代码\--instruction基于错误分析结果写修复代码\--context$(delegate_task result t-001)子任务B会收到子任务A的输出作为上下文实现链式处理。3.子Agent的上下文隔离 独立工具集多Agent模式最容易被忽视但最重要的特性就是上下文隔离。3.1为什么需要上下文隔离假设你的主Agent已经聊了很多轮上下文窗口里塞满了各种信息项目背景、技术栈讨论、之前的代码修改记录。如果在这个上下文中分配写单元测试这个子任务子Agent会继承主Agent的全部上下文吗答案不会。这也是正确的设计。子Agent的上下文是干净的——它只看到你通过--instruction和--context参数显式传给它的信息。这带来几个好处减少干扰子Agent不会因为主会话中的无关讨论而分心节省tokens子Agent的上下文只包含与其任务相关的内容信息隔离敏感信息如生产数据库密码不会传递到不需要它的子Agent3.2独立工具集每个子Agent可以配置独立的工具集# 子Agent A只能读数据库delegate_task--name查询用户数据\--instruction查询最近一周的活跃用户数\--toolsdatabase_read# 子Agent B只能写代码delegate_task--name生成数据报表\--instruction基于查询结果生成HTML报表\--toolsfile_write# 子Agent C只能访问网络delegate_task--name搜索最佳实践\--instruction搜索Go并发编程的最佳实践\--toolsweb_search通过限制工具集你可以精确控制每个子Agent的能力边界避免意外操作比如一个负责写代码的Agent不小心删了生产数据库。3.3工具集配置可用的工具类型包括3.4上下文空间管理子Agent也有自己的上下文限制。你可以给它分配更多或更少的上下文容量# 给子Agent 32K的上下文适用于需要处理大量日志的分析任务delegate_task--name分析大量日志\--instruction... --context_limit 32000 # 给子Agent 8K的上下文适用于简单的查询任务 delegate_task --name 简单查询 \ --instruction ...--context_limit8000合理分配上下文容量让系统资源用在刀刃上。4.实操让子Agent写代码自己继续需求分析这是一个实际生产中我会反复使用的场景——让你真正体会多Agent的效率。4.1场景说明你在开发一个用户认证服务需要同时做两件事继续完善需求分析你亲自和主Agent讨论写注册接口的代码交给子Agent两步可以完全并行。4.2第一步分配代码任务delegate_task--name写注册接口\--instruction实现用户注册API接口包含以下功能 1. POST /api/v1/register 接收 email, password, nickname 2. 密码使用bcrypt加密存储 3. 验证email格式和密码强度最少8位含大小写字母和数字 4. 返回201状态码和用户ID 5. 如果email已存在返回409冲突 技术要求 - Go Gin框架 - GORM操作PostgreSQL - 使用testify写单元测试 - 错误使用中文返回 输出文件 - handlers/register.go - services/register_service.go - models/user.go - handlers/register_test.go\--toolscode_write,code_read,git_operations\--modelanthropic/claude-3-5-sonnet-202410224.3第二步继续和主Agent讨论在子Agent写代码的同时你可以继续和主Agent讨论需求你:我们还需要考虑密码重置流程你觉得用邮箱验证码还是安全问题好主Agent:建议用邮箱验证码方案原因如下 1. 安全性更高安全问题容易被暴力破解 2. 用户体验更好不用记住额外的答案 3. 和注册流程的邮箱验证逻辑可以复用 流程设计 1. 用户请求重置 - 发送6位验证码到邮箱 2. 用户提交验证码 - 验证通过后进入重置页面 3. 用户提交新密码 - 更新数据库 你觉得这个方案怎么样4.4第三步获取子Agent结果当子Agent完成后delegate_task status t-001# 状态: 已完成delegate_task result t-001子Agent返回的结果包括它生成的所有代码文件内容。你可以审查后合并到项目# 或者让主Agent帮你审查子Agent的输出帮我看一下子Agent写的注册接口代码重点检查安全性4.5第四步继续分配更多任务基于讨论结果和子Agent的代码可以继续分配新任务delegate_task--name写密码重置接口\--instruction基于以下需求实现密码重置API [粘贴刚才讨论的邮箱验证码方案] 数据库需要新增表 - password_reset_tokens (email, token, expires_at) 输出文件 - handlers/reset_password.go - services/reset_service.go - models/reset_token.go \--context$(delegate_task result t-001)\--toolscode_write,code_read注意--context参数传入了第一个子Agent的输出这样第二个子Agent可以基于已有代码继续开发保持代码风格和结构一致。4.6效果对比单Agent模式串行1. 讨论需求10轮对话→15分钟2. 写注册接口Agent写代码→5分钟这段时间你发呆3. 讨论密码重置方案5轮对话→8分钟4. 写密码重置接口Agent写代码→5分钟 总计:33分钟你实际干活25分钟等Agent8分钟多Agent模式并行1. 子Agent写注册接口后台运行 同时你讨论密码重置方案 →10分钟2. 密码重置方案确定后分配第二个子Agent写接口 同时你审查第一个子Agent的代码 →5分钟3. 所有子Agent完成 → 你汇总结果 总计:15分钟你全程在干活没有等待时间效率提升50%以上而且你的注意力没有被中断。5.子Agent能力边界什么不能做子Agent虽然强大但也有明确的边界。了解这些边界可以帮助你合理分配任务。5.1子Agent不能做的事1. 不能创建新的子Agent子Agent不能递归委派任务。这是一个安全设计——防止无限递归和资源耗尽。# ❌ 子Agent的内部不能执行 delegate_task# 如果你需要多层级委派只能从主Agent层面发起2. 不能修改主Agent的配置子Agent不能更改主Agent的记忆、Skills、配置等。它对主Agent工作区是只读的。3. 不能访问主会话的未共享上下文子Agent只能看到你通过参数显式传递的信息。主会话中之前讨论的内容如果没有传给子Agent它不知道。4. 不能执行交互式操作子Agent不能要求用户输入、不能打开交互式编辑器。它只能基于给定的指令和工具执行任务。5.2子Agent的局限性除了明确的不能做还有一些实际局限性上下文上限子Agent默认使用较小的上下文窗口通常是16K-32K。如果任务需要分析100万行日志你可能需要拆分或使用支持长上下文的模型。工具范围受限子Agent只能使用你明确授予的工具。如果某个任务中途需要额外的工具你必须重新分配任务。结果大小限制子Agent的输出结果默认限制在几千行内。如果要求生成一个完整的Rails项目上百个文件结果可能被截断。这种情况下应该让子Agent直接写入文件系统而不是返回全部文本。5.3安全边界# 在 config.yaml 中配置子Agent的安全策略subagent:security:# 允许子Agent访问的路径白名单allowed_paths:-/home/user/projects/# 禁止子Agent执行的命令黑名单forbidden_commands:-rm -rf-DROP TABLE# 禁止子Agent访问的网络forbidden_hosts:-10.0.0.*# 内网6.并行 vs 串行的选择这是多Agent协同中最需要权衡的设计决策。6.1并行模式多个子Agent同时运行互不依赖。# 三个调研任务并行执行delegate_task--name调研Three.js--instruction...delegate_task--name调研WebGL--instruction...delegate_task--name调研Canvas2D--instruction...# 等待所有完成delegate_task wait-all优点总耗时 最慢子任务的耗时吞吐量最大化缺点如果子任务需要共享资源比如都写同一个文件可能产生冲突适用场景独立调研任务不相关的代码生成数据采集6.2串行模式子任务顺序执行后一个依赖前一个的输出。# 第一步分析问题delegate_task--name分析Bug--instruction分析堆栈...# 等第一步完成delegate_task--name修复Bug\--context$(delegate_task result t-001)\--instruction基于分析结果写修复代码...# 等第二步完成delegate_task--name验证修复\--context$(delegate_task result t-002)\--instruction验证修复是否正确...优点保证数据一致性后续任务基于完整的前置结果缺点总耗时 所有子任务耗时之和适用场景CI/CD流水线逐层代码审查依赖链式输出6.3混合模式大多数实际场景采用的是混合模式——某些子任务并行某些串行。# 阶段1并行调研delegate_task--name调研数据库--instruction...delegate_task--name调研缓存方案--instruction...delegate_task wait-all# 阶段2基于调研结果写设计方案delegate_task--name写设计文档\--context$(delegate_task result t-001)\n$(delegate_task result t-002)\--instruction基于数据库和缓存方案调研结果写设计文档...# 阶段3基于设计文档并行实现delegate_task--name实现数据库层--context$(delegate_task result t-003)--instruction...delegate_task--name实现缓存层--context$(delegate_task result t-003)--instruction...delegate_task wait-all这种模式既发挥了并行的效率优势又保证了阶段间的依赖关系。7.实战用多Agent同时调研3个技术方案纸上谈兵这么多我们来一个完整的实战案例。7.1任务描述你要为一个新的电商后端做技术选型。需要在1小时内完成三个技术模块的初步调研和推荐方案消息队列: RabbitMQ vs Kafka vs Redis Streams搜索引擎: Elasticsearch vs Meilisearch vs Typesense监控方案: PrometheusGrafana vs Datadog vs New Relic7.2第一步分配三个并行调研任务# 任务1消息队列调研delegate_task--name调研-MQ\--instruction对比 RabbitMQ、Kafka 8.0、Redis Streams 以下维度 1. 消息可靠性持久化、ACK机制 2. 吞吐量每秒可处理多少消息 3. 运维复杂度需要几个组件、维护成本 4. Go SDK成熟度 5. 典型场景什么场景选哪个 最后给出推荐对于中等规模的电商后端日均100万订单推荐哪个为什么 输出为markdown格式。\--toolsweb_search\--modeldeepseek/deepseek-chat# 任务2搜索引擎调研delegate_task--name调研-搜索\--instruction对比 Elasticsearch 8.x、Meilisearch 1.6、Typesense 0.26 以下维度 1. 搜索速度特别是中文分词效果 2. 索引构建速度 3. 资源消耗内存/CPU 4. 高可用方案 5. Go客户端 场景需求电商商品搜索日均500万搜索请求需要支持拼音搜索、拼写纠错、分类过滤。 输出为markdown格式。\--toolsweb_search\--modeldeepseek/deepseek-chat# 任务3监控方案调研delegate_task--name调研-监控\--instruction对比 PrometheusGrafana、Datadog、New Relic 以下维度 1. 部署方式自建 vs SaaS 2. 成本估算日均10万指标点 3. 告警能力 4. APM支持 5. 自定义Dashboard灵活性 6. 和Go应用的集成度 输出为markdown格式。\--toolsweb_search\--modeldeepseek/deepseek-chat7.3第二步监控进展whiletrue;docleardelegate_task listsleep10done输出t-001|调研-MQ|已完成|100%|1m45s t-002|调研-搜索|运行中|70%|2m10s t-003|调研-监控|运行中|50%|1m30s7.4第三步最早完成的任务先审核任务1最快完成。不等其他两个先看结果delegate_task result t-001假设结果中推荐了 Kafka但你的团队对Kafka不熟悉你可以继续和主Agent讨论你:任务1推荐了Kafka但团队对Kafka不熟悉RabbitMQ的经验更丰富主Agent: 基于团队的技术栈考虑RabbitMQ也是合理的选择。 不过可以折中先用RabbitMQ预留Kafka迁移路径。 建议在消息处理层做抽象未来可以无缝切换。 具体建议1. 使用RabbitMQ Streams插件支持消息回溯2. 消息处理接口抽象化interface定义3. 预留Kafka的topic设计分区键策略7.5第四步汇总所有结果三个子任务都完成后让主Agent汇总把三个调研结果汇总成一个技术选型报告包含 1. 每个模块的推荐方案 2. 推荐理由 3. 备选方案 4. 实施建议优先级、风险点 5. 团队需要提前学习的技术 输出格式为markdown保存到 docs/tech-stack-report.md最终产出的一份完整报告包含了消息队列、搜索引擎和监控方案的选型建议而且三个子任务的调研是并行完成的——总耗时约3分钟而不是串行的9分钟。8.多Agent的高级模式除了基本的委派模式还有一些高级用法值得了解。8.1辩论模式让两个子Agent从不同角度分析同一个问题然后汇总delegate_task--name正方-用微服务\--instruction从架构灵活性、团队协作、技术多样性角度论证为什么应该采用微服务架构\--modelgpt-4o delegate_task--name反方-用单体\--instruction从开发效率、运维复杂度、性能角度论证为什么应该采用单体架构\--modeldeepseek/deepseek-chat delegate_task wait-all综合正反两方的分析给出最终建议。考虑项目实际情况5人团队开发周期6个月预期1年后用户量增长10倍。这种模式能避免单一视角的局限性特别是对于复杂的技术决策。8.2审查模式一个Agent写代码另一个Agent审查# Agent A写代码delegate_task--name写订单模块\--instruction实现订单创建和查询功能...\--toolscode_write delegate_taskwaitt-001# Agent B审查代码delegate_task--name审查订单模块\--context$(delegate_task result t-001)\--instruction代码审查重点关注 1. SQL注入风险 2. 并发安全问题订单状态更新 3. 错误处理是否完备 4. 是否符合Go最佳实践 给出审查报告和修改建议。\--toolscode_read8.3看门狗模式主Agent负责协调子Agent负责监控# 一个持续运行的任务delegate_task--name监控日志\--instruction每分钟检查一次应用日志 如果发现ERROR级别且包含panic或fatal的日志 立即报告给主Agent\--toolsfile_read\--persisttrue--persist true让子Agent长期运行持续监控。9.注意事项与陷阱9.11. 不要过度拆分三个独立调研任务并行跑是好的但把一个写注册接口拆成写handler、“写service”、写model三个子任务就过头了——Agent写这三部分通常在一段上下文中完成拆分反而增加了沟通开销。经验法则如果子任务的指令少于100字说明拆得太细了。9.22. 注意子Agent的数量限制同时运行的子Agent数量有限制默认3-5个取决于配置。超过限制的任务会排队等待。# 在config.yaml中配置subagent:max_concurrent:5# 最大并行数queue_size:10# 队列长度timeout:300# 单任务超时秒9.33. 避免循环依赖# ❌ 错误循环引用delegate_task--nameA--context$(delegate_task result B)delegate_task--nameB--context$(delegate_task result A)# ✅ 正确线性依赖delegate_task--nameA delegate_task--nameB--context$(delegate_task result A)9.44. 子Agent失败处理任何子Agent都可能失败超时、工具出错、模型异常。要有容错机制# 重试失败的任务delegate_task retry t-001# 查看失败原因delegate_task log t-001# 如果某个子任务不重要可以忽略delegate_task cancel t-00110.总结多Agent协同是Hermes Agent最接近团队协作的功能。它让你从一个AI助手的使用者变成一个AI团队的指挥者。今天的关键点何时用大任务中有多个独立子任务时使用怎么用delegate_task分配任务独立上下文独立工具集并行vs串行独立任务并行依赖任务串行实战案例并行调研技术方案、边写代码边讨论需求高级模式辩论、审查、看门狗注意事项不过度拆分、注意数量和依赖关系下一篇文章我们将讨论Hermes Agent的安全与权限控制——如何安全地让AI访问你的代码和系统。作者挖AI金矿系列Hermes Agent 从小白到高级 — 第 13/18 篇下一篇安全与权限控制 — 把Agent关进笼子里