Agent 评估不能只看答案:Oracle 把执行路径也放上考卷1×0:007:490:08开场1:07事件播报2:23技术拆解3:59工程意义5:42落地建议7:11收尾0:08主播早上好,欢迎收听 AI Loop Engineering 每日深度播客。先交代一下范围:过去二十四小时里,我没有找到足够扎实、能撑起单主题深挖的一手动态,所以今天按频道约定,把窗口扩大到近一周。本期追踪的是 Oracle 在七月一日发布的 OCI Agent Evaluation Framework。它提出一个很直接的问题:Agent 给出了正确答案,能不能算通过?在生产环境里,答案经常是不能。0:37主播Oracle 的文章说得很清楚,Agent 不只是生成回答。它会检索证据,调用工具,带着身份权限行动,维护状态,有时还会触发真实副作用。于是评估对象就变了:不能只看最后一句话,还要看路径、工具、状态变更,以及出错之后怎么恢复。这个判断听起来朴素,但对工程团队很要命,因为很多 Agent 事故不是错在最后的自然语言,而是错在那条看不见的执行轨迹。1:07主播Oracle 这次把 Agent 评估拆成一条生命周期:从能力准入、提示词和 RAG 测试、工具轨迹评估,到发布门禁、生产回放、金丝雀验证、漂移检测,再到事故复盘和重新认证。它的核心不是做一个更漂亮的分数面板,而是让每一次评估都能追到证据。比如一次企业客服 Agent 正确告诉用户「账户状态已经更新」,最终回答看起来没问题;但 trace 显示它跳过审批,用了高权限更新工具,还在错误授权上下文里写了客户记录。按 Oracle 的口径,这次交互必须失败。1:45主播这和传统 chatbot 评估的差别很大。传统评估常常问:回答对不对,格式合不合规,有没有幻觉。Agent 评估还要继续问:检索证据有没有权限,引用是否支撑具体声明,工具选择和参数是否正确,写操作有没有审批,目标系统的状态是否真的被验证,失败之后有没有安全终止。Oracle 甚至把 MCP 应用也单独列出来,因为工具发现、描述符、授权、同意、令牌处理、出站访问和副作用,本身就是安全边界。2:23主播从 Loop Engineering 的角度看,这篇文章真正有价值的地方,是它把评估从「答案层」下沉到了「循环层」。一个 Agent loop 至少有计划、检索、决策、工具调用、状态验证、恢复或终止这些环节。只评最后的答案,相当于只看流水线末端有没有吐出成品,却不看中间有没有越权取料、绕过质检、或者把半成品写进生产库。2:51主播Oracle 建议的最小 trace 也很工程化:模型调用,检索,策略决策,工具调用请求,工具调用结果,状态事件,再到恢复或终止事件。这里不需要读取模型的私有思考过程,重点是保留可观察行为。RAG 要保留 chunk ID、引用映射、索引版本、新鲜度和访问控制决策;写操作要连到状态验证器。换句话说,评估不是说「这个 Agent 看起来靠谱」,而是能指出它在哪个节点通过,在哪个节点失败。3:26主播这也解释了为什么单次成功不能当作发布证据。Oracle 在可靠性部分强调,随机性 Agent 要报告结果一致性、轨迹一致性、工具选择方差、恢复方差、延迟和成本方差。连续重试同一个样本,不能假装是独立样本;高风险切片样本不够时,结果应该进入人工复核,而不是硬给通过。这个要求对很多团队不舒服,因为它会暴露一种现实:你的 Agent 可能大多数时候答对,但有时会走一条完全不同、也不该被允许的路径。3:59主播这条动态和过去几期我们讲过的观测、质量飞轮、安全治理是同一条主线,但 Oracle 的切口更偏发布与审计。它把 eval 从「研发阶段的测试集」推进到「生产系统的控制面」。生产里一旦出现漂移、循环、越权或证据缺口,系统应该给出可执行决策,比如通过、失败、复核、隔离、回滚、降级或禁用,而不只是亮一个红色告警。4:29主播Splunk 在六月二十九日的 Agent observability 文章里也给了同样的压力背景:Agent 不是一次模型调用,它会循环、规划、调工具、重试、交接,并在每一步重新携带上下文;他们引用 Gartner 的说法,Agent 每个任务可能消耗聊天机器人的五到三十倍 token。成本问题背后其实还是可见性问题。如果你不知道第几轮开始失控,不知道哪个工具重复调用,不知道哪条评估被跳过,那就只能等月末账单或线上事故来提醒你。5:01主播再往底层看,七月一日提交到 arXiv 的 Self-GC 论文把长周期 Agent 的上下文看成可治理对象,而不是一段可以随便裁剪的文本。论文报告,在一个三十三个会话的 hard set 上,Self-GC 剪掉了百分之四十三点九五的前缀 token,同时让百分之八十四点八五的未来续写不受影响。这个数字不必直接套到每个系统,但它说明了一件事:当 Agent 变长,工程问题会从「模型聪不聪明」变成「运行时对象、证据和状态能不能被治理」。Oracle 这次讲评估,Self-GC 讲上下文管理,指向的都是同一个方向。5:42主播如果你今天在团队里负责 Agent 落地,可以先做一个很小的版本。别一上来就搭完整平台。先挑一个 RAG 路径、一个工具写入路径、一个拒答或升级路径、一个恢复路径。每条路径都准备版本化样本,记录 trace,并且把判断拆成 outcome 和 path 两组。outcome 看任务有没有完成,path 看证据、权限、工具、审批、状态验证和终止条件有没有过线。6:11主播第二步,把高风险动作从「Agent 自己说成功」改成「外部状态验证」。比如更新客户资料,不能只看 Agent 回答「已更新」,还要查目标系统的字段、审批记录和操作身份。调用 MCP 工具时,也别只看工具有没有返回结果,要检查描述符、授权、同意和副作用边界。很多生产故障就卡在这里:日志里显示调用成功,但真实系统已经被不该发生的动作改过。6:41主播第三步,把评估结果变成发布动作。开发阶段可以轻一些,跑快速回归和轨迹调试;一旦涉及敏感数据、写操作、长会话或多 Agent 协作,就要增加证据深度。发布门禁不应该只有一个平均分,而应该有明确的风险切片、样本覆盖、复核条件和回滚条件。线上发现问题后,把事故 trace 变成新的评估样本,再跑一次修复验证。这样 eval 才真的进了 loop。7:11主播今天可以带走的判断是:生产级 Agent 的考卷不能只问「答得对不对」,还要问「它是怎么答出来的,动了什么,谁授权的,失败后停在哪里」。如果团队现在只有最终答案评分,下一步最值得补的不是更复杂的 judge,而是一条可回放、可定位、能连到状态验证器的执行轨迹。没有这条轨迹,Agent 越能干,风险越难解释。我们明天继续看 AI Loop Engineering 的新动态。