从参数竞赛到系统能力：大模型竞争进入新阶段

两个产品调用同一个模型，一个能稳定完成报表核对，另一个却经常漏字段。差异可能来自数据接入、提示版本、工具定义、错误恢复和验收规则，而不是模型本身。参数规模仍会影响能力上限，但用户购买的是完整任务结果。

“系统能力”不是把所有工程问题笼统装进一个词，而是要求把模型放回它真正工作的链路：输入如何构造，工具如何调用，状态如何保存，结果如何验证，失败如何退出。只有这样，模型更新才能被转化为可靠产品。

参数量不是产品指标

参数量可以帮助理解模型容量和部署资源，却不能直接说明特定语言、行业材料或多步骤任务的表现。训练数据、后训练、工具、推理预算和解码设置都会改变结果。即使同一模型，是否拿到正确上下文也可能比参数差异更重要。

HELM 论文主张跨场景、多指标评估，并公开评测仍未覆盖的部分。这种思路适合产品团队：与其问“哪个模型第一”，不如列出场景、指标和缺失证据。

公开基准还可能面临训练数据污染、提示设置差异和任务饱和。即使成绩可信，也只说明模型在该评测协议下的表现。产品决策应把公开基准当作候选筛选信号，再用未公开的真实任务和失败案例确认。

完整系统至少有六个可测试层

层级	要回答的问题	示例指标
模型	能否理解并生成所需内容	任务正确率、格式通过率
上下文	是否拿到正确且最新的信息	证据覆盖率、过期率
工具	是否选择并正确调用外部能力	调用成功率、参数错误率
控制	是否遵守权限、状态与风险边界	越权率、重复执行率
任务	是否完成端到端目标	一次完成率、人工接管率
业务	是否产生可持续价值	单位成功成本、返工与事故

这六层不要求六套平台。关键是日志能把一次任务关联起来：使用了哪个模型和提示，检索了什么，调用了哪些工具，验证是否通过，最终是否被人员接受。

可以为每条核心工作流建立一套任务夹具：固定输入、模拟工具、预期状态变化和验收结果。模型在可控环境中运行，既检查回答，也检查是否选择了正确动作、是否在缺数据时停止。这比只保存一组问答更接近生产。

工具使用把语言问题变成系统问题

OpenAI 的代理指南把模型、工具和指令列为代理基础组件，并建议先建立能力基线，再用较小模型优化成本。工具让模型能够查询和执行，也带来传统分布式系统问题：超时、重试、幂等、授权和版本兼容。

例如，模型正确判断“需要创建工单”，不等于工单被正确创建。工具 schema 可能允许缺失优先级，网络超时后重试可能生成两张工单，用户凭据也可能没有被传到下游。把最终结果归因给模型，会错过真正故障点。

系统还应限制模型能看到和能调用的能力集合。工具描述过多会增加选择混淆，权限过宽则扩大一次误判的影响面。按任务动态装配最小工具集，既降低风险，也让评测结果更稳定。

可靠性要用重复运行和失败恢复衡量

一次成功演示说明路径存在，不能说明服务稳定。对关键任务应重复运行、改变输入表达、加入缺字段和冲突条件，并观察结果方差。系统还要在模型超时、工具不可用或输出校验失败时提供确定行为。

模型升级不应直接覆盖生产版本。先在历史流量上回放，再进行小比例影子或灰度测试；结果变好也要检查新的失败类型。回滚需要同时恢复模型、提示、工具 schema 和检索配置，不能只改一个模型名称。

NIST 的 TEVV 资源强调可信 AI 依赖可靠的测量与评估。对产品而言，评测要覆盖正常任务、边界任务和故障注入，且每次模型或工具升级都能复跑。

成本应以成功任务为分母

token 单价、每秒 token 和首字延迟只是链路指标。产品真正关心的是每个通过验收任务的模型费用、检索费用、工具调用、重试和人工复核。便宜模型如果频繁返工，单位成功成本可能更高。

MLPerf Inference在质量约束下比较系统性能，说明速度不能脱离质量解释。企业内部也应先设任务质量底线，再比较延迟和成本，避免通过降低输出质量获得漂亮性能。

竞争优势来自可复用的交付闭环

模型供应会变化，系统积累更慢：真实失败样本、受治理的数据连接、可复用工具、权限模式、回归评测和人工反馈。这些资产让团队能更快吸收新模型，而不是每次重建产品。

评估下一代 AI 产品时，可以问三个具体问题：它在哪些任务上有可重复证据；失败能否被检测并恢复；换模型后业务逻辑和评测是否仍可用。回答还应包含版本、样本、运行成本和未覆盖场景，而不是只给结论。证据要能由不同成员独立复跑验证。能够用同一套证据持续回答这些问题的系统，才真正越过参数竞赛。