企业官网建设流程全解析

一个很现实的问题：当所有大模型都在强调“智能体（Agent）”能力时，为什么绝大多数 Agent 仍然只能跑在云端的 GPU 集群上？原因并不复杂——设备端放不下、跑不动、不会用工具，三者缺一不可。而 LFM2.5-2.6B 这类模型的出现，正在把问题从“能不能在端侧跑”推进到“怎么在端侧跑得好”。

我的判断是：On-Device Agents（端侧智能体）不是云 Agent 的廉价替代品，而是另一种产品形态。它牺牲了一部分模型上限，换来了隐私、延迟、成本和离线可用性。LFM2.5-2.6B 的价值，恰恰在于它瞄准了端侧 Agent 最关键的三个能力：工具调用、长上下文和低资源占用。这篇文章会先讲清楚 On-Device Agents 为什么值得做，再拆解 LFM2.5-2.6B 这类小模型的核心定位，最后用一套完整可复制的本地部署示例，带你跑通一个真正会调用工具的最小 Agent。

1. On-Device Agents 为什么突然成为焦点

过去两年，Agent 的主流形态是“云端大脑 + 云端工具”。用户发一句话，请求传到服务器，大模型决定调用哪个 API，最后把结果返回手机。这套流程很成熟，但它在产品层面有几个无法回避的痛点。

第一是隐私。个人助理类 Agent 要访问日历、通讯录、短信、相册，这些数据一旦上云，合规成本和用户信任成本都会直线上升。第二是延迟。一次 Agent 任务往往要经历多轮模型推理，每一轮都走一遍网络，体验很难做到“像本地应用一样跟手”。第三是成本。云端按 token 计费，Agent 这类多轮调用场景的 token 消耗远高于普通对话，长期运营成本不容小觑。第四是可用性。网络差、弱网、断网场景下，云端 Agent 基本不可用。

On-Device Agents 的思路是把模型部署在手机、PC、车机或边缘设备上，模型在本地完成意图理解、工具调度和结果生成。它不需要把用户数据传出设备，响应延迟只取决于本地算力，也没有按 token 计费的问题。

但端侧有一个硬约束：模型必须足够小。当前主流旗舰手机的内存虽然在 12GB 到 24GB 之间，但操作系统和应用本身会占用相当大一部分，留给大模型的内存往往只有几个 GB。在这个约束下，1B 到 8B 参数的模型是现实选择。2.6B 这个规模恰好处于“能力可用”和“资源可承受”的交叉点：比 1B 级别模型更聪明，能处理更复杂的多步指令；又比 7B 级别模型更省内存，更容易在端侧跑出可接受的延迟。

所以，LFM2.5-2.6B 这类模型的受关注，背后是端侧 Agent 产品化的真实需求，而不是单纯的参数竞赛。

2. LFM2.5-2.6B 的核心定位：为 Agent 而生的端侧模型

LFM 的全称是 Liquid Foundation Model，是 Liquid AI 发布的一系列基础模型。这个系列的显著特点是在传统 Transformer 架构上做改进，将部分注意力层替换为更高效的计算单元，从而在同等参数规模下获得更好的效率表现。

LFM2.5-2.6B 从命名上看，是 LFM2.5 代际中约 2.6B 参数规模的版本，定位直指端侧 Agent 场景。相比通用小模型，它更强调以下几项能力。

1. 工具调用与函数调用（Function Calling）：Agent 的核心工作是“理解意图，调用工具”。模型需要在对话中输出结构化的工具调用结果，例如tool_calls字段，而不是把工具结果混在自然语言里。2.6B 模型要做到这一点，必须在训练阶段专门强化过工具调用的数据分布。

2. 长上下文能力：端侧 Agent 经常需要携带较长的对话历史、工具描述和中间结果。LFM2 系列在长上下文方面有明显投入，例如更早的 1.6B 版本就支持很长的原生上下文窗口。对 Agent 来说，上下文长度直接决定了它能“记住”多少任务状态。

3. 低资源占用：端侧部署要考虑内存带宽、KV Cache 占用和推理延迟。LFM 系列的架构设计在减少激活值和缓存占用上有一定优势，这比单纯堆积参数更有工程意义。

需要说明的是，本文中的部署流程以通用小模型端侧部署思路为主，LFM2.5-2.6B 的具体推理模板、工具调用格式和官方 API 细节，请以官方模型卡片和发布说明为准。下面的示例会用一套标准的 OpenAI 兼容协议来演示，这也是当前端侧推理框架最通用的接入方式。

判定一个模型是否适合做端侧 Agent，不应该只看跑分，而应该看三个问题：它在没有网络的环境下能否稳定输出合法工具调用？它在量化之后是否仍然保持格式稳定性？它的推理延迟是否能被用户接受？LFM2.5-2.6B 的意义在于，它把这些问题当成设计目标，而不是事后修补。

3. 从云端 Agent 到端侧 Agent，到底改变了哪些环节

很多人以为端侧 Agent 只是把模型文件从服务器搬到了手机里，其实远没有这么简单。两者在架构、工具接入方式和产品逻辑上都有本质差别。

从工程视角看，端侧 Agent 的架构发生了三个关键变化。

第一个变化是“工具”的定义变了。云端 Agent 调用的是一个 HTTP API，比如天气服务的GET /weather。端侧 Agent 调用的是本地能力，比如读取日历事件、发送通知、控制智能家居设备。这意味着工具调用的输入输出格式必须精简，因为模型上下文有限；同时工具执行逻辑必须跑在设备本地，需要一套权限管理机制来约束模型能调用什么、不能调用什么。

第二个变化是推理框架变了。端侧没有 NVIDIA 数据中心 GPU，只有手机 SoC 上的 NPU、GPU 或 PC 上的集成显卡。模型通常需要转换成 GGUF、ONNX 或 MNN 格式，并做 INT4/INT8 量化才能适配端侧硬件。调试方式也从“看 GPU 日志”变成“看内存和电量消耗”。

第三个变化是把失败处理前置了。小模型能力有限，工具调用可能输出非法 JSON、参数缺失或者幻觉参数。端侧 Agent 必须在模型层、框架层和应用层都增加校验和重试机制。云端 Agent 面对 70B 模型时，偶尔坏一次可以接受；端侧 Agent 面对 2.6B 模型，必须假设它会经常坏，然后把兜底逻辑做扎实。

理解了这些差异，再看 LFM2.5-2.6B 的部署价值就会更清晰：它解决的不是“模型能不能推理”的问题，而是“在受限硬件上，Agent 闭环能不能稳定跑起来”的问题。

4. 环境准备与模型获取

在完整示例之前，先把环境准备到位。本文演示以 PC 开发环境为主，最终产物可以迁移到手机或其他端侧设备。以下版本和路径均为通用实践，具体请结合本机环境和官方文档调整。

4.1 硬件要求

• 内存：建议 8GB 以上。运行 2.6B 模型 Q4 量化版本，加载权重约需 1.5GB 到 2GB，加上 KV Cache 和系统开销，8GB 内存是底线，16GB 会更从容。
• 处理器：Apple Silicon（M 系列芯片）体验最佳，因为统一内存可以给 GPU 使用；NVIDIA GPU 也可以，通过 CUDA 加速。
• 纯 CPU 推理也可以，但速度会慢，适合先验证流程。

4.2 软件与依赖

• 操作系统：macOS、Linux 或 Windows（WSL2）均可。
• Python：3.10 或更高版本。
• llama.cpp：使用最新 release 版本，旧版本可能缺少对新型模型架构或 Jinja 模板的支持。
• 模型权重：从 Hugging Face 或 ModelScope 下载 LFM2.5-2.6B 的原始权重。

# 创建并激活 Python 虚拟环境 python3 -m venv .venv source .venv/bin/activate # 克隆 llama.cpp git clone https://github.com/ggerganov/llama.cpp cd llama.cpp # 安装转换工具依赖 pip install -r requirements.txt

如果你的网络环境访问 Hugging Face 不稳定，可以使用 ModelScope 魔搭社区下载权重，这是国内比较稳妥的模型获取渠道。具体仓库名以模型发布页为准，示例命令如下：

# 通过 ModelScope 下载模型权重（仓库名请以官方页面为准） pip install modelscope modelscope download --model <your-namespace>/LFM2.5-2.6B --local_dir ./models/LFM2.5-2.6B

4.3 将权重转换为 GGUF 格式

llama.cpp 使用 GGUF 格式加载模型，因此需要先把 Hugging Face 的原始权重转换为 GGUF，再进一步量化。

# 在 llama.cpp 目录下执行转换 python3 convert_hf_to_gguf.py \ ../models/LFM2.5-2.6B \ --outfile ../models/LFM2.5-2.6B-Q4_K_M.gguf \ --outtype q4_k_m

q4_k_m是端侧部署中比较常用的量化档位，兼顾了模型体积和输出质量。如果设备内存紧张，可以尝试q4_0或q3_k_m；如果内存充足且更在意工具调用稳定性，可以尝试q5_k_m甚至不量化。转换完成后，会生成一个约 1.5GB 左右的 GGUF 文件。

5. 完整示例：本地跑通一个最小 Agent

这一步是本文的核心。我们用 llama.cpp 的本地推理服务器启动 LFM2.5-2.6B，并让它具备调用天气工具的能力。整个过程不需要连接任何云端大模型 API。

5.1 启动本地推理服务

先编译 llama.cpp，然后启动llama-server。

# 在 llama.cpp 目录下编译 mkdir -p build && cd build cmake .. -DLLAMA_CURL=ON cmake --build . --config Release -j 4 # 启动本地推理服务，端口 8080 ./bin/llama-server \ -m ../../models/LFM2.5-2.6B-Q4_K_M.gguf \ --host 127.0.0.1 \ --port 8080 \ -c 8192 \ --n-gpu-layers 99 \ --jinja

参数说明：

• -m：指定 GGUF 模型路径。
• -c 8192：上下文长度设为 8192，兼顾 Agent 多轮对话和端侧内存。
• --n-gpu-layers 99：把尽可能多的层放到 GPU。如果是纯 CPU 环境，删掉这个参数即可。
• --jinja：启用 Jinja 模板解析，让服务器正确识别模型的聊天模板和工具调用格式。如果该参数在你的版本中不存在，先升级 llama.cpp。

启动成功后，终端会输出类似server is listening on http://127.0.0.1:8080的提示。

5.2 验证基础对话

先用 curl 验证模型是否能正常推理。

curl http://127.0.0.1:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "messages": [ {"role": "system", "content": "你是一个简洁的本地助手。"}, {"role": "user", "content": "1+1等于多少？"} ], "temperature": 0 }'

如果返回内容中包含"content": "2"或类似答案，说明服务正常。

5.3 定义一个天气工具并让模型调用

端侧 Agent 的关键是工具调用。我们给模型注册一个get_weather工具，然后观察模型是否会输出结构化工具调用。

# 文件路径：agent_minimal.py import json import urllib.request BASE_URL = "http://127.0.0.1:8080" tools = [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的当前天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名"} }, "required": ["city"] } } } ] def call_chat(messages, temperature=0.2): payload = { "messages": messages, "tools": tools, "tool_choice": "auto", "temperature": temperature, } req = urllib.request.Request( f"{BASE_URL}/v1/chat/completions", data=json.dumps(payload, ensure_ascii=False).encode("utf-8"), headers={"Content-Type": "application/json"}, ) with urllib.request.urlopen(req) as resp: return json.loads(resp.read().decode("utf-8")) def get_weather(city): # 简化实现：实际项目中替换为真实天气查询逻辑 return {"city": city, "weather": "晴", "temperature": 26} def run_agent(user_input): system_prompt = ( "你是运行在用户本地的轻量级智能助手。请尽量简短回答。\n" "当用户需要实时信息或外部能力时，使用提供的工具。\n" "如果工具调用失败，直接告诉用户，不要编造结果。" ) messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_input}, ] for _ in range(5): result = call_chat(messages) msg = result["choices"][0]["message"] messages.append(msg) if msg.get("tool_calls"): for tc in msg["tool_calls"]: fn = tc["function"] args = json.loads(fn["arguments"]) tool_result = get_weather(args["city"]) messages.append({ "role": "tool", "tool_call_id": tc["id"], "content": json.dumps(tool_result, ensure_ascii=False), }) else: print("Agent 回答：", msg["content"]) return print("Agent 达到最大迭代次数，未能完成回答。") if __name__ == "__main__": run_agent("北京今天适合出门吗？帮我查一下天气。")

代码逻辑拆解：

• tools列表声明了模型可以调用的工具，使用 OpenAI 兼容的 function calling 格式。
• call_chat把消息和工具定义一起发给本地推理服务。模型如果认为需要查天气，会在返回的message中携带tool_calls字段。
• run_agent模拟 Agent 循环：模型请求工具 → 本地执行工具 → 把工具结果回填给模型 → 模型生成最终回答。
• 这里设置最大 5 轮迭代，避免模型陷入“反复调工具不结束”的死循环。

5.4 移动端部署的替代方案

如果你的目标是手机端，而不是 PC，llama.cpp 只是第一步。Android 端可以借助llama.android或MNN-LLM做集成，iOS 端可以借助 Core ML 转换工具。核心思路一致：把模型量化为适合移动端推理引擎的格式，然后在 App 进程内启动推理服务，再通过 JNI 或 Objective-C 绑定暴露给上层调用。移动端的内存预算比 PC 更紧张，建议把上下文长度从 8192 下调到 4096，并进一步检查工具描述的 token 占用。

6. 运行结果与效果验证

运行上面的 Python 脚本：

python3 agent_minimal.py

预期会出现类似输出：

Agent 回答： 北京今天天气晴，气温 26 度，适合出门。

如果打印出“Agent 回答”而不是报错，说明整个本地 Agent 闭环已经跑通：模型理解了用户意图，生成了工具调用，本地工具执行成功，最终回答也正确。

但这只是最低标准。在实际工程中，还要验证三个指标。

1. 工具调用格式的稳定性。连续运行 10 次同样的请求，统计有多少次能在一轮内返回合法的tool_calls。2.6B 模型偶尔会出现“工具调用和自然语言混在一起输出”或“参数是非法 JSON”的情况，需要重点观察。

2. 端到端延迟。从用户输入到最终回答的时间，需用程序计时。同样用 curl 测接口耗时：

time curl -s http://127.0.0.1:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"messages":[{"role":"user","content":"帮我查一下上海的天气"}],"tools":[{"type":"function","function":{"name":"get_weather","description":"查询指定城市的当前天气","parameters":{"type":"object","properties":{"city":{"type":"string"}},"required":["city"]}}}],"temperature":0}' \ -o /dev/null

如果-c 8192导致速度过慢，优先降低上下文长度，因为 KV Cache 会随上下文长度线性增长。

3. 内存峰值。在 macOS 上用top，在 Linux 上用htop或nvidia-smi，观察模型进程的常驻内存。如果内存接近设备上限，需要换更低的量化档位或更短的上下文。

如果脚本没有输出任何回答，第一步不是改代码，而是检查llama-server的终端日志。大部分问题都会在启动阶段暴露，比如模型加载失败、模板解析错误、OOM 等。

7. 常见问题与排查思路

这里最关键的一点是：小模型的工具调用不稳定，不是 bug，而是既定约束。端侧 Agent 的工程目标不是“保证 100% 正确”，而是“错误可检测、可重试、可降级”。把 JSON 解析失败当成正常分支处理，而不是崩溃分支处理，是端侧 Agent 工程实践的必修课。

8. 工程最佳实践与战斗建议

把 LFM2.5-2.6B 真正用到产品里，以下几条经验值得提前掌握。

8.1 量化档位选择

端侧模型部署，量化是绕不开的一步。我的建议是：先跑q4_k_m，然后在目标设备上做工具调用稳定性测试。如果格式错误率偏高，尝试q5_k_m；如果内存吃紧，再降级。量化不是越激进越好，而是在“模型体积、推理速度、输出稳定性”三者之间取平衡。

8.2 系统提示词要短而硬

小模型的注意力资源有限。系统提示词越长，真正留给用户指令和工具信息的空间就越少。建议用短句、命令式语气，明确告诉模型“什么时候用工具，什么时候不用”，并且强调“不要编造工具结果”。大模型可以接受的委婉表达，在小模型这里往往会被忽略。

8.3 工具描述要极简

工具定义里的description字段会占用上下文 token，也会影响模型的决策准确率。工具描述应该用一句话说清楚功能和参数，避免长段解释。工具数量也要克制，一个 Agent 场景注册 3 到 5 个工具就已经足够测试了，注册 20 个工具会让小模型陷入选择困难。

8.4 建立工具调用的三层校验

端侧 Agent 必须遵守“模型输出不可信”的原则。第一层校验在推理框架：确认tool_calls字段是否存在。第二层在应用层：解析 JSON、校验参数名和类型，不合法则重试。第三层在工具执行层：工具返回值要结构化成 JSON，并严格限制长度，避免大段文本占满上下文。

8.5 设置安全边界和权限

On-Device Agents 能访问本地数据，这是它的价值，也是它的风险。模型本身只是一个概率系统，它可能会在无授权的情况下尝试读取某类数据或触发某个本地操作。因此工具层必须做最小权限设计：每个工具都应有独立的授权检查，用户在 UI 层能看到“Agent 正在请求调用哪些权限”，而不是让模型直接访问系统级能力。涉及隐私数据或不可逆操作时，必须加入明确的用户确认环节。

8.6 合理使用上下文管理

Agent 多轮对话会产生大量历史消息。如果你的设备内存有限，不能无限保留历史。推荐做法是：只保留最近 8 到 10 轮消息，更早的内容做摘要后压缩成一条系统消息。这样既保住关键信息，又控制了 KV Cache 峰值。

8.7 准备云端兜底

端侧模型不是万能的。如果 Agent 在本地连续重试 2 到 3 次仍然失败，或者用户提出的任务明显超出小模型能力边界，应该设计一条云端兜底路径。这个降级策略要在产品设计阶段就明确，而不是上线后才发现。注意，兜底意味着用户数据可能出设备，因此必须明确告知用户并获取同意。

9. 总结与后续可以深入的方向

LFM2.5-2.6B 和它代表的 On-Device Agents 趋势，核心不是“把大模型变小”，而是围绕端侧的物理约束重新设计模型的 Agent 能力。模型规模、上下文长度、工具调用稳定性、量化策略和权限模型，这些因素共同决定了端侧 Agent 能否从演示变成产品。

如果你准备上手，建议先按本文流程把最小 Agent 在 PC 上跑通，然后依次做三件事：第一，把你的真实工具（日历、备忘录、天气 API）接入示例代码；第二，在目标设备上测一遍量化档位和内存占用；第三，用 20 到 30 条真实用户指令做工具调用稳定性回归，把失败案例整理成重试和降级的触发条件。

模型只是 Agent 的下限，围绕它的工程体系才决定体验的上限。接下来值得深入的方向包括：小模型的强化学习工具调用微调、端侧模型的多模态能力整合，以及更轻量的本地推理框架适配。每一步，都比纠结“哪个模型跑分更高”更有实际价值。