Scale AI Muse Spark 1.3 下载受限，opencode 该怎么配？

访问权限到手，接下来才是麻烦的开始

周二下午，我收到了 Muse Spark 1.3 的访问权限。Scale AI 那封邮件里夹着一个 Hugging Face 仓库链接，写着模型权重已经可以下载。我点开一看，屏幕上跳出 "this model is not available in your country"。

这句话对我来说不陌生。Claude 也好，某些版本的 Llama 也好，都曾在同一步卡住。可 Muse 不太一样——名义上它是 "open weights"，按理说在哪个国家都能下，但 Hugging Face 的地理围栏照样把我挡在外面。

绕过地区限制，有哪几种办法

两个晚上，我试了三种做法，最后留下最稳的那一个。

办法一：把 Hugging Face 账号的注册地区改掉

这个说法在网上传得最广，真试下来并不可靠。Hugging Face 判断地理位置，不只看账号注册地，还会参考 IP、历史支付方式，连浏览器时区都算进去。我拿新邮箱注册、挂上代理去访问，下载到中途还是断了，提示 "access revoked"。

办法二：找镜像站或学术镜像

国内确实有几家 Hugging Face 镜像站，同步延迟从几小时到几天都有。Muse Spark 1.3 发布那一周，主流镜像全都没跟上。另外镜像站的模型卡页面常缺东西，config.json 或者 tokenizer 文件说没就没，下回来也跑不起来。

办法三：API 代理加本地缓存

我最终用的是这个。权重不直接下，改走支持 Muse 的推理 API 服务做代理，比如 Together AI，或者 Scale AI 自己提供的托管端点。模型先加载到对方服务器上，再用 OpenAI-compatible 的 API 格式去调。

配置大致长这样：

import openai
client = openai.OpenAI(
    base_url="https://api.together.xyz/v1",  # 或其他支持 Muse 的端点
    api_key="YOUR_API_KEY"
)
response = client.chat.completions.create(
    model="scale-ai/muse-spark-1.3",
    messages=[{"role": "user", "content": "写一个 Python 函数，读取 CSV 并返回前 10 行"}],
    extra_body={"tool_choice": "auto"}  # Muse 支持工具调用
)

extra_body 里的参数是重点。Muse 的工具调用协议和 OpenAI 有点差别，tool_choice 必须显式声明，不写的话默认走纯文本，函数调用不会被触发。

opencode 配置：把 Muse 接到本地工作流里

地区这道坎过了，我就想把 Muse 拉进平时的开发环境。我用的编辑器是 VS Code 加 opencode 插件，它能自定义 provider，属于 AI 编码助手。

opencode 的配置文件放在 ~/.config/opencode/config.yaml。要加 Muse，得新建一个 provider 块：

providers:
  muse-spark:
    type: openai-compatible
    api_key: ${TOGETHER_API_KEY}
    base_url: https://api.together.xyz/v1
    model: scale-ai/muse-spark-1.3
    # Muse 特有的参数
    default_params:
      temperature: 0.2  # 代码生成建议调低
      max_tokens: 4096
      tool_choice: auto
    # 系统提示词，影响工具调用的稳定性
    system_prompt: |
      You are a coding assistant. When you need to modify files,
      use the edit_file tool. Always verify the file exists before editing.

这里头有几个坑。

坑一：工具调用的 schema 格式

在 function calling 上，Muse 对 schema 的要求比 GPT-4 更严。我一开始直接把给 GPT-4 写的工具定义拿来用，Muse 就老是生成不合 schema 的参数，比如把 boolean 写成 "true" 这种字符串。

处理办法是把 schema 写得更明确：

{
  "type": "object",
  "properties": {
    "file_path": {"type": "string"},
    "should_backup": {"type": "boolean", "enum": [true, false]}
  },
  "required": ["file_path", "should_backup"]
}

加上 enum 约束以后，Muse 的 compliance 提升很明显。

坑二：多文件修改时的上下文管理

Muse Spark 1.3 打的招牌之一是 "multi-file editing"。但实际测下来，一次性喂太多文件上下文，模型会把路径搞混。我的处理方式是：每次只让 Muse "看到" 当前正在编辑的文件和它的直接依赖，靠 opencode 的 include 和 exclude 规则来卡。

context:
  include:
    - "src/**/*.py"
  exclude:
    - "tests/**"
    - "*.pyc"
  max_files: 5  # 硬限制，超过就报错

自动化测试怎么跑：测试用例的设计思路

等配置跑稳了，我才动手规划测试用例。Scale AI 那场反馈征集并没有发下来一套标准测试集，只提了句 "real-world scenarios"。我按自己做项目的经验，把它们归成了四类。

第一类是基础代码生成，像 "用 FastAPI 写一个带 JWT 验证的用户登录接口" 这种。这类活儿主要看语法对不对、对框架 API 熟不熟。Muse 在这上面发挥挺稳，代码出来基本能直接跑，个别时候 import 路径得自己动手调一下。

第二类是代码补全和续写，给半段函数让它接着写。测下来发现，Muse 在 "意图推断" 上比 GPT-4o 差点意思。举个例子，我给了一段处理日期字符串的函数前半截，变量名是 dt_str，Muse 有时当它是 ISO 格式，有时又当它是自定义格式，前后不太一致。

第三类是工具调用链，这算是 Muse 的主场。我搭了个三步任务：先读配置文件，再照配置去调外部 API，最后把结果写进数据库。Muse 得正确挑出 read_file、http_request、execute_sql 这三个工具，还得把上一步的输出接到下一步。实测成功率差不多 70%。翻车的情况主要是两种：工具参数填错，比如把 URL 当成文件路径；或者漏掉中间某个步骤，直接跳到结尾。

第四类是代码重构和 bug 修复。给一段明摆着有问题的代码，让 Muse 诊断再修。我特意埋了个 Python 里经典的可变默认参数坑：

def append_to(element, to=[]):
    to.append(element)
    return to

Muse 确实把这个坑认出来了，但修法不太固定，有时候改成 to=None 再在函数里判断，有时候又改成 to=() 元组。两种都没错，可风格老变，我有点想不通——这到底是训练数据造成的差异，还是解码时的随机性在作怪？

提交反馈：contributor 流程的实际体验

测了整整一周，我攒下 12 条有效反馈，走 Scale AI 官方渠道交了上去。这里说说实际走下来的感受。渠道一是 Hugging Face 的模型卡讨论区，适合公开的技术问题，比如 "这个 tokenizer 的 special token 定义在哪里"。回复一般要等 2-3 天，而且是 Scale AI 的工程师亲自回，不是社区志愿者代劳。

渠道二是 GitHub 仓库 issue，适合代码层面的 bug，比如 "tool calling 在特定 schema 下返回 malformed JSON"。填的时候得按模板来：复现步骤、预期行为、实际行为、环境信息，环境信息里包括 opencode 版本、API 端点、模型版本。我一共提了 3 个 issue，其中 1 个在 5 天内被标成 "confirmed"，进了他们的内部 backlog。

渠道三是官方反馈表单，一个 Google Form，适合不方便公开讲的细节，比如商业场景下的性能数据。我填过一次，没收到直接回复，不过两周后在 release note 里看到了类似问题的修复，是不是我那条反馈起了作用，说不准。

反馈质量的关键在于复现路径。我最早交上去的几条被标成 "needs more info"，原因是复现步骤写得太笼统。后来学乖了，每条反馈都搭一个最小可复现脚本，比如：

# repro_muse_tool_call.py
# 运行: python repro_muse_tool_call.py
# 预期: 正确调用 get_weather 工具
# 实际: 返回 text 响应，未触发工具调用
import openai
client = openai.OpenAI(base_url="...", api_key="...")
tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "parameters": {
            "type": "object",
            "properties": {"location": {"type": "string"}},
            "required": ["location"]
        }
    }
}]
response = client.chat.completions.create(
    model="scale-ai/muse-spark-1.3",
    messages=[{"role": "user", "content": "北京今天天气怎么样"}],
    tools=tools,
    tool_choice="auto"
)
print(response.choices[0])

有了这种脚本，对面工程师一眼就明白问题出在哪，沟通起来顺畅多了。

一些没解决的疑问

一周测下来，Muse Spark 1.3 给我的整体观感是：在代码生成这个垂直场景里，它确实比通用聊天模型更 "懂" 工程实践，比如会自动考虑异常处理、会建议加日志。但工具调用的稳定性、多轮对话里的上下文一致性，还有很长的路要磨。

有几个疑问，我至今没弄明白。

• 同一个 prompt，为何有时会触发工具调用，有时却只走纯文本回复？temperature 已经设成 0，结果依然带随机性。
• "muse spark 1.3 fr" 这个法语变体，难道只是训练数据里语言分布不同？架构层面跟主版本有没有差别？Hugging Face 上的 config.json 我看过，两者完全一样。
• Scale AI 提到的 "hotfix"，落地方式到底是什么？动的是权重，还是推理服务前面的那层逻辑？

这些点我后面会接着追，也欢迎同样在测 Muse 的人一起聊聊。