Articles
Agent 的评价：Proxy Metric ≠ Real Outcome
测试通过、API PASS 和 outcome.ok 都可能是真的，但它们仍然不等于用户的问题已经解决。
我们讨论 Agent 优化时遇到过一个直接的问题：一个 Agent 的测试全部通过，是否意味着它真的把事情做好了？答案并不一定是。
outcome.ok = true
12 tests passed
API PASS
multi-style PASS
↓
用户反馈：
「覆盖问题也没有修正」
一、Proxy Metric 很容易看起来像结果
传统软件里，HTTP 200、单元测试 PASS、API PASS、Workflow SUCCESS 往往已经很接近执行结果。但 Agent 做的事情越来越接近开放目标以后，过程成功和目标完成需要分开。
Proxy Metric
↓
「过程看起来成功」
Real Outcome
↓
「目标实际上被完成」
二、为什么 Agent 更容易出现这种偏差
Agent 的执行通常是 Goal → Action → Tool → Environment → Observation → Adjustment。于是成功标准天然有两层：Action 有没有正确执行，以及 Action 有没有让环境朝目标移动。
如果只测第一层，Agent 很容易学会优化代理指标，而不是优化真正的目标。
三、Ground Truth Status
我们讨论 Agent Optimizer 时，我提出过把真实结果状态显式记录下来，而不是只保存一个 ok=true：
Ground Truth Status ├── test_verified ├── user_confirmed └── unverified
test_verified 表示自动校验已经提供证据；user_confirmed 表示用户明确确认；unverified 则意味着证据还不足。这样比一个简单的 outcome.ok 更诚实。
四、Proxy 与真实结果发生冲突
Proxy Metric
↓
PASS
│
│ ≠
↓
Real Outcome
↓
User Confirmed: FAIL
=> divergence_flag = true
divergence_flag 不是为了判断谁一定正确，而是告诉 Optimizer：这里出现了评价体系与真实反馈之间的偏差，不能直接把这条轨迹当成成功案例学习。
五、为什么要有 Held-out Test
Visible Tests
↓
Proxy Signal
Held-out Tests
↓
Independent Signal
User Feedback
↓
Real-world Signal
如果 Agent 自己生成的测试就是最终优化的测试，很容易把优化变成“对着可见指标做高分”。Held-out Test 提供独立信号，用户反馈则进一步把评价拉回真实环境。
六、Evaluation 应该进入 Agent Loop
Goal ↓ Agent ↓ Action ↓ Environment ↓ Observation ↓ Evaluation ↓ Gap ↓ Next Action ↺
Evaluation 的作用不只是打分，而是回答：现在的结果，离真正目标还有多远？
七、这会直接影响 Agent Optimizer
错误 Proxy
↓
Optimizer
↓
更强的策略
↓
更高的 Proxy 分数
↓
更大的 Real Outcome 偏差
因此 Optimizer 的第一步不是“怎么优化”，而是先回答：这个成功信号是真的吗？
我们讨论过把 task_fingerprint、ground_truth_status、divergence_flag 和 cost 放在一起。它们分别帮助系统识别任务、判断证据强度、发现评价冲突，并记录得到结果付出的成本。
八、我现在更愿意这样理解 Agent Evaluation
传统软件 Function → Expected Output → PASS / FAIL Agent Goal → Agent → Action → Environment → Observed Outcome → Ground Truth
Agent Evaluation 不是给 Agent 一个分数，而是建立 Proxy Metric 与 Real Outcome 之间的对应关系。
如果两者长期一致，Proxy 才值得信任；如果出现偏差，就应该优先研究这个偏差，而不是继续提高 Proxy 分数。
最终 Agent 真正需要优化的不是“我通过了多少测试”，而是：我是否真的解决了用户要解决的问题？
一个正在用的薄实现是 llm-trace-reuse（站内：Projects）：复用 preferred_path 之前，仍然要先问这条轨迹的成功信号是不是真的。优化器怎么用这些经验，见 Agent Optimizer。