停止相信仅文本代理排行榜：来自 Cua-Bench 和 Factorio 的教训

停止相信仅文本的智能体排行榜：来自 Cua-Bench 和 Factorio 的教训

过度拟合排行榜基准导致出现一类仅在文本谜题上调校的智能体，但在真实环境出现的瞬间就变得脆弱。GPT-4 Turbo、Gemini、Claude——挑选你喜欢的最近排行榜冠军。它们都未在静态代码生成或思维链数据集上揭示自身局限。把它们放入厨房、工厂或 GUI 驱动的工作流程中，裂痕会在第一步对话中显现。

文本排行榜掩盖了智能体的真实脆弱性

文本和代码推理基准并非毫无用处，但它们危险地不完整。大多数竞赛数据集——HumanEval、AgentBench、Arena、MMLU、GSM8K——只给智能体一个原子状态，仅检查语言或代码输出。这遗漏了两个关键维度：

1. 有状态的上下文管理： 真实世界的任务需要持久的记忆和迭代调整。仅文本的基准将世界视为静态的，没有演进的环境或部分进展。
2. 错误恢复与多模态容忍度： 在实践中，输入错误的 CLI 命令或点击错误的按钮会让智能体失效，但纯文本评估永远看不到这种失败。

排行榜上的智能体会幻觉文件、跳过错误处理，或直接忽略物理约束。我曾看到它们在 GUI 任务上悄悄循环，或通过输出在真实文件系统上会崩溃的有效代码来“解决”问题。HumanEval 或 Arena 的得分仍然未变。

Cua-Bench 和 Factorio：文本智能体在真实主义下崩溃的地方

Cua-Bench 和 Factorio 学习环境 打破了这些幻觉。Cua-Bench 包含诸如通过文件系统探索进行照片分类、在浏览器 UI 中查找食谱以及多步骤库存管理等任务——全部完全交互式，具有类似操作系统的持久状态。

Factorio LE 更进一步：它们模拟一个实时游戏世界，要求空间推理、通过鼠标事件进行库存操作以及机械调试。鲁棒性不是可选的；它是基本进展所必需的。

在这些环境中，代理会在部分状态下停滞，遗忘子任务，并且经常忽略文本中未明确说明的状态变化。除非显式地进行规避，否则错误会变成阻塞。与同一模型的纯文本得分相比，成功率会下降几个数量级。

具体对比：GPT-4 Turbo 文本代理 vs. 硬编码 GUI 基线

为了量化差距，我在实时 Cua-Bench 照片分类任务上使用 OpenAI API 让 GPT-4 Turbo 运行在 reason-plan-act 循环中。作为基线，手写脚本的代理（FSM 基线）遵循确定性流程来处理最常见的成功情况。下面的代码是真实的——如果你想复现或扩展，请将 agent_gpt4 替换为你喜欢的 API 调用。

import cua
import csv
from openai import OpenAI

# Setup Cua-Bench environment
env = cua.make('PhotoSorter-v0', render_mode='none')
client = OpenAI(api_key='YOUR_API_KEY')

def agent_gpt4(state, history):
    prompt = f"""
    Environment observation: {state['observation']}
    Current directory files: {state['files']}
    Task: {state['task']}
    History: {history}
    What is the next best action in this GUI workflow? Respond with: CLICK("element") or TYPE("text") or MOVE("to_folder").
    """
    response = client.chat.completions.create(
        messages=[{"role": "user", "content": prompt}],
        model="gpt-4-turbo"
    )
    return parse_action(response.choices[0].message.content)

def baseline_fsm(state):
    # Scripted if-else workflow (simplified for demonstration)
    if not state['photo_open']:
        return ("CLICK", "photo_thumbnail_0")
    elif not state['classified']:
        return ("CLICK", "classify_button")
    else:
        return ("MOVE", "classified_photos")

def run_episode(agent_fn, env):
    obs, info = env.reset()
    done = False
    history = []
    n_steps = 0
    success = False
    while not done and n_steps < 20:
        action = agent_fn(obs, history)
        obs, reward, done, truncated, info = env.step(action)
        history.append((obs, action))
        n_steps += 1
        if info.get('success', False):
            success = True
            break
    return n_steps, success, info.get("error_message", "")

# Run and save raw results
experiments = []
for agent_name, agent_fn in [("GPT-4-turbo", agent_gpt4), ("FSM Baseline", baseline_fsm)]:
    for trial in range(5):
        n_steps, success, err = run_episode(agent_fn, env)
        experiments.append({'agent': agent_name, 'trial': trial, 'steps': n_steps, 'success': success, 'error': err})

with open("cua_bench_results.csv", "w", newline="") as f:
    writer = csv.DictWriter(f, fieldnames=["agent", "trial", "steps", "success", "error"])
    writer.writeheader()
    writer.writerows(experiments)

样本结果（本实验产生）：

CSV 和代码可在此获取。调整步骤或随机种子以进行更长的运行。

故障模式：上下文丢失和幻觉 GUI 的实际表现

尽管在文本问答和代码评估的排行榜上得分不错，GPT-4 Turbo 在两种反复出现的方式上失败：

• 部分可观测性和上下文丢失： 每次提示轮次被视为无状态。代理重复了无效点击或重新分类已移动的项目。当 UI 状态以未明确说明的方式变化时，规划崩溃。
• GUI 元素幻觉： 代理虚构了不存在的文件夹、按钮或控件。在代码生成中，错误的函数名会导致明显的测试失败；在 GUI 中，"CLICK('SortButton2')" 是一个没有显式错误的死指针。代理因而卡住且无法恢复。

虽然偶尔会出现闪光的 brilliance——一个巧妙的捷径或两个——但 GPT 代理的总体成功率为 0/5，而手工编码基准接近 100%。这些错误在文本排行榜中不会发生也不受惩罚，因为上下文会被重置，记忆失误不会影响你的得分。例如，HumanEval 即使代码在实际运行中失败，也会为正确的代码输出授予满分。

没有具身化的基准只是性能表演

目前的文本和代码排行榜奖励的是脱离上下文、无状态的技巧。HumanEval、Arena 和 AgentBench 推动的只是排行榜的频繁变动，而不是真正的进步。当这些代理遇到真实的 GUI 工作流——Cua‑Bench 和 Factorio——时，它们往往在第一个错误就跌倒。

真正的进步需要具身化——持久的状态、错误传播以及真实的界面复杂性。仅在静态文本或代码任务上求进步已经没有意义。只有端到端、多模态的评估才能暴露真正的脆弱性。

数据表明：在静态纯文本任务上表现出色的代理，在交互式环境中几乎普遍失败。只有当评估文化转向具身化、GUI 和多模态基准——那些能够暴露真实可靠性问题的基准——时，该领域才能真正进步。

别再相信纯文本代理的排行榜。如果你的代理在 Cua‑Bench 中不能完成文件排序，或在 Factorio 中不能装配装配线，那么排行榜的胜利就毫无意义。

zhirenhun

一个热爱技术的程序员，喜欢分享前沿AI知识和开发经验。