Douchat adds Jev for multi-agent task collaboration
Douchat uses Jev's Choice to pick a leader, decide whether collaboration is needed and judge member relevance, while LLMs plan and execute and the program handles scheduling and failure recovery.
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 群聊真正难的地方，在于让每一次参与都有明确责任：为什么需要你、你要交付什么、依赖谁的结果，以及什么情况下才算完成。 --- 欢迎来 http://douchat.ai 建群玩谁是卧底。😄
This post quotes another post: x.com/idoubicc/status/2099745155817599464