返回信息流
新闻事件
idoubi (X)
1 个来源

Douchat 接入 Jev:让多个 Agent 围绕任务协作

Douchat 接入 Jev,尝试把群聊中的多个 Agent 从轮流回复消息转变为围绕任务协作。系统由 Jev 负责结构化判断,LLM 负责规划和执行,程序负责调度、状态记录和故障恢复,并支持 Leader 选择、任务分工、串并行执行和故障恢复。作者还计划升级为显式 DAG,并补充任务级监工、结构化接管和结果验收等能力。

SynthePulse Insight · AI 深度解读

多 Agent 群聊的下一道题:从“轮流发言”到“责任到人”

版本 1 · 1 个来源

Douchat 接入 Jev 后,把群聊里多个 Agent 的协作方式从轮流回复消息改成围绕任务分工。这套机制的关键不在模型能力,而在于把“谁来做、交付什么、依赖谁、何时算完成”写进程序。

  • Douchat 接入 Jev,目标是让群聊中的多个 Agent 从轮流回复消息转为围绕一个任务协作。
  • 整体分工是 Jev 负责结构化判断、LLM 负责规划与执行、程序负责调度、状态记录和故障恢复。
  • 决策层先判断五种情形:无需回复、单成员处理、多成员独立并行、按顺序完成、进入复杂任务规划。
  • 当前支持单人、串行和并行执行,并行最多同时执行 4 个成员。
  • 显式 DAG、任务级监工、结构化接管和结果验收均属“接下来想补齐”的计划,来源未说明是否已实现。
展开章节目录问题不在模型,而在“谁该说话”

问题不在模型,而在“谁该说话”

多 Agent 群聊最常见的形态是轮流发言:每个 Agent 依次对同一条消息给出回应。Douchat 最近接入 Jev,尝试把这种模式改成围绕一个任务协作——不是每条群消息都需要所有 Agent 回复,而是先判断这件事到底需不需要协作、需要谁来协作。

作者把整体思路拆成三层:Jev 负责结构化判断,LLM 负责规划和执行,程序负责调度、状态记录和故障恢复。这个划分本身透露了设计取向:判断与执行分开,而调度和状态这类容易出错、又必须可靠的部分交给程序,而不是交给模型自由发挥。

需要说明的是,以上均来自作者在 X 上的自述,属于来源方主张,尚无第三方验证或性能数据支撑。

两种决策模式与一条回退路径

产品提供两种决策模式。默认决策复用群成员配置的 LLM,不需要单独配置决策模型;Jev 决策使用 Douchat 云端决策服务,会消耗决策积分。决策模型只负责“谁来做、怎么组织”,真正执行任务时各个 Agent 仍使用自己的模型和工具。

这里有一条明确的兜底路径:当 Jev 不可用、判断不确定,或者任务需要复杂规划时,会自动回退到成员 LLM。也就是说,Jev 决策并非唯一通路,系统在判断力不足时会把决策权交还给成员模型。

来源没有给出 Jev 决策模式的具体积分消耗量或计费规则,也没有说明这套集成是否已全量上线、面向哪些用户、处于何种发布阶段。

Leader 是组织者,派发由程序完成

新任务进入群聊后,程序先检查成员的可用性,再结合任务、群聊上下文和成员能力选择 Leader。默认模式由成员 LLM 返回 Leader 和执行计划,Jev 模式则通过 Choice 选择适合的 Leader。Leader 不固定为群里的第一个 Agent;对于同一个任务的后续协作,会尽量保留健康且合适的 Leader,避免频繁切换。

一个容易被误读的点是 Leader 的权限边界。按作者描述,Leader 是任务组织者,真正的派发、超时处理和状态持久化由程序完成。换句话说,Leader 承担的是组织角色,而不是调度器本身。

作者还提到,不要求 Leader 每次都先说一句“收到”:能直接开始的工作就直接开始,需要主持、准备或澄清时才先由 Leader 发言。

先判断要不要协作,再决定怎么协作

决策层要回答的第一个问题不是“谁来做”,而是“要不要做”。作者列出五种判断结果:无需回复、由一个成员直接处理、由多个成员独立并行处理、按顺序完成成员贡献,以及进入更复杂的任务规划。

在成员筛选上,当前 Jev 会通过 Noul 逐个判断候选成员是否仍有必要参与:明确相关的入选,明确不相关的排除,判断模糊时交给 LLM 进一步规划。为了减少等待,Leader 选择、路由和成员相关性等相对独立的问题可以合在一次 Jev 请求里处理。

来源没有说明 Jev 与 Noul、Choice、Score 等组件的具体技术实现与相互关系细节,因此这里只能描述它们各自承担的角色,无法还原完整调用链。

执行方式与它的硬边界

当前支持单人、串行和并行三种执行方式。串行任务中,后续成员能看到前序结果;独立任务可以并行,最多同时执行 4 个成员。简单任务直接分配,复杂任务由成员 LLM 生成计划,明确哪些成员参与、每个成员具体交付什么、按什么顺序执行、是否需要 Leader 最后汇总,以及是否缺少必要信息需要先等待用户补充。

并行上限 4 个成员是一条明确的约束,但来源没有说明这个上限是否可配置或会调整。执行过程还设有次数和超时限制,目的是避免 Agent 无限互相交接。

失败之后:不冒充、不静默跳过、不盲目重跑

成员执行失败后,调度器会再次请求决策,选择跳过、替补或暂停。不同任务的处理方式不同:个人参与类任务不能由别人冒充完成;明确要求的交付物不能因为成员失败就被静默跳过。

已完成的结果会被记录下来。对于中断后可能已经产生外部操作的步骤,系统不会盲目重跑——这是一条偏保守的约束,代价是可能牺牲一部分自动恢复的流畅度,换取避免重复副作用。

需要继续协作时,决策层结合已有结果安排下一步;需要用户补充时进入等待;完成后由 Leader 按需汇总。

下一步:显式 DAG 与三项待补能力

作者明确表示,目前的计划主要还是“成员分工+串行/并行”,下一步希望升级为显式 DAG,并给出示例链路:A、B 并行调研 → C 整理方案 → A 审核 → Leader 汇总。每个任务节点拥有独立 ID、依赖、执行者、交付物和状态,由程序根据依赖推进。

在此基础上还计划补三件事:任务级监工,由执行器上报心跳、实际进展和阻塞原因,区分“还在线”和“还在推进”;结构化接管,让替补继承已完成工作、产物和剩余任务,避免从头再来或重复操作;结果验收,每轮先检查交付物是否满足要求,再决定完成、返工或继续拆解。成员选择也可以进一步引入 Score,针对不同子任务评估适配度,同时考虑置信度和团队能力覆盖。

这些都属于“接下来想补齐”的方向,来源未说明是否已经实现。来源也没有提供任何性能、成功率或对比基准数据来验证该协作机制的实际效果。

可信度边界

本文全部内容基于作者 idoubi 在 X 上发布的一篇产品自述帖(2026 年 9 月 24 日,浏览量约 4,000),属于第一方来源方主张,而非独立验证结论。文中涉及的功能、模式、上限与计划,均按来源表述记录,未做事实升级;显式 DAG、任务级监工、结构化接管、结果验收和 Score 成员选择均为计划项,来源未说明实现状态。来源未提供性能、成功率或对比基准数据,也未说明该集成的发布阶段与适用范围。

核心结论

这套方案真正值得关注的地方,不是 Jev 的判断有多强,而是它把多 Agent 协作的难点从“模型会不会说话”挪到了“责任是否明确”:为什么需要你、你要交付什么、依赖谁的结果、什么情况下才算完成。显式 DAG 和三项待补能力,都是围绕这个命题展开的工程化尝试,但目前仍停留在计划层面。

主报道

idoubi (X)

主报道来源