AI Agent为什么总是不稳定？终于有了一个系统性基准来拆解

过去一年，三星在大模型领域显得格外活跃。

从持续加码 Foundation Model 研发，到布局 Physical AI，再到持续推进 Galaxy AI 和多设备智能生态，三星正围绕 AI 重构其终端生态，并将 AI 打造成未来产品和服务的核心技术底座。近期，三星还进一步提出 Agentic AI 战略，将 AI Agent 从移动设备扩展至智能制造、智能家居等更广泛的智能基础设施，AI 已成为三星未来最重要的战略方向之一。

在这一背景下，三星大模型团队联合北京大学、香港城市大学、香港科技大学等科研机构，共同发布了面向 AI Agent 的基准测试 LiveClawBench。

不过，它关注的并不是「谁的 Agent 更强」，而是一个更基础、也更关键的问题：

为什么同一个 AI Agent，在一些任务中已经接近可用，而在另一些任务中却会突然失稳？

LiveClawBench 给出了一个更有意思的答案：任务领域并不能充分解释 Agent 的性能参差。

在高性能模型组（如 Kimi-K2.7-Code、GLM-5.2、GPT-5.5）中，任务领域只能解释约 9.6% 的 case-level 分数波动；如果换成任务的「复杂度画像」，解释比例则达到约 18.6%。在中等性能模型组（如 DeepSeek-V4 的 Flash 版本）中，趋势也类似：任务领域解释约 12.9% 的分数波动，而复杂度画像解释约 21.1% 的分数波动。

这意味着，当模型已经具备一定跨领域基础能力后，真正拉开差距的，可能不再是「它会不会做邮件、代码或日历」，而是任务内部到底包含了哪些更深层的复杂性。

这里的「复杂度画像」，可以理解为一个任务的挑战清单：

它不问任务属于哪个领域，而是问任务「到底难在哪里」，例如，跨多个服务协作，需要推断用户没有明说的目标，或者涉及长期知识维护。

这正是作者想回答的问题：AI Agent 好不好用，到底差在哪？

为此，他们构建了面向 AI Agent 的基准测试 LiveClawBench。 做了三件事。

第一，它构建了一个个人助理工作流 benchmark，用于评测当前主流 LLM Agent 在真实任务形态下的整体表现。

第二，它提出复杂度因子体系，把真实世界任务复杂性拆解为可标注、可统计、可比较的结构性压力。

第三，它用全栈可执行 mock 环境和轨迹分析，将模型最终得分、环境状态变化和行为模式联系起来，从而分析模型为什么成功、为什么失败。

• 论文标题：LiveClawBench: Benchmarking LLM Agents on Complex, Real-World Assistant Tasks
• 论文链接：https://arxiv.org/abs/2604.13072
• Github：https://github.com/Mosi-AI/LiveClawBench
• 轨迹路径：https://huggingface.co/datasets/Mosi-AI/LiveClawbench-trajectories

134 个可执行任务，前沿模型也没有打穿

作为一个面向开放领域的 benchmark, LiveClawBench 包含 134 个可执行 case，覆盖 10 个 OpenClaw 应用领域，并构建在 22 个可复用的全栈 mock 服务之上。

这些任务不是孤立的 API 调用，而是个人助理工作流。模型需要在多个服务、文件、状态和上下文之间完成真实操作，并由最终环境状态决定任务是否成功。

实验结果显示，即使是当前较强的模型，也还没有稳定解决个人助理任务。

这里的 Pass^3 (score>0.8) 指三次运行评分都超过 0.8 分。它衡量的不是偶然成功，而是高质量稳定完成。在 22 个高难度任务上，强模型如 GPT5.5 的 Pass^3 仅为 5.3. 这说明，当前 Agent 已经具备一定的软件操作能力，但距离可靠的个人助理仍有明显差距，在复杂、有状态、跨服务的工作流中仍然存在明显不稳定性。

从任务分布来看，LiveClawBench 更关注日常个人助理工作流。相比之下，当前的 SOTA 模型，如 Opus 系列模型、GLM 5.2 等，则在 coding 与安全对齐上经过更强优化。

这里的关键差异在于任务闭环。Coding 任务通常发生在仓库、测试和沙盒环境中，模型的动作边界相对清晰，获得相对明确的反馈也相对明确。而个人助理任务往往需要直接作用于用户数据和外部通信，例如发送邮件、提交表单、修改日历、更新记录。一旦执行，就会产生真实的状态变化和副作用。因此，个人助理场景更考验模型如何处理行动边界。相比于代码场景，对于更强调安全边界和谨慎策略的模型，更容易触发「停下来确认」的保守行为，从而影响任务完成率。

从轨迹上看，GLM-5.2 和 Opus-4.8 倾向于更保守：它们可以读完信息、完成必要判断，但在需要发送邮件、提交表单或执行外部动作时，更容易停在「需要用户确认」或「无法验证条件」的阶段。例如在部分采购、财务和日程类任务中，模型已经识别出关键信息，却没有完成最终状态变更，导致判定失败。

这种现象说明，不同模型之间的用户体验差异，很大程度上也取决于不同场景下的执行策略与风险偏好取舍。谨慎可以提升安全性，但在个人助理场景中，如果模型频繁停在确认、拒绝或说明阶段，也会降低用户体验。这正是 LiveClawBench 希望测试的问题：模型对真实工作流中的行动边界的判断。

任务领域不是答案，复杂度画像才更接近真实难点

Leaderboard 只能回答「谁更强」，不能回答「为什么强、为什么弱」。一个模型得分更高，究竟是因为它更会调用工具，还是更会理解隐含目标？这正是 LiveClawBench 引入复杂度因子体系的原因。

为了解决这个问题，LiveClawBench 提出了三轴复杂度框架，将个人助理任务中的困难概括为三类：

• A: 环境复杂性，关注软件环境本身带来的挑战，包括跨服务依赖 (A1) 和污染初始状态 (A2)。前者要求 Agent 在多个服务之间维护一致状态，后者要求 Agent 识别并修复错误、不完整或冲突的环境信息。
• B: 认知负担，关注用户请求和长期上下文带来的挑战，包括隐含目标解析 (B1) 和知识维护 (B2)。真实用户请求往往简短、模糊、不完整，Agent 需要从上下文和环境中推断真实目标，并在更新持久化知识或 artifact 时保持一致性。
• C: 运行时适应性，关注执行过程中出现变化后，Agent 是否能调整计划，并确认最终结果仍然满足用户目标。它包括环境扰动 (C1)，以及环境变化后的结果验证 (C2)。

在这个框架下，每个 case 都不只是一个任务题目，而是一个带有复杂度因子标注的诊断单元。一个任务可能涉及跨服务依赖，也可能包含污染初始状态；可能要求模型推断隐含目标，也可能同时包含运行时扰动和最终结果验证。

这使 LiveClawBench 不只是回答「哪个模型，在什么领域上分数更高」，而是进一步回答：

• 这个模型在哪些复杂度来源下表现稳定？在哪些任务压力下容易退化？
• 它的失败，到底是来自现实世界任务中的何种挑战？

谁更能解释分数波动？领域不够，复杂度更接近答案

如果只按 domain 分析，我们可以知道模型在 daily-life、coding、content 等领域的平均表现。

但这种分析会掩盖同一领域内部的高低波动。

一个 daily-life 任务可能只是添加日历事件，也可能需要跨邮件、日历、提醒、联系人和文档协调状态。

一个 coding 任务可能只是修复明确报错，也可能需要处理污染配置、依赖冲突、服务启动失败和最终部署验证。

如果只看 domain，这些任务会被放进同一个桶里；但如果看复杂度画像，它们对应的挑战完全不同。

谁解释了更多分数波动？

按照平均分数均分成三档后：

• 高性能模型中，domain 能够解释约 9.6% 的分数波动，复杂度因子可解释分数波动达 18.6%；
• 中等性能模型中，domain 解释约 12.9% 的分数波动，复杂度画像解释约 21.1% 的分数波动；
• 低性能模型中，domain 解释约 17.7% 的分数波动，复杂度画像解释约 16.1% 的分数波动。

这说明，弱模型可能仍更受基础领域能力限制；但当模型跨领域基础能力逐渐增强后，真正决定性能波动的，不再主要是任务属于哪个领域，而是任务是否包含更深层的结构性复杂度。

这也解释了用户为什么会感到 Agent 表现参差。

Daily-life 用户更常遇到跨服务依赖和结果验证问题。Coding 用户可能更多遇到污染状态和运行时适应问题：Agent 修复了表面错误，却没有发现环境配置本身已经脏了；服务启动失败后，它没有重新规划。Content 用户可能更多遇到隐含目标和知识维护问题：Agent 写出了流畅文本，却没有维护长期上下文一致性，也没有过滤不该传播的信息。

这些都不是简单的 domain 差异，而是复杂度因子差异。

复杂度因子会带来不同失败模式

LiveClawBench 的实验也进一步显示，复杂度因子会系统性影响模型表现，而且不同 factor 暴露出的失败模式并不相同。

跨服务依赖是当前 Agent 的核心难点之一。个人助理任务经常要求模型在多个服务之间维护一致状态。如果模型只能完成局部操作，却无法把多个服务的状态协调起来，用户就会感到任务「看似做了，但没有真正完成」。

隐含目标解析是另一个稳定瓶颈。真实用户请求往往不会把所有约束显式写出来。很多失败并不是模型完全不会操作，而是它优化了错误的目标：执行了很多步骤，但做的并不是用户真正想要的事。

运行时适应性进一步暴露出当前 Agent 的脆弱性。真实环境不是静态的。任务执行过程中，状态可能变化，前提可能失效，某个操作可能没有真正生效。Agent 不能只沿着初始计划走到底，而必须在执行后重新验证最终状态是否仍然满足用户目标。

LiveClawBench 的核心不是把任务做得更难，而是让任务难度可解释。

它用复杂度因子体系把真实个人助理任务中的复杂性原则化拆解出来，并进一步验证这些复杂性确实会对模型性能产生系统性影响。

为什么不能只做 API mock？

如果要诊断 Agent 为什么成功或失败，仅仅设计复杂任务还不够。评测环境本身也必须足够真实。

很多 Agent Benchmark 使用 mock 服务来保证可控性和可复现性。但如果 mock 只是一个 endpoint-level stub，评测很容易退化成「模型能否选对 API」。这类评测可以测试工具选择能力，却很难观察个人助理任务中真正关键的东西：session 是否保持，artifact 是否更新，后端状态是否改变，下游副作用是否发生，最终环境是否真的满足用户目标。

这就是 LiveClawBench 强调 mock fidelity 的原因。

LiveClawBench 没有把 mock 环境简化成一组孤立接口，而是将每个任务实例化为可复现的全栈 mock 应用。Agent 需要在容器化环境中与浏览器界面、服务 API、文件系统、后端数据库和审计日志交互。

任务是否完成，不只看模型说了什么，而是看最终软件状态是否真的被正确改变。

在个人助理任务中，成功不是「调用了正确 API」，而是「用户目标在环境中真的成立」。邮件是否发给了正确的人，日历是否避免了冲突，文档是否被正确更新，代码环境是否真的修复，敏感信息是否没有被传播 —— 这些都需要一个有状态、可验证、可复现的软件环境来承载。

这种 mock fidelity 让 LiveClawBench 兼顾了两点：

• 一方面，它避免直接依赖真实线上服务带来的不稳定性和不可复现性；
• 另一方面，它又尽可能保留真实软件工作流中的状态转移、artifact 更新和副作用证据。

因此，LiveClawBench 的 full-stack mock 并不是为了把任务变简单，而是为了在可控环境中保留真实执行语义。只有这样，复杂度因子才真正能被测量，模型失败才会留下可观察的证据。

轨迹分析：复杂度不仅影响分数，也改变 Agent 行为

LiveClawBench 进一步分析了 Agent 的执行轨迹。

如果说 Leaderboard 告诉我们「模型表现如何」，复杂度因子告诉我们「任务难在哪里」，那么轨迹分析则进一步回答：这些复杂性是如何改变 Agent 行为的。

作者从 Agent 轨迹中提取多组行为指标，包括执行步数、工具调用密度、重复调用、工具多样性、错误恢复、验证行为、盲改率和终止行为等。

这些指标不依赖模型隐藏的思维过程，而是来自可观察的工具调用、环境反馈和最终动作。

结果显示，不同复杂度因子会诱导不同的行为模式。

跨服务依赖、污染状态和隐含目标通常会让 Agent「多想多做」，但这并不必然带来更高成功率。模型可能调用更多工具、读取更多上下文、执行更多步骤，却仍然因为状态整合失败或目标判断错误而空耗。

知识维护类任务则可能出现另一种行为：Agent 完成字面要求后过早收手，没有继续维护更深层的长期一致性。

运行时扰动和结果验证任务中，失败又常常表现为没有在关键状态变化后重新检查，最终以过早结束收尾。

这说明，复杂度因子不只是影响最终分数，也会改变 Agent 的行为过程。

这对诊断非常重要。

两个模型可能最终都失败，但失败路径可能完全不同：一个模型可能反复调用同一个工具，说明它陷入局部循环；另一个模型可能很少验证写入结果，说明它缺乏状态意识；还有一个模型可能频繁读取信息但无法收敛，说明它在目标解析或计划更新上存在问题。

因此，LiveClawBench 的诊断并不止于「这个任务失败了」。它可以进一步追踪失败发生在任务复杂性的哪一部分，以及 Agent 在执行过程中表现出了什么行为模式。

这也是 LiveClawBench 与普通 Leaderboard 的根本区别：它不只评估结果，还试图打开 Agent 执行过程。

从排行榜走向诊断工具

LiveClawBench 给出的判断是：当前 Agent 已经越来越会操作软件，但距离真正可靠的个人助理仍有距离。

在整体榜单上，前沿模型已经明显领先，但 Hard 子集和 Pass^3 结果表明，它们在复杂、有状态、跨服务工作流中仍不稳定。

复杂度分析进一步提示，domain 只能解释有限的性能波动，而 complexity profile 更接近任务挑战来源，尤其对高性能通用模型更明显。

Factor-level 分析说明，这种不稳定并不是随机噪声，而是与跨服务依赖、隐含目标解析、污染状态诊断、知识维护深度、运行时适应和结果验证等真实任务复杂性直接相关。

轨迹分析则进一步显示，这些复杂性不仅影响得分，也会改变 Agent 的执行行为。

因此，LiveClawBench 的价值不只是提供一个新的 Agent 排行榜。

它更像是一个诊断工具：用 benchmark 给出整体能力水平，用复杂度因子体系分解真实世界任务复杂性，用 full-stack mock 环境保留可验证的执行证据，再用轨迹分析解释 Agent 在不同复杂性压力下如何行动、如何失败。

这也给模型改进提供了更具体的方向：

更稳健的多服务编排，更主动的隐式目标确认，更可靠的污染状态诊断，更深层的知识维护，更严格的完成度自检，以及更好的安全副作用控制。

这正是个人助理型 Agent 进入真实用户工作空间之前必须回答的问题：

AI Agent 好不好用，到底差在哪？

作者信息

本文共有 3 位共同第一作者，分别为三星大模型研究员龙翔、杜理，以及香港科技大学徐翊龙。

通讯作者唐业辉现任三星大模型团队负责人，负责三星 Foundation Model 与 Physical AI 核心技术研发，带领团队构建三星统一的底层 AI 能力体系，为手机、PC、智能家居、机器人等终端生态提供统一的基础模型与算法能力。公开资料显示，唐业辉博士毕业于北京大学，长期从事大模型研究，Google Scholar 引用超过 1.3 万次。

文章来自于微信公众号 “机器之心”，作者 “机器之心”