多 Agent / 多策略 A/B 评测 =
在相同场景分布下，
对不同 Agent 结构 / 决策策略 / 阈值 / Prompt，
进行可复现、可归因、可统计的行为级对比评测。
关键词只有三个：
同场景 · 行为级 · 可归因
一、为什么 Agent 一定要做 A/B，而不是“看起来更聪明”？
因为 Agent 系统里：
更聪明 ≠ 更安全
更会说 ≠ 更少上云
更复杂 ≠ 更稳定
而且：
Agent 的失败是“系统性”的，不是单点的
所以必须回答这些问题
哪个策略少犯致命错误？
哪个策略更省云、更稳？
哪个策略在坏条件下不崩？
二、A/B 评测的对象是什么？
不是只比模型
不是只比 Prompt
✅可 A/B 的维度包括：
1️⃣ Agent 结构
单 Agent vs 分层 Agent
是否有 Monitor / Critic
是否端侧有否决权
2️⃣ 决策策略
上云阈值（0.5 / 0.7 / 自适应）
置信度校准方式
fallback 策略
3️⃣ 云侧策略
不同 Prompt
不同 LLM
是否 RAG
是否多轮反思
A/B 的本质是：策略函数不同
三、系统总架构
┌───────────────────┐ │ Scenario Pool │ ← 同一批场景 └─────────┬─────────┘ │ ┌─────────▼─────────┐ │ Agent Variants │ │ A / B / C / ... │ └─────────┬─────────┘ │ ┌─────────▼─────────┐ │ Trajectory Logger │ ← 行为轨迹 └─────────┬─────────┘ │ ┌─────────▼─────────┐ │ Evaluator │ │ Rules + LLM-Judge │ └─────────┬─────────┘ │ ┌─────────▼─────────┐ │ Comparator │ ← A/B 结论 └───────────────────┘四、核心设计 1：统一 Scenario
场景是“随机变量”，Agent 是“对照变量”
{ "scenario_id": "iot_high_risk_007", "initial_state": {...}, "events": [...], "constraints": {...} }每个 Agent 必须跑完全相同的 scenario
五、核心设计 2：Agent Variant 描述/工程化
{ "agent_id": "agent_B", "edge_policy": { "cloud_threshold": 0.7, "fallback_enabled": true }, "cloud_policy": { "model": "gpt-x", "prompt_version": "v2" } }Agent = 配置 + 代码
六、核心设计 3：轨迹级日志
每个 Agent、每个 Scenario，产出一条轨迹：
{ "scenario_id": "iot_high_risk_007", "agent_id": "agent_B", "trajectory": [ { "step": 1, "actor": "edge", "decision": "call_cloud", "confidence": 0.82 }, { "step": 2, "actor": "cloud", "decision": "suggest_shutdown" }, { "step": 3, "actor": "edge", "decision": "execute_shutdown" } ] }没有轨迹，就没有 A/B。
七、评测输出（单 Agent × 单 Scenario）
{ "task_success": true, "failures": [], "metrics": { "cloud_calls": 1, "latency_ms": 820, "unsafe_action": false }, "llm_judge": { "score": 4, "comment": "决策稳健" } }八、A/B Comparator：怎么“比”？
1、单场景对比（pairwise）
{ "scenario_id": "iot_high_risk_007", "better_agent": "agent_B", "reason": "Agent A 未上云导致误判" }用于case study / 复盘
2、跨场景统计
| 指标 | Agent A | Agent B |
|---|---|---|
| Task success rate | 91% | 95% |
| Unsafe action rate | 3% | 0.5% |
| Avg cloud calls | 0.6 | 0.9 |
| P95 latency | 420ms | 780ms |
不存在“全面最优”，只有 trade-off
3、Failure 分布对比
| Failure Type | A | B |
|---|---|---|
| MISSED_CLOUD_ESCALATION | 12 | 3 |
| UNNECESSARY_CLOUD_CALL | 5 | 18 |
| UNSAFE_ACTION | 4 | 1 |
📌决定策略取舍的关键
九、LLM-Judge 在 A/B 中的正确位置
不要让 LLM-Judge 决定胜负。
正确用法：
解释差异
标注策略问题
生成自然语言分析
不该做：
单独作为成功率
覆盖硬指标
十、注意事项
❌ 场景分布不同
❌ Agent 有随机性却不控 seed
❌ 只看均值，不看 P95 / failure
❌ 忽略高风险场景子集
构建了多 Agent / 多策略的 A/B 评测系统，
在统一的场景分布下，对不同 Agent 配置进行轨迹级对比。
评测以任务成功率、安全失败率和端云调用效率为核心指标，
并结合 Failure taxonomy 和 LLM-Judge 做差异归因，
从而支持 Agent 策略的可控迭代和上线决策。
