1000 TPS 大模型与手机智能体：高速推理真正改变了什么

高速推理不是完整手机 Agent

1000 TPS 大模型与手机智能体的讨论，最容易被误读成一句话：模型越快，Agent 越强。实际情况更细。1000 tokens/s 级别的高速推理确实会减少等待，尤其在连续对话、快速改写、代码辅助和多步判断里很有意义；但手机 Agent 不是只靠输出文字。它还需要理解目标、选择工具、检查权限、打开正确流程、展示结果，并在关键动作前让用户确认。

把速度放进真实手机任务里看，差别会更清楚。用户说“把这条地址打开到地图，顺便准备一条到达时间回复”，模型需要先读懂通知，再判断是否要查路线，再准备回复，再等待确认。高速推理可以让每一步更快，但它不能替 Android 授权，也不能替用户确认发送内容。需要了解手机动作本身的执行边界，可以把安卓手机 Agent 执行层作为背景阅读；这里的重点是速度如何改变上游推理，而不是重写完整手机控制指南。

在 FoneClaw，我们把模型速度视为重要的上游能力，而不是完整产品。更快的模型可以让任务规划更顺、等待更短、错误修正更及时；但我们仍然要把它接到受支持 Android 手机动作、可见确认和失败回退上。没有这层设计，1000 TPS 也只是更快地生成建议，而不是可靠地完成手机任务。

MiMo UltraSpeed 证明了什么，也没有证明什么

截至 2026 年 7 月 15 日核对，小米 MiMo 官方页面把 MiMo-V2.5-Pro-UltraSpeed 描述为 MiMo-V2.5-Pro 的 UltraSpeed 体验模式，基础是 1T 旗舰模型。页面称其最高推理速度突破 1000 tokens/s，支持文本输入输出、工具调用、流式输出和缓存，并给出输出 TPS 约 500-1000、普通 MiMo-V2.5-Pro 约 50-100 的对比说法。页面还列出量化交易、实时风控、科研和实时编程辅助等场景。

这些信息说明一件重要的事：高速推理已经从实验室指标进入产品叙事，并开始和工具调用、实时任务、长流程辅助联系在一起。对 AI Agent 来说，这不是普通的“回答更快”，而是让模型有机会在任务过程中更频繁地观察、判断和修正。一个慢模型可能在第二步就让用户等得不耐烦；一个高速模型可以把计划拆得更细，反馈也更贴近当前上下文。

但这些仍然是小米官方对 MiMo 的声明，不等于独立基准证明，也不等于 FoneClaw 使用 MiMo。我们不会把 MiMo UltraSpeed 的速度数字外推到所有模型、所有设备或所有手机 Agent。想从更宽的角度理解模型能力如何影响 Agent，可以参考AI Agent 模型能力指南；本页只讨论高速推理对手机 Agent 工作流的具体含义。

延迟为什么会放大长序任务的差别

单次聊天里，延迟只是“等几秒”的体验问题。长序任务里，延迟会被多次放大。一个手机 Agent 处理消息归类、路线检查、日历安排、通知清理或多应用信息整理时，通常不是一步完成，而是经历“理解目标、查找上下文、计划下一步、执行动作、检查结果、必要时重试”的循环。每一环都慢，整体任务就会变得不可信。

以通知清理为例，用户可能希望系统把快递、会议、支付提醒、聊天消息分成不同处理方式。模型要快速读懂通知类型，判断哪些可以忽略，哪些需要提醒，哪些要打开 App，哪些要等待确认。如果每个判断都要长时间等待，用户宁愿自己点。高速推理的价值在于让这些小判断更接近日常手机操作的节奏。

但速度不会自动解决质量问题。模型仍可能误解联系人、混淆时间、错误选择 App，或者在缺少权限时无法继续。长序任务真正需要的是快而稳：足够快，用户不觉得被拖住；足够稳，系统不会在不确定时继续推进。对手机 Agent 来说，延迟减少只是让更多检查变得可承受，而不是取消检查本身。

快模型与深度模型配合，才更接近实时 Agent

高速推理带来的一个设计启发，是快模型和深度模型可以分工。轻量、快速的模型适合做即时判断：这条通知是不是需要处理？用户这句话是不是补充了约束？当前页面是否和计划一致？更深的模型则适合处理复杂规划：跨多个 App 的任务顺序、敏感动作风险、长文本理解和失败后的替代方案。

这个思路不需要被理解成某个具体产品的内部架构，而是一种实用模式。实时对话和手机任务经常需要快速响应，也需要在关键时刻认真判断。快模型负责让系统不迟钝，深度模型负责让系统不草率。二者之间的配合，比单纯追求一个峰值 TPS 更接近真实 Agent 的需求。

例如，用户正在规划晚上的行程，系统可以用快速判断不断吸收新信息：朋友改了时间、地图显示拥堵、日历里有冲突、某条消息需要回复。等到需要决定是否改提醒、发送消息或切换路线时，再进入更谨慎的判断和确认。这样的循环才是高速推理真正有用的地方：它让 Agent 能更频繁地检查状态，而不是一次性输出一大段计划后就离开。

手机动作仍需要可靠执行层

推理和执行是两件事。模型可以判断“应该设置提醒”，但提醒需要进入系统或应用流程；模型可以判断“应该回复这条消息”，但回复内容需要展示给用户；模型可以判断“应该打开导航”，但地图 App、位置权限和当前网络状态都会影响结果。高速推理让判断更快，却不能替代手机侧的动作承接。

这就是为什么手机 Agent 仍需要执行层。执行层要回答具体问题：这个动作是否受支持？需要哪些权限？结果在哪里显示？用户是否必须确认？失败时如何回退？如果模型输出再快，却没有这些问题的答案，手机 Agent 只会更快地进入不确定状态。我们在 FoneClaw 关注的正是这部分：把意图转成可见、可控、可停止的 Android 手机步骤。

手机作为设备本身也提供了特殊条件：传感器、通知、应用入口、屏幕确认、系统权限和本地上下文都在这里汇聚。关于这个更大的设备视角，可以看AI 手机超级载体。但即使手机是最接近日常动作的设备，也不意味着任何模型都能自动接管它。没有可靠执行层，1000 TPS 仍然只是更快的上游能力。

我们在 FoneClaw 如何吸收这件事

在 FoneClaw，我们从 MiMo UltraSpeed 这类速度信号中看到的，不是“某个模型已经解决手机 Agent”，而是上游推理正在变得更适合长任务。更快的模型能缩短等待，让任务规划、状态检查和失败修正更自然。它会让手机 Agent 有机会从“一次性回答”变成“持续推进任务”。

这也已经进入 FoneClaw 的实际产品体验优化。FoneClaw 已经申请到 MiMo V2.5 Pro UltraSpeed 的内测账号，并正在使用这个小米官方称最高突破 1000 TPS 的万亿参数大模型来优化 FoneClaw 的使用体验。对手机 Agent 来说，价值不是抽象的跑分，而是更快理解用户意图、更快修正步骤，并让受支持的手机动作响应得更迅速。

我们的角色不是声明 FoneClaw 使用 MiMo，也不是追逐某个 TPS 数字。我们的路线是构建 Android 受支持手机动作：让用户知道系统准备做什么，需要什么权限，结果在哪里，什么时候必须由用户确认。高速模型可以增强这条路线，但不能替代它。没有权限边界和可见确认，再快的推理也不适合直接触碰敏感手机动作。

对用户和产品构建者来说，实用结论是：1000 TPS 级别的大模型会让 Agent 更有机会处理长序任务、实时对话和快速反馈；但真正可信的手机 Agent 还要把速度接到设备动作、权限、安全确认和失败回退上。我们在 FoneClaw 会继续把模型智能看作上游，把受支持 Android 手机动作看作产品落点。速度越快，边界越要清楚。