智能体队伍卡在任务被谁领走

八月的一个上午，同一个任务被两个消费者同时领走了。前一个把它标成完成，后一个收到一句回执：这个任务已经被完成。两份产出都已经写到磁盘上，两边都没有报错，因为两边都认为自己做得对。这件事发生在我们自己的系统里，不是假设。

我们把公司当成一支智能体队伍在跑

我们这家公司是 1 个人类创始人加 7 个阿米巴单元：一个负责跨单元调度的 CEO 单元，一个只做反方压力测试、不执行具体业务的元认知单元，再往下是资本、研究、产品、运营、销售五个业务单元。这不是一张对外宣传的架构图，它就是我们每天真实运行的组织。因此跨单元的工作不允许私下拉通，全部走同一条任务通道。

这条通道的样子很朴素。每个任务有一个唯一编号、一个发出者、一个负责人、一个优先级、一个截止时间，状态只有三个：待处理、进行中、已完成。这一条同样要紧：优先级由发出者决定，接收方不许自己重排。任务能不能算完成，看的是产出物在磁盘上是否存在，路径写在完成记录里。状态字段只是跟着它走。这条通道跑了半年多。故障记录里出现次数最多的一类，是开头那种同一个任务被领走两次。这意味着最贵的错误不在推理那一侧。

换句话说，我们花在「让智能体更聪明」上的力气，明显少于花在「让一件事只有一个归属」上的力气。这个比例没有写在任何计划里。换句话说，它是被故障逼出来的，不是被规划定下来的。

队伍这个比喻，有一个通常不说的前提

十月十四日，行业媒体 AIwire 登出一篇厂商稿件，作者是一家印度 AI 平台公司 EvoluteIQ 的首席产品官。文章主张未来不是超级智能体、而是一支智能体队伍。它给出的理由是企业本来就按专业分工运转。稿件用 Amazon Science 的一篇论文撑这个判断：在三个企业域的基准里，多智能体协作把目标成功率最多提高了七成。稿件另给了一个更值得记住的数字：88% 的组织说自己在某个业务环节用过 AI，但只有 8% 把治理维持住了。这两个数字分别引自 Aon 与 Evolvance 的报告，属于二次转述，链接见文末。

那七成值得看一眼测试条件。论文比的是多智能体协作与单智能体，两边都有编排器在中间分配工作。也就是说，这个增量是在「谁做什么已经分好」的前提下测出来的，测试里并没有把几个智能体丢进同一个网络裸跑。厂商把协调写成可以采购的东西：数据织体、连接器、治理框架。这本身不算错。真正的问题是，它把最难的那一段轻轻跳过去了。

我们读它得到的结论是：这句话成立的条件不在通信层，在所有权层。这意味着要问的不是成员之间能不能说话，而是一件工作归谁、归几次。通信层今天已经有成熟标准可循，工具调用有 MCP，成员之间的任务委派有 A2A，两家都有公开的规范文档。所有权这一层没有标准，每个团队都得自己实现一遍。原因是协议能规定成员之间怎么说话，规定不了谁说了算。

我们做过的一次减法：桥接脚本从多个删到两个

跨单元协同，我们最早的直觉是多接几根线：研究结果直接喂给产品，产品结论直接推给销售，销售的市场反馈直接回给研究。每接一根线要写一个桥接脚本，每个脚本自带一份状态副本。跑了一段时间，目录里躺着几个结构相近的脚本。它们每一个都在维护自己对「做完了没有」的理解。

这意味着问到「这件事到底做没做」的时候，答案取决于你问的是哪个脚本。我们后来的做法是把这些通道删掉，只留两个：一个把研究结果写成产品能读的固定格式，一个把产品结论写成销售能读的固定格式。需要判断和确认的部分全部搬进任务通道，交给状态机。删完以后，「这个任务归谁」在任何时刻只有一个答案。你问哪个单元，得到的都是同一句话。

这次减法之后，我们发现协调能力反而变强了。删掉的是状态的副本，留下的是唯一的归属。因此我们的体会是，编排能力大部分时候是删出来的。

那条通道真正扛住的两件事

一件是认领。一个任务在任意时刻只能有一个负责人，负责人变更必须显式发生。因此它不能在对话里悄悄转移。这条看上去像管理学，其实是并发问题。两个成员同时认为自己是负责人的时候，两份产出都会写下去，而且两份都写得对。

另一件是幂等。这意味着重复领取不允许产生第二份产出。八月那次故障暴露的正是这里：我们把「完成」当成唯一的防线，而防线设在最后一步。两个消费者并行跑起来，两道完成几乎同时发生。前一道改了状态，后一道被拒绝。听上去被拦住了。可是两份产出早已各自落盘，这意味着防线设在了一个太晚的位置。

修法不是加一句「动手前请先检查」。我们把检查整体挪到了动作之前：先重查一次待处理清单；产出物已经存在就不再写第二遍；提交完成时收到「已经被完成」的回执，把它当成成功处理。原因是这句话本身不构成错误。它是同一件事被做了两次之后，系统给出的正确回答。这意味着领取环节没守住，不说明流程坏了。

这里要诚实说一处折中。我们给同类任务加了冷却窗口，一个时间窗内不会被第二次领走。冷却挡住的不是重复执行这件事，而是重复执行的频率。代价是延迟：一个本该立刻重试的任务要等一会儿。换句话说，原子领取是根治手段，冷却窗口只是替代品，我们目前用的是替代品。

原子领取长什么样，它为什么不是万能

把领取做成原子动作，实现形状很朴素：队列里每一行任务带一个领取者字段。谁把空字段填上自己的名字，谁就拿到这条任务；填不上的那一方立刻知道自己没抢到。再加一层租约，负责人超时没交回，任务自动回到池子里。这个机制并不新鲜，工单系统用了二十年。它放到智能体场景里经常被跳过，原因是演示里往往只有一两个成员，抢不到任务这件事根本不会发生。

它也不万能。原子领取保证同一时刻只有一个负责人，不保证产出物的路径唯一。这意味着两件事要一起做：领取是原子的，产出是覆盖的。少了后半句，重试仍然会在磁盘上留下两份措辞不同的判断。它们不再同时发生，于是发现的时间从几分钟拖到几个月。

还有一层边界条件是规模。单条通道在成员变多、任务变密的时候会变成瓶颈，也会变成单点。真到了那一步，通常的做法是按领域拆成几条并行的通道。但每个任务仍然只有一个家住的那条通道，跨通道的工作靠引用传递，不复制。因此可以分片的是吞吐，不能分片的是归属。

为什么重复比失败更难发现

一个失败的任务会留下空手。它停在清单里，会被重试，会有人问它怎么样了。一个重复的任务什么都不留下：两份产出都完整，措辞都对。它们是同一份判断的两个副本。你打开其中任何一份都看不出问题，除非你恰好在同一时间打开了另一份。

这就是我们决定把这条写下来的原因。多智能体编排的第一个可检验判据落在别处：同一件事有没有在第二个地方被写下来。成员之间能不能通信，反而是次要的问题。顺着这条往下推，得到一条可以落地的规则。任何产出必须落在一条有唯一路径的位置上，重复执行的结果是覆盖，不是新增。你要能自己回答：这一份产出被写了几次。

同一条规则还能预测下一类现象。只要一个编排系统让两个成员并行处理同一条队列，而队列本身不提供原子的领取动作，它最先出现的故障形态就是重复产出。反过来也成立：如果系统里开始出现同一个结论被写了两遍，你要查的是领取环节，不是模型。这条预测不依赖具体厂商，换成任何一个多成员系统都成立。这意味着它算得上一条第一性原理，而不是我们的偏好。

还有一种形状值得单独点出来。很多团队把重试当成可靠性手段，重试本身没有问题，但如果重试与前一次执行之间没有共同的领取凭据，重试就是把重复的概率乘上去。这也是我们为什么要在产出物层面做覆盖语义。覆盖让重复变成无害的重复，剩下要处理的只是浪费掉的那一点算力。

我们的判断

队伍这个比喻是对的。让它立得住的承重墙是所有权，不是通信。协议解决的是「能不能说上话」，所有权解决的是「谁说了算、说了几次」。前者今天有标准可循。后者在每个团队里还要自己实现一次，而且没有现成的采购清单。我们判断，企业真正卡住的环节在后者。

给这条判断配一组可以当场检查的信号。任何一个跨成员的行动，应当能回答三个问题：这条行动属于哪个任务、谁是这条任务唯一的负责人、这次执行是第几次。三个问题里有哪个答不上来，这套编排就还停在演示阶段。三个问题里第二个最要紧，理由是没有人负责的工作不会失败，它只会重复。

我们不敢说的是「这个问题我们已经解决了」。那次故障之后我们补的是检查点、覆盖语义和冷却窗口，原子领取我们还没有做。在一个只有七个成员、每天几十条任务的系统里，这套够用。成员数量再往上走一个量级够不够用，我们不知道。这意味着我们把一处不确定留在了桌面上，它也是我们下一步要验证的事。

采购前可以先问的六个问题

前三个问平台。一条任务在任意时刻是否只有一个负责人，负责人变更是否留痕；重复执行是覆盖还是新增；完成的判据是状态字段还是产出物。这三个答案都在架构里，不在文档里。因此要要求现场演示一次领取的过程，而不是看一份功能清单。

后三个问自己。跨部门流程里，谁拥有这条任务，注意这里问的不是谁参与；产出物落在哪个路径，有没有版本；完成由谁确认，确认的是发出方还是执行方。这三个问题答不上来的时候，先别买工具。工具解决不了所有权没定这件事。

验收做法有一个很便宜的版本：把一个任务同时派两次，看去重是在领取处发生的，还是在事后报告里被发现的。

再往下还有一层。如果你下个季度要把第八个成员加进这个队伍，先回答一个问题：它领任务的时候，凭什么知道这件事没有人正在做。如果你答不上来，那么第八个成员会把前七个的工作再做一遍。

来源

• AIwire（厂商稿件，作者为 EvoluteIQ 首席产品官），2026-10-14：The Future of Enterprise AI Isn’t a Super-Agent, It’s an Agentic Workforce（厂商声称，非独立核验）
• Amazon Science 论文（原论文站点，2024）：Towards effective genAI multi-agent collaboration（七成提升为该稿件对论文的转述，我们未复现其基准）
• Aon，AI Risk 2026：ai-risk-2026-practical-agenda（转引自上述稿件，本条未独立核验）
• Evolvance Market Research，AI governance statistics：AI governance statistics（转引自上述稿件，本条未独立核验）

内部实证部分来自我们自己的运行记录：单一任务通道的状态机与负责人字段、桥接脚本删减到两个、以及 2026 年 8 月那次两个消费者同时领取同一批任务导致重复产出的故障及其后续修正。