这段时间我在用Hermes Agent批量处理一批结构化信息提取与摘要生成任务。刚开始的用法很直接脚本里起一个Agent实例循环读入任务逐个交给大模型执行。头几十个任务还撑得住等任务量涨到几百上千问题全冒出来了——单个Agent串行处理每个任务都要等模型返回、等工具结果整条队列被拖得极慢更难受的是一个任务因为工具调用异常卡住后面所有任务全部排队陪跑。被这个局面折腾了几轮之后我把架构重构成了“基于Hermes Agent的多实例任务分发与协同”模式一个调度器负责拆任务和管状态多个Hermes Agent实例作为Worker并行消费任务再通过统一的消息通道回传结果。这篇文章把我从设计到落地的完整过程、关键代码思路、实测数据和踩过的坑都整理出来给正在折腾Agent批处理和多实例协同的朋友一个可参考的样本。1. 单实例Agent的瓶颈我为什么把Hermes Agent拆开跑1.1 场景复盘100个任务跑掉一晚上我接到的需求是这样的手头有一批业务文档需要逐一做关键信息抽取、摘要生成并附带一轮基于抽取结果的规则校验。每个文档的处理流程包含两到三轮大模型调用中间穿插几个工具函数比如解析PDF、查数据库、比对字段。任务之间互相独立不共享中间状态。第一批任务差不多100个。我最初在代码里采用最朴素的循环串行方式等一个任务完全跑完再取下一条。100个任务跑下来耗时非常难看差不多花了三四个小时。原因也不难理解——Hermes Agent不是简单发一次请求就完事它内部是一个“思考-调用工具-观察结果-再思考”的循环每一次循环都要等模型推理、等工具返回任何一个环节慢整条链路就慢。串行模式下这100个任务的耗时基本线性累加完全吃不到并发红利。1.2 单实例模式的三个隐藏问题串行慢是我能提前想到的真正逼我改架构的是另外三个问题。第一个问题是“一颗老鼠屎坏一锅汤”。某个任务调用外部工具时因网络抖动超时Agent会进入长时间的重试循环我的主循环在等它它后面排队的99个任务全部被堵住。我试过给单次工具调用加超时但Agent内部的重试逻辑不是能在外部轻易拦截的光是定位卡住的进程就花了不少时间。第二个问题是资源利用率极低。我用远程API方案时账号明明支持较高并发但串行调用把并发能力完全浪费了后来切到本地方案跑模型单实例同时只占一份算力GPU利用率也上不去。第三个问题是Agent会话上下文污染。串行处理时如果没有显式重置Agent的会话状态上一轮任务残留的工具结果和对话历史就会带入下一个任务。数据抽取任务最怕这个——前一个任务里出现的字段值可能在后一个任务的结果里“借尸还魂”。这三点叠加让我决定不再跟单实例死磕直接把架构改成多实例并行。2. 多实例架构的搭建调度器、Worker与任务队列怎么分工2.1 整体架构主调度器与Worker实例的职责边界我采用的架构分三层生产者Producer、任务队列Queue、消费者Worker。生产者通常是主调度器负责把用户提交的大任务拆解成多个子任务写入任务队列Worker则是多个独立进程每个进程内跑一个Hermes Agent实例订阅任务队列取到任务就执行执行完把结果回传。为什么要单独拆一个调度器出来而不是让多个Worker直接瓜分原始任务列表核心原因是状态管理和失败恢复。直接分任务列表的方案看着简单但一旦某个Worker中途挂了它手里正在跑的任务就没人管了任务列表也不知道该把这条任务重新分给谁。引入任务队列之后任务的全部生命周期都由调度器和队列管理Worker只是一个“拿了任务干活、干完交差”的无状态执行者挂掉一个Worker不影响整个批次。职责边界划清楚之后排查问题的思路会清晰很多任务没执行去看队列任务执行了但结果不对去看Worker日志任务执行超时去看调度器的超时策略。每一层责任单一不会三块糅在一起半天定位不到根因。2.2 任务队列选型我用Redis Stream而不是直接塞进消息中间件任务队列是整个架构的主动脉选型上我对比过几类方案。第一类是RabbitMQ和Kafka这类完整消息中间件功能全、可靠性高但引入一个独立组件对个人项目和小团队来说偏重部署运维成本不低。第二类是直接用关系型数据库建一张任务表靠轮询或FOR UPDATE SKIP LOCKED模拟队列胜在简单但轮询的实时性和数据库压力会随任务量上升变得尴尬。第三类是我最终采用的Redis Stream。选Redis Stream有几个实际理由。第一Redis基本已是后端项目的标配不用额外引入新组件部署成本几乎为零。第二Stream天然支持消费者组可以做到一条消息只被一个消费者消费契合“一个任务只被一个Worker处理”的需求同时XREADGROUP、XACK、XPENDING、XAUTOCLAIM这套命令把消费确认和失败重投机制都补齐了不需要自己在业务代码里写一套复杂的可靠投递逻辑。第三Redis性能足够好任务量在几万级别时完全没有压力。提示如果你的场景对消息可靠性要求极高任务状态不能有一丁点丢失建议上RabbitMQ这类ACK机制更完善的消息中间件。但大部分Agent批处理场景Redis Stream的可靠性已经够用了记得开启AOF持久化。2.3 任务数据结构与状态机设计任务数据结构直接决定后面所有逻辑好不好写。我用的核心字段是下面这套JSON{ task_id: task_20240817_0001, job_id: batch_20240817_01, type: doc_extract, payload: { doc_id: DOC-10086, source_path: /data/docs/xxx.pdf, extract_fields: [title, author, amount, date] }, priority: 1, timeout_seconds: 300, retry_count: 0, max_retries: 3, created_at: 1723856000, status: pending }task_id是全局唯一标识用来做幂等job_id标识这批任务属于哪个大任务方便整批维度的统计和重跑type决定Worker用哪条处理链路payload放业务参数priority和timeout_seconds分别用于优先级调度和超时控制status是任务当前状态。任务状态机我设计成六个状态状态含义可能去向pending已入库等待分发dispatcheddispatched已被Worker领取running / timeoutrunningWorker执行中succeeded / failedsucceeded执行成功结果已回传结束failed执行失败pending重试/ dead放弃timeout超时未完成pending重投/ dead放弃调度器定期扫描状态把超时任务捞出来重新投递重试次数达到上限再进dead队列等待人工介入。这套状态机不复杂但把系统里可能发生的异常情况都覆盖了后续加告警、加统计都省事。3. 任务分发的完整链路从提交到结果回传的关键细节3.1 调度器侧优先级、超时与任务重试调度器向Redis Stream写入任务时一般用XADD命令。Stream本身不直接支持按优先级消费我的处理方式是把队列按优先级分成多条Streamurgent、normal、low三个队列。Worker消费时优先读urgent再读normal最后读low。用多条Stream模拟优先级队列比把所有任务塞进一条队列、到Worker里再排序要简单得多也符合实际任务分布——高优先级任务永远是少数。超时控制是任务分发里最容易疏忽的一环。任务进队列时除了任务本身的数据我还会在ZSet里记录一条“task_id - 预计超时时间戳”的索引。调度器每秒扫描一次ZSet发现当前时间已超过超时时间戳且任务状态仍不是终态就把任务标记为timeout再决定重新投递还是进入dead队列。这里有一个关键点超时时间不能一刀切等会儿踩坑部分我会专门展开。任务重试也不是简单把原任务再投一次就完事。我在重投时会带上retry_count和last_error字段既让Worker在日志里看到这是第几次重试、上次为什么失败也能在调度侧根据重试次数判断是否放弃。重试阈值要分错误类型模型API限流这类瞬时错误重试价值很高业务参数错误这类确定性错误重试多少次都白费不如直接进dead队列人工看。3.2 Worker侧消费、幂等处理与Agent会话重置Worker侧的代码逻辑比调度器更贴近Hermes Agent本身。每个Worker进程起来后先初始化一个Agent实例然后进入循环从队列取任务、执行、回传结果、取下一个任务。消费时最关键的是幂等处理。Redis Stream的消费者组能保证一条消息只被组内一个消费者消费但“只被消费一次”不等于“只被处理一次”。Worker从队列拿到任务、开始执行后如果执行到一半进程崩溃这条消息会因为没有ACK被重新投递给另一个Worker。如果新Worker不做幂等检查同一个任务就会被执行两遍。对LLM调用和工具调用这类有外部副作用的操作重复执行要非常小心。我用的幂等方案是给每个任务加一个processing标记Worker开始执行前用SETNX task_processing:{task_id} 当前worker标识 EX 300只有设置成功才真正执行任务执行完删除标记。第二个Worker拿到同一任务时发现标记还在就直接放弃等待消息过期后重新投递。这套方案在分布式系统里不算严密但用在个人项目的多实例场景下足够可靠。还有一个很容易踩的坑Agent会话状态。同一个Worker进程会连续处理几十个甚至几百个任务如果不重置Hermes Agent的会话上下文模型会把上一个任务的信息当成当前任务的背景知识。我早期就吃过这个亏明明是不同租户的数据解析任务结果A租户的结论串到了B租户的结果里。现在的做法是每个任务处理前强制对Agent做一次会话重置创建一个全新上下文对象任务结束后直接丢弃不留任何残留。提示Agent会话重置不是调一个reset函数那么简单要确认历史消息、工具调用记录、暂存状态全部清理干净否则表面重置了历史信息其实还残留着。3.3 结果合并与失败兜底单点任务失败不影响整批Worker执行完任务后把结果写回结果通道。我的设计是结果写入Redis键名格式为task_result:{task_id}TTL设为24小时同时XACK确认消息消费完成再把任务的最终状态写入任务状态表。调度器汇总一批任务时直接查这些结果键就行。结果回传也会遇到失败。常见场景是任务执行成功但Worker在回传结果时进程崩了导致这条消息没得到确认随后被重新投递。因为任务已经成功执行过再次执行就会重复。针对这个问题Worker在执行任务前会生成一个唯一的execution_id回传结果时带上。调度器发现同一个task_id带着新execution_id的结果回来时就知道是重复执行会丢弃第二次返回的内容。失败兜底我分了三级。第一级是单任务重试最多重试3次间隔递增第二级是任务级熔断如果某个type的任务短时间内连续失败超过5次调度器自动暂停该类型任务的投递并发出告警第三级是批次兜底允许一个批次里有少量任务失败但不允许整批因为某个任务卡住而停摆——所有失败任务都会进dead队列批次汇总报告里标出来事后统一处理。4. 多实例协同不只是“多个Worker”还有角色分工4.1 共享上下文的实现方式前面讲更多的是“任务分发”也就是把相互独立的任务并行跑起来。但真实场景里不少任务之间存在共享信息的需求。比如一批任务围绕同一个客户做分析每个任务的提示词都要带客户基础信息又比如后一个任务需要用到前一个任务的输出。我的做法是把共享上下文放到Redis里不塞进任务消息体。任务消息体只放task_id和核心参数Worker执行时按需去Redis读取共享上下文。这样有两个好处一是避免任务消息体变得臃肿二是多个任务可以共享同一份上下文上下文更新后所有相关任务看到的是最新值不需要重新投递任务。共享上下文的更新要考虑并发。几个Worker同时写同一个上下文键时我用Redis分布式锁保证同一时刻只有一个Worker更新。锁的粒度要尽量小——只锁要修改的上下文键而不是锁住整个任务处理流程。锁超时也很有讲究太短任务没写完锁就释放了太长其他Worker要等很久。4.2 任务依赖编排从并行到分支汇聚完全并行的任务分发是最简单的情况现实中更常见的是任务之间有依赖关系。比如“提取文档信息”的任务要先完成“基于信息生成报告”的任务才能开始。为此我在任务数据里加了parent_task_id字段调度器生成任务时把依赖关系记录下来。依赖编排我采用了一个比较轻量的方案批次内的任务分成多个阶段调度器按阶段下发。每个阶段的任务都完成之后再下发下一阶段。这样避免实现一个完整的DAG调度引擎代码复杂度可控同时也能满足大多数批处理场景的需求。如果依赖图确实复杂要进入分支汇聚的阶段比如第1层2个任务、第2层3个任务、第3层汇总成1个任务我就在调度器里维护一个任务依赖树。每个任务完成时调度器把完成事件注册到依赖树上触发后续任务的就绪判断。这里提醒一句依赖越复杂出错定位成本越高。如果不是必须尽量把任务设计成扁平结构让尽量多的任务能并行依赖关系越少越好。4.3 多Agent角色协同规划、执行与审核分离任务分发之外我还实践了另一种协同方式多个Agent承担不同角色共同完成一个目标。这比单纯“你干你的、我干我的”更进一步Agent之间是有分工、有上下游的。我常用的一套分工是规划Agent、执行Agent、审核Agent。规划Agent负责把一个大目标拆解成可执行的任务列表执行Agent基于任务列表去调用工具、搜索、生成内容审核Agent专门对执行结果做校验——检查格式、验证数据一致性、判断内容质量。三个角色各跑一个或多个独立实例通过共享任务队列和结果通道衔接。这种角色化协同最大的价值是把“驾驶”和“质检”分开。单Agent模式下Agent既要想着怎么完成目标又要检查自己的输出这个过程既容易遗漏也容易自欺欺人——模型生成的结果让它自己判断往往会得到“没问题”的答复。有了独立审核Agent等于加了一道外部检查很多低级格式错误和数据错误能在进入下一步之前被拦下来。协同还有一个值得说的细节Agent之间的“对话”用什么协议。我试验过两种。一种是直接把上游Agent的输出作为下游Agent的输入提示词简单直接但信息密度低下游Agent要在一大段文字里找自己需要的信息另一种是上游Agent把结果整理成结构化JSON写入共享存储下游按需拉取字段。实测下来结构化协议比自然语言协议稳定很多输出格式准确率、下游处理效率都有明显提升。5. 实测数据与踩坑记录跑通容易跑稳很难5.1 三个Worker实例的吞吐量实测架构改造完我先拿之前那批100个文档任务做了对比测试。执行环境是一台32核CPU的服务器模型走远程API。单实例串行模式下100个任务平均耗时约200分钟。换成3个Worker实例并行后耗时降到约75分钟接近1/3。理论上3个实例应该接近1/3耗时多出来的时间主要来自任务队列读取、结果回传等待、以及少量任务重试的额外开销。我又试过把Worker加到6个发现耗时并没有继续等比例下降只降到约55分钟。瓶颈从任务执行转移到了模型API并发限制——6个Worker同时调用API触发限流不少请求需要重试反而拖慢整体效率。这个结果说明多实例不等于越多越好Worker数量要根据下游系统的承载力来确定盲目堆Worker不会线性提速。5.2 踩坑一并发调用LLM被限流限流是我遇到的第一个现实问题。远程API方式下单个账号通常有每分钟请求数限制和每分钟Token数限制。6个Worker同时跑每个Worker内部又有自己的多轮循环瞬时请求量很容易触顶。解决办法有两层第一层在Worker内部做请求限速用一个令牌桶把每个Worker的请求速率控制在安全范围内第二层在调度器上控制同时运行的Worker数量从源头限制并发总量。如果业务对速度要求更高更彻底的方案是申请更高API配额或者换用支持更高并发的模型网关。5.3 踩坑二本地方案显存溢出后来我尝试把一部分任务切到本地方案用自己显卡跑模型。单个Hermes Agent实例没问题两个Worker各跑一个模型实例时显存直接爆了。根因很直接多实例模式下每个Worker进程都独立加载一份模型权重模型参数在显存里堆了两份、三份自然不够用。解决办法是把模型服务化模型只加载一份通过一个支持高并发的推理服务对外提供接口所有Worker共享同一个模型服务而不是各自加载模型。这样做之后显存占用从“Worker数量乘以单份模型大小”变成“单份模型大小加一点显存开销”推理服务的调度还能把并发请求管理得更高效。如果你也打算用本地方案跑Hermes Agent多实例建议一开始就把模型服务化纳入设计别等爆显存了再改。5.4 踩坑三任务超时判定太粗暴超时策略我一开始写得很简单所有任务统一给300秒超时。结果一批数据量差异很大的任务跑下来误判率非常高——简单任务几十秒就完成复杂任务跑到5分钟还没结束被标记成超时重投到另一个Worker两个Worker同时跑同一个任务结果互相覆盖白白浪费算力。后来我把超时设置改成按任务type区分不同类型任务配置不同超时时间调度器扫描时按类型读取对应阈值。同时给超时任务增加一个“宽限期”第一次触发超时不立即重投等宽限期过了任务还是没结束再执行重投。宽限期默认值我设为基础超时的20%实测下来误判率下降了很多。5.5 踩坑四Agent上下文污染导致结果串味前面提到的会话上下文污染实际出现频率比想象中高。比如同一个Worker处理两个相似任务时生成第二个任务摘要时偶尔会把第一个任务里的公司名称揉进结果。排查这类问题难度很高因为偶尔出现的串味结果格式完全正常如果不做逐条交叉校验根本发现不了。我最终的解决方案有两个。前置方案是每个任务都显式重置Agent会话绝不复用后置方案是增加一个自动化交叉校验环节对一批任务结果做字段一致性抽查比如检查结果中的公司名称是否落在该任务预期出现的集合里。两个方案配合之后串味问题基本消除。6. 从“任务队列”到“协作网络”后续可扩展的方向6.1 动态扩缩容与Worker健康检查目前我的Worker数量是写死在配置里的但真实业务任务量有波峰波谷。后续计划给Worker加动态扩缩容机制调度器根据队列积压情况动态调整Worker数量任务量大时自动多起几个Worker实例闲下来再回收。实现上不复杂把Worker进程交给进程管理器统一管理调度器通过心跳感知每个Worker的存活和繁忙状态需要扩容时下发指令拉起新Worker。Worker健康检查值得单独做。多实例场景下某个Worker可能因为内存泄漏、连接泄漏进入“假死”状态——进程还活着但已经无法正常处理任务。我的做法是给每个Worker的日志加心跳输出调度器根据心跳时间戳判断Worker是否健康连续几次心跳超时就主动重启把它已领取但没完成的任务重新投递回队列。6.2 人工审批节点与可观测性实际业务里有些任务的结果不能直接放行需要人来确认比如自动生成的重要邮件、涉及金额的数据变更。我准备在状态机里增加一个awaiting_approval状态Agent完成任务后不直接进入succeeded而是进入待审批状态把结果推送给相关人确认。批准后任务才算真正完成驳回则带修改意见重新下发。这一步把自动化和人的判断结合起来——并不是所有环节都交给Agent自动化流程反而更可靠。可观测性方面目前主要看日志和Redis里的状态数据。后续计划把任务队列长度、任务各状态分布、Worker运行状态、模型调用耗时和成功率这些指标接上监控面板在批量任务出问题的时候做到尽早发现、尽早定位。6.3 多Agent协同的下一步角色化协同我已经跑通了规划、执行、审核三个角色的基本流程后续想做的方向有三个。一是把协同协议从“任务下发-结果回传”扩展成更灵活的“事件驱动”模式Agent之间直接订阅对方发布的事件像消息总线一样协作二是引入反馈闭环让审核Agent发现的问题反哺给规划Agent下一轮任务拆解时自动修正同类问题三是把协同策略沉淀成可复用的配置模板不同项目通过加载不同模板快速调整Agent数量、角色分工和任务协议。目前这套多实例任务分发架构已经稳定跑了一个多月累计处理了几千个批量任务。从最初被单实例堵到怀疑人生到现在多实例并行、自动重试、失败兜底、角色分工都跑顺最深的体会是Agent批量化的难点不只是把框架跑起来更在于任务怎么设计结构化、状态怎么管理、失败怎么兜底、实例多了之后怎么让它们各干各的还不互相干扰。先把这些基础问题想清楚再去堆Worker数量才有意义。最后分享一个小技巧起步阶段别一上来就追求复杂架构先用一个调度器加两个Worker把全链路跑通再根据瓶颈决定要不要加实例、加队列、加角色分工顺序反了容易把自己绕进去。