5. 评测对象、系统边界与可观察性

核心方法论 · 2～3 小时

学习目标

区分 Model、Agent、Harness、Environment 与 Evaluator
避免把环境故障算成 Agent 能力
设计可追踪的 Agent Run

前置知识

第 4 章
基本软件系统可观测性

本章产物： 画出被测 Agent 的 System Boundary 与 Trace Schema。

5.1 先问：你到底在测谁？

Agent Eval 常见对象有三种：

Model-only

固定 Agent Harness，只换模型。

Agent System

模型、Prompt、Tool、Memory、Planner 都属于被测版本。

Full Product

还包含 UI、权限、网络、外部服务和真实工作流。

如果不声明边界，结果无法公平比较。

5.2 Version Everything

一次 Run 至少固定：

agent_version
model_provider/model/revision
system_prompt_hash
tool_schema_version
retrieval_index_version
memory_policy_version
environment_version
evaluator_version
dataset_version

否则“模型变好了”可能只是 Tool schema 改了。

5.3 Trace 不等于隐藏 Chain-of-Thought

工程上需要的是可观察执行轨迹：

input；
assistant message；
tool call；
tool arguments；
tool result；
retry；
state transition；
error；
timing；
token/cost；
final answer。

不要要求或存储模型不可见的私有推理。

5.4 环境失败要单独分类

例如 API 500：

Agent capability failure?   不一定
Environment failure?        可能
Recovery failure?           如果 Agent 没有合理重试，可能

推荐结果：

run_status: completed
task_success: false
failure_origin: environment
recovery_quality: 0.4

这样不把 Infrastructure Flakiness 与 Agent Regression 混在一起。

5.5 可复现 Snapshot

对关键环境保存：

DB seed；
container image digest；
fixture version；
mock response version；
browser site image；
Git commit；
K8s manifest；
current time / locale。

Agent Benchmark 最大敌人之一就是“环境悄悄变了”。

5.6 验收问题

Model Eval 与 Full Product Eval 的边界怎么区别？
为什么 Tool schema 也必须版本化？
为什么 Environment Error 不应该简单算 Agent Error？

本章依据

原理性结论优先来自原始论文和官方文档。论文中的实验数字只属于论文声明的模型、数据、环境和评测设置，不能直接外推为你的生产结论。