这是 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，模型网关的负载、限流和模型版本可能已经变化。正确顺序是交错：
for repetition in range(1, repeats + 1):
for framework in frameworks:
run(framework=framework, repetition=repetition)
还要记录真实 provider/model，而不只记录请求名称。代理网关可能静默路由到不同后端；如果证据里只有“我请求了什么”，比较基础已经不成立。
不要把适配器质量误判成框架质量
框架评测必然经过 adapter。adapter 写错，会让一个好框架显得很差。每个 adapter 至少需要：
- 独立的工具协议测试；
- usage 与调用次数对账；
- 错误、取消与超时映射测试；
- checkpoint/恢复测试；
- 框架版本和额外包装记录。
报告中应同时呈现“framework version”和“adapter/harness version”。发现 harness bug 时，保留旧结果并发布新契约版本，而不是覆盖历史。
怎样才可以说“更强”
一次运行只能说明集成成功过。三次交错属于 Alpha 观察；十次以上才适合做带离散程度的方向比较；要做正式选型，通常需要三十次或根据目标差异做功效分析。
即使样本足够，也要问两个问题：分差是否超过正常波动？分差是否具有业务意义？每次快 50 毫秒可能没有价值，而一次审批绕过足以否决整个框架。
所以，一个严谨结论应写成：
在生产变更场景 v1、指定模型和单机 Linux 环境下，A 与 B 均通过治理门槛；A 的 token 中位数较低，B 的适配代码更少。当前样本不足以宣布总体赢家。
这比“框架 A 第一名”更克制，也更能支持真实决策。