如何更真实地评估 AI 编程 Agent：数据标注交互任务法

评测方法的困境：编码基准与开放演示的盲区

随着 AI 编程工具（Cursor、Codex、Claude Code 等）成为开发者日常助手，如何衡量它们在真实工作中「到底有多大用处」，正变得越来越困难。作者 Andrew Marble 在博客文章中指出，当前主流的两类评测方式都存在明显缺口。

一类是编码基准，如 The Artificial Intelligence Coding Agent Index 综合了 DeepSWE、Terminal-Bench V2、SWE-Atlas-QnA 三个公开数据集，考察 agent 在明确定义的软件工程任务上的表现。这类基准的优势在于可复现、可比较，但它们衡量的是「能否完成任务」，而不是「在人与 agent 协同的情况下效率如何、产出质量如何」。当几乎所有模型都能在 human-in-the-loop 模式下完成既定任务时，再去寻找它们做不到的边界，更像是出难题、找边角情况，而非真实使用场景的代理指标。

另一类是开放式定性检验，例如 Andrej Karpathy 建议的提示词视频生成、单次通关的小游戏，或 Netlify 博客中模型一次性完成网页设计的对比。它们能产出炫酷演示，却过于开放——既不衡量约束条件下的「刚性」表现，也通常只测单次输出，不涉及交互过程，难以预测真正被人类使用时工具的效用。

设计原则：从「能做」转向「做得好不好」

针对上述两类方法的盲区，作者提出了一套评测任务的设计原则：

• 有约束的必要成功标准：任务需要包含明确的、功能层面的硬性要求，确保 agent 不能靠「看起来不错」蒙混过关。
• 保留开放选择空间：在约束之外留出足够的自由度，让模型能够展现「品味」与判断力，例如界面布局、信息组织方式、交互流程设计等。
• 可代理的真实使用情境：任务本身最好对应作者自己在工作中频繁使用的场景，例如为数据标注或注释构建支持软件——这类软件既要呈现数据让用户做出判断，又要在流程、进度保存、可读性上体现质量，而最终成败取决于用户能否高效完成标注。

这套思路的目标并不是完全模拟真实使用，而是通过有意义的交互与成功标准，建立对工具效率与有效性的合理代理测度。

任务示例：构建数据标注界面

基于上述原则，作者设计了若干任务，要求 agent 在较短的交互式编码会话中生成数据标注界面。其中典型的一类是「分类标注」：

• 从维基百科中分别抽取 75 句关于「互联网泡沫」和「2008 年金融危机」的句子。
• 要求 agent 构建一个交互界面，让用户通过阅读每条句子，标出其所属文章主题。
• 评估维度包括：用户跑完所有样本的效率（标注速度）、界面布局与流程是否真正减轻了用户的认知负担，以及整体产品感的「品味」。

这类任务既具备清晰的正确性指标（标注结果是否对得上原始文章），也允许模型在呈现方式、键盘快捷键设计、进度提示等方面自由发挥，从而考察 agent 作为「工具」的真实表现，而非单纯的代码生成能力。

评测对象与方法局限

作者在文中表示对五个 agent 进行了实测，其中包括三个较小的本地模型与两个接近前沿水平的模型，但原文摘录在此处截断，详细得分与逐项对比未完整给出。文章整体属于个人博客层面的方法论探讨，而非来自主要厂商或学术机构的正式研究，因此其结论的传播力与可复现性都相对有限。

值得肯定的是，作者把评测讨论从「能不能做」推进到了「做得好不好、做得快不快、用起来舒不舒服」，这一方向与近期业界对 agent 产品化体验的关注是吻合的；对于希望建立内部 agent 评估体系的小团队而言，其任务设计框架具有可借鉴的参考价值。