ReadingResearchRadarInvestment framework
Sign in / Sign up
← Back to reading
NewsTopic · 智能体评估框架3 min read·2026-10-15DisconfirmAI Editorial

Google Engineer Hugo Selbie Proposes Systematic Evaluation Framework for AI Agents, Moving Beyond Vibe Checks

Hugo Selbie, a Customer & Partner Solutions Engineer at Google, details how to build an evaluation pipeline for AI agents. He argues that 'vibe checks'—running a few prompts in a terminal—are insufficient to detect silent failures like retry loops and tool parameter hallucinations. The article outlines a three-phase method from defining Critical User Journeys (CUJs) to integrating CI/CD gates, recommending the open-source agent-eval toolkit and boolean checks over vague scoring to capture operational costs like latency and token consumption.

ImportanceMaterialEvidenceE3 inspectableWrite-upQuick

Original publication time 2026-10-15

When teams start building AI agents, their testing approach is often identical: connect a model, give it a few tools, run three or four prompts in a terminal, and visually inspect the output. If the answer looks reasonable, they ship it. However, Hugo Selbie, a Customer & Partner Solutions Engineer at Google, points out that this practice quickly breaks down in reality. Agents fail differently than standard software; they might get stuck in retry loops, trigger multiple tool calls, yet still return a polite, plausible final answer. These hidden failures are costly in production, silently inflating cloud bills and token usage, exhausting downstream API rate limits, and leaving users staring at loading spinners.

To move beyond simple subjective checks, Selbie proposes an evaluation framework based on two core pillars: human oversight and targeted tooling. The first step is defining success through Critical User Journeys (CUJs) rather than abstract benchmarks. CUJs anchor tests to what users expect the system to achieve, structured around roles, goals, constraints, and validation conditions. For example, 'As an operations analyst, I want the agent to receive trade discrepancy emails... and draft a reply without human intervention.' Each clause in this statement becomes an evaluation point, aligning product stakeholders, end-users, and engineers on how to measure 'success'.

Sign in / Sign up
ReadingResearchRadarInvestment framework

The second step is starting with simulated users and gradually transitioning to real traffic. Developers don't need six months of online logs to build an initial golden dataset; instead, they can break each CUJ into specific scenarios and feed them into a user simulator LLM. By setting personas and behavioral constraints, the simulator mimics the messy phrasing and multi-turn complexity of real users. The third step is measuring across the full stack, setting up four layers of checks—unit tests, deterministic metrics, LLM-as-a-judge rubrics, and integration tests—to pinpoint root causes.

Selbie highlights four common pitfalls to avoid. First, discarding tests and breaking baselines; every addition or removal makes score changes uninterpretable. Second, relying on vague 1-to-5 scoring; he recommends converting rubrics into boolean (pass/fail) questions because LLMs are notoriously inconsistent with qualitative scores. Third, evaluating only text while ignoring operational costs; an answer that passes all quality checks but takes 40 seconds and makes twelve redundant tool calls is still a production failure. Fourth, building different evaluation pipelines for different agent frameworks; he suggests standardizing traces around open specifications like OpenInference to decouple evaluation from orchestration frameworks.

On a practical level, the article provides a Day 0 to Day 2 rollout process. Day 0 focuses on scenarios, simulation, and 'red pen' scoring, where developers manually read execution traces to mark every hesitation, hallucinated parameter, or wrong tool choice, creating a high-signal checklist. Day 1 uses tools like agent-eval to convert these red-pen notes into automated checks, establishing a regular cadence and validating the auto-judge against manually scored traces. Day 2 turns the trusted pipeline into a permanent regression safety net, integrated into CI/CD pull request gates, enforcing global pass thresholds and zero-regression rules for core metrics.

Sources

  • 原始出处developers.googleblog.com↗
Topic

智能体评估框架

随着AI应用从单轮对话转向多步推理的智能体(Agent),传统的“凭感觉检查”(Vibe Check)已无法捕捉重试循环、工具参数幻觉等隐性失败。Google工程师Hugo Selbie指出,智能体可能在输出看似合理的同时悄悄消耗大量Tok…

4 steps0 piecesUpdated 2026-10-16 06:38

How it got here

  1. 2024-12-19Google发布博客《Optimizing RAG retrieval》,提出通过测试数据集和自动化指标(如忠实度、相关性)来识别RAG系统中的“静默失败”,为后续智能体评估奠定基础。
  2. 2025-11-18Google进一步阐述智能体评估方法论,提出包含成功标准、过程轨迹(Trajectory)和信任安全三大支柱的框架,强调需区分“结果正确但过程错误”的情况。
  3. 2026-02-04Google Cloud针对生命科学等高监管行业发布指南,要求智能体评估必须满足GxP合规性,重点在于证明推理过程的透明性和可审计性,而不仅是任务完成率。

What is still unsettled

  • 在缺乏统一基准的情况下,不同厂商(如Google vs Microsoft)定义的“成功”指标是否存在不可比性?
  • LLM-as-a-judge在评估复杂多步智能体时的自身偏差率是多少,是否足以作为生产环境的唯一门禁?
Read the full topic →
Continue researching →