免费的才是最贵的：游戏研发团队选择/自研 AI 工具的经验

calendar 2026-10-02 · 8 分钟阅读
免费的才是最贵的：游戏研发团队选择/自研 AI 工具的经验

这几个月，曾老师一直在尝试把传统的互动影游，与休闲游戏进行结合。在这个过程中，需要创建大量内部工具，并进行无数开源和闭源模型的测试。

可以说，市面上大多数的视频音频生成模型/文本推理模型/图像生成编辑模型，曾老师的团队全都试了个遍。

我们都知道，效率的提升，往往不是来自于是否接入了最优秀的模型，更多的是来自于是否构建了适合团队工作的工具。

目前产品已经上线，是时候总结一下了。

这也是在总结曾老师和团队一直在完善的 #AI嵌入游戏研发工作流 相关经验。

文章目录

工具列表

深度 AI 原生工作的团队都知道，高效率的核心不是工具，而是工具与人的配合。可以说，人类对于 AI 的边界越了解，整个团队的效率就越高。

随着团队人员的增长，管理成本和沟通成本会不可避免地增加，团队效率随之降低。

想要提升团队效率，需要在 Agent 和人类的配合上下功夫。因此，也需要在设计工具的时候，考虑 Agent 和人类的同时可操作性。

已经完成的工具不止下面这些，而且还在一直增长。

把清单按游戏素材的生产流水线摆一下，会更直观：

flowchart LR subgraph P1[素材生产] direction TB A["视频生成工具"] end subgraph P2[素材加工] direction TB B["抠图工具
matting"] C["视频抠图转透明
序列帧动画"] D["图像 / 视频超分
upscale"] end subgraph P3[界面制作] direction TB E["游戏 UI 生成与拆分
Figma + Photoshop"] end subgraph P4[共享与更新] direction TB F["资源分享工具
Agent + 人类"] G["NAS / 云盘 / S3 / CDN
更新工具"] end P1 --> P2 --> P3 --> P4

永远选择最优秀的工具

AI 时代，开发效率暴增，优秀的工具层出不穷。不同领域都有大量工具，如何选择？

例如，编程领域的 ChatGPT(Codex)/Claude Code/ZCode(GLM)/Kimi/OpenCode/Qoder/CodeBuddy/Kilo……，视频领域的即梦/可灵/MiniMax/Vidu……，音频领域的 Suno/Mureka/MiniMax/ACE-Step/Stable Audio/ElevenLabs Music……，图像领域的 Nano Banana/gpt-image-2.5……

你也注意到了，上面的对比维度是不统一的。例如 gpt-image-2.5/ACE-Step 是模型名，即梦是产品名，Mureka 是平台名，而且既有商业平台，也有开源模型。

更别提还有一堆优秀的整合产品，例如 LoveArt/剪映等等。如何选择？

对于以商业化目标作为主要目的的初创团队来说，在选择工具的时候，曾老师只遵循以下简单的原则：

  1. 编程选最好的。目前最好的工具只有 Claude/ChatGPT，闭眼入即可。前提是你不被封号。
  2. 视频选匹配的。例如目前最优秀的视频生成模型是 Seedance 2.5，成片效率高（贵）。但游戏内的序列帧动画生成，完全可以用 MiniMax H3 胜任，量足。
  3. 图像生成和编辑模型，选最好的。目前最好的是 gpt-image-2.5，没有之一。

至于剪映/LoveArt 这样的工具，根据团队需要充值季卡即可，如果有特殊优惠可以上年卡。毕竟不知道什么时候，就会有更好的工具出现。

相信我，更好的工具会随着时间的推移，逐渐集中在大厂身上。

许多流量很高的 Agent 工具，真的就是普通人玩玩就好。毕竟：

  • 大多数人追求的是「免费好玩」。
  • 团队追求的是「哐哐挣钱」。

免费的才是最贵的。

团队中转站统一 TOKEN 消耗

New API/OmniRoute 都是优秀的自部署中转站，这样的项目还有不少。

把团队使用的所有 API，全部集中在一个中转站管理，能省去不少麻烦。不但解决了一个 KEY 支持一吨模型的问题，还解决了多模型之间接口的统一问题，顺便也能把计费和额度管理起来。

但不是每个中转站都能解决全部的问题。因为：

  1. 大多数推理大模型，主要是兼容 OpenAI 的两套 API 标准，这个没问题。
  2. 但有一些模型，已经走在世界前列，你必须遵循这些模型自己的标准。例如 Seedance。

Seedance 视频生成是任务式异步 API——创建任务、返回任务 ID、隔几分钟去查结果。而所有主流开源网关（OmniRoute、new-api）都是请求-响应式的，它们适配的协议是 chat completions、images generations 这类「一发一收」的 API。

每个模型都有自己的计费标准，而且模型的更新非常快速，因此中转站也需要不断更新支持不同的调用和计费方式。

例如这次 New API 的提交就在解决 Seedance 2.0 的计费问题：

https://github.com/QuantumNous/new-api/pull/5300

2.0 解决了，那 2.5 呢？

中转站大多使用自己的封装方式，对原生的模型进行了一次再包装。那么，既然要独立实现每个不同模型的调用协议，为什么不直接调用原始模型呢？

重新定位问题

到这一步，曾老师停下来把问题重写了一遍。

最初的问题是「使用一个 API 支持多个模型」。但真正的问题其实是：让团队成员用顺手的 Agent 工具，调用视频/音频/图像生成/编辑能力，将计费、授权、审计都在内部系统里闭环。

网关（中转站）只是基于流量设计的方案，它不是一个好方案。

SORB 包含了所有模型

在游戏开发和漫剧制作的过程中，曾老师已经把所有的模型支持都整合进了内部系统 SORB。翻一下清单，目前包含了 68 个模型和工具。

SORB 内置工具

那么，只需要让 Agent 能使用这些模型，再补上资源管理，所有分散的资源和流程就能全部整合进同一个平台。

这样，团队内部就能共享同一套资源库、知识库和工作流，不必再用低效的 IM 互传方式共享资源。

模型选择

解法 1：让 SORB 内置 Agent

曾老师最初的做法，是在 SORB 工具中，整合一个 Harness，让它能读取所有的资源，使用所有的工具，自动创建卡片和提示词。这也是目前主流工具的做法。下图就是虎澈 AI 团队内部的 Agent 牛百万在无限画布中工作的场景。

牛百万在 SORB 的无限画布中

Harness 对 Skill 的支持，让我们可以不断扩展工具的能力。

内置技能选择

然而这里出现了一个限制，本地的 Agent 无法使用 SORB 工具。

例如，下面的操作会难以进行：

  1. 本地的 Codex 或者 Claude Code 中，使用 SORB 的生视频/编辑视频/抠图/超分功能
  2. 利用本地 Agent 中的 Skill 和上下文去 SORB 中继续工作
  3. 利用本地 Agent 的能力解析本地的图像和视频，再去 SORB 进行生成和编辑
  4. 等等……

解法 2：让 SORB 支持 MCP

SORB 的调用链路是通的，权限、任务、计费体系都是现成的。反过来做也是可以的——让能力所在的系统向外暴露标准协议。

MCP（Model Context Protocol）恰好就是为这个场景设计的。SORB 通过 MCP 开放了 61 个功能，下面是其中 3 个：

  • create_video_task：创建任务。参数用 JSON Schema 完整表达——时长、分辨率、镜头控制、多参考素材，全都能类型化地声明
  • get_video_task：查任务状态
  • list_video_models：报账号真实可用的模型

无论本地、远程还是云端的 Agent，都可以使用同样的流程：调 create_video_task 拿任务 ID，隔几分钟调 get_video_task 查结果。异步任务配工具调用，不需要任何协议层面的多余操作。

客户端方面，ChatGPT、ZCode、Claude Code、Kimi Code、DeepSeek Harness…… 都天然支持 MCP，团队成员完全可以选择自己熟悉的 Agent 工具。

多 Agent 关系：牛百万和外部 Agent 怎么分工

有个绕不开的问题：SORB 自己有内置 Agent 牛百万（Canvas 智能助手）。现在又让外部 Agent 通过 MCP 进来，两个 Agent 会打架吗？

不会，因为它们的分工很明确：

  1. 牛百万是画布内工具：它在无限画布里陪用户讨论创意、优化提示词、创建生成卡片。SORB 是权限、画布版本、任务、计费、授权和生成素材的唯一事实来源，牛百万就是这套秩序的界面。付费和破坏性操作返回 pending_approval 时，必须停下来等授权，不许重试，不许绕过。
  2. 外部 Agent（ZCode、Claude Code 这些）是员工的手：它们不在无限画布的工作流程中，通过 MCP 拿到的是 SORB 授权出去的工具。

外部 Agent 不能直接碰生成服务商，不能绕过计费，不能跳过 pending_approval。牛百万管的是画布里的创意流程，外部 Agent 管的是员工自己的工具链。两者通过 MCP 这个明确定义的接口交接，各干各的。

MCP 协议升级的影响

MCP 协议今年 7 月底刚经历最大改版（2026-07-28 规范）：核心架构改成无状态，远程 HTTP 传输推荐了 OAuth 2.1 授权流。

https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/

目前外部 Agent 工具对新的 MCP 协议的支持还处于过渡阶段，让 SORB 同时支持 stdio 和 OAuth 即可，这样老的客户端也能继续使用 SORB MCP。

MCP 接入

内部工具不只是中转站

游戏研发团队内部 AI 工具，不能只是一个中转站。

中转站解决的是「一个 KEY 调用一吨模型」，这是流量问题。团队真正的问题是——成员用顺手的 Agent 工具，调用视频、音频、图像的生成和编辑能力，计费、授权、审计全部在内部闭环。

曾老师的解决方案：

  1. SORB 内置 Agent 牛百万，管住画布里的创意流程。
  2. SORB 向外暴露 MCP，让外部 Agent 拿到授权的工具，成为员工自己的手。
  3. 选择最优秀的工具，如果没有，那就写一个。AI 时代，制作一个新的工具，无比简单。
flowchart TD A["最初的问题
一个 API 支持多个模型"] B["中转站方案
New API / OmniRoute"] C1["任务式异步 API
创建任务、轮询结果"] C2["调用与计费方式各异
模型更新快，网关跟不上"] D["真正的问题
成员用顺手的 Agent 调用工具能力
计费 / 授权 / 审计内部闭环"] E["SORB
已整合 68 个模型和工具"] F["解法 1：内置 Agent
牛百万，管画布内的创意流程"] G["解法 2：对外开放 MCP
61 个功能，stdio + OAuth 2.1"] H["外部 Agent 自由接入
ChatGPT / ZCode / Claude Code / Kimi……"] I["共同边界：不绕过计费
不跳过 pending_approval"] A --> B --> C1 B --> C2 C1 --> D C2 --> D D --> E E --> F E --> G G --> H F --> I H --> I

优秀的工具，解决的不是生成问题，而是效率问题。AI 时代，生成的成本无限降低，但选择和决策的低效问题仍在。核心问题是人与人之间的高效沟通，以及产出的半成品和工作结果之间，尽量用工具减少低效的人类沟通。

人类的沟通方式，还是太落后了。

来胡扯社群，一起聊天！

有很多重要内容，公众号发不了，但群里特别能聊。

「胡扯漫剧」 社群关注最新的 AI 漫剧知识，技巧和搞钱方法论。

「胡扯游戏」 社群有独立开发者，游戏公司创始人、大厂负责人、量子理论研究者…… 独立游戏、商业游戏、流量游戏、研发、投放、发行、运营、招人 都能聊，纯唠嗑也欢迎。

「胡扯行业」 群关注游戏、电商、工具、视频…… 泛互联网行业都可以加入。

「胡扯AI」 社群关注 AI 深度整合进入工作流。

胡扯知识（免费） 胡扯社群（免费）
胡扯知识
胡扯社群

胡扯知识库栏目

识别上方二维码获取加入胡扯社群的详细说明，关注下方公众号亦可获得更多信息。

「曾嵘胡扯的地方」是一个关注AI、游戏、互联网前沿资讯的公众号。撰稿人曾老师基于丰富的创业经验和公司管理经验，多年的游戏研发经验，全栈编程和自研+自发经验，二十多年的写作经验，持续以公众号为阵地，进行高频输出和有效讨论。公众号追求松弛感，提供正能量，为群友提供价值，为行业做点贡献。

都刷到这里了，不来个「点赞」「分享」「在看」一键三连吗？