通用代码助手能写脚本、改 UI、跑测试，但游戏项目的主体工作不止代码。UltraGameStudio 的设计目标更窄：让模型理解引擎、资产、构建和运行时，把一次聊天变成可审计、可复现、可切换宿主的工程操作。
大部分 coding agent 的默认假设是：项目主要由文本文件组成，任务最终落到代码 diff。这个假设在 Web 后端、工具脚本、库维护里很有效，但放到游戏开发会丢信息。游戏项目有场景、Prefab、蓝图、材质、动画状态机、打包配置、资源导入规则，很多失败不是类型错误，而是资源路径、引擎约定或流水线状态错了。
UltraGameStudio 的重点不是再做一个聊天 UI，而是把游戏开发里的“非代码部分”纳入同一个代理工作台。模型可以从代码切到图片、Sprite、3D 模型、音频和视频生成，再回到工程修改；会话历史保留上下文，用户不用在多个工具之间手动搬运 prompt、结果和文件。
这也解释了项目为什么采用本地优先的桌面架构。游戏工程通常体积大、路径深、引擎状态复杂，上传到远端服务既慢，也容易碰到授权和隐私边界。桌面端直接贴近工作区，远端模型只处理需要推理的部分，API key、历史记录和运行日志留在本地。
项目的活核心在 app/src/runtime/。它不关心自己运行在 Tauri 窗口、Node CLI，还是未来的远端 runner；它只处理任务图、上下文、回调、网关和验收。
桌面端负责窗口、文件选择、状态渲染和 Tauri 命令。CLI 负责参数、流式输出和退出码。核心语义不复制。
复杂任务需要并行、验收和重试。把任务显式建成图，比把所有步骤塞进一次模型调用更容易观测和恢复。
.ugs-run/ 记录事件、ledger 和 verdict。失败时能定位是哪一步、哪个通道、哪个验收条件出问题。
游戏开发任务的模型需求差异很大。改一个配置文件不需要最贵的推理模型；排查渲染管线、重构系统边界或做最终审查时，强模型的价值更高。UltraGameStudio 把供应商差异收敛到本地代理和通道配置里，让同一个聊天面板可以在 Claude Code、Codex、Gemini、OpenRouter、GitHub Models、本地 Ollama 等路径之间切换。
本地 free-channel proxy 负责协议翻译和错误处理。它把 Anthropic 风格和 OpenAI 兼容流式协议接到统一入口，遇到 429 或上游 5xx 时会冷却通道，再尝试下一个候选。这个设计不把“免费模型”包装成质量承诺，只把它当成可调度资源：便宜任务走低成本路径，关键任务走高可信路径。
这里的关键边界是：密钥和选择权留在本机。用户配置自己的 provider key，桌面应用只保存本地设置。远端通道可以扩展，但不应该把整个项目控制权交给一个托管服务。
游戏里的素材不是“附属品”。一张 UI mockup、一个 tileable texture、一段语音或一个 blockout mesh，都会影响代码结构和引擎配置。把资产生成放进同一会话，模型才能在产物和工程修改之间建立连续上下文。
| 能力 | 普通 coding agent | UltraGameStudio 的处理方式 |
|---|---|---|
| 引擎上下文 | 主要识别源码和 package 配置。 | 按项目标记判断 Unity、Unreal、Godot、Cocos 或 Web 引擎，再选择对应术语和文件边界。 |
| 素材产物 | 通常要求用户去外部工具生成，再手工导入。 | 图片、Sprite、3D、音乐、语音、视频走内置模式，结果留在聊天记录和工程上下文里。 |
| 专家分工 | 一个通用 assistant 处理所有问题。 | 按任务启用技术总监、玩法、AI、网络、工具、关卡、音频、QA、发布等角色。 |
| 运行证据 | 输出聊天内容，失败时难复盘。 | 运行事件、任务账本、模型选择和 verdict 持久化，便于重跑和审查。 |
第一，项目没有把运行逻辑绑死在 React 组件里。代价是接口层更明确，RunGateway、RunCallbacks、RunContext 这些概念需要维护；收益是同一套核心能被桌面端和 CLI 复用，测试和日志也更稳定。
第二，通道数量多会带来配置复杂度。这里的取舍是给用户选择权，而不是替用户假设“唯一正确模型”。实际工程里，模型可用性、速率限制、价格和任务风险每天都在变。把路由做成显式能力，比把供应商写死在产品里更耐用。
第三，资产生成会让产品边界变宽。它不再只是代码助手，还要处理图片、音频、模型、视频和 provider 配置。但游戏开发本来就不是纯文本工作流。如果产品只覆盖代码，它在最需要上下文的地方会断开。