Douchat 接入 Jev，让群聊里的多个 Agent 围绕任务协作

Douchat × Jev：让多个 Agent 围绕任务协作 最近在 Douchat 接入了 Jev，尝试把群聊里的多个 Agent，从“轮流回复消息”变成“围绕一个任务协作”。 整体思路是：Jev 负责结构化判断，LLM 负责规划和执行，程序负责调度、状态记录和故障恢复。 下面是目前的实现，以及接下来想完善的方向。 ## 1. 决策配置 提供两种决策模式： - 默认决策：复用群成员配置的 LLM，不需要单独配置决策模型。 - Jev 决策：使用 Douchat 云端决策服务，消耗决策积分。 决策模型负责“谁来做、怎么组织”；真正执行任务时，各个 Agent 仍使用自己的模型和工具。 Jev 不可用、判断不确定，或者任务需要复杂规划时，会自动回退到成员 LLM。 ## 2. Leader 选择 新任务进入群聊后，程序先检查成员的可用性，再结合任务、群聊上下文和成员能力选择 Leader。 默认模式由成员 LLM 返回 Leader 和执行计划；Jev 模式通过 Choice 选择适合的 Leader。 Leader 不固定为群里的第一个 Agent。对于同一个任务的后续协作，会尽量保留健康且合适的 Leader，避免频繁切换。 这里的 Leader 是任务组织者，真正的派发、超时处理和状态持久化由程序完成。 ## 3. 判断是否需要协作 不是每条群消息都需要所有 Agent 回复。 决策层先判断当前应该： - 无需回复； - 由一个成员直接处理； - 由多个成员独立并行处理； - 按顺序完成成员贡献； - 进入更复杂的任务规划。 当前 Jev 会通过 Noul，逐个判断候选成员是否仍有必要参与。明确相关的成员入选，明确不相关的排除；判断模糊时交给 LLM 进一步规划。 Leader 选择、路由和成员相关性等独立问题，可以合在一次 Jev 请求里，减少多次请求的等待。 ## 4. 任务分工与执行 简单任务直接分配，复杂任务由成员 LLM 生成计划，明确： - 哪些成员参与； - 每个成员具体交付什么； - 按什么顺序执行； - 是否需要 Leader 最后汇总； - 是否缺少必要信息，需要先等待用户补充。 当前支持单人、串行和并行执行。串行任务中，后续成员能看到前序结果；独立任务可以并行，最多同时执行 4 个成员。 不要求 Leader 每次都先说一句“收到”。能直接开始的工作就直接开始，需要主持、准备或澄清时才先由 Leader 发言。 ## 5. 故障恢复与任务收尾 成员执行失败后，调度器会再次请求决策，选择跳过、替补或暂停。 不同任务的处理不同：个人参与类任务不能由别人冒充完成；明确要求的交付物不能因为成员失败就静默跳过。 已完成的结果会记录下来。对于中断后可能已经产生外部操作的步骤，不会盲目重跑。 需要继续协作时，决策层结合已有结果安排下一步；需要用户补充时进入等待；完成后由 Leader 按需汇总。执行过程也有次数和超时限制，避免 Agent 无限互相交接。 ## 6. 接下来想补齐的部分 目前的计划主要还是“成员分工＋串行／并行”，下一步希望升级为显式 DAG： A、B 并行调研 → C 整理方案 → A 审核 → Leader 汇总。 每个任务节点拥有独立 ID、依赖、执行者、交付物和状态，由程序根据依赖推进。 在此基础上，再补三件事： - 任务级监工：执行器上报心跳、实际进展和阻塞原因，区分“还在线”和“还在推进”。 - 结构化接管：替补继承已完成工作、产物和剩余任务，避免从头再来或重复操作。 - 结果验收：每轮先检查交付物是否满足要求，再决定完成、返工或继续拆解。 成员选择也可以进一步引入 Score，针对不同子任务评估适配度，同时考虑置信度和团队能力覆盖。 我觉得多 Agent 群聊真正难的地方，在于让每一次参与都有明确责任：为什么需要你、你要交付什么、依赖谁的结果，以及什么情况下才算完成。 --- 欢迎来 douchat.ai 建群玩谁是卧底。😄 idoubi @idoubicc 做协作类 agent 的关键点之一是，如何把多个不同能力的 agent 拉到同一个群组，让他们在无人干预的状态下，自主分工，协作完成复杂的任务。 要实现无监督自主运行，需要保证群组的整体可用性。比如一个群里面有 claude、codex、gemini、grok、openclaw、harmes 等 10 余个 agent，晚上睡觉前往群聊丢个任务：帮我写个对标 codex 的桌面 agent，明早起来验收。 要完成这个任务，首先需要有个任务协调者，也可以叫做 leader，由这个角色来负责理解任务，拆解任务，分配工作给群里的其他 agent。leader 自身可以不参与具体的工作，但是需要监控其他成员的工作状态，适当干预、调配工作。比如 claude 做 leader，让 codex、gemini、harmes 等成员分工去写代码，并要求他们每五分钟报告一次任务进度。期间 gemini 因为模型限额罢工了，leader 需要把罢工 agent 没干完的活分给其他空闲 agent 接着干。 协作类 agent 产品的设计难点和重点一定是群组的整体可用性建设问题。 多 agent 协作过程容易遇到的问题包括： 1. 某个成员 agent 因为模型限额或封禁、工具调用异常、网络等问题导致罢工 2. leader 不靠谱，分配任务不合理，成员 agent 之间容易干重复或者冲突 3. leader 自己挂了，缺了协调者，其他 agent 干完一轮不能继续干下去 4. 其他外部依赖异常（比如定时任务）导致整体进度没有往前推进 要通过 agent 协作实现全自动无人值守干活（比如建个群，让群里的 agent 每天晚上自己干 8 小时，去找到一些热点需求，做出产品，推给目标用户，让用户付费，实现产品商业闭环，人类群主躺着赚钱），需要一些关键的设计来保证群组的可用性： 1. 冗余机制。群内的 agent 成员，在条件允许下尽可能多配置，同类型的 agent 互为备份，按能力等级分组排序，比如 claude、codex 为一组，gemini、grok 为一组，kimi、zhipu 为一组，openclaw、harmes 为一组 2. 协调与监控。先指定一个 leader，比如 claude，由 leader 来理解任务、拆解任务、分配任务。发到群里的任务，leader 首先处理，从 agent 分组中按能力组合选择部分 agent 作为 worker 来执行任务。leader 需要定时查看群内的 agent 进度，如果发现某些 agent 进度异常或超时无响应，就从备份 agent 中挑选替换者，来接替异常 agent 继续完成任务 3. 进度上报。作为 worker 的 agent 需要定时把自己的任务进度上报到群组，方便 leader 和其他成员感知任务进度。 4. leader 选举。leader 跟所有的 worker 之间保持定时心跳，在 leader 挂了的情况下触发选举或由底层程序指定新的 leader，由新 leader 继续组织工作 5. 恢复机制和结果一致性。agent 协作过程中肯定会遇到各种异常问题，需要设置很多个 checkpoint（检查点），任务状态和依赖关系需要明确，支持断点恢复和幂等重入。继任的 worker 需要延续前任 worker 的工作进度继续推进，最终需要通过测试和验收来确认结果，不能只依赖 agent 自己报告完成 --- 最近在做协作类agent 产品，感觉分布式系统的可用性架构设计理论有很多可以参考的思路，我在 termany.sh 里面也实现了很多的策略，目标还是要把本地的多个 agent 聚合在一起，在无人值守模式下实现自主协作，共同完成复杂任务。 欢迎试用与交流。👇 termany.sh a 🔗 View Quoted Tweet 💬 0 🔄 1 ❤️ 1 👀 311 📊 1 ⚡