1. How to Evaluate AI Agents From Tool Calls to Task Completion
- 作者/来源: Sophia Abbassi、Chris Alexiuk、Davide Onofrio、Gomathy Venkata Krishnan / NVIDIA
- 发布日期: 2026-09-21
- 原文: https://developer.nvidia.com/blog/how-to-evaluate-ai-agents-from-tool-calls-to-task-completion/
推荐理由: 很多 Agent eval 仍停留在“tool name 选对了吗、arguments 填对了吗”。这篇把评测对象完整地提升到 真实环境中的任务完成:Agent 要连续调用工具、处理错误、改变环境状态,最终由 executable verifier 判断世界是否真的变成了目标状态。它给出了一个可以直接落地到 coding agent / workflow agent 的分层 eval 模型。
核心要点:
- Agent eval 的基本对象应该是完整 execution trace,而不是最终回复。 NVIDIA 将一次运行拆成
Benchmark → Trial → Task → Turn → Step。step-level process score 用于定位哪一步失败,end-to-end score 则只看最终环境状态是否正确。前者适合 debug,后者才适合作为 production release gate。 - 成功率必须和稳定性、轨迹长度、成本一起看。 文中建议同时追踪 task success rate、跨 3–5 次 trial 的 consistency、tool-call precision、argument accuracy、steps per success 和 cost per success。对于随机系统,一个单点成功率无法说明可靠性;真正有业务意义的经济单位也不是 token 数,而是 cost per successful task。
- 生产评测应尽量使用 executable verification。 数据库行是否更新、测试是否通过、PR 是否达到目标状态,都比 LLM-as-a-Judge 更可信。公开 benchmark 只能给 capability floor,企业最终应从真实 ticket、API 和历史 trace 构建私有 domain eval,并在自己的 harness 上重新测量。
核心启示:Agent eval stack 应围绕
task + stateful environment + execution trace + executable verifier + repeated trials + cost/success构建。模型分数只能说明能力上限,真正决定能否上线的是“在你的环境里是否稳定把事情做完”。
2. UCL-led dataset opens new research into how AI coding agents are instructed
- 作者/来源: UCL Computer Science / Giuseppe Destefanis 等
- 发布日期: 2026-09-23
- 原文: https://www.ucl.ac.uk/engineering/news/2026/sep/ucl-led-dataset-opens-new-research-how-ai-coding-agents-are-instructed
- 相关论文: https://arxiv.org/abs/2608.10906
- AlphaXiv: https://www.alphaxiv.org/abs/2608.10906
推荐理由: 这是目前研究 Agent Skills 生态非常值得关注的一组数据。研究团队没有只讨论“怎样写好一个 Skill”,而是把 Skill 当成一种新的软件 artifact 来研究:它主要由自然语言构成、由模型概率性选择执行、缺少 compiler/type checker,也没有成熟的 registry、版本管理和依赖治理。GitSkills 为后续研究 Skill 的传播、维护、质量和安全提供了第一个大规模基础数据集。
核心要点:
- Skill 正在形成一个没有 package manager 的自然语言软件生态。 GitSkills 在 2026 年 7 月从 282,200 个公开 GitHub 仓库中收集了约 379.7 万个
SKILL.md文件,其中约 187.8 万个是不同内容;约 50.5% 文件是 byte-for-byte 的重复副本,说明 copy-and-paste 已经成为 Skill 传播的重要机制。 - Skill 的复用模式带来了传统软件供应链之外的新风险。 Skill 可以要求 Agent 执行 shell、调用脚本、访问网络或修改文件,但复制时通常没有统一的 provenance、版本、依赖解析和安全审查。一个过期或危险的自然语言指令可以被复制到大量仓库,却没有类似 CVE、package registry 或 lockfile 的成熟治理机制。
- Skill evolution 现在可以被系统化研究。 数据集不仅保存文件内容和 hash,还关联 repository metadata、同目录 scripts/reference files,并为约 45.9 万个 Skill 保存 commit history。研究者因此可以测量 Skill 的 churn、复制路径、维护频率、作者模式、安全问题传播,以及未来把这些指标与 routing accuracy / task performance 联系起来。
核心启示:Skill 不应再只被视为 prompt 文件,而应被视为一种需要
provenance + versioning + dependency metadata + security scanning + eval + lifecycle governance的软件资产。GitSkills 让“Skill 如何进化”第一次具备了可大规模实证研究的数据基础。