读《State of Open Source AI 2026》：模型会越来越便宜，真正应该掌握的是Harness

今天看到 Mozilla 发布的《The State of Open Source AI 2026》。一开始我以为这又是一份讨论开放模型和闭源模型谁更强的报告，但完整看下来以后，发现它真正想讨论的并不是模型排名。

报告的判断是：开放模型和闭源模型的能力差距正在缩小，推理成本快速下降，模型本身逐渐变成一种可以替换的基础能力。真正决定 AI 产品能不能落地、成本能不能控制、数据能不能积累的，已经变成模型上面的 Harness。

这正好对应我们最近在做的叙事视频项目。

前几天我刚刚把这个项目重新定义成一套 Narrative Creation Harness。当时主要是从项目开发过程倒推出来的。现在看完 Mozilla 的报告，相当于又从整个行业的发展方向验证了一遍这个判断。

报告到底说了什么

报告先用几个数字描述开放模型目前的位置：

开放模型与顶级闭源模型的平均能力差距约为 3.3 个百分点；
达到 GPT-4 级别的推理成本，在 36 个月内从每百万 Token 约 20 美元下降到 0.4 美元，降幅约 50 倍；
到 2025 年末，OpenRouter 上大约三分之一的 Token 来自开放权重模型；
2026 年 6 月，OpenRouter Token 使用量最高的五个模型全部是开放权重模型。

但这里不能简单理解成“开放模型已经全面超过闭源模型”。

3.3% 只是一个平均值。报告把它称为 jagged frontier，也就是不同任务上的能力边界并不平整：

在 Coding、指令遵循和通用知识方面，开放模型已经接近闭源模型；
在复杂推理、长上下文检索和 Agent 任务方面，闭源模型仍然有明显优势。

所以，现在更有意义的问题已经不是“开放模型够不够好”，而是：

当前这项工作到底需要什么能力？

对大部分普通任务来说，可能没有必要永远使用最贵的 Frontier Model。但对于复杂推理、长程 Agent、创作质量判断和多模态任务，也不能因为开放模型价格低，就假设它一定可以替代闭源模型。

这个区别对我们的项目非常重要。视频生产包含脚本、事实核验、图片、语音、渲染和跨模态评测。这里面有些步骤可以用便宜模型，有些步骤仍然需要更强的模型，不能只选一个模型从头跑到尾。

开放模型的问题已经不主要是模型

报告里最值得注意的一组数据，是采用率和生产率之间的差异：

79% 的受访开发者使用开放模型；
71% 使用闭源模型；
其中一半的开发者同时使用两者；
但开放模型进入生产的比例只有 51%，闭源模型是 63%。

这说明很多团队愿意尝试开放模型，但真正进入生产时还是会卡住。

开发者给出的主要问题也很实际：

基础设施和算力成本；
安全、隐私和合规；
持续维护和升级；
部署、托管和扩容复杂；
缺少专业支持；
模型评测和比较困难。

模型性能不够反而不是排名最高的问题。

这让我想到我们前面抽取 Narrative Skill 时遇到的情况。理论上，把 Python、FFmpeg、图片生成、TTS 和渲染脚本放到本地，Agent 就可以调用它们生产视频。但“能够在某台电脑上跑通一次”和“可以作为产品稳定交付”，完全是两件事。

真正困难的是：

依赖怎么安装和升级；
任务状态保存在哪里；
中断后从哪里恢复；
哪些文件属于当前版本；
哪些操作需要用户确认；
模型调用失败后重试哪一步；
生成结果怎么评测；
无人值守任务由谁保证完成；
客户端和服务端怎么避免形成两套逻辑。

这些都不是模型问题，而是 Harness 问题。

为什么报告认为 Harness 是下一层竞争

报告把 Agentic Harness 类比为浏览器。

浏览器是 Web 时代的 User Agent。它运行在用户一侧，帮助用户与不同服务器打交道。Agentic Harness 则处在模型和现实世界之间，帮助用户与数据、工具、系统、其他 Agent，甚至资金和业务操作打交道。

报告把 Harness 分成了几个部分：

Govern
  状态策略、执行记录、预算、撤销

Surface
  用户界面、支付和计量

Action
  沙箱、执行、权限、评测、可观测性

Reach
  Tool、Context、MCP、A2A、Memory

Control
  Agent 的推理与执行循环

Model
  最底层可替换的模型

这个结构和我们的项目已经非常接近。

在 Narrative 项目中：

OpenCode 提供通用的 Session、模型、Provider、Tool 和权限交互；
Narrative Skill 负责叙事领域的操作策略；
Typed Tool 和脚本负责确定性执行；
Workflow 负责规划、确认、生产、评测、重试和导出；
Manifest 记录版本、产物、哈希和恢复位置；
本地 Runtime 负责受监督创作；
服务端 Worker 负责无人值守生产；
Gate A 和 Gate B 分别验证工程链路与真实创作质量。

所以，我们并不是在 OpenCode 里增加几个视频生成按钮。我们是在通用 Harness 上面增加一层专门用于叙事创作的领域 Harness。

报告的五个建议，对应我们项目里的五个问题

报告最后给出了五个建议。我觉得几乎每一个都能在当前项目里找到对应物。

1. Build the open harness

报告认为，开放模型如果没有与之匹配的 Harness，即使模型能力接近，也可能在真实部署中输给模型和 Harness 深度绑定的闭源产品。

这也是我们基于 OpenCode 做客户端的意义。

我们不应该重新实现 OpenCode 已有的模型、Provider、Session、终端、权限和设置。真正需要掌握的是 Narrative 领域层：Brief、Workflow、Skill、Manifest、Evaluation 和 Runtime。

如果以后更换模型或者更换客户端宿主，这一层仍然应该保留下来。

2. Own the memory

报告有一句话我非常认同：

The model is interchangeable. The memory is the asset.

模型会更新、降价，也可能被下线。真正会随着使用不断积累价值的，是自己的数据和记忆。

对于 Narrative 项目来说，Memory 不是保存全部聊天记录，而是保存：

用户的创作 Brief；
来源材料和 Claim-Source 对照；
Script Package 和历史版本；
Manifest 和 Artifact；
用户修改了哪些镜头；
哪些图片、发音和叙事方式被拒绝；
每次评测的问题和人工改判；
哪些重试最终改善了结果。

这些数据以后可以用于改进 Skill、Prompt、Workflow 和评测器。如果它们只存在某一家模型厂商的会话里，我们换模型时就什么也带不走。

narrative-codex 使用 Git 保存共同规格，项目运行时使用 Manifest 保存产物和版本，其实都是在建立可迁移、可追溯的 Memory。

3. Solve portable permission

报告认为，目前 Harness 最没有解决好的问题不是读取，而是写入。

读取文档、查询状态一般可以重试，后果也比较有限。但发送消息、花费预算、修改记录、覆盖文件、发布内容，都可能产生不可逆的副作用。

认证只能说明 Agent 是谁，不能说明它现在可以做什么。

这和我们当前设计的两个确认点完全一致：

高成本生产前确认；
最终导出前确认。

除此之外，我们还需要目录授权、版本锁、哈希校验、安全 Reveal、写锁、预算上限和无人值守任务的权限策略。

不能每次都弹出一个“是否允许”。如果用户习惯性全部点击允许，确认框就失去意义了。真正需要的是根据当前状态、操作类型、成本和历史行为来判断下一次写操作能否执行。

4. Break the meter

报告提醒团队不要等到模型调用量很大以后，才发现自己完全被按 Token 计费和单一供应商锁住。

我们的项目不能只接入一个模型，然后在代码里到处写死它的返回格式和行为。更稳妥的方案是：

保留 OpenCode 的 Provider 能力；
Tool 和 Workflow 不绑定具体模型；
对开放模型和闭源模型运行同一套 Golden Case；
记录质量、耗时、费用、失败率和人工介入；
为关键步骤保留第二模型来源；
在负载稳定、评测明确的环节考虑开放模型或自托管。

这并不意味着所有环节都要改成本地模型。开放模型应该提供退出能力和成本选择，而不是变成新的技术信仰。

5. Make the open default plural

开放也可能形成新的单一供应商依赖。

如果所有开放模型都来自同一个组织，训练数据、对齐方式和拒答策略仍然会被同一套选择影响。只是权重可以下载，不代表整个系统已经没有集中风险。

所以，我们真正要保留的是可替换能力，而不是从一个闭源模型迁移到一个固定的开放模型。

这份报告也不能全盘接受

Mozilla 本身长期支持开放 Web 和开放 AI，所以这份报告并不是完全中立的市场研究，它有很明确的立场。

另外还有几个数据边界需要注意：

第一，OpenRouter 的 Token 流量只能代表经过 OpenRouter 的使用情况，不能等同于整个 AI 市场。

第二，开放权重不等于完整开源。很多模型只提供权重，不提供训练数据、完整训练代码和对齐过程。报告虽然在方法部分区分了这两个概念，但正文中有时仍然把它们放在一起讨论。

第三，模型排行榜、价格和融资数据变化非常快。报告自己也说明，这些数据应该作为 2026 年 6 月附近的时间切片，而不是长期不变的事实。

第四，我们的视频项目恰好包含长上下文、Agent、多模态和主观审美，而这些正是开放模型目前还没有稳定占优的区域。我们不能从“开放模型总体接近够用”，直接推导出“整个视频生产链都应该开放模型化”。

因此，我得到的结论不是“以后全部使用开放模型”，而是：

把模型当作可替换能力，把 Harness、Memory、Permission 和 Evaluation 留在自己手里。

后续应该怎么做

结合这份报告，我觉得 Narrative 项目后面要继续坚持几件事：

OpenCode 是通用宿主，Narrative 业务不能写死在 OpenCode 上游代码里。
客户端和服务端使用同一套 Workflow、Tool Schema 和 Manifest 合同。
用同一个 Golden Case 对不同模型做质量、成本和失败率对比。
用户修改、评测结果和重试效果必须形成可追溯的数据。
高成本和不可逆操作必须进入统一的写权限策略。
本地创作与无人值守生产分开运行，但不能分叉成两套业务实现。
每一个关键模型能力都要考虑第二来源和退出方案。

前面我们在多 AI 开发中也遇到过一个很具体的问题：AI 花了大量时间运行测试和整理证据，却没有优先完成用户可见功能。

这个问题同样说明，模型只是 Harness 里的一个执行者。任务描述、上下文、文件权限、验收标准和反馈信号设计错了，再强的模型也会朝错误的方向优化。

模型能力当然重要，但它正在快速变便宜，也会不断被替换。真正值得长期投入的，是模型外面的那套系统，以及系统运行以后留下来的数据。

这也是我看完这份报告以后，对当前项目最明确的判断。