企业官网建设流程全解析

手机本地跑AI Agent，听起来很时髦，但实际验证完一轮之后，我的结论比较清醒：在手机上跑一个本地大模型不难，难的是让模型稳定完成工具调用、多轮状态维护和结果纠错，最后串成一个真正能用的Agent。这次我重点测试了Liquid AI LFM 2.5相关架构在端侧的部署表现，也想借这篇文章把“架构”和“性能”这两个词从宣传语里拉回到可执行的判断标准上。

如果一个读者现在问我：这值不值得关注？我的回答是：如果你只是想让手机离线回答几句话，那没必要研究LFM 2.5；但如果你想把Agent任务真正卸载到本地，关心长上下文下的内存增长、连续多轮后的稳定性、以及在无云端辅助时的工具调用能力，那LFM 2.5这类非传统Transformer路线的模型就值得仔细看。

这篇文章不是跑分报告，也不打算给出一个“所有手机都能跑”的结论。我更想拆清楚一件事：手机本地跑Agent，到底跑的是什么、瓶颈卡在哪、架构差异怎么影响体验、以及你拿到手之后应该怎么测、怎么判断、怎么避坑。

1. “手机本地Agent”这几个词，先拆到可验证的粒度

很多文章把“手机本地跑AI”和“手机本地跑Agent”混为一谈。实际上这是两件难度完全不同的事。

普通聊天任务，模型只需要根据用户输入生成回复。Agent任务则多了几个环节：理解任务目标、拆解步骤、选择工具、生成结构化调用参数、执行工具、读取结果、继续推理，直到给出最终答案。任何一个环节断了，Agent都不成立。

1.1 把Agent拆成四个可观测环节

我对这次测试的定义，是把Agent运行流程拆成四个环节来观察：

• 规划：模型能不能从一句自然语言里识别出要做哪件事，比如“明天早上九点提醒我给客户回电话”。
• 格式化输出：模型能不能按照预先定义的JSON结构，输出工具名和参数，而不是输出一段自然语言。
• 工具执行与结果注入：程序执行工具后，把结果塞回上下文，模型能不能读懂并继续。
• 多轮收敛：执行完工具后，模型能不能给出最终回答，而不是继续循环调用工具，或者在多轮后丢失最初目标。

这四步中，最容易被低估的是第二步。端侧模型如果输出不合法JSON，后面的工具执行和结果注入全部失效。

1.2 LFM 2.5架构在端侧选型里的位置

Liquid AI的LFM系列和常见Transformer路线的最大不同，在于它并不是沿用“每个token都和历史token做全量注意力”的路线，而是更强调把输入压缩成状态，走线性复杂度方向。放到端侧场景里，这个思路的理论优势很明显：上下文越长，内存和计算增长的曲线越平缓，不像传统Transformer那样每多一轮对话，KV Cache就膨胀一轮。

LFM 2.5这个名字在测试里给我最直接的观感是：它不再只是“跑通一个模型”，而是要解决端侧Agent最头疼的长期状态问题。不过“架构趋势好”和“当前手机能跑得好”是两码事。这要看运行时的算子适配、量化支持、生成质量和工具调用格式控制。

1.3 先确认一个边界：单轮问答不等于Agent

我见过不少团队在手机上加载了一个模型，做了个简单对话框，就说自己实现了端侧Agent。这个判断跨度太大了。

单轮问答只需要一次生成，而Agent至少需要一次生成加工具调用，通常还要经历多轮。真正接近生产形态的Agent，还涉及系统提示词注入、工具定义压缩、任务队列、失败重试、超时控制、日志记录等额外项目。手机型号不同、系统版本不同、后台应用占用不同，这些都会影响跑出来的效果。所以不要把一次成功的演示截图当成产品结论。

2. 部署前要准备的环境和参数：低配手机怎么起步

先把一个原则说清楚：不要一上来就下载最大版本的模型，也不要一上来就追求最全的Agent框架。手机本地跑Agent，第一步是让模型能在当前设备上稳定生成。稳不住生成，后面所有编排都是空中楼阁。

2.1 手机硬件基线：先看内存、存储和散热，再看NPU

不同手机情况差异很大，但通常可以按这个顺序估算：

• 运行内存：优先关注8GB及以上机型。6GB设备也能试，但要把上下文长度和系统后台占用压到很低，否则App很容易被杀进程。
• 存储空间：模型文件、运行缓存、日志和临时文件都要占用空间。测试前至少留出足够放模型和日志的空间，避免跑到一半I/O报错。
• 散热条件：手机没有主动风扇，连续跑推理时会明显发热。温度一高，SoC会降频，生成速度会变慢。这不是软件Bug，而是物理规律。
• NPU支持：如果推理引擎能调用NPU或者GPU加速，速度会好一些；如果架构特殊，很多现成的NPU加速栈不一定支持，最终可能还是CPU兜底。

我自己调试时会先跑一个最小样例，只有一条几百字的输入，观察三轮生成：第一轮启动速度、稳定后的连续延迟、以及跑完十轮之后的温度表现。如果第十轮已经比第一轮慢很多，那后面加上下文、加工具肯定更吃力。

2.2 运行时可选项和格式适配

手机端推理不是直接把模型放进App里执行。通常需要把模型转成某种量化格式，再交给对应运行时加载。

常见的推理栈包括llama.cpp系列在移动端的移植版本、MLX这类面向Apple Silicon的方案、以及其他能在Android或iOS上加载GGUF格式的运行库。问题是，LFM 2.5这类架构如果和传统Transformer的算子结构不同，那么“支持GGUF格式”并不等于“支持高推理性能”。加载模型可能很顺利，但解码算子在运行时不一定走了最优实现。

这里最要命的坑是：很多新架构模型还没有被主流框架完整适配。即便适配了，不同量化粒度下的效果也完全不同。拿到模型后的第一步应该是确认当前运行时是否支持这个架构，而不只是看文件能不能加载。

2.3 一组用于首次验证的参考配置

我不会建议一开始就把上下文拉到最大值。建议第一次开启Agent测试时，采用一套保守的参数起步：

这套参数只作为首次验证的起点，不代表最优值。如果你跑出来输出经常不合法，先把上下文调短或把工具定义改精简；如果回答太机械，再把温度提到0.5左右试。始终一次只改一个变量。

3. 实测流程：设计一条能把Agent逼到工具调用边界的用例

手机本地跑Agent，如果只跑“写一段自我介绍”这种纯问答，根本测不出真实水平。应该专门设计一条必须调用工具才能完成的任务，把模型逼到结构化输出的边界上。

3.1 用例选择原则

我的建议是选三类任务：

• 设置提醒：时间参数清晰，输出结构简单，适合验证日期解析。
• 查询本地信息：比如询问“明天的日程安排”，需要调用本地日程接口。
• 两步组合任务：比如“查询明天天气，如果下雨就添加提醒”，这种任务要求模型先调用一次工具，再根据结果决定是否第二次调用。

这三类任务覆盖了单步调用、参数解析、条件分支和结果注入。既能验证模型能力，又不会因为外部接口太复杂而无法定位问题。

先说提醒任务。我会给模型定义这样的工具：

{ "type": "function", "function": { "name": "create_reminder", "description": "创建一个系统提醒", "parameters": { "type": "object", "properties": { "time": { "type": "string", "description": "提醒时间，格式为YYYY-MM-DD HH:mm" }, "text": { "type": "string", "description": "提醒内容" } }, "required": ["time", "text"] } } }

然后输入：

明天早上9点提醒我给客户回电话

期望模型输出一个合法的JSON调用结果，而不是回复“我能帮你设置提醒，请问你想几点呢”。如果模型把这个简单输入当成聊天来处理，那说明它的工具对齐能力还没有达到能当Agent用的水平。

3.2 最小闭环怎么实现

下面这一段是伪代码，重点不是语言特性，而是Agent循环的结构：

messages = [system_prompt, user_message] for step in range(max_steps): response = model.generate( messages=messages, tools=tool_schemas, temperature=0.2, max_tokens=256 ) if response.has_tool_call(): tool_result = execute_tool(response.tool_call) messages.append(response.to_message()) messages.append(create_tool_result_message(tool_result)) continue return response.content raise AgentStepLimitExceeded("超过最大步数，需要人工介入")

这段逻辑有几个关键点：

• 每次生成的完整消息要追加到历史里，否则模型不知道之前发生过什么。
• 工具执行完毕后，必须把结果以“工具结果”的身份注入历史。
• 一旦超过最大步数，应该停止并抛错，不能无限重试。
• 生成结果里如果带出多个工具调用，也要逐一处理。

很多人的第一版Agent代码看起来正常，实际跑起来却有问题，原因往往就出在消息结构上。工具结果被当成普通用户消息放回去，模型可能误以为那是用户新输入，导致上下文语义错乱。

3.3 如何判定闭环成功

怎么判断一次闭环是成功的？我个人会用四个标准：

1. 输出格式合法：JSON能被解析，且字段和工具定义一致。
2. 工具名正确：没有调用一个不存在的函数。
3. 参数结果正确：时间被正确解析成本地时区，内容没有乱加格式。
4. 结果注入后能收敛：拿到工具结果后，模型能输出最终回答，而不是反复调用同一个工具。

一次成功不代表稳定。建议同样的用例连续跑十次，统计成功率。如果十次里有三次以上输出非法JSON或错误参数，那就不该直接上复杂任务。

3.4 首次失败案例和修正路径

我实际调试时最常见的失败，是模型输出类似下面这样的内容：

好的，我现在为你在明天早上9点设置提醒，请稍等。

它没有输出JSON，而是输出了一段聊天内容。这种问题通常不是模型笨，而是系统提示词和工具定义给了模型一种“先回答用户”的余地。修正路径是改写系统提示词，明确告诉模型：只要任务需要调用工具，你必须直接输出工具调用JSON，不要先解释流程。

另一种失败是模型输出了合法的JSON，但函数名拼错。比如工具名是create_reminder，模型却写成create_reminder_task。这种问题需要在使用前做一个函数名校验，而不是直接把参数传给执行器。

4. 架构差异如何影响手机上的实际性能表现

LFM 2.5在架构层面的宣传点，放到手机本地场景里到底有没有意义？不能只看发布会材料，要看实测过程里出现的问题。

4.1 第一轮看不出差距，多轮状态才是关键

传统Transformer在生成时，每个新token都需要参考前面所有历史token的KV缓存。上下文越长，缓存越大。到了长对话场景，单次生成不仅要算当前部分，还要频繁读写越来越大的历史缓存，延迟和内存占用都会增长。

LFM 2.5这类走状态压缩路线的架构，理论优势在于不依赖无限膨胀的KV缓存，而是把历史信息压缩成固定维度状态。这样多轮对话时，内存增长会更平缓。但实际测试中，第一轮提问大家差距很小，要跑很多轮，或者输入特别长的工具定义和工作日志，才看得出内存和延迟曲线的差别。

如果你只是每轮问一句话就跑，那任何架构都够用。真正能让架构差异显现的场景，是连续十轮以上对话，并且每一轮都携带一份不小的工具结果。

4.2 架构好不一定等于端侧跑得快，要看算子生态

这是最容易被忽略的一点。一个架构在学术场景里计算复杂度再低，如果手机端推理库没有针对它的算子做优化，最终解码速度依然可能不如传统Transformer模型。

举个例子：如果某个推理框架已经针对Transformer的注意力算子做了多层优化，包括量化、内存复用、GPU Kernel优化，那么同体积的其他架构模型换到这个框架里，只能走通用算子，速度不一定有优势。所谓“架构决定性能”，只有在运行时已经充分适配的前提下才成立。

所以选型时要同时看两条线：模型架构本身的复杂度曲线，以及目标推理框架对这个架构的支持程度。只看其中一条，都很容易踩坑。

4.3 功耗、降频和缓存命中的影响

手机端跑模型还有一个桌面端不太敏感的维度：功耗与散热。

刚开始跑的时候，SoC可以短时间跑到较高频率，生成速度看起来不错。连续跑五到十分钟后，温度升高，系统开始主动降频，单次生成时间会明显变长。有些机器还会因为电池温度而限制总输出功率。

另一个性能盲点是文件I/O和缓存命中。如果模型在后台被系统清理，或者需要通过内存交换恢复数据，表现会突然掉一大截。这类问题不会出现在“刚加载完模型跑第一条”的测试里，只会在长时间使用或者后台切换后出现。

4.4 判断性能瓶颈的一套排错顺序

如果测试过程中感觉“模型变慢了”，不要过早下结论说架构不行。按这个顺序排查：

1. 先看是不是受热降频：摸一下机身背面，看连续任务有没有明显的延迟阶梯。
2. 再看上下文是否膨胀：工具结果和历史消息是否越加越长。
3. 再看系统后台占用：是否同时开着大量应用，导致内存不足。
4. 再看运行时算子路径：确认当前模型是否走了该推理框架的优化分支。
5. 最后才是模型自身能力问题：比如生成了过长的无效内容，导致解码时间被浪费。

这个排查顺序适合大多数端侧模型，不只是本文的测试对象。很多时候，性能问题的根因根本不在模型身上。

5. 性能指标怎么读：不只看token/s，还要看失败成本和热稳定性

“性能”这个词在手机本地Agent场景里，包含的东西比桌面端多得多。桌面端可能主要看显存和解码速度，手机端还要看功耗、热量、后台进程稳定性和长期使用后的性能衰减。

5.1 值得长期记录的指标清单

我会建议把下面这些指标记录下来，而不是只看日志里打印的token/s：

这些指标里，工具调用成功率和连续任务稳定性，比单纯解码速度更重要。因为一个Agent只要有一次输出非法JSON，整条任务就断了，可能还要从第一步重跑。重跑消耗的时间远大于单次生成快出来那几秒。

5.2 延迟高的几种信号和对应原因

如果出现“首Token很慢，但后续生成还算正常”，大概率是系统提示词和工具定义太长，模型在预填充阶段需要处理大量输入token。这时候可以尝试压缩工具定义，删除不必要的描述字段。

如果“首Token正常，但生成到一半明显变慢”，问题可能出在解码阶段算子上，也可能是生成长文本时命中了效率较低的计算路径。

如果“每次调用工具后，下一次生成都更慢”，要警惕多轮历史和工具结果在持续膨胀。传统Transformer会不断增大KV缓存；状态类架构相对平缓，但如果工具结果被反复塞进消息列表，也一样会拖慢处理时间。

如果“单条任务很快，但连续跑五条后越来越慢”，优先查内存释放和散热。先退出其他后台应用，关闭无关服务，再跑一轮。如果依然存在衰减，再考虑上下文管理。

5.3 什么样的结果代表“当前手机带得动”

我的判断标准不是“能不能加载模型”，而是“能不能连续完成真实任务且不崩溃”。

一个比较务实的验收口径是：同一个用例连续跑十次，全部能正常输出合法JSON；单次任务耗时落在你觉得可以接受的范围内；机身温度没有高到让你不敢继续用；最终答案没有因为多轮历史太长而丢失最初任务目标。

能做到这几点，基本可以认为这台手机当前配置带得动这个Agent。如果十次里有三次失败，哪怕单次速度再快，也不能算稳定可用。

6. Agent化之后的问题排查：JSON格式、函数幻觉、上下文污染

单条任务跑通只是起点。真正把Agent用起来，会遇到一堆和“模型会不会”无关的问题。下面几个是我觉得最常踩、也最容易误导人的坑。

6.1 模型总是生成不存在的函数名

如果模型频繁输出一个和工具定义很像、但实际不存在的函数名，比如把create_reminder写成create_reminder_task，问题往往出在系统提示词和工具定义之间的冲突。

可以按顺序排除：

• 检查工具定义是否真的传进了模型输入，而不是只存在代码层。
• 检查温度是否过高。工具调用场景下，温度超过0.7后函数名乱写的概率会明显增加。
• 检查工具列表是否过长。端侧模型对过长的工具定义响应能力有限，工具数量多时反而容易混。
• 考虑在系统提示词里加入“只能从以下函数列表中选择”的明确限制。

还有一个更稳的做法：在解析模型输出时，不直接执行函数名，而是做一次白名单校验。如果函数名不在已注册工具列表里，直接判失败，并让模型重新生成。不要自己去猜它想调用哪个函数。

6.2 多轮对话后参数错乱

第二类常见问题是单轮任务很稳定，到了多轮任务，模型开始把其他轮次的数据填进当前工具参数里。

比如用户先问“下周三的会议时间”，再问“给会议发起人设置一个提醒”，模型可能把“下周三”当成提醒时间，而不是根据第二轮的上下文重新确认时间。这个问题的本质是模型在上下文里检索到了错误信息，并且把上一轮的关键词错误复用了。

修正思路是：在每轮Agent执行前，把“当前任务”单独提炼成一段最新指令，放在本轮消息最前面，减少模型从历史中猜测的空间。同时，把工具调用参数里已经生成的字段，在下一轮里标记为“已确认信息”，降低重复修改概率。

6.3 工具执行结果污染历史对话

工具返回的结果可能是原始数据，格式乱、内容长、还可能带上敏感字段。如果把工具结果原样塞回上下文，一方面会占用大量上下文空间，另一方面模型可能会把乱格式当成学习样例，后续输出反而更不稳定。

建议对工具结果做结构化简化再注入。只保留模型下一步需要看到的字段，比如状态、时间、摘要，不要保留整张原始表。简化后的工具结果能让模型更准确收敛，也能减少上下文增长。

6.4 任务循环卡住和无限重试

如果Agent在一个工具调用和结果注入之间反复循环，而且每次都生成同一批输出，说明模型没有从工具结果里找到停止信号。

处理方法包括三层：

• 设置最大步数限制，在进入循环前强制停止。
• 在系统提示词中加入明确指令：如果工具结果已经满足用户请求，直接给出最终回答，不要再次调用工具。
• 在代码里判断“连续两步工具调用相同且结果相同”时，主动中断。

这里看起来像模型能力问题，但往往可以通过约束解码和循环判断解决。不要因为是端侧小模型就放弃控制，多数循环问题都来自上下文结构不够清晰。

6.5 手机上常见的内存和功热排查

如果Agent运行一段时间后卡顿严重，先看是不是内存占用持续上涨。可以通过系统工具查看App内存趋势。

如果是内存持续增长，可能存在两种原因：一是在多轮生成中保留了所有历史消息快照，没有做裁剪；二是每次工具调用后保存的对象没有被释放，尤其是图片、文件内容或长字符串。

如果是机身过热导致的降频，解决方案更简单：降低连续任务频率、给任务之间插入间隔、或者将上下文长度重新调小。不要在满载状态下测试性能，那只能测出最差解，不能代表日常体验。

7. 落地结论：LFM 2.5这类模型在手机上适合承接什么任务

做了这么多轮实测，我的总体感受是：LFM 2.5在端侧的意义，不能简单用“快不快”来评价，而要看它能不能撑起一个真正带状态的Agent。架构方向有可取之处，但最终能不能被普通用户用起来，仍然受制于端侧算子优化、工具调用格式和手机硬件边界。

7.1 适合先做稳的场景

比较适合先落地的场景，是那些输入短、动作单一、工具定义明确的任务：

• 语音或文字设置提醒、创建日程。
• 本地信息查询，比如从通讯录、日程表、备忘录里找出某条信息。
• 简单的条件决策，比如天气触发提醒、电量低自动记录。
• 隐私敏感的本地文本整理，比如把一段录音转写文本压缩成摘要。

这些场景有一个共同点：工具返回结果可控，参数结构简单，不需要跨应用长期跟踪复杂状态。端侧模型在这些任务上的成功率会高一些，也更容易做失败兜底。

7.2 现阶段不建议做的任务

我不建议一上来就做这些：

• 跨应用多步自动化，比如自动打开浏览器、填表、读取验证码再返回，这类任务依赖的系统接口太多，出错的环节也太多。
• 长篇文档整体总结。端侧上下文和算力有限，强行处理长文档会非常吃力。
• 需要长期记忆个人偏好的复杂助理。手机端模型很难在每次启动之间保存并恢复完整的用户状态。
• 高频次的实时语音交互。不是模型做不到，而是功耗和响应速度会很快击穿体验底线。

做减法非常重要。先在端侧承接一个很小的闭环，把工具调用、结果注入、失败重试全部验证好，再逐步扩大范围。不要一开始就想着做一个全能助手。

7.3 如果继续优化，应该从哪里下手

如果接下来想把这个方案推向更接近生产的状态，我会优先做四件事：

第一，为工具参数做严格Schema校验，不让任何非法JSON进入执行层。

第二，对工具结果做摘要化，只保留必要信息，降低模型读取负担。

第三，增加日志系统，记录每一步的输入输出、耗时和失败原因。很多问题只有在完整日志里才能看出来。

第四，设计任务级别的重试策略，而不是无限重试。比如同一任务失败三次后转为兜底回答。

这些工作看起来不如换一个模型那么吸引眼球，但对实际可用性的提升，往往比换架构更明显。

7.4 最终判断

手机本地跑Agent不是伪需求，它有明确的实用场景，比如离线可用、隐私保护、定时任务、弱网环境下的本地信息处理。LFM 2.5这类架构降低了长上下文状态管理的复杂度，这是值得肯定的方向。

但真正把它做成产品，需要同时满足三个条件：手机性能足够支撑稳定生成；推理框架已经适配好对应架构并做了量化优化；Agent编排层对工具调用、上下文长度和失败重试有足够严格的控制。这三个条件缺一个，就会出现“模型能跑但Agent不可用”的局面。

我更愿意把这次测试看成一次“架构能力验证”，而不是“生产可用宣言”。验证的目的是搞清楚一件事：当你想在手机本地做Agent时，LFM 2.5能覆盖到哪一步，不能覆盖到哪一步。把这个边界摸清楚，比盯着解码速度或者参数数量更有价值。

如果你也想在手机上尝试类似方案，我建议从最小任务、最保守参数、最简单的工具定义开始，先把成功率跑稳，再谈复杂Agent编排。先做单条闭环，再谈批量任务，这是端侧Agent最稳的路径。