AI Agent 本地化部署正在成为移动端最有潜力的技术方向之一。过去在手机上跑 Agent大多数人是把请求发送到云端大模型等返回结果后再拼接下一轮工具调用。Demo 阶段这种方案没有问题一旦进入真实日常场景延迟抖动、断网不可用、隐私边界和按 token 计费的成本都会变成硬约束。于是出现了一个现实问题手机自己的内存和算力能不能支撑一个会识别意图、调用本地工具、做多轮决策的 AgentLiquid AI LFM 2.5 就是讨论这类问题时经常出现的一个模型系列。它提供了不同参数规模的权重覆盖从手机到数据中心的部署场景也延续了对非纯 Transformer 混合架构的探索。这篇文章不会只停留在模型介绍而是从架构特点出发说明为什么这类小参数模型适合本地 Agent再给出部署、量化、启动本地服务的完整流程并用一个最小 Agent 循环验证工具调用能力最后整理性能测试和常见问题排查路径。文章不绑定某个固定手机型号也不给出无法复现的“跑分神话”。性能部分重点讲测试方法和结果解读方式。你手边只要有一台支持本地大模型推理的设备无论是 Android 旗舰、Apple Silicon Mac还是普通 Linux 开发板都可以按这套流程跑一遍。1. 手机端跑 AI Agent为什么比跑聊天助手更难1.1 Agent 不是对话框而是多轮决策循环聊天助手的核心是文字生成。用户输入一句话模型预测后面最可能的 token生成一段回答会话结束。这里模型只需要理解语言、保持上下文一致、提供有用信息并不会真的操作系统。Agent 完全不同。它至少要完成“理解目标、拆解步骤、确定是否调用工具、执行工具、读取结果、继续推理、直到完成”这样一条链路。用手机本地模型承载 Agent第一道坎不是模型会不会说话而是模型能否在连续多个回合里保持工具调用格式稳定。一个常见场景是用户帮我把明天上午十点的会议提醒记到笔记里。 模型应该调用 save_note 工具。 Agent执行 save_note(会议提醒, 明天上午十点开会)。 模型根据工具结果确认保存成功。整个过程至少需要两次模型推理中间还要插入一次实际文件写入。如果模型在第二次推理时忘了用户目标或者输出 JSON 结构变形Agent 循环就会中断。因此手机端选模型不能只看单轮问答效果还要看指令遵循稳定性、JSON 输出稳定性和多轮状态记忆能力。1.2 手机端的硬约束不只是“内存不够”很多人以为手机跑不了大模型是因为内存太小。实际上真正卡住体验的是三个因素同时作用内存容量、内存带宽和散热功耗。大模型推理时权重需要反复读取生成阶段属于典型的 memory-bound 场景。单纯提高 CPU 频率或 GPU 核心数收益并不高瓶颈往往在内存带宽。一个 3B 模型用 4bit 量化后约 2GB理论上不少手机放得下但每次生成一个 token 都要把全部权重扫一遍内存带宽不足时速度会明显下降。内存容量决定模型能否放得下内存带宽决定生成速度散热功耗决定能不能持续跑。许多手机在连续推理几分钟后会出现温度升高、系统调度降频原本 30 token/s 的生成速度会掉到十几甚至更低。这也是本地 Agent 和云端 API 最大的体验差异云端超时或抖动是网络问题本地跌速是散热问题。1.3 本地 Agent 换来的是隐私、离线和稳定成本本地部署要接受算力弱于云端这个事实换来的是三样确定性隐私。语音、笔记、日程等敏感内容不需要上传到外部服务。离线可用。地铁、飞行、无信号的房间里Agent 依然能处理本地工具。成本可预期。不再按 token 计费只需要一次性承担功耗和设备折旧。LFM 2.5 这类模型的价值在于它本身瞄准了“分层部署”方向小参数版本可以放在移动设备中参数版本可以跑在个人电脑再大的版本才留给服务器集群。对个人开发者来说先用小模型跑通 Agent 闭环再把部分复杂任务交给云上大模型是当前比较现实的混合架构。2. 理解 LFM 2.5 架构混合模型到底在混合什么2.1 为什么不能只看参数量给模型选型时很容易陷入“参数越大越聪明”的惯性。可对手机来说同一个 3B 模型采用纯 Transformer 结构还是混合结构长上下文表现可能差很远。纯 Transformer 的 KV cache 会随序列长度线性增长。Agent 单轮任务往往不短系统提示词、工具说明、历史对话、工具执行结果全部塞进上下文之后KV cache 会快速膨胀。手机内存本来就要放模型权重再叠加持续增长的 KV cache很快就会出现内存紧张。这还没有把“上下文变长后计算量上升”的问题算进去。LFM 2.5 在公开资料里延续了混合架构思路。工程上一般会认为这类架构不像纯 Transformer 那样每一层都使用标准注意力而是把不同类型的层组合到同一个网络里用更少的内存代价换取接近标准注意力的记忆能力。2.2 注意力层、滑动窗口层和线性注意力模块的分工如果只看网络配置混合模型通常会让不同层承担不同职责层类型主要职责优点需要付出的成本标准注意力层从完整历史中检索精确信息长距离记忆能力强KV cache 随上下文增长滑动窗口注意力层只关注最近一段相邻 token捕捉局部语义计算量可控距离较远的依赖会丢失线性注意力或门控循环类模块把历史信息压缩成固定状态状态尺寸近似固定适合长上下文极端精确记忆能力弱于标准注意力在 Agent 场景里三种能力都有用。标准注意力适合记住用户最初的目标。比如用户先说要“明天上午十点开会”中间又说了三段别的话题最后要求“把它写进日程”此时模型必须从早期上下文找回目标。滑动窗口注意力负责处理工具输出的局部格式比如 JSON 里括号是否完整、字段名是否正确。线性注意力类模块则控制整体状态规模避免上下文不断变长后内存失控。LFM 2.5 实际每个版本如何配置这些层需要以官方权重仓库和模型卡为准。不同参数规模的版本差异可能很大不能认为“同一个系列就复制同一套配置”。2.3 这些设计落到手机端意味着什么对手机端推理来说最值得关注的不是精度对比表而是三个实际表现较长上下文下 KV cache 增长更平缓4bit 量化后小参数模型仍能保持稳定工具调用格式解码过程对内存带宽和算子库优化的敏感度更高。第二个方面尤其需要亲自验证。一个架构再合理的模型如果只支持 FP16 且没有量化版本手机端依然跑不动。一个量化质量差的 3B 模型即使能加载也可能在输出 JSON 时频繁出错。实际选择 LFM 2.5 时建议按下面这张表做初步判断参数规模典型定位手机本地能否直接跑建议验证重点1B 左右轻量分类、意图识别、简单问答能量化后占用低工具调用是否稳定、中文是否够用3B 左右本地 Agent 主力能需要 4bit 量化和足够的运行内存多轮指令遵循、JSON 输出格式7B 左右高性能本地 Agent部分旗舰设备勉强能跑散热、功耗、内存占用14B 及以上电脑或服务器场景不建议直接用于手机边缘设备上评测推理速度表格不是绝对结论。真实表现取决于推理引擎、量化格式、设备内存和系统后台策略。2.4 混合模型的另一个潜在收益量化友好混合架构通常比同规模纯 Transformer 更容易压缩。原因是线性注意力或门控循环类模块对低比特权重波动的容忍度往往高于标准注意力中的 QKV 投影。落到实操上就是 Q4_K_M、MLX 4bit 这类常见量化版本可能比预期更接近 FP16 的结果。但这也是最容易踩坑的地方。量化友好的判断不能泛化到所有层。如果量化时没有保留某些关键层或者混合层在推理引擎中没有完整实现后果不是精度轻微下降而是输出完全乱掉。因此选 LFM 2.5 权重时不要只下载最大或最小的那个文件而是先确认本地推理引擎对混合架构的支持程度。若引擎没有对应算子的最优实现可能表现为能加载、能推理但速度远低于同参数量传统模型。3. 本地部署前需要确认的环境和依赖3.1 先选推理引擎再决定怎么下载权重手机和边缘设备上的推理引擎选择取决于操作系统和硬件。下面是一组常见组合设备环境推荐推理路线适合场景Apple Silicon MacMLX、llama.cpp、Ollama开发调试、快速验证模型、性能对比Android 手机 / Linux 开发板llama.cpp、ExecuTorch、MediaPipe LLM Inference端侧集成、App 内原生推理Windows / Linux 电脑llama.cpp、Ollama、vLLM 等中大型模型本地验证、服务化树莓派类弱设备llama.cpp CPU 推理低频 Agent 任务、联网警报类场景对新手而言最容易起步的是先安装支持 GGUF 的推理框架。llama.cpp 的llama-server可以把模型包装成本地 HTTP 服务并提供一个兼容 OpenAI 风格 chat 接口后续写 Agent 循环会方便很多。安装前先确认推理框架是否支持当前权重使用的算子。不同框架对混合架构的优化程度差异很大同一个 GGUF 文件在 llama.cpp 和另一个只优化传统 Transformer 的引擎上跑速度可能差出数倍。3.2 模型权重和量化格式怎么选LFM 2.5 的权重通常按仓库发布常见格式包括 GGUF、MLX 权重和原生 safetensors。三个格式对应不太一样的用法格式特点适合场景GGUF易于量化llama.cpp 生态支持广手机、电脑、开发板通用MLX 权重针对 Apple Silicon 优化Mac 上体验最佳safetensorsHugging Face transformer 生态常用原型调参、评测、微调手机本地部署优先选 GGUF 量化版本。不熟悉量化参数时可以先从 Q4_K_M 或同等 4bit 量化入手它在模型体积和精度损失之间通常比较平衡。下载权重前要做的检查确认设备的可用内存大于模型文件体积的 1.3 到 1.5 倍确认推理框架版本支持 LFM 2.5 对应的架构确认权重文件的校验值和仓库发布信息确认 chat template 是否已内嵌在权重 meta 中确认当前引擎输出是否支持 OpenAI 格式的 chat completion。不要只看模型文件大小。许多手机虽然有 16GB 内存但留给普通应用的高性能内存区不一定足够。Android 上还要考虑系统限制单进程占用内存的情况。3.3 部署前五项检查进入正式部署前建议先执行一次环境检查# Linux / 开发板查看可用内存 free -h # 查看 CPU 和负载信息 lscpu | grep -E Model name|Core|Thread|MHz # 查看磁盘剩余空间 df -h .Mac 上可以打开活动监视器先记录空闲内存。Android 上不要只记总内存先查看后台应用占用必要时清理后台任务。这五项不需要全部复杂操作但能避免后面反复试错可用内存是否足够。是否开启高性能电源模式。当前推理框架对 LFM 2.5 架构的支持情况。模型 chat template 是否齐全。是否有连续 10 到 20 分钟不移动设备的环境用于稳定测试。4. 最小可运行的本地 Agent 工具调用循环4.1 先用本地 HTTP 服务把模型拉起来在手机或开发板上直接用 Python 往返调用本地推理是最快的验证方式。选择 llama.cpp 自带的llama-server启动参数大致如下llama-server \ -m ./lfm-2.5-3b-q4_k_m.gguf \ --port 8080 \ --ctx-size 8192 \ --threads 4 \ -ngl 0不同版本参数名称可能不同先执行llama-server --help确认。-ngl 0表示不使用 GPU 层适合先验证模型本身如果手机支持 GPU 加速且框架支持混合架构可以逐步增大层数。启动成功后用下面的请求验证服务curl -s http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: lfm-2.5-3b-q4, messages: [ {role: user, content: 用一句话说明你是谁} ], temperature: 0.2 }如果返回 JSON 中包含choices字段说明模型服务已经可用。4.2 Agent 循环如何设计才能绕过模型的不稳定不同模型的工具调用能力实现方式不一样。有的原生支持 OpenAI 风格的tools参数有的只是靠系统提示词里的文本格式约束。为了兼容性更强这里用“纯 JSON 协议”来演示要求模型在需要调用工具时输出固定结构的 JSONAgent 解析后执行对应工具再把工具结果作为后续消息传回模型。这种写法不依赖后端对 tools 参数的特殊映射适合拿不同模型做横向对比。真实产品中可以再根据模型能力切换到原生tools协议。一个最小 Agent 循环示例代码如下import json import time import urllib.request from datetime import datetime from pathlib import Path OLLAMA_ENDPOINT http://127.0.0.1:8080/v1/chat/completions MODEL_NAME lfm-2.5-3b-q4 NOTE_FILE Path(./local_notes.json) SYSTEM_PROMPT 你是一个运行在本地设备上的 AI Agent。 你可以使用以下工具只能输出 JSON 对象不要输出任何解释。 工具列表 1. get_time()获取当前时间。 2. list_notes()列出记事本中的所有笔记。 3. save_note(key, text)将文本保存到本地记事本。 如果需要使用工具输出如下格式 {tool: 工具名, arguments: {参数名: 参数值}} 如果不需要工具直接输出最终回答 {answer: 你的回答} def chat_once(messages, temperature0.2, max_tokens1024): payload { model: MODEL_NAME, messages: messages, temperature: temperature, max_tokens: max_tokens, stream: False, } req urllib.request.Request( OLLAMA_ENDPOINT, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json}, ) with urllib.request.urlopen(req, timeout120) as resp: data json.loads(resp.read().decode(utf-8)) return data[choices][0][message][content] def execute_tool(name, args): if name get_time: return {result: datetime.now().strftime(%Y-%m-%d %H:%M:%S)} if name list_notes: if not NOTE_FILE.exists(): return {result: []} return {result: json.loads(NOTE_FILE.read_text(utf-8))} if name save_note: notes {} if NOTE_FILE.exists(): notes json.loads(NOTE_FILE.read_text(utf-8)) notes[args[key]] args[text] NOTE_FILE.write_text(json.dumps(notes, ensure_asciiFalse, indent2), utf-8) return {result: 保存成功} return {result: 未知工具} def run_agent(user_input, max_steps5): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input}, ] for step in range(max_steps): raw chat_once(messages).strip() print(f[step {step}] model raw:, raw) try: action json.loads(raw) except json.JSONDecodeError: return 模型输出不是合法 JSONAgent 中断。 if answer in action: return action[answer] if tool in action: messages.append({role: assistant, content: raw}) result execute_tool(action[tool], action.get(arguments, {})) messages.append({ role: user, content: f工具结果{json.dumps(result, ensure_asciiFalse)}。如果需要继续请再次输出 JSON如果已经完成请输出 answer。, }) continue return 未知的 Agent 动作中断。 if __name__ __main__: while True: user_text input(请输入任务输入 quit 退出) if user_text.strip().lower() quit: break start time.perf_counter() result run_agent(user_text) elapsed time.perf_counter() - start print(最终结果:, result) print(f端到端耗时: {elapsed:.2f}s)代码里有一个值得注意的点执行完工具后把“工具结果”包装成user消息回传而不使用 OpenAI 标准里的tool角色。这样做是为了兼容更多本地模型。如果模型原生支持tool角色可以按引擎要求改造。4.3 用几个任务验证 Agent 闭环启动服务后测试以下三类输入1. 现在几点 2. 在记事本里保存一条笔记key 为 meetingtext 为明天上午十点开会。 3. 记事本里现在有多少条笔记正常第 1 条会触发get_time工具第 2 条触发save_note第 3 条触发list_notes。通过后再尝试一个多轮任务先保存一条笔记今天完成网关改造。然后告诉我记事本里有哪些内容。这句话需要模型连续调用两次工具才能正确完成是最小但有效的 Agent 压力测试。4.4 验证时应该看什么不要只看最终答案对不对。回看日志中的模型原始输出至少确认三点模型是否在第一步就输出了正确的工具名。工具结果回传后模型是否能维持原始用户目标。连续多轮调用后JSON 格式是否保持稳定。如果模型第一次输出了save_note第二次却回答“我已经完成了没有调用任何工具”说明上下文丢失或指令遵循能力不足。这时先不要急着怪模型性能差可以检查系统提示词是否过长、工具说明是否清晰以及量化是否过重。5. 如何建立一套可复现的本地性能基准5.1 先定义五个关键指标手机本地 Agent 的性能不能只看一个“每秒 token”。建议固定五个指标指标含义关注原因首 token 延迟TTFT从发送请求到收到第一个 token 的时间决定感知响应速度解码速度稳定生成阶段每秒生成 token 数决定整体生成耗时峰值内存加载模型和运行中最大内存占用决定是否会被系统杀死设备温度连续推理后的温度变化决定持续运行是否降频端到端耗时Agent 完成一次工具调用的总时间决定真实用户体验在 Agent 场景里端到端耗时比纯语言生成更重要。一次工具调用至少包括模型第一次生成、代码执行工具、模型第二次生成。如果单次生成耗时都在 10 秒以上一个五步工具任务可能需要一分钟这已经接近可用性边界。5.2 标准测试脚本的写法固定输入提示词固定生成长度固定上下文长度是避免测试失真的前提。import json import time import urllib.request ENDPOINT http://127.0.0.1:8080/v1/chat/completions def measure_chat(prompt, max_tokens128, rounds3): times [] for _ in range(rounds): payload { model: lfm-2.5-3b-q4, messages: [{role: user, content: prompt}], temperature: 0, max_tokens: max_tokens, stream: False, } req urllib.request.Request( ENDPOINT, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json}, ) start time.perf_counter() with urllib.request.urlopen(req, timeout180) as resp: data json.loads(resp.read().decode(utf-8)) elapsed time.perf_counter() - start usage data[usage] total_tokens usage[completion_tokens] decode_speed total_tokens / elapsed times.append((elapsed, decode_speed, usage)) return times每次测试至少跑三遍取中位数而不是平均值。平均值容易被某次系统后台同步、短暂发热干扰。如果想测 TTFT需要开流式输出记录第一个 chunk 的到达时间payload[stream] True # 读取 SSE 响应中的第一行 data: 的时间即为 TTFT5.3 一张可以套用的结果记录表下面是一张空白的记录模板用来说明记录字段数值不是固定结论模型版本量化格式上下文长度Prompt tokensTTFT解码速度峰值内存设备温度测试环境LFM 2.5 1B4bit4096200待测待测待测待测设备型号与引擎版本LFM 2.5 3BQ4_K_M81921500待测待测待测待测设备型号与引擎版本LFM 2.5 7BQ4_K_M81922000待测待测待测待测仅限高内存设备测试时一定要记录 Prompt tokens因为纯聊天 prompt 和长工具说明 prompt 的 TTFT 差距很大。一个包含大量工具描述的 Agent prompt 可能有两三千 tokenTTFT 会明显高于普通对话框。5.4 性能结果的三个影响因素同一款模型在不同设备上的表现没有可比性。就算同一台设备也会因为系统版本、后台应用、运行温度产生变化。读数据时注意三个因素模型量化格式影响速度。FP16 虽然质量好但内存占用翻倍手机端往往不如 4bit 实用。Prompt 长度影响首 token 延迟。上下文越长prompt 处理阶段耗时越久。设备散热决定持续表现。刚开始跑很快跑十分钟后变慢往往是降频而不是框架问题。所以比较不同模型时最好在同一台设备、同一个引擎版本、同一份 prompt 和同一种量化策略下进行。6. 手机本地 Agent 最容易踩的六个坑6.1 模型加载成功却提示内存不足或 mmap 失败现象服务刚启动就退出或推理时报cannot allocate memory。常见原因模型量化格式仍然偏大或者启动脚本指定了过大的--ctx-size。上下文长度设置得过高会预分配大量 KV cache 内存。处理方式# 先降低上下文长度 --ctx-size 2048 # 或者换更小的量化版本 -m ./lfm-2.5-1b-q4_k_m.gguf检查顺序是先看系统剩余内存再逐步增加上下文长度不要一上来就开 16K。6.2 首 token 很慢但不是生成速度的问题现象请求发出后要等好几秒才出现第一个字但后续生成速度还过得去。可能原因有两个方向。一是 prompt 太长本地 CPU/GPU 需要逐 token 处理二是系统在后台做了功耗调度App 拿不到高优先级资源。检查方式分别用 100 token 和 2000 token 的 prompt 请求同一个模型对比 TTFT。如果 TTFT 随 prompt 长度明显上涨说明是 prompt 处理瓶颈。如果短 prompt 也一样慢优先检查系统是否进入省电模式。6.3 Agent 循环拿不到合法 JSON现象模型返回一大段解释文字而不是固定 JSON。原因很常见系统提示词里的格式描述与模型训练格式不一致或者温度设置过高导致输出发散。建议先做三件事把 temperature 降到 0.1 到 0.2简化工具说明最多保留三个工具在系统提示词里给出一个完整 JSON 示例。不要无限堆工具说明。手机小模型在长 prompt 下更容易丢失格式要求。6.4 多轮 Agent 中上下文越来越长推理越来越慢现象Agent 第一轮很快到第五轮后响应时间明显拉长。原因每轮工具结果都被追加到 messages 里上下文被无限撑大。KV cache 增大prompt 处理时间也增长。处理方式是在 Agent 循环外部维护“会话窗口”。只保留最近三轮内容较早的中间推理可以丢弃或者用摘要函数压缩# 简单裁剪示例 if len(messages) 10: messages messages[:1] messages[-6:]这个示例只用于说明思路实际项目要根据工具轮次和 token 预算调整。6.5 推理一段时间后被系统强制回收现象Agent 跑到一半进程消失回到桌面时发现后台任务被杀。原因手机系统为了省电会杀掉高耗电、高内存的后台进程。处理方向推理任务在前台进行避免切到后台申请前台服务或同等后台能力定期保存 Agent 会话状态进程重启后可恢复减小模型规模降低内存和功耗压力。这里不涉及系统底层绕过核心原则是让系统知道当前任务是用户可见的。6.6 用错推理引擎混合架构算子没生效现象模型能跑但速度比同规模传统模型慢很多甚至出现乱码。原因推理引擎没有完整实现 LFM 2.5 涉及的混合层算子回退到了低效实现。处理方式先看引擎发布说明或仓库 issue 是否写明支持该架构。不要拿一个只优化过 Llama 的旧版本引擎强行加载新型权重。必要时把模型量化和算子实现一起升级。下面用表格汇总这六个问题问题现象常见原因检查方式处理建议启动后内存不足模型大或 ctx 过大查看系统剩余内存降低 ctx换更小量化首 token 慢prompt 处理慢或省电策略对比不同 prompt 长度缩短工具说明开高性能模式JSON 输出不稳格式约束不足查看原始模型输出降温、减少工具、给示例多轮越来越慢上下文无限制增长打印 messages token 数裁剪旧消息进程被杀死后台功耗受限观察系统日志前台运行、保存状态模型速度异常慢引擎算子不匹配查引擎版本支持列表升级引擎或换权重格式7. 从“能跑”到“能日常用”Agent 的本地化改造方向7.1 工具调用不要做得太自由这个最小示例里Agent 可以对三个本地工具自由调用。真实手机场景中工具数量可能膨胀到几十个比如读日历、发消息、控制闹钟、打开应用、读取传感器等。工具越自由小模型越容易出错。更稳妥的方式是分层一层轻量意图分类决定当前请求属于哪个领域一个领域内的 Agent 只加载两三个工具工具名称尽量短参数尽量少每个工具执行前如果涉及写操作应该经过用户确认。不要设计一个“万能工具”去执行任意 shell 命令。模型是不可信的它可能被用户输入里的 prompt injection 诱导调用危险操作。7.2 上下文管理要从第一版就做本地 Agent 的上下文预算远小于云端模型。建议从第一版就引入 token 计数def estimate_tokens(text): # 中文约 1 到 2 token/字英文约 4 字符/token return max(len(text) // 1, len(text) // 4)工具结果不能无限追加。保存笔记时只需要回传“保存成功”不需要把整篇笔记内容再让模型读一遍。工具结果要裁剪到最简状态。7.3 隐私、权限和离线的边界要清楚本地模型最大的卖点是隐私但隐私不等于完全不联网。Agent 里接入联网搜索、地图、天气等外部服务时要明确告知用户哪些请求发出去了。手机端工具权限要遵循最小授权原则只读取当前任务需要的数据写操作弹窗确认语音、通讯录、短信等敏感权限单独列开关会话记录加密存储。如果后续要把部分复杂任务交给云端大模型应坚持“本地预处理、脱敏后再发送”的原则。7.4 把性能优化当成系统问题而不是模型问题跑通 LFM 2.5 后很容易把精力都放在“换更大的模型”上。真实设备体验受模型、引擎、系统调度、程序代码四方面共同影响。一个合理的优化顺序是先把 Agent 工具调用跑稳不追求最大模型记录同一设备上的 TTFT、解码速度和峰值内存调整 ctx 和量化格式找到体验与质量的平衡点引入会话裁剪和工具结果压缩最后再对比更大参数模型是否有明显质量收益。对新手最有价值的练习不是更换最大模型而是把一次完整 Agent 任务端到端耗时压到可接受范围。这需要同时观察模型输出质量、推理速度、内存占用和功耗而 LFM 2.5 的混合架构特性恰好让这些维度在小参数规模下就能完整展开。手机本地 AI Agent 的价值不在于某一项模型指标的领先而在于“识别、决策、执行、确认”这一整条链路能够在本地完成闭环。下一步如果你手上正好有可运行的推理引擎建议从 1B 模型开始先用这个最小 Agent 循环跑通工具调用再逐步换成 3B、7B 量化版本对比不同尺寸下工具输出稳定性和实际响应速度。真正的本地 Agent 体验是靠一次多轮工具调用和一台发热但可用设备验证出来的。