“手机本地跑 AI Agent”这件事最近讨论度比很多人想象中高。大家提到 Liquid AI LFM 2.5 时注意力往往集中在“这个模型能不能装进手机”却很少接着追问两个更实际的问题装进去之后一套真正的 Agent 流程该怎么在手机这种资源受限的环境里运转如果第一个任务能跑通它能不能长期稳定地跑下去我过去几个月一直在尝试把开源模型部署到移动端设备上也踩了不少坑。最初的结论很朴素能跑但跑得不算舒服。后来慢慢发现问题不在模型“能不能跑”而在于我们用评估云端大模型的那套标准去判断一个本来就该在边缘设备上生存的 AI 系统。LFM 2.5 之所以值得拆开来看是因为它把“模型架构”和“端侧 Agent 需求”这两个话题重新绑到了一起。这篇文章我会先讲清楚手机本地跑 Agent 的本质约束再拆 LFM 2.5 的架构设计取舍然后给出一条可复用的落地流程和一套性能评估方法最后聊一聊什么时候这件事真的值得做。1. 先放下“手机装模型”的执念想想 Agent 为什么需要本地化1.1 本地 Agent 要回答的不是“能不能”而是“值不值得”打开任何一家模型下载平台能看到一批能在消费级硬件上跑的开源模型。很多模型参数量并不大用手机上的 NPU、GPU 或者通过 CPU 推理也不是完全跑不动。所以“手机能不能本地跑模型”这个问题早就不是一个技术判断题而是一个体验判断题。但 Agent 和“聊天机器人”不是一回事。一个完整的 AI Agent至少要包含意图理解、任务规划、工具调用、结果解析、状态迭代、异常恢复这几个模块。每多一个模块手机端要承担的计算和内存压力就会多一层。你可以把模型看成 Agent 的“大脑”但大脑之外还有神经系统、肌肉和反馈回路。在手机上把这些东西组装起来问题从“模型性能怎么样”变成“整套系统在有限资源下能不能稳定完成有实际价值的任务”。这个转变非常关键。如果只是想向模型提一个问题手机本地的价值其实不大因为云端模型的回答质量通常更高。Agent 场景则不同它会连续多次往返先理解用户请求再决定调用哪个工具拿到工具结果后继续推理最后输出答案。这个过程中每一步都要把模型和状态数据送到本机推理。此时“数据不出设备、推理不需要等待网络、能力不依赖服务商”就变成了实打实的收益。1.2 本地运行真正换到的三样东西很多人一上来就对比速度和效果反而把最该关心的东西漏掉了。手机本地跑 Agent真正换到的是下面三件事第一是数据边界。用户的需求、Agent 的中间思考、工具读到的内容、最终生成的回复都在自己手机上完成推理。对于处理个人笔记、日程、通讯录、代码片段、本地文件这类任务这个边界非常有吸引力。当然如果 Agent 要调用在线天气接口、搜索网页、同步云端笔记这些操作依然会出网数据边界就要按实际模块重新画清楚不能笼统说“本地就完全安全”。第二是可用性。本地推理不受服务器排队、服务停售、网络故障影响。只要设备有电Agent 就还活着。这听起来很基础但在生产环境里它意味着你可以把一些关键小任务完全交给本地系统去执行不必担心外部服务宕机。第三是可控性。你可以改系统提示词、换推理参数、调整工具调用的策略甚至可以给 Agent 增加一条强制校验规则。这个自由度在云端 API 上不一定有本地模型给了你完全修改的权利。但这些收益有一个前提任务复杂度必须和手机算力匹配。手机不能同时运行几十个 Agent也不能处理超长文档和深度多步推理。过度乐观地认为“本地化就是更好”是所有问题的开始。1.3 重新理解“小模型没有 Agent 能力”的旧偏见过去很长一段时间大家默认 Agent 能力是参数量堆出来的小模型只能做简单问答。但实测过端侧 Agent 之后我的判断变了。Agent 对模型的要求和“博学程度”不完全是一回事。更多时候Agent 需要的是模型具备三件事能不能严格按照系统提示词进行角色扮演能不能稳定输出工具调用所要求的结构化内容能不能在结果异常时继续往下走而不是直接崩溃。你会发现这些能力更多依赖训练阶段对指令遵循和工具调用格式的强化。一个参数量相对小、但针对工具调用场景优化过的模型往往比一个通用大模型更适合做手机 Agent 的“大脑”。这恰恰是我关注 LFM 2.5 的原因它的关注点不是“堆更多参数”而是让模型在资源受限的场景下仍然保留下游任务需要的关键能力。2. Liquid AI LFM 2.5 的设计取舍不是把参数变小而是把架构做聪明2.1 从液态神经网络到基础模型LFM 的来历要聊 LFM 2.5先要理解它背后的来源。Liquid AI 团队在做基础模型之前已经花了很多年研究液态神经网络。这个方向脱胎于生物学启发神经网络不一定非要用固定的大规模矩阵去模拟“记忆”而是可以通过连续时间、更紧凑的状态表达来处理序列信息。传统观点认为神经网络只要规模够大就能涌现能力但液态网络的思路更侧重“用合理的动态机制在更小规模下表达时间依赖和因果关系”。LFM 是把这套思路扩展到了大语言模型上。它不是简单地造一个和 Transformer 完全等价但换个名字的模型而是在更底层的算子组织和状态管理上做了不同设计。当然这个过程非常复杂LFM 2.5 也不是推翻所有传统技术。更准确地说它是一套模型家族里面既有偏通用的结构也有接近传统 attention 思路的部分不同变体有自己的定位。我在这里不会声称自己掌握了官方所有技术细节。因为大模型架构论文和开源代码都在快速迭代网上能搜到的信息也经常滞后。我建议读者把它理解为一次架构层面的重新权衡传统 Transformer 在长上下文场景下需要消耗大量缓存而 LFM 这类更强调“状态紧凑性”的架构目标是在同样的成本下把模型需要的运行资源压得更低。2.2 架构到底在调什么活跃参数、状态缓存与推理过程很多人以为模型架构是纯粹的理论问题和手机部署没关系。其实架构恰恰决定了 Agent 在手机上能走多远。我们可以从三个层面看第一是参数量与内存占用。模型文件有多大往往直接决定手机能不能装得下。但内存占用不只是模型参数还包括推理时的激活值、临时缓冲区和上下文状态。所以你会看到一个很反直觉的现象有些模型参数量看起来不大但跑起来内存占用却高得吓人。这是因为它的架构在推理时需要保留大量中间状态。第二是每输出一个 token 需要做多少计算。同一个模型可以在桌面上流畅运行在手机上却慢一倍不只是 CPU 和 GPU 的性能差异还和模型架构中计算密集程度有关。如果模型结构和设备加速能力匹配推理速度会有明显改善。第三是上下文变长后资源的增长速度是不是让人能接受。传统 Transformer 的 KV Cache 很容易随序列长度线性甚至超线性增长。手机上跑 Agent 时系统提示词、工具定义、多轮对话记录都会堆进上下文如果架构对这部分不友好很快就会耗尽内存。LFM 2.5 系列在这三点的取舍上给我的感觉是它不希望用户永远只能用“缩水版模型”跑在手机上而是希望通过架构层面的设计让模型在同样资源下有更高的可用阈值。2.3 对 Agent 来说真正稀缺的是“结构化输出”和“稳定的状态管理”现在很多讨论集中在模型数学能力和推理能力上。但在手机 Agent 场景里我最关心的不是模型能不能写出一段优美的论文摘要而是它能不能在连续三轮工具调用中不犯格式错误。一个 Agent 通常需要模型输出类似 JSON 的结构化内容用来表达“下一步要调用哪个工具、传入什么参数”。这对模型来说是一种约束不是自然语言生成。很多模型在自由聊天时表现得很好一进入严格格式就频繁出错JSON 少括号、字段名拼错、参数类型搞混、工具名臆造。这类问题在参数量小、量化级别高的模型上尤其常见。LFM 2.5 如果只是“跑得快的通用模型”那它对手机 Agent 的帮助仍然有限。但如果它在训练阶段强化了指令遵循和结构化输出能力甚至模型本身就擅长把复杂指令拆解成可控状态序列那它在 Agent 场景中的价值会远高于同等体量的传统模型。这也是为什么我说不能只看“能不能跑”还要看跑出来的行为是否符合 Agent 系统的需要。提示这个判断不能替代实测。无论模型宣传多好都要先用三条工具调用任务做基准测试再决定要不要集成进正式项目。3. 从模型到 Agent一次可以复用的手机端落地流程3.1 前置条件动手之前先确认三件事把 LFM 2.5 或任何同类模型放到手机 Agent 里第一步不是下载模型而是先把前置条件想清楚。第一确认设备的“资源预算”。手机能用的内存、SoC 的推理能力、系统是否允许长时后台运行、散热表现如何都会影响最终体验。建议先在开发者设置里打开显示 CPU 和内存占用跑一次模型后记录资源峰值。不要只盯着模型文件大小因为实际运行内存通常是模型文件的几倍。第二确认 Agent 要解决的任务边界。不要说“我想在手机上跑一个万能助手”这很难落地。更好的定义是它能读取我的本地日程能调用天气接口能帮我写待办清单。任务边界越清楚工具定义越简单模型的表现就越可控。第三确认模型格式和推理引擎是否匹配。手机端通常很难直接加载 PyTorch 的 safetensors 权重常见的做法是把模型转换为 GGUF 等更适合边缘推理的格式再由支持该格式的推理引擎加载。LFM 2.5 具体支持哪些格式和引擎要以模型下载页面和推理项目文档为准。落地前一定要先做一次版本确认不要拿旧教程里的命令直接套。3.2 模型转换与量化不要在源头把路走窄模型权重文件从 Hugging Face 或其他平台下载下来后通常是高精度格式直接放手机上既占空间又跑不动。常见做法是在电脑上完成模型格式转换和量化然后把量化后的文件传到手机。量化就是用更低的数值精度去表示权重换取更小的文件体积和更快的推理速度。代价是模型精度下降尤其在结构化输出和工具调用这类对“确定性”要求高的任务里量化带来的误差可能比想象中更明显。我的建议是先从 Q4_K_M 或同等档位开始如果 Agent 工具调用频繁出错再换更高精度版本试试不要一上来就选最小文件。转换这一步需要看具体模型适配的转换脚本。常见路径是先安装对应推理框架的命令行工具再执行从 safetensors 到 GGUF 的转换命令。这里不展开具体命令因为不同模型、不同框架的参数差异很大。你只要记住一个原则转换和量化都应该在 PC 上完成手机只负责加载最终文件。这样能大幅度减少手机端的调试成本。3.3 选对推理引擎比调参更重要手机端跑模型不是只有一个选择。常见思路包括使用 llama.cpp 及其衍生项目。这类方案对 GGUF 模型支持好在 Android 上也有不少封装应用适合先跑通一个最小验证。使用支持本机推理的服务化封装。让模型在本地一个端口上提供 OpenAI 兼容接口Agent 代码就可以用统一方式调用降低和具体框架的耦合。使用系统级 GPU/NPU 能力。部分厂商提供了专门的端侧推理框架能调用 NPU 加速但模型格式和算子支持限制更多适合产品化时不一定要用在早期验证。我经历过最典型的坑是模型文件明明没问题但推理引擎跑在 CPU 后端上速度慢到 Agent 一次工具调用要等两分钟。后来换成支持 Metal/OpenCL 或 NPU 的后端速度才有质的变化。如果你在手机上做验证优先确认推理引擎能用 GPU 或加速后端而不是默认 CPU 跑。3.4 最小 Agent 运行链路把流程拆成四个模块跑通手机 Agent 的初期不要追求复杂框架。我建议先实现一条最小链路它大概长这样# 伪代码用于展示最小 Agent 流程的核心结构 tools define_tools() # 定义工具列表名称、描述、参数 schema history [system_prompt] # system prompt 中包含工具说明 while True: user_input get_user_input() history.append({role: user, content: user_input}) response local_model.chat(history, toolstools) # 本地推理 if response.tool_call: # 模型要求调用工具 result execute_tool(response.tool_call) history.append({role: tool, tool_result: result}) continue # 把结果回填后继续推理 if response.is_final_answer: show_to_user(response.text) break这段流程虽然简单但已经把四个核心模块框出来了工具定义模块它决定模型能看到哪些能力边界工具描述写得越清晰模型越不容易幻觉。对话历史管理模块在手机端不能无限追加消息否则上下文膨胀、内存崩溃只是时间问题。工具执行模块负责真实调用本地功能或外部接口并把结果转换成模型可以理解的文本。循环控制模块必须设置最大迭代次数防止模型陷入“反复调用同一个工具”的死循环。不要小看这四个模块。在实际项目中四个模块任何一个做得不严谨Agent 都会在长任务中失败。3.5 参数调节一次只动一个变量本地模型跑 Agent 时下面几个参数最值得关注temperature 控制输出的随机性。Agent 工具调用阶段建议调低比如 0.1 到 0.3防止模型每次输出的 JSON 都不同。max_tokens 决定单次生成的最长输出。工具调用阶段的输出往往很短但最终回答可能需要较长空间。要根据任务分别设置。context length 要尽量保守。手机端不是越长的上下文越好因为上下文越长推理占用内存越高速度也越慢。初期先用 2048 或 4096 验证再决定是否有必要加大。线程数和批处理大小也要关注。线程开太多可能造成资源竞争反而变慢。建议通过小任务反复测试记录不同参数下的耗时和内存再做选择。这里最重要的一条经验是一次只改一个参数。如果你同时调大上下文、改低 temperature、换了量化版本出问题后根本不知道是谁引起的。4. 性能好坏看哪几个数手机端 Agent 的测量方式4.1 峰值内存模型大小不是唯一标准手机端 Agent 最容易出现的不是“模型跑不动”而是“跑着跑着被杀后台”。Android 和 iOS 对后台进程都有严格限制如果 Agent 在推理时内存占用过高系统会直接回收进程连报错都没有。真正决定生死的是运行时的峰值内存。你可以通过系统工具观察进程内存曲线也会发现它和模型文件大小并不是同一比例。上下文越长缓存越大工具返回内容越长临时缓冲区越大Agent 不断调工具历史记录越堆越多。我建议记录三类数值空载内存、一次最短对话的峰值内存、一次带多次工具调用的峰值内存。用这三个数据能判断出模型本身吃多少内存、上下文扩展吃多少内存、Agent 长期运行会不会把所有内存吃光。4.2 首 token 延迟比每秒 token 数更重要跑模型时大家习惯看“每秒生成多少 token”这个指标很有用但放在 Agent 场景里会误导人。Agent 在一次任务里往往要经历多轮推理。每一轮推理都包含一次“读请求、做计算、返回结果”的往返。相比生成速度首 token 延迟往往更影响体感如果模型每轮都要十几秒才开始输出哪怕后面每秒几百 token用户也会觉得它“卡住了”。更好的测量方式是“端到端时延”也就是从用户输入开始到最后完整结果输出中间包含多少次工具调用、每次调用等待了多久、模型级耗时是多少。如果你发现瓶颈出在工具执行上那和推理引擎无关是 Agent 流程的问题如果瓶颈出在每轮模型的预填充阶段那就要优化上下文长度和工具定义。4.3 Agent 场景的性能表怎么量化一轮任务下面这张表可以用在本地 Agent 的基准测试里测量时最好让 Agent 执行同一个任务三次取中间值避免抖动指标测量内容观察目的首 token 延迟从提交请求到第一个 token 输出判断系统响应是否“让人觉得活着”单轮推理耗时一次完整推理从开始到结束判断单步任务是否能接受工具调用次数Agent 完成任务实际调用几次工具判断 Agent 是否高效是否存在无效循环峰值内存运行期间最大占用内存判断是否会被系统杀进程量化误差率结构化输出中格式错误的比例判断量化档位是否影响了 Agent 能力稳定性连续运行 10 次成功的比例判断是否能作为长期任务使用这些指标不是一次测完就结束。建议把结果存成日志以便后面每次改动参数时对比。4.4 电池、散热和降频跑得快不等于跑得久手机端和 PC 差别最大的一点是手机会因为温度升高而主动降频。第一次跑 Agent 时可能一切正常连续跑十分钟后处理器频率被限制推理速度下降到原来的三分之一都是常见现象。所以在评估手机本地 Agent 时不能只看冷启动状态下的性能。要测试连续多轮任务后的表现设备是否发烫、是否降频、电池电量下降速度、是否触发系统保护被迫休眠。如果要做长期运行的任务最好让 Agent 每执行完一轮就暂停一段时间或者在低功耗状态下等待。不要把手机当成不受限的服务器时刻保持“资源有限”的敬畏心。注意手机不是为长时间满负荷推理设计的。如果 Agent 需要 7x24 小时运行请认真考虑它跑在 PC、开发板或云端服务的可能性不要硬扛在手机上。5. 多步执行、工具调用和意外中断排查不听话 Agent 的顺序5.1 单轮问答通过不等于 Agent 可用我见过很多人在验证本地模型时只跑一个“你好帮我介绍一下你自己”然后下结论说模型可用。这种测试距离真正的 Agent 差得很远。真实 Agent 任务通常是这样的用户要求“查一下明天杭州的天气如果是晴天就提醒我带上相机并写入待办清单”。Agent 需要先解析意图决定先调用天气接口拿到结果后判断是否需要写入待办清单然后用另一个工具创建任务。这一条链路下来至少有两次工具调用和一次条件判断。任何一步出问题任务都会失败。常见的失败模式包括模型不调用工具而直接编造天气数据模型调用了一个不存在的工具模型能调用工具但参数格式错误工具返回结果过长导致上下文爆掉模型在循环里反复执行同一个工具不退出Agent 中断后没有恢复机制。看到这些失败我的第一反应不是“模型不行”而是“Agent 系统的防御还不够”。5.2 排查链路从现象定位到具体环节下面这条排查顺序是我实际项目里反复用到的现象优先排查对象可能原因方向模型输出闲聊话不调用工具系统提示词和工具 schema工具描述在上下文中被截断或模型没被明确告知必须调用工具调用了工具但参数乱工具 schema 设计和量化级别参数名不清晰、格式不规范、模型量化精度太低工具结果能拿到但不会继续分析历史回填格式工具结果没有被正确拼接到对话上下文里反复调用同一个工具Agent 循环控制缺少最大迭代次数或模型没收到“结果已完成”的明确信号跑几步后直接退出日志和错误捕获内存不够被系统杀死或 JSON 解析异常未处理任务越跑越慢上下文长度和历史管理历史消息无限制增长缓存压力持续上升回答质量突然变差量化档位和 context 长度超过模型有效上下文窗口后中间信息丢失排查时不要跳步骤。先确认现象是什么再去看输入再看环境再看参数最后才怀疑模型本身。5.3 防御性方案别把 Agent 的全部信任交给模型模型在 Agent 系统里承担的是“决策建议”角色不是“绝对可靠”。真正能保障系统安全的是外层代码。工具调用结果要校验不能直接把模型给的 JSON 传给执行函数。你应该检查工具名是否在允许列表中参数类型是否正确目标路径是否越权。这既是安全问题也是稳定性问题。循环控制要设上限。无论模型认为还有多少步没执行一旦超过设定轮次Agent 就应该停下来并向用户解释当前状态。最好的做法是保存中间状态让 Agent 以后可以恢复。所有步骤要留日志。手机端 Agent 最大的优势是可控如果你没有把模型输入、工具调用、结果返回和最终输出记录下来那这个优势就被浪费了。出了问题时日志是定位问题的唯一线索。6. 边界判断这类方案适合谁又会在哪里失灵6.1 适合什么场景手机本地 Agent 并不是一个“什么都做”的通用方案。它有明确的适用场景在我看来下面几类场景最适合第一类是个人数据助理。读取本地日历、整理备忘录、对笔记做摘要、自动生成待办。这类的数据敏感度高任务规模小不需要超强通用推理非常适合端侧模型。第二类是原型学习和实验环境。如果你想研究 Agent 架构、测试模型能力、训练自己修改提示词和工具调用的手感手机本地环境比云端便宜得多也能更快看到改动效果。第三类是离线可用性要求高的场景。比如你在飞行模式下也需要 Agent 帮自己整理本地文件或者在某些不允许数据出局的环境里运行本地 Agent 几乎是唯一选择。6.2 不适合什么场景手机本地跑 LFM 2.5 类模型不适合解决以下问题需要超大上下文的任务不要选它。比如一次分析 10 万字 PDF 并回答复杂问题这是手机算力解决不了的需求。需要高并发服务的场景不要选它。手机不是服务器也没有稳定的供电和网络如果想做一个多人使用的 Agent 服务请把推理放到云服务器或本地服务器上。对工具调用数量和复杂度要求极高的场景不要选它。如果一个 Agent 要管理上百种工具手机端的上下文窗口会迅速被工具定义占满留给真实任务的空间不够。需要极高确定性的任务也不要全依赖它。例如医疗建议、财务决策、法律判断本地小模型不应该作为最终决断者。6.3 长期工程化还要补齐什么如果你确定手机本地 Agent 这件事值得做我建议在完成最小验证后补上下面几块拼图配置管理。把模型路径、推理引擎地址、量化类型、上下文长度、温度、循环上限都抽成配置文件方便在不同设备间复现。任务队列。不要让多个任务同时挤占推理资源用一个串行队列管理 Agent 任务至少不会因为资源竞争导致系统无响应。状态恢复。如果 Agent 在任务中途被系统杀掉重新启动后是否有能力恢复未完成任务这不是小问题而是决定能不能长期信任它的关键。模型版本和指标追踪。每次更新 LFM 2.5 版本或推理引擎版本都要重新跑一遍基准任务记录指标变化。否则你只能凭感觉判断“新版比旧版好”在工程上这是不可靠的。6.4 手机本地 Agent 真正改变了什么最后说一个我更底层的判断。手机本地跑 AI Agent 的价值不在于把云端那个强大的助手压缩成手机里的低配版而在于它第一次把一个可以修改、可以观察、可以完全控制的推理闭环放进了你的贴身设备里。你不再需要面对一个黑盒 API你可以清楚看到它为什么调用某个工具、在哪一步开始跑偏、哪个参数让输出变得稳定。LFM 2.5 这类架构让我看到的方向是模型不再只是“更大”而是更在意算力有限的真实场景。它能不能成为手机 Agent 的最佳选择还需要更多实测数据验证但架构上的这次转向比任何一个具体分数都值得关注。如果你现在正准备动手我只有一个建议先别急着追求大模型和复杂框架。拿着你手里这台手机挑一个具体的个人任务把最小流程跑通把日志调出来再基于日志去调架构。你会发现真正难的部分不是模型而是如何把一个不受控制的模型驯服成一个让人信任的工作流。这个过程才是手机本地 Agent 最迷人的地方。