
同一个对话里既查资料又写长文,做到中途常常停下来问要不要继续,后文也容易跟着前面的偏差走。Mavis 用 团队引擎 把这件事拆开:统筹角色先确认目标并分派,执行角色只拿自己的工具和上下文,验收角色再看事实来源、覆盖范围和风险边界。核验不通过就回到产出环节改,而不是自己宣布完成。聊天软件里它会先说已经开始,你还可以中途加要求。适合要交出可核对的研究、代码或长文档的人。改一个错字、换一个常量,继续用单个助手更合适。
MiniMax 把升级后的智能体命名为 Mavis,取意是一个能长期协作的管家。用户仍只发一条目标。任务又长又复杂时,桌面端可以拉起多个角色并行:统筹角色拆结构,执行角色分头做检索、代码或文档,验收角色再核对来源和风险。团队引擎按产出、核验、完成管理状态,核验失败会退回修改。即时通讯里它会先回复已收到,再在后台继续。官方明确写了短任务、低风险任务不必组队。
使用门槛: 需要一定基础
统筹执行与验收
统筹角色把目标变成任务结构,执行角色按专业分头做,验收角色把完成改成可以交付,二者形成对抗式往返。
团队引擎状态流转
每个任务按产出、核验、完成推进。核验失败会重新唤起产出节点,统筹角色还能给正在跑的角色补提示。
聊天里的异步推进
即时通讯场景先快速回复已收到,长任务在后台拆开并行,并在开始、阻塞、需要决定和完成时汇报。
代码与研究分工
代码任务可分成实现、测试和审查;研究任务并行收集来源,再由验收角色核对链接和反面证据。
长文研究后排版交付
需要同时交 Markdown 和网页版本时,检索、写作和格式检查分给不同角色,并核对引用。
跨文件的代码修改
改动涉及多个文件时,实现、跑测试和审查分开,失败日志可以退回继续改。
聊天软件里的后台任务
人在飞书或类似对话里丢下一个长任务,先得到确认,再等阻塞或完成的汇报,不必盯着一个窗口。
官方把团队写成可选项。任务链路长、要并行、结果必须核验时再用。改错字、替换常量,单个助手或脚本更合适。研究、跨文件代码和正式长文档才值得拆成统筹、执行、验收。没有验收标准和停止条件的群聊式分工,文中认为并不能提高交付质量。
引擎用状态机管理每个角色的一轮运行,顺序是产出、核验、完成。核验不通过就重新唤起产出节点修改。统筹角色能看到最新状态,也可以向正在运行的角色追加说明。这和只调用一次子任务、等一段文字返回的做法不同,中间可以多轮沟通。
来自真实用户的评价和反馈