多智能体任务重复，如何判断是分工还是通信问题？

多智能体系统里出现任务重复执行，表面看是同一个任务被多个 Agent 处理，但根因往往分属两个完全不同的层面：分工边界问题和通信协议缺失。这两类问题的外在表现高度相似，内在机制却截然不同，修正方向也几乎相反。如果在错误的层面反复打补丁，问题只会持续反弹。

分工边界问题本质上是职责重叠。系统里两个 Agent 的职责描述都包含了同一个任务关键词，比如一个负责数据清洗，另一个负责特征提取，但两者的定义里都写着“识别异常数据并修正”，于是同一批脏数据被各自处理了一遍。这种重复是角色定义层面的缺陷，跟 Agent 之间能不能通信没有关系。即使通信协议做得再完善，两个 Agent 依然会同时接手同一个任务，因为它们都认为自己有权处理。通信协议缺失则是另一种情况：分工本身清晰，但 Agent 处理完数据后没有广播“已完成”状态，或者下游无法查询到上游的执行进度，于是保险起见又处理了一遍。这种重复是执行层面的信息不对称，问题出在状态感知机制上，而不是职责定义。

区分这两类根因有一个实用的思想实验：把通信机制全部停掉，看任务是否还会重复。如果停了通信重复依然存在，那就是分工问题；如果停了通信重复消失但系统直接跑不动，那才是通信问题。实际系统里往往两类问题同时存在，但这个判断方法能帮助快速定位主要矛盾。

落到具体系统里，有两个直接的观察点。第一个是看同一任务的触发来源：把日志按任务 ID 聚合，统计执行次数，再留意触发来源。如果同一个任务由多个不同的上游 Agent 各自发起，大概率是分工边界问题——每个上游都认为自己该发起这个任务；如果同一个任务由同一个上游反复发起，但下游每次都当作新任务处理，更可能是通信问题——下游无法感知到任务已被处理过。第二个观察点是看 Agent 之间有没有状态同步机制：是否存在共享的任务状态存储？执行前会不会先查询这个存储确认任务状态？执行完成后会不会把结果写回并标记“已完成”？如果三个答案都是否，通信协议大概率是缺失的。

分工问题的修正方向在角色定义和任务分配机制上。最核心的动作是给每个 Agent 划定明确且互斥的职责范围，把系统里的任务类型逐个确认归属，出现同一个任务关键词就必须调整，要么划给其中一个，要么加上明确的排除条款。另一个有效做法是引入任务分配的唯一责任方，由编排器或专门的任务调度 Agent 根据任务类型和职责匹配，决定每个任务只发给一个 Agent 执行，从机制上杜绝多个 Agent 同时接手同一任务的可能。这里要提醒一点：分工粒度不是越细越好，任务拆得过碎会增加交接频率和协调成本，合理的粒度是每个 Agent 负责一个相对完整、可独立交付的子任务。

通信问题的修正重点在状态共享和进度感知上。最基础的一步是建立共享的任务状态存储，所有 Agent 执行前先查询、执行中更新为“进行中”、完成后标记“已完成”，关键是所有 Agent 读写同一份数据。在此基础上可引入进度广播机制，Agent 完成任务后主动通知相关 Agent，减少下游的轮询等待。还有一个容易被忽略的点是超时重试策略：Agent 发起请求后超时未响应就默认失败并重试，但如果第一次请求其实已成功只是响应延迟，重试就会造成重复执行。解决思路是给每个请求生成唯一 ID，重试时带上同一个 ID，下游根据 ID 判断是否已处理过，处理过就直接返回之前的结果。

任务重复执行不是单点故障，而是系统设计缺陷的映射。建议把“重复执行检测”纳入日常监控，按任务 ID 聚合统计执行次数大于 1 的任务，定期回溯根因；在新增 Agent 或调整职责时，把“职责是否重叠”作为必检项。先通过日志和状态机制定位真正的根因，再有针对性地修正，才能避免在错误的层面反复打补丁。