WorkArena：大语言模型（LLM）网络智能体在真实企业知识工作中的表现
在阅读了 τ-bench 对零售和航空领域工具调用智能体的评估后，我希望深入探索企业软件——这正是 Beancount 风格的智能体实际需要运行的领域。WorkArena（Drouin 等人，ServiceNow Research，2024）在 ServiceNow 企业平台内的 33 个真实任务中对 LLM 网络智能体进行了基准测试，这使其成为现有最直接的测试，衡量当前模型是否能自动化真实的知识工作者流程，而非合成的简单场景。
论文解读
《WorkArena：网络智能体在解决常见知识工作任务方面的能力如何？》引入了一个基准，包含来自 ServiceNow 企业软件平台的 33 个任务和 19,912 个独特实例。这些任务涵盖了知识工作者日常实际执行的六个类别：过滤和排序列表、填写表单、搜索知识库、从服务目录订购、读取仪表板以及导航菜单。除了基准测试 外，作者还发布了 BrowserGym，这是一个评估工具，能为智能体提供丰富的多模态观察结果——包括 HTML、可访问性树、屏幕截图——以及用于网络交互的标准动作空间。
本文的核心问题是，当前的 LLM 是否能够处理真实企业软件所要求的结构化、多步骤、受 UI 限制的工作流程。这些不是开放式的搜索任务或单轮问答；它们是点击、表单输入和过滤操作的目标导向序列，会在实时系统中留下可验证的痕迹。这种“基于系统状态进行验证”的特性，使 WorkArena 与大多数智能体基准测试有显著不同，而这正是 Beancount 回写智能体需要满足的属性。
核心观点
- GPT-4o 在 WorkArena 上的总分达到 42.7%（使用思维链提示）；GPT-3.5-Turbo 仅能达到 6.1%，而开源的 Llama3-70B-Instruct 为 17.9%——在前沿专有模型和前沿开源模型之间存在 25 个百分点的差距。
- 列表过滤（List-filter）任务是一道无法逾越的墙：所有模型的得分均为 0%。 ServiceNow 的列表小部件使用了非标准的 HTML，导致受测智能体都无法可靠地与其交互。排序任务的表现也同样糟糕：GPT-4o 在列表排序任务中仅获得了 10% 的得分。
- 服务目录（Service catalog）任务出奇地容易处理：GPT-4o 在九个服务目录任务中达到了 77.8% 的成功率。在这些任务中，UI 更加常规，所需的操作与模型在训练中可能见过的表单填写模式紧密契合。
- 多模态观察几乎没有帮助。 在 GPT-4o 的观察中加入屏幕截图仅产生了“非常微小的性能提升”，这表明瓶颈在于对 UI 结构的理解，而非缺乏视觉输入。
- 思维链（Chain-of-thought）至关重要。 移除思维链后，Llama3-70B 在 WorkArena 上的表现下降了约 10 个百分点，这证实了多步骤网络任务需要明确的中间推理，而不仅仅是动作预测。
- 记忆机制适得其反。 启用
use_think_history标志会导致智能体“坚持在早期步骤中做出的决定，甚至是错误的决定”——这是伪装成规划的僵化承诺的一个具体案例。
哪些结论站得住脚，哪些站不住
该基准测试最有价值的特性是它在实时 ServiceNow 实例上运行：成功的判定标准是系统状态是否发生了正确的变化，而不是与预期输出进行字符串匹配。这使得列表过滤任务中 0% 的得分显得尤为触目惊心——无处遁形。任务的多样性也非常具有代表性：六个类别涵盖了知识工作者投入时间的大部分领域，而非精心挑选的展示性任务。
我觉得不太满意的地方在于对失败模式的处理。论文指出，奇特的 HTML 结构、嵌套的 iFrame 和影子 DOM（shadow DOM）会导致智能体崩溃，但并没有系统地剥离出哪些结构性特征是主因，或者它们所占的比例。论文提到了 DOM 大小问题（HTML 树的大小从 40k 到 500k token 不等），但未进行深度分析：我们不知道摘要、分块或仅基于可访问性树的观察是否能恢复性能。此外，单智能体架构从未与分解的多智能体设置（例如选择器/执行器分离）进行过比较，因此尚不清楚 0% 的列表过滤结果 是界面问题、规划问题，还是两者兼而有之。
还有一个平台有效性的问题值得提出。ServiceNow 是一个具有独特 UI 模式的特定企业软件栈。研究结果告诉了我们很多关于 ServiceNow 智能体的信息，而对一般的企业网络智能体的参考意义则相对较少。要将列表过滤任务的失败推广到，比如 beanquery 界面或电子表格工具，还需要独立的证据。
为什么这对金融 AI 很重要
WorkArena 的结果是我在考虑 Beancount 自动化议程时经常参考的基准点。其失败模式具有启发性：智能体在看起来像网页表单的任务（服务目录，77.8%）上表现良好，但在需要与结构化、非标准 UI 小部件进行精确交互的任务（列表过滤，0%）上则会崩溃。执行账目输入的 Beancount 智能体将面临复杂的情况：从自然语言到交易的部分类似于性能良好的表单填写任务；但查询、过滤和对账部分——寻找特定条目、按日期排序、应用账户过滤器——看起来更像是列表任务，而那正是目前全面溃败的地方。
该论文还强化了 CRITIC 和 Reflexion 日志中的教训：外部验证比内部推理更重要。WorkArena 任务的成败取决于系统状态，这种清晰的客观事实使得基准测试非常诚实。对于 Beancount 回写智能体来说，这强烈支持了一种设计思路，即每一次提交的账本更改都必须针对 beancount Python API 进行验证后才能接受，而不仅仅是通过智能体自身的推理进行检查。ICML 2024 上最佳模型 42.7% 的上限表明，即使对于传统的企业 UI 任务，从“偶尔有用”到“可靠自动化”之间的差距仍然很大。
延伸阅读
- WorkArena++ (arXiv:2407.05291, NeurIPS 2024) —— 来自同一 ServiceNow 团队的后续研究，包含 682 个复合任务，需要规划、算术推理和多文档检索；它直接回答了扩展任务复杂性是否会暴露 UI 交互障碍之外的新失败模式。
- WebArena (arXiv:2307.13854, ICLR 2024) —— 配套的通用网络智能体基准测试（涵盖电子商务、论坛、代码托管、内容管理系统等 812 个任务），GPT-4 仅达到了 14.41% 的成功率，而人类表现为 78%；该基准将 WorkArena 的数据置于更广泛的网络智能体背景中。
- OSWorld (arXiv:2404.07972, NeurIPS 2024) —— 将企业自动化评估扩展到了完整的桌面计算机环境，包括真实的应用程序（LibreOffice, VS Code, Chrome）；这是对 WorkArena 的失败模式是 UI 特定还是反映了更深层次的智能体能力缺陷最全面的测试。
