多 Agent 是否更强？先统一评测条件

4 个 AI Agent 打败了 Minecraft 的末影龙，50 个 Agent 组成的殖民地却遇到了资源短缺。两个故事放在一起，很容易得出「小团队比大集群更有效」的结论。但原文真正想说的是：它们根本不是一场公平比赛。

作者没有证明多 Agent 更强，而是给出了一套评估方法：在相同任务和预算下，把成功率、耗时、资源消耗与协调成本摆在一起。对正在尝试 AI 并行编程的开发者，这比观看一场热闹的演示更有参考价值。

4 个打赢、50 个受挫，为什么不能拿来排名

先看两组实验究竟做了什么。

4 个 Agent 的实验在随机生成的世界里进行，难度为 Easy。它们编写了 2,783 个程序，死亡 605 次，用 27 小时 14 分钟完成目标。据研究作者介绍，Agent 通过聊天和共享记忆协调，没有人类预先分配角色，也没有人为提供游戏逻辑。

另一组 50 个 Agent 的目标是建立繁荣的文明。它们产生了约 5,900 条消息，很快耗尽附近的树木；总共 34 次死亡中，有 22 次发生在第一个夜晚。它们也形成了层级结构，并通过共享笔记管理食物，但更多成员同时带来了更多食物需求。

这些数字展示了不同的能力和失败方式，却不能证明哪种配置更好。两组实验的目标、模型、Agent 数量、运行时长和环境条件都不同，也没有提供统一条件下的单 Agent 对照。

Agent 数量是配置项，完成目标的效率才是评估对象。

单 Agent 的优势是协调路径少：不用处理成员分歧、重复分工和共享账本的一致性。多 Agent 可以并行搜集信息、拆分独立任务，也可能在某个成员卡住时继续推进，但要额外承担消息、集成、冲突和重试的成本。

关键不在于系统做了多少动作，而在于这些动作推进了多少目标。如果任务的每一步都依赖上一步，多几个 Agent 可能只是多几份上下文，以及更多等待。

先约定怎么判输赢，再启动 Agent

原文最实用的建议，是先把任务写成可观察的完成条件。

「做点厉害的东西」很难评分；「收集 20 单位资源 A，并放进指定仓库」就清楚得多。后者能判断是否完成，也能记录失败发生在哪里。

接着固定六项条件：

• 单 Agent 和多 Agent 接收相同目标，使用相同成功标准。
• 设定相同的总预算，可以是 token、工具调用次数或实际经过时间的上限。
• 保持初始环境、工具、权限和外部信息等价。
• 使用多个种子或初始状态重复试验。
• 统一在成功、失败或耗尽预算时停止。
• 每轮记录结果、耗时、token、动作和协调消息。

这里最容易漏算的是总预算。4 个 Agent 各自拿到一份完整额度，不能直接与只拿到一份额度的单 Agent 比较。并行模型调用都要计入账单。

消息也要先统一口径：一条广播送达 4 个 Agent，究竟算 1 条广播，还是 4 次投递？两种定义都能使用，但不能中途切换。

如果真要做 Minecraft 实验，原文提到 Mineflayer 可以提供机器人与游戏世界的接口。它提供 JavaScript API，也可通过 Python 使用，涵盖移动、背包、合成、挖掘、建造和聊天。不过，作者没有复现上述实验，下面的程序也不负责运行 Agent，只负责统计运行后的日志。

这份评分表为什么不直接选出冠军

每轮试验在 trials.jsonl 中保存一行 JSON。原文给出的最小记录如下，它展示了相同起点下两种配置的记账方式：

{"setup":"single","trial":"seed-01","success":true,"seconds":840,"tokens":12000,"actions":83,"messages":0}
{"setup":"swarm-4","trial":"seed-01","success":true,"seconds":510,"tokens":27800,"actions":121,"messages":34}

要看的是两行相同的 trial：seed-01 表示它们共享同一个初始条件。这只是记录格式示例，不能据此认定多 Agent 已经获胜。

下面是原文的 score.py，用于检查必需字段并按配置汇总结果：

import json
import statistics
import sys
from collections import defaultdict
from pathlib import Path

REQUIRED = {"setup", "trial", "success", "seconds", "tokens", "actions", "messages"}

def load_trials(path):
    groups = defaultdict(list)
    for line_no, line in enumerate(Path(path).read_text().splitlines(), 1):
        if not line.strip():
            continue
        row = json.loads(line)
        missing = REQUIRED - row.keys()
        if missing:
            raise ValueError(f"line {line_no}: missing {sorted(missing)}")
        if row["seconds"] < 0 or row["tokens"] < 0:
            raise ValueError(f"line {line_no}: seconds and tokens must be non-negative")
        groups[row["setup"]].append(row)
    return groups

def summarize(rows):
    successes = [r for r in rows if r["success"]]
    return {
        "trials": len(rows),
        "success_rate": len(successes) / len(rows),
        "median_seconds_all": statistics.median(r["seconds"] for r in rows),
        "median_tokens_all": statistics.median(r["tokens"] for r in rows),
        "median_actions_all": statistics.median(r["actions"] for r in rows),
        "median_messages_all": statistics.median(r["messages"] for r in rows),
        "median_seconds_success": (
            statistics.median(r["seconds"] for r in successes) if successes else None
        ),
    }

def main():
    path = sys.argv[1] if len(sys.argv) > 1 else "trials.jsonl"
    groups = load_trials(path)
    if not groups:
        raise SystemExit("No trial rows found")
    for setup, rows in sorted(groups.items()):
        print(setup, json.dumps(summarize(rows), sort_keys=True))

if __name__ == "__main__":
    main()

最该留意的是 median_seconds_all 与 median_seconds_success 两处统计：前者保留失败和超时试验的耗时，后者只看成功试验，避免只展示成功案例带来的错觉。

执行 python3 score.py trials.jsonl，就能分别看到各配置的成功率，以及耗时、token、动作和消息数量的中位数。中位数比平均值更不容易被单次异常快的结果拉偏，但仍应保存完整记录。

作者刻意没有把这些指标揉成一个总分。假设多 Agent 成功时更快，却更贵、失败更多，那么是否采用，要看业务能否接受重试，以及截止时间是否比成本更重要。

消息数量也不是协作质量。大量消息可能在交换有效信息，也可能只是反复确认。需要抽样读消息，才能分辨两者。

我的判断

我赞成先从单 Agent 建立基线，再判断是否增加成员。它让讨论从「哪个演示更震撼」回到「我的任务有没有收益」。

但原文没有提供作者自己完成的受控对照数据。关于多 Agent 适用条件的建议，应当看作工程经验和实验设计指导，不能当作已经验证的性能结论。

这份脚本也只是起点。虽然保存了 trial，统计时却只按 setup 分组，没有检查两组是否覆盖相同的初始条件，也没有计算成对差异或结果分布。它检查必需字段，以及耗时、token 是否非负，但没有完整校验字段类型、重复记录和其他计数。要支撑生产选型，还需要补充这些环节。

原文提出可以从成功、时间或质量判断收益，但当前记录里没有质量字段。对代码任务，测试通过、行为正确、可维护程度未必能由一个 success 布尔值充分表达，成功标准必须提前明确。

相比一次性拉起很多成员，我更认可作者建议的折中路径：少量 worker 接收边界清晰的任务，各自返回可验证结果，再由集成步骤检查重复和矛盾。前提是任务确实能拆开。如果所有工作都挤在同一个共享文件、协调者或受限工具上，加人很难解决吞吐瓶颈。

能拿来做什么

• 给日常 AI 编程建立一个单 Agent 基线，选定明确任务和验收标准，记录成功率、耗时与总 token，再用相同起点测试多 Agent 配置。
• 前端或 Node 项目尝试并行处理时，优先选择结果能够分别验收的独立任务，并安排明确的集成检查；连续依赖前一步结果的工作，可以先交给单 Agent。
• 给运行日志补上模型版本、提示词版本、工具权限和停止原因，保留失败记录，并检查两种配置是否完成了相同的一组试验。
• 增加 worker 前先查看瓶颈，抽样检查协调消息。如果时间主要花在共享资源等待、重复工作或结果冲突上，先修任务分工和共享状态管理。