我们如何为手机本地 Agent 选择模型

这套测试最早不是为了做一张模型排行榜。

我们当时遇到的问题很具体：手机里的本地 Agent 需要一个默认路由模型。它不能只会聊天，还要在很短的时间里判断用户想做什么、选择正确的能力、提取执行参数，并在信息不足时停下来追问。与此同时，它还得装得进手机，不能因为 8K context 就把内存和发热推到不可接受的水平。

所以我们真正想验证的是：

在我们的双语、结构化、手机本地 Agent 场景里，哪个模型能以合理的资源成本，最稳定地完成路由与执行参数生成？

这个限定很重要。我们测到的不是模型的通用智力，也不是写作、数学或知识问答排名。它回答的是一个产品工程问题。

先把 Agent 的工作拆开

用户说一句“明天早上七点叫我起床”，真正执行之前至少要完成两步判断。

第一步从当前可用能力中选出正确的 Skill，例如闹钟、日历、邮件或记忆。第二步再选择具体 Action，提取已知参数、列出缺失参数，并判断当前应该直接执行、先规划，还是向用户追问。

flowchart LR
    A[用户请求] --> B[候选 Skill 召回]
    B --> C[Stage 1: Skill 选择]
    C --> D[Stage 2: Action 与参数]
    D --> E{信息是否完整}
    E -->|完整| F[执行或规划]
    E -->|缺失| G[结构化追问]
    F --> H[Swift Runtime 校验]
    G --> H

我们没有让模型直接输出一段看起来合理的自然语言，然后凭感觉打分。评测器要求它返回明确的结构：Skill、Action、Mode、已知 Slots、缺失 Slots 和目标。Swift Runtime 再用确定性规则检查这个结构是否属于当前候选范围、是否符合 Schema。

原因很简单：对于一个会操作系统能力的 Agent，“大概理解了”不够。选错 Action 和少填一个关键参数，后果完全不同。

96 条用例是怎么组成的

当前模型横测使用 v3-96-staged-skill-action 数据集，共 96 条请求：

core 用例验证常见表达，例如创建闹钟、查询日程、起草邮件。challenge 用例会加入相近能力干扰、缺少必要信息、跨能力规划和更含糊的说法。

我们刻意保留了短输入。真实手机上的指令经常只有几个字，“八点提醒我”或者“回一下这封邮件”都很常见。一个模型如果只在写得像测试题的完整句子上表现稳定，对实际产品帮助不大。

每条用例都保存期望 Skill、Action、Mode 和相关结构约束。当前公开成绩按完整 96 条作为分母，不会把解析失败的样本从准确率里删掉。

96 条用例和预期结果

下面的“预期结果”不是最终自然语言答案，而是模型必须交给 Runtime 的路由契约。每条用例分别核对 Skill、Action 和 Mode；“附加断言”表示该题是否还检查缺槽为空/非空，或者必须进入规划。

三种具体判分示例

• 信息完整：明天早上七点设置一个起床闹钟

应为 builtin.alarm.manage → create_alarm，Mode 为 act，missing_slots 必须为空。

• 信息不完整：帮我起草一封邮件

应为 builtin.mail.draft → create_draft，Mode 为 clarify，missing_slots 必须非空。邮件 Schema 要求收件人、主题和正文。

• 多步骤任务：先查看明天日程，然后为没有空闲时间的事项创建提醒

应为 builtin.task.plan_recover → orchestrate，Mode 为 act，并满足 requires_plan = true。

这里也能看出当前版本的一项限制：v3 对缺槽只检查“空”或“非空”，还没有逐个给缺失字段名称计分。精确槽位名称和值会进入下一版契约测试。

Core：48 条常规用例

Challenge：48 条边界用例

我们分别看哪些指标

我们不使用一个可以互相抵消问题的总分。

Parse 高不代表语义正确。一个模型可以非常稳定地输出合法 JSON，同时稳定地选错 Skill。反过来，模型可能理解了任务，却因为输出格式漂移而无法被 Runtime 使用。这两类失败必须分开看。

最终是否适合作为执行路由模型，主要看 Skill、Action、Mode 和缺槽行为。只在 Skill 上表现好、Action 明显偏低的模型，可以继续研究为第一阶段粗选器，但不能直接获得系统操作权。

尽量公平，不等于所有 Prompt 一模一样

10 个模型统一使用 GGUF Q4_K_M，相同 evaluator、相同数据集、相同 4K/8K 配置，以及固定解码参数：

temperature = 0
top_p = 1
top_k = 1
seed = 42
candidate_limit = 3

但我们没有把同一段 ChatML 文本硬塞给所有模型。Llama 3 使用自己的 header tokens，SmolLM3 显式关闭 extended thinking，LFM2.5 使用要求的 start-of-text token。Prompt 内容和输出契约保持一致，外层模板遵循模型原生格式。

这是我们对公平性的理解：任务相同、信息相同、规则相同，但不要故意用错误模板让某个模型吃亏。

每个权重还记录发布方、仓库、commit、文件名、字节数、SHA-256、许可证和 Prompt Profile。只写一个模型名称远远不够；同名模型的不同转换或量化文件，结果可能并不一样。

能力测试和真机测试为什么分开

这里有一个容易误读的地方。

96 条能力用例使用相同模型权重，在桌面 Metal evaluator 上运行。这样做便于批量执行、保存完整原始输出，并让不同模型在稳定环境中重复比较。

资源数据则来自 iPhone 15 Pro Max 真机，配置为 A17 Pro、8 GB 物理内存、SwiftLlama 和 llama.cpp b8668。每个模型分别测试 4K 与 8K，每个组合独立启动三次，共 60 次。

真机记录：

• 模型加载时间；
• 短 Prompt 的 TTFT；
• 进程内存；
• Metal 内存；
• 热状态；
• 是否成功完成基础生成。

flowchart TB
    A[固定模型文件与 SHA-256] --> B1[桌面 Metal 能力评测]
    A --> B2[iPhone 真机资源评测]
    B1 --> C1[96 条双语请求]
    C1 --> D1[Parse Skill Action Mode]
    B2 --> C2[4K 与 8K 各三次独立启动]
    C2 --> D2[Load TTFT Memory Thermal]
    D1 --> E[选型判断]
    D2 --> E

我们没有把这两类数据混在一起。桌面上的能力准确率不能冒充 iPhone 端到端任务成功率；iPhone 上成功加载也不能证明模型已经理解了 96 条请求。

4K 和 8K 到底测了什么

本轮真机 Prompt 很短，生成也很短。因此 4K/8K 数据主要回答三件事：

1. 模型能否在目标设备上按该 context 配置成功加载；
2. context 扩容带来多少内存增量；
3. 短请求下的启动、首 token 和热状态是否可接受。

它没有证明模型在填满 8K token 后仍然保持同样速度，也没有测长文 prefill 吞吐。要验证后者，需要实际放入约 3.5K 和 7.5K token，并记录 prefill、生成速度、能耗和持续热曲线。

换句话说，本轮的 8K 是容量与资源测试，不是“8K 长文本能力认证”。

一次结果如何留下证据

每次能力评测都会保存模型原始输出及其 SHA-256，而不只保留最后的百分比。汇总 JSON 同时记录：

• 数据集版本与 digest；
• 模型文件 SHA-256；
• Prompt 配置 SHA-256；
• Prompt Profile；
• context 与候选数量；
• 每条用例的期望值、实际值和各项判断；
• TTFT、E2E 延迟和 token 数；
• 是否触发格式修复。

真机侧保留每次独立启动的原始文本、CSV 汇总和单模型校验文件。整个证据目录另有统一 SHA256SUMS.txt。

这套做法不能阻止所有人为错误，但至少可以回答三个基本问题：当时测的是哪个文件、使用了什么配置、最后一个百分比是由哪些原始样本算出来的。

我们不会用这套结果证明什么

目前这套测试可以支持“为当前手机本地 Agent 选择路由模型”，但不能直接支持以下说法：

• 某个模型的通用智力更强；
• 某个模型在所有语言、所有 Tool 场景都更好；
• 8K 长文吞吐已经得到验证；
• 真实闹钟、日历或邮件操作的端到端成功率已经达到某个数字；
• 这是一份学术意义上的行业排名。

当前 96 条中，48 条 core 用例参与过开发反馈，不能视为完全独立的最终留出集。clarify、planning 等关键切片的样本仍然偏少。真机每个配置只有三次启动，也没有完成随机运行顺序、统一冷却、耗电和 20 轮持续会话。

这些限制不是附在文章末尾的客套话，而是结论的一部分。

下一版怎么补强

我们已经为下一版准备了更严格的方向：

1. 建立不少于 300 条的独立 holdout，并与 tuning 集隔离；
2. 每条案例由两名非作者按版本化 Rubric 复核；
3. 每案例至少运行三次，报告稳定通过、波动案例和 95% Wilson 下界；
4. 加入真实 3.5K/7.5K prefill、持续会话、耗电、热曲线与 Jetsam 恢复；
5. 在隔离 Tool fixture 中验证参数、调用顺序、审批、追问和最终环境状态；
6. 最后再用真机系统能力验证少量高风险端到端路径。

其中 300 条 tuning/holdout 草案和 Harness 已经存在，但尚未完成人工双审，所以我们不会把它们包装成正式成绩。

回到最初的问题

这套方法没有试图找出“世界上最聪明的小模型”。它做的是一件更窄、也更有用的事：在明确的设备、Runtime 和 Agent 契约下，找出最适合当前场景的默认模型，并知道它为什么赢、会在哪里失败。

完整的 10 模型结果、4K/8K 真机资源数据和逐模型判断，可以继续阅读《iPhone 真机横测 10 款小模型》。