别急着问哪个 Agent 框架最好：先把比较问题定义对
这是 Agent 框架评测实验室系列第一篇。
“框架强弱”不是一个单变量
比较两个 Agent 框架时，最容易犯的错误是：给它们各写一套最顺手的 prompt 和工具包装，跑一次，然后按最终答案打分。这样同时改变了框架、提示词、工具协议、错误恢复和输出解析，最后根本不知道分数差异来自哪里。
真正可回答的问题应该写成：
在指定企业任务、风险策略、运行环境、模型、工具和成本口径下，哪个框架更适合，弱点在哪里，证据是什么？
每轮实验只能有一个主要变量。测框架，就冻结任务、prompt、工具、模型、provider、temperature、token limit、价格、执行顺序和评分策略；测模型，就冻结框架；测 prompt，也不要同时升级工具。
公平与原生能力之间的矛盾
统一输入可以保证公平，但统一适配层也可能抹掉框架特长。例如把所有框架都压成一个普通 ReAct 循环，就测不出 LangGraph 的图状态与恢复，也测不出 OpenAI Agents 的 handoff 和原生 lifecycle。
Lab 因此采用两条赛道。
受控公共赛道
每个框架拿到同一份版本化任务、prompt、工具、模型和输出契约。它测的是：
- 工具协议是否稳定；
- 最终任务是否完成；
- token、延迟和调用次数；
- 是否越权或违反输出协议；
- 同样输入下的失败率。
它回答“相同条件下谁执行得更好”，但不代表框架能力上限。
原生上限赛道
允许框架使用推荐的 graph、handoff、checkpoint、memory、审批和恢复能力，但业务结果与治理门槛仍相同。新增的代码、依赖、配置和运维复杂度都要记录。
它回答“按框架原生方式开发，谁更适合这个企业结果”。
两条赛道不能不加说明地合并成一个榜单。一个框架可能公共赛道非常轻巧，原生赛道缺少持久恢复；另一个可能代码更多，但长流程恢复明显更强。这不是矛盾，而是能力画像。
先画能力向量，再算总分
企业框架至少要从这些维度观察：
| 维度 | 典型证据 |
|---|---|
| 任务效果 | 完成率、rubric 分、结构化协议 |
| 安全治理 | 工具授权、审批绑定、数据边界 |
| 可靠恢复 | 工具失败、取消、崩溃、重启、幂等 |
| 可审计性 | 事件无缺口、trace、工件哈希、lineage |
| 效率 | token、成本、模型/工具调用数、p50/p95 延迟 |
| 可运维性 | 安装、诊断、升级、依赖足迹 |
| 开发体验 | 类型安全、测试难度、适配器代码量 |
| 可迁移性 | 对模型、provider、工具协议的耦合 |
前五项可以主要由运行证据产生；可运维性和开发体验通常需要版本化人工 rubric。二者必须分开标注，不能把主观评分伪装成遥测数据。
公平执行还要处理时间偏差
如果先把框架 A 的 30 次全部跑完，再跑框架 B，模型网关的负载、限流和模型版本可能已经变化。正确顺序是交错：