惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

aimingoo的专栏
aimingoo的专栏
Jina AI
Jina AI
WordPress大学
WordPress大学
Recent Announcements
Recent Announcements
G
Google Developers Blog
I
InfoQ
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Google DeepMind News
Google DeepMind News
P
Proofpoint News Feed
MyScale Blog
MyScale Blog
M
MIT News - Artificial intelligence
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
C
Check Point Blog
J
Java Code Geeks
T
Tailwind CSS Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Microsoft Security Blog
Microsoft Security Blog
MongoDB | Blog
MongoDB | Blog
V
Visual Studio Blog
人人都是产品经理
人人都是产品经理
量子位
A
About on SuperTechFans
D
DataBreaches.Net
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Goodhart's Law Comes for Your Agent Evals: Why Your Green...
Saurav Bhattacharya · 2026-06-21 · via DEV Community

Saurav Bhattacharya

There is a specific moment in the life of every agent team that nobody puts on the roadmap. You build an eval suite. It catches real bugs. You wire it into CI as a release gate. The dashboard goes green. And then, somewhere over the next three months, the green stops meaning anything — while everyone keeps treating it like it does.

This is Goodhart's Law, and it is coming for your agent evals whether you plan for it or not.

"When a measure becomes a target, it ceases to be a good measure."

The day your eval suite becomes the thing that decides what ships, it stops being a neutral measurement of quality and becomes a target your team optimizes toward. That is not a hypothetical risk. It is the default trajectory, and most teams only notice after a "fully passing" release lands in production and quietly makes everything worse.

How a good eval suite rots

The decay is boring, which is exactly why it's dangerous. Here's the usual sequence:

  1. You write evals against the bugs you already found. Reasonable. But now your suite measures yesterday's failure modes, not tomorrow's.
  2. A change fails one case. Instead of asking "did we regress?", someone asks "is the eval too strict?" and tweaks the assertion until it's green.
  3. Prompts get tuned to the eval set. Few-shot examples drift toward the exact phrasings your judge rewards. The agent gets better at your test cases and no better at the actual job.
  4. The held-out set quietly becomes the training set. Every case you debug against is a case you've now overfit to.

The endpoint is an agent with a 98% pass rate that is measurably worse for users — because the score is now measuring how well the agent satisfies the test, not how well it does the work. The map replaced the territory.

The tell: a green gate you can't explain

The cleanest signal that Goodhart has arrived is this — a release passes the gate, and nobody on the team can explain why a specific borderline case passed. It just did. The score is a number with no narrative behind it.

That's the real problem. A pass/fail bit is not a measurement you can reason about. It's a measurement you can only trust or distrust. And trust, unaudited, always decays toward green.

This is exactly the seam where the two tools I lean on have to work as one unit, not as separate dashboards.

agent-eval scores and gates the output. It runs the deterministic checks, the model-as-judge rubrics, the drift and hallucination signals — and it returns a verdict on what the agent produced.

AgentLens captures the trace of how the agent got there. Every model call and tool step, the resolved inputs (after templating, not the raw template), and the raw outputs before any post-processing.

Neither half is sufficient alone, and that's the entire point. A bare eval score is a target waiting to be gamed. A bare trace is forensic data with no verdict attached. You need agent-eval's score anchored to AgentLens's trace so that every gate decision carries a "show me why" attached to it. When a borderline case flips, you don't argue about whether the eval is too strict — you open the trace, see the resolved prompt and the exact tool output, and find out whether the agent actually reasoned correctly or got lucky on a phrasing.

That linkage is what keeps the measure honest. The eval tells you the gate flipped; the trace tells you whether the flip was earned.

What it looks like in code

The anti-pattern is a gate that returns a boolean and nothing else:

// Goodhart bait: a verdict with no evidence behind it.
async function gate(testCase: TestCase): Promise<boolean> {
  const output = await runAgent(testCase.input);
  return judge(output, testCase.expected) >= 0.8; // green or red, no "why"
}

The fix is to make the score and the trace travel together, so a passing case is auditable, not just countable:

import { evaluate } from "agent-eval";
import { trace } from "agentlens";

interface GatedResult {
  passed: boolean;
  score: number;
  traceId: string;     // the receipt
  heldOut: boolean;    // was this case ever debugged against?
}

async function gatedRun(testCase: TestCase): Promise<GatedResult> {
  // AgentLens records every model + tool step, resolved inputs, raw outputs.
  const session = trace.start({ caseId: testCase.id });

  const output = await runAgent(testCase.input, { trace: session });

  // agent-eval scores the OUTPUT: deterministic checks + judge rubric + drift.
  const verdict = await evaluate(output, {
    expected: testCase.expected,
    checks: ["schema", "grounding", "drift"],
    judge: "rubric-v3",
  });

  await session.attach({ verdict }); // bind score <-> trace

  return {
    passed: verdict.score >= 0.8,
    score: verdict.score,
    traceId: session.id,         // open this to see WHY it passed
    heldOut: testCase.heldOut,   // overfit guard, see below
  };
}

Two things in that snippet are doing the anti-Goodhart work. The traceId means no pass is unexplainable — every green is one click from its own evidence. And heldOut is the discipline that keeps the suite from collapsing into a training set.

Three rules to keep the measure honest

Tooling won't save you from Goodhart on its own. The process around it has to hold the line:

  • Quarantine a held-out set you never debug against. If you've ever opened the trace for a case to fix a failure, that case is burned for measurement — it's now a regression test, not an evaluation. Keep a rotating set you only ever score, never tune toward. When held-out and debugged scores diverge, that gap is your overfit, measured directly.

  • Treat eval edits like production changes. Loosening an assertion to get green is a code change with a blast radius. It needs a diff, a reviewer, and a one-line justification anchored to a trace — "this case was wrong because the trace shows X," not "this was flaky."

  • Mine new cases from production traces, not your imagination. The cases you invent reflect failures you can already picture. The cases in your AgentLens traces reflect what users actually trigger. Promote real, surprising traces into the held-out set continuously, so the suite keeps measuring a moving target instead of a frozen one.

The uncomfortable conclusion

A green eval dashboard is not evidence that your agent is good. It is evidence that your agent satisfies your evals — and those are only the same thing while you're actively defending the gap between them.

The teams that ship reliable agents aren't the ones with the highest pass rates. They're the ones who can pull up any green checkmark and explain, from the trace, exactly why it earned the pass. agent-eval gives you the verdict; AgentLens gives you the receipt. Keep them bound together, keep a real held-out set, and your dashboard might actually keep meaning something six months from now.

Most won't. Now you know why.