Agent 评估不再只看能力上限，先守住最坏行为

过去一年，Agent 从会聊天的界面，变成了会调用工具、修改文件、访问业务系统的执行者。能力上限因此涨得很快，系统的风险面也一起变宽了：它可能完成一个原本没人想到的任务，也可能把数据删掉、把竞争对手推荐给客户，或者借着邮箱权限发出一封没人愿意署名的垃圾邮件。

Ben Hylak 在 AI Engineer 的这场分享里，给出了一个很实用的判断：评估 Agent 的核心问题，已经从“它能做到多好”转向“它最糟糕时会造成什么伤害”。前者决定产品的天花板，后者决定用户还愿不愿意继续使用。原视频：https://www.youtube.com/watch?v=jHMiYtjoJfA

Agent 变复杂以后，旧评估方法开始失效

聊天机器人时代的评估相对简单。给模型一个问题，检查它有没有返回正确答案。比如问美国首都，答案应该是华盛顿特区。问题空间有限，人工也大致知道正确答案在哪里。

Agent 的工作方式完全不同。它会根据任务决定是否调用工具，工具又会改变外部状态；它可能在执行过程中遇到异常，临时换一条路径；同一个目标，换模型、换框架、换 CLI，执行轨迹就可能完全变化。结果里有一部分来自模型，一部分来自工具，一部分来自上下文和环境，单看最后一句文本已经不够了。

视频里提到一个很典型的现象：团队花几个月搭出一套评估集，切换新的模型或 harness 之后，原有评估大面积失去意义。分享者用了“80% 的评估失效”来描述这种冲击。这个数字的价值不在精确统计，而在于提醒工程师：评估绑定的对象可能是旧执行环境，换了 harness，就像换了考试规则，原来的分数不能直接横向比较。

因此，Agent 评估不能继续停留在提示词游乐场里。它更接近代码测试：写在仓库中，跟着实现一起变更，能够在本地或 CI 环境里反复运行。单元测试检查局部行为，端到端测试检查完整任务，Agent 的离线评估也应该有类似的边界和复现路径。

“天花板”和“地板”是两套指标

Hylak 把 Agent 的能力拆成两个方向。

天花板是它最厉害时能做到什么。比如，它能否自主完成一项复杂工作，能否组合多个工具，能否发现人类没有预先写进流程的解决办法。天花板决定产品有没有突破空间，也决定演示时能不能让人眼前一亮。

地板是它最糟糕时会做什么。比如给客户推荐竞争对手，批量删除数据，向外部收件人发送未经审核的内容，或者在权限范围内做出用户完全没想到的动作。地板决定信任是否会被一次事故击穿。

很多团队喜欢追逐天花板，因为天花板容易展示。一个 Agent 完成了复杂任务，演示视频很漂亮，发布会也容易讲清楚。地板却藏在长尾里，通常需要从生产数据、用户反馈和异常轨迹中慢慢挖出来。

这也是 Agent 产品和传统自动补全工具的分水岭。代码补全错了，工程师可以删除建议；命令行 Agent 出错了，工程师往往还能看到终端并承担最后一步确认。产品把决策权交给 Agent 以后，用户承担的检查责任会逐渐变重。医疗、金融、客服、运维等场景尤其如此：用户是否具备领域知识，直接影响错误的后果和恢复成本。

所以，评估不该只问“成功率是多少”，还要问三件事：错误会不会破坏信任，错误发生后能不能恢复，用户有没有能力发现它已经错了。

每个问题先补齐两个数字

视频给出的实践建议很朴素：发现一个问题后，先查它是什么时候开始出现的，以及它影响了多少用户。

“什么时候开始”用来定位变化。问题昨天才出现，通常意味着近期发生了某种变更：模型换了，提示词改了，工具版本升级了，数据格式变了，或者下游服务出了调整。问题存在了几个月，则可能属于长期缺陷，处理优先级和排查方法都不同。

“影响多少用户”用来判断严重程度。三个用户遇到的问题，和十万用户同时遇到的问题，处置方式当然不同。前者可能需要人工跟进、补一个分类器，后者可能需要立即回滚或限制能力。

这里的数字不能孤立看。时间告诉团队“可能是哪次变更引入了问题”，用户占比告诉团队“影响面有多大”，两者组合起来才形成决策依据。只报一个错误次数，往往会把轻微高频问题和严重低频问题混在一起。

视频还强调，用户规模会改变评估策略。只有五到十个用户的内部工具，不适合一上来做大规模 A/B 测试；面向数百万用户的产品，则可以抽取较小流量做实验，观察修复是否真的减少了问题。小样本场景更适合人工复盘和逐条确认，大规模场景才有条件用统计方法换取速度。

这和传统软件监控很像。监控系统不会只告诉团队“日志有多少条”，还会关心错误从何时开始、影响哪些实例、是否集中在某个版本。Agent 需要一套相似的生产观测能力，只是被观测对象从 HTTP 请求扩展到了决策、工具调用和完整轨迹。

聚类看起来聪明，却不等于发现问题

我最认同的一点，是他对“把轨迹聚类起来”的质疑。

把大量 trace 放进向量空间，再让模型找出若干相似簇，适合做一次性的探索。它能帮助团队快速浏览数据，发现一些此前没见过的共同模式。问题在于，聚类边界会漂移，团队无法稳定控制“什么算同一个问题”，也很难可靠地追踪一个簇随时间的变化。

举个例子，系统把“报价错误”和“退款计算错误”放进了“价格问题”这个簇。它们表面上都包含价格相关词，实际根因可能完全不同：前者来自报价服务，后者来自退款规则。聚类把它们放在一起，给了人一种“问题已经被归类”的感觉，却没有提供真正能执行的修复边界。

更麻烦的是，产品不同，“同一个问题”的定义也不同。对电商客服来说，优惠券计算错误可能是一类问题；对企业财务 Agent 来说，金额精度、币种转换和审批权限可能必须分开管理。通用聚类模型很难替每个产品做出这种业务判断。

Hylak 的建议是，把可解释的代码模式用于 trace 分类。工程师可以写出明确的分类器，用关键词、工具调用、状态变化、响应结构等确定性信号先筛选数据，再把筛选后的样本交给 Agent 做分析。这样做的好处是边界可读、版本可控、运行成本可估算，也能在沙箱里先验证，再扩展到生产规模。

这套方法和软件工程里的静态规则很接近。规则不能解决全部问题，却能稳定抓住一批高价值信号。Agent 更适合处理规则筛出的具体案例，而不是让它在海量数据中漫无目的地寻找异常。

Agent 不擅长找异常，却适合调查异常

分享者还提出一个容易被忽略的边界：Agent 做异常检测很差，调查已经发现的异常却很有价值。

原因并不神秘。异常检测需要稳定的基线、清晰的阈值和长期一致的统计口径。Agent 面对生产数据时，容易把正常波动误判成异常，也可能因为上下文不完整而忽略真正危险的变化。让它直接看所有 trace，等于把“发现问题”和“解释问题”两项工作混在了一起。

更可靠的流程是先提取确定性信号。例如某个关键词在搜索请求中的出现频率突然上升，某个工具的失败率超过过去基线，某类输出在新版本后集中出现。关键词上涨本身未必代表产品故障，却足以成为调查入口。接下来再让 Agent 阅读相关轨迹，比较前后版本，判断用户意图，归纳可能根因，并给出修复建议。

可以把这套分工理解成医院的分诊：仪器先发现体温、血氧或心率异常，医生再结合病史做判断。让医生盯着所有人的原始传感器数据找异常，效率很低；让仪器先把可疑样本筛出来，医生的判断质量会更高。

对 Agent 系统来说，确定性检测器负责“把范围缩小”，Agent 负责“把含义讲清楚”。前一段要追求稳定和低成本，后一段才适合使用模型的推理能力。

评估应该成为仓库里的代码资产

从这场分享继续往下推，评估本身就该算产品代码。

提示词游乐场适合早期试验。团队可以快速改一段指令，观察模型响应，判断方向是否值得继续。产品进入持续迭代后，评估需要进入仓库，拥有版本、负责人、运行命令和失败记录。否则每次模型升级，团队都只能重新回忆“上次为什么认为它是好的”。

一套可维护的 Agent 评估，至少应该记录以下内容：

• 输入场景和用户目标；
• 允许使用的工具与权限；
• 预期轨迹或关键约束；
• 最终结果与副作用；
• 失败时间、影响用户比例和对应版本；
• 人工复核结论，以及修复后是否回归。

这里的“预期轨迹”不代表每一步都必须固定。Agent 可能通过多种路径完成同一个任务，评估应当检查关键不变量，例如不能越权、不能删除未确认的数据、必须调用某个审计工具、输出必须包含可追溯来源。只要这些约束满足，具体路径可以保持一定弹性。

这和高仙机器人做设备诊断、任务执行分析时的思路也相通。一个异常结论不能只靠模型说“看起来像这样”，还要结合告警、时间线、设备状态、历史修复记录和确定性规则。模型负责综合，证据链负责约束。Agent 的评估最终会落到同一个问题：结论能不能复核，动作能不能回放，修复有没有副作用。

我的补充：先把“地板”写成可验证的合同

看完这场分享，我最想带回工程现场的一句话是：Agent 的竞争力，越来越取决于团队能否持续降低最坏行为。

具体做法不必从一套庞大的评估平台开始。先选五到十个最不能接受的失败场景，把它们写成可重复执行的测试。每个场景都给出触发条件、允许动作、禁止动作、恢复方式和验收证据。让 Agent 运行一次，再让独立 verifier 检查结果，避免执行者自己给自己打分。

接着补生产数据里的两个维度：问题起始时间、受影响用户比例。没有这两个维度，团队会在“看起来很严重”的个案和“实际上影响很广”的问题之间反复摇摆。

最后才考虑聚类、自动归因和更复杂的分析模型。先用规则抓稳定信号，再让 Agent 调查具体案例；先把评估写进仓库，再讨论如何扩大规模。这样做的节奏可能没那么华丽，却更容易积累真正能复用的工程资产。

如果只能记住一句话，记住“抬高底线”。天花板决定演示效果，底线决定产品能不能留在生产环境里。

视频信息

• 讲者：Ben Hylak，Raindrop CTO、联合创始人
• 频道：AI Engineer
• 视频：https://www.youtube.com/watch?v=jHMiYtjoJfA
• 主题：Designing Agents（The Floor Is the Frontier）