我越来越不愿意直接回答“哪个模型更好”。
不是因为这个问题没有意义，而是因为它经常把太多变量压缩成了一个名字：模型、Agent 的编排方式、上下文装载、工具权限、任务难度、验收标准，甚至最后有没有人复核。
在一个公开的 Maglev CLI 仓库里，一个很小的版本检查任务让我重新意识到这件事：仓库里的六项 Node 测试全部通过，但运行结果仍然显示 CLI 版本和包内发行物版本不一致。
version --json
{"cli_version":"0.7.4","bundled_version":"0.5.6"}
version
maglev-cli: 0.7.4
bundled-dist: 0.5.6
错误: CLI 版本与包内发行物版本不一致
exit code: 2这不是“模型好不好”的证据。它只是提醒我：评估一个 AI 系统时，能输出结果、能通过已有测试、能识别真正的风险，是三个不同问题。
相关公开资源
- Idea-Maglev/maglev：公开的 CLI、技能与验证协议。
- Maglev CLI 版本测试：展示一个确定性任务如何定义可观察结果。
- OpenAI Cookbook 的工具调用示例：展示模型生成工具参数、调用方执行工具的边界。
- Google Gemini Cookbook 的函数调用示例：展示手动函数调用和 SDK 自动执行的区别。
模型不是最小评估单位
把模型单独拿出来比较，有点像只比较发动机型号，却不记录车辆、道路、驾驶方式和目的地。
同一个模型，放进不同 Agent 之后，可能会遇到完全不同的工作环境：
- 一个 Agent 只负责生成答案，另一个 Agent 会先读取仓库、拆任务、调用工具再修改文件；
- 一个 Agent 要求每次工具调用都经过调用方确认，另一个 Agent 由 SDK 自动执行；
- 一个 Agent 能保留完整的 Handoff 和验证证据，另一个 Agent 只返回一段最终文本；
- 一个任务允许模型自由发挥，另一个任务要求严格遵守 schema、退出码和文件边界。
如果这些条件没有固定，最后得到的差异很难归因于模型本身。
所以我现在更愿意把比较单位写成：
模型 × Agent × 任务 × 上下文 × 工具 × 成本约束。
这不是为了让评估表变得复杂，而是为了避免把不同系统的结果误读成模型差异。
三种不同复杂度的公开任务
Maglev 项目里已经有几个适合做评估样本的公开任务。它们的价值不在于已经证明哪个模型更强，而在于它们要求 AI 暴露不同类型的能力。
| 任务 | 主要考察 | 可观察结果 |
|---|---|---|
| CLI 版本与发行物检查 | 确定性验证、错误识别、退出码理解 | JSON 字段、版本差异、错误码、风险解释 |
| Multica completed / blocked 接力 | Agent 协同、角色边界、失败处理 | 委派、Handoff、阻塞原因、下一责任人 |
| Reality Projection 三场景验证 | 长上下文、证据定位、结构化审查 | explain、locate、verify、evidence refs |
任务一：确定性 CLI 验证
这是最容易被低估的一类任务。
表面上，它只是运行命令并解析 JSON；真正的验收却至少有四层：
- 输出是否是合法 JSON；
- 必填字段是否齐全；
- CLI 版本和包内发行物是否一致；
- 发现不一致时，是否给出正确的阻断信号。
如果只把“命令有输出”当成成功，评估就会漏掉最后两层。
这个任务适合做低复杂度基准：输入固定、工具数量少、结果容易复核，但仍能区分“会执行命令”和“会解释风险”。
任务二：完成与阻塞的 Agent 接力
协同任务的难点不只是把下一步做出来，而是知道谁应该做、什么情况下不能继续做。
一个公开的 Multica Runtime Proof 契约要求记录：
- 承载环境；
- 协调角色和成员 Agent 的对象标识；
- 触发输入；
- 精确 mention；
- 成员的终态 Handoff；
- 协调角色对 Handoff 的消费结果。
它还明确区分两条路径：
completed：成员完成任务并回传，协调角色决定结束或继续派发；blocked：成员发现输入、权限或批准不足，明确阻塞并请求升级或补充。
这类任务不能只用“最终有没有答案”评价。一个 Agent 如果在缺少关键输入时继续编造进度，最终文本再完整，也不应该算成功。
需要说明的是，公开仓库目前提供的是任务契约和验收标准，不等于已经完成了一次可公开复放的第三方 Runtime Proof。因此这里把它当作公开任务样本，而不是现成的横向实验结果。
任务三：Reality Projection 的证据验证
第三类任务更接近长上下文审查：Validator 需要在独立 worktree 中读取模板、Work Contract、Module Map、Gate A/B、完整代码和 Reality 资料，然后覆盖 explain、locate、verify 三类场景。
它的输出也不是一句“验证通过”，而是一份带有 commit、digest、review layers、blocking gaps 和 evidence refs 的结构化 Validation Result。
这类任务适合观察：
- 能不能找到结论对应的证据；
- 能不能区分已知、未知和阻断；
- 能不能维持结构化输出；
- 能不能在资料不足时停止，而不是补一个看起来完整的答案。
它的上下文和审查要求明显高于 CLI 任务。如果把这两个任务混在一个平均分里，复杂度差异就会被隐藏。
互联网资料能说明什么
互联网资料很适合帮助我们识别“可能的差异来源”，但不适合替代同一任务集的实测。
OpenAI 的公开函数调用示例把边界写得很清楚：模型生成工具名和参数，API 不替调用方执行函数；调用方还可以选择强制调用、禁止调用或允许模型自行选择。示例也展示了并行函数调用这一种可能的执行方式。
Google Gemini 的公开示例则展示了另一种接口差异：Interactions API 需要调用方手动处理函数调用和结果，而 Chat SDK 可以启用自动函数执行。
这意味着，在同一个 Maglev 任务上，两个组合之间可能出现这些差异：
- 谁负责执行工具；
- 每次调用是否可单独审计；
- 错误返回由谁处理；
- 多个工具调用是否并行；
- Agent 是否保留完整的中间证据。
这些是合理的比较维度，但仍然不是质量结论。
另外，GitHub Copilot cloud agent 的官方文档描述的是一个更完整的 Agent 产品层：它可以研究仓库、制定计划、在分支上修改代码，并进入 review 流程。这样的对象已经包含模型之外的仓库上下文、执行环境、分支和审查机制，不能直接和一次裸模型调用放在同一栏里比较。
我会把这类资料用来拆变量，而不是用来宣布赢家。
一张足够小的评估矩阵
如果真的要比较两个模型或两个 Agent 组合，我会先固定下面这些字段：
| 字段 | 要记录什么 |
|---|---|
| task_id | 固定的任务编号和任务说明 |
| input_context | 允许读取的上下文范围和版本 |
| model | 模型名称、版本和调用模式 |
| agent | Agent 编排方式、角色和停止条件 |
| tools | 可用工具、权限和自动/手动执行方式 |
| run_id | 每一次独立运行的标识 |
| output | 产物、调用记录、错误和退出码 |
| quality | 任务特定的正确性和完整性判断 |
| traceability | 是否能回查证据、Handoff 和决策路径 |
| cost_latency | 成本、耗时和工具调用次数 |
| human_intervention | 是否需要人工补充、纠偏或复核 |
这里最重要的是 quality 和 traceability 不能只填一个主观总分。
CLI 任务可以检查版本一致性和退出码；协同任务可以检查 Handoff 是否完整、阻塞是否正确；Reality 验证可以检查证据引用和未知项表达。不同任务的质量标准应该随任务定义一起固定，而不是跑完之后再挑一个最方便的指标。
我现在能下的判断，到这里为止
我可以说：
- 模型比较如果不固定任务和 Agent，很容易把系统差异误判成模型差异；
- Maglev 的公开任务可以提供不同复杂度、不同证据要求的评估样本；
- 公开 API 文档显示，工具执行和 Agent 编排方式确实存在不同；
- “测试通过”和“发现真正风险”应该拆成不同的验收项。
我还不能说：
- 哪个模型在 Maglev 上最好；
- 哪个 Agent 一定更稳定或更省成本；
- 自动工具执行一定优于手动工具循环；
- 某次厂商文档中的能力一定会在当前权限和接入层中复现。
如果没有统一任务集，我宁愿保留这些未知，也不愿意用一张看起来完整的排行榜替它们做决定。
结尾：先比较组合，再讨论模型
模型当然重要。但在真实工作里，模型只是系统中的一个变量。
任务是否固定，上下文是否一致，Agent 是否能正确调用工具，失败时是否会停下来，结果能不能被复核，这些因素往往决定了一个模型的输出到底能不能变成交付物。
所以我现在会把问题换一种问法：
不先问“哪个模型最好”，先问“在什么任务、什么 Agent、什么上下文和什么成本约束下，哪个组合更合适”。
这个问题的答案可能没有排行榜那么干脆，但更接近真实工作，也更容易被下一次任务验证。