资讯 · 改写稿
别再靠「感觉」测 Agent：一套 60 分钟能搭起的评估流水线
结论先给：Agent 上线的最大隐患不是跑不通，而是「看起来对」。来源的做法是搭一条自动评估流水线，让改动带来的好坏有分数可看——他们的评分卡抓到了人工抽检完全没发现的 33% 质量问题。
来源（dev.to，Google AI 的 AI Agent Clinic 一期）先描述了一种普遍做法：改一版提示词，手跑两条查询，看着输出还算合理，就当它没问题了。来源把这种靠感觉的验证叫「vibe check」，并指出它会很快失效，原因有三：
- 静默回归：同事提了个 PR 或调了下工具定义，你没有任何办法知道效果是变好还是变差；
- 成本与延迟尖峰：Agent 陷进多轮重试循环，悄无声息地烧掉大量 token；
- 「看起来对」陷阱：输出读起来很顺，却漏掉了关键参数，或者臆造了关键指令。
他们搭了什么
来源用 60 分钟搭了一条端到端、与框架无关的评估流水线。几个要点：
- 被测对象：一个开源的 LangGraph Agent，功能是扫 GitHub 的 issue 与 PR、找出文档缺口并自动开 PR。
- 框架无关的遥测：用 OpenTelemetry + OpenInference 把多轮 trace 标准化，覆盖 LangGraph、CrewAI、AutoGen、ADK 等，避免被单一框架绑定。
- 三层指标策略：来源强调不要一上来就写 50 个指标，而是分三层——托管的核心指标（轨迹质量、工具调用正确性、接地性）、自定义的 LLM 评判（按评分表检查格式、代码块、可操作性）、以及确定性的断言与运维跟踪（语法检查、延迟、token 用量、API 成本）。
- 0.33 盲点：自动评分卡抓出了一处 33% 的文档质量失败，而这处问题被人工抽检完全漏掉。
本站计算——把「多轮重试」的代价折算一下：若一个 Agent 每轮约消耗 2,000 token，陷进 10 轮重试，单次任务就多花约 2 万 token；一天出现 100 次这样的任务，就是约 200 万 token 的额外开销——这正是「成本尖峰」在没人盯着时会悄悄累积的量级。
为什么自动评估会改变做法
来源说得很直接：一旦有了可比较的分数，你就不再是「凭感觉改提示词」，而是能回答「这次改动到底让哪一项变差了」。他们把工具也开源了（评估工具包与被测 Agent 的代码），视频约 25 分钟、分 10 个小节，从映射执行流一路走到解读评分卡。
改完提示词只跑两条查询：静默回归不会自己暴露。
一上来写 50 个指标：来源建议先用三层结构，从核心指标起步。
只看输出是否通顺：流畅的输出照样可能漏参数、臆造指令。
自检清单
常见问题
「vibe check」为什么会失效？
来源列出三点：改动的静默回归无法察觉；Agent 陷多轮重试会悄悄烧 token；以及输出「看起来对」却漏掉关键参数或臆造指令。
评估流水线的三层指标是什么？
来源建议分三层：托管的核心指标（轨迹质量、工具调用正确性、接地性）、自定义 LLM 评判（格式、代码块、可操作性），以及确定性断言与运维跟踪（语法、延迟、token、成本）。
那处 33% 是什么？
来源称自动评分卡抓出了一处 33% 的文档质量失败，而这处问题被人工抽检完全漏掉。
遥测为什么强调框架无关？
来源用 OpenTelemetry 与 OpenInference 标准化多轮 trace，覆盖多种 Agent 框架，目的是避免被单一框架绑定。
来源参考
以上为外部来源；本文为 RefHub 用自己的结构重写，事实以来源页为准，价格与政策会变，请回源核对当日。