企业官网建设流程全解析

如果你最近在关注终端设备上的大模型应用，应该能感受到一个明显变化：过去讨论的是能不能在手机里跑一个对话模型，现在大家讨论的已经是能不能在手机里跑一个能自己干活、会调用工具、能连续完成任务的 Agent。也就是说，单点问答已经不够了，行业正在把注意力从“模型会不会说”转向“模型会不会做”。

LFM2.5-2.6B 的定位恰好踩在这个转折点上。参数规模控制在 2.6B 级别，目标场景是 On-Device Agents，也就是端侧智能体。先说我的判断：这类模型真正要解决的并不是“移动端能不能推理”的问题，而是端侧 Agent 能否承担完整任务闭环的问题。模型只是其中一环，工具调用、上下文管理、任务编排、失败恢复，这些工程链路才是决定端侧 Agent 好不好用的关键。

这篇文章会围绕 LFM2.5-2.6B 和 On-Device Agents 展开，讲清楚四件事：端侧 Agent 为什么重要，LFM2.5-2.6B 在技术路径上为什么值得关注，如何在一个最小环境里把这类模型跑起来并做成一个能调用工具的智能体，以及在真实项目中会遇到哪些坑、应该怎么规避。对于正在做端侧 AI 应用、Agent 产品或者嵌入式智能设备的开发者，这篇文章可以作为一条较完整的从认知到实践的参考路径。

1. 端侧 Agent 不是把模型塞进手机那么简单

1.1 云端 Agent 的体验瓶颈在哪里

先看一个很常见的业务场景：一个智能助手需要帮你查询行程、预约会议室、整理待办事项。传统做法是把语音识别、意图识别、槽位填充、任务执行拆成多个模块，每走一步都要和云端交互一次。云端大模型方案出现后，这个流程简化成了“一个大模型 + 一堆工具”，理解能力和任务规划能力确实大幅提升。

但把 Agent 完全放在云端，问题也很直接。

• 首包延迟不稳定。多轮工具调用需要在云端和端侧之间来回传输，每轮都有网络开销。
• 隐私敏感数据不能随便出设备。医疗数据、会议内容、个人文件，在很多场景下根本不允许上传。
• 离线等于不可用。在飞机、地下车库、野外环境，云端 Agent 直接失效。
• 长期成本不低。高频工具调用意味着大量 token 消耗，按量计费在规模化后是明显压力。

这些痛点不是模型能力不够，而是产品形态与部署位置不匹配。于是 On-Device Agent 成为一种必然的技术方向。

1.2 端侧 Agent 和端侧模型不是一回事

很多文章把端侧模型和端侧 Agent 混为一谈，这是理解上最容易出偏差的地方。

端侧模型解决的是“在设备上完成一次推理”，比如输入一段话，输出一个回答。端侧 Agent 解决的是“在设备上完成一个任务”，比如收到指令后规划步骤、调用工具、读取结果、继续推理，直到任务完成。前者是一个模型能力事件，后者是一个系统工程事件。

换句话说，端侧 Agent = 端侧模型 + 工具执行环境 + 上下文管理 + 任务调度 + 异常处理。LFM2.5-2.6B 的出现，解决的是其中最核心的“端侧模型”部分，但模型之外的其他环节仍然需要开发者自己搭建。

这就引出一个关键结论：就算模型再好，如果工具调用协议不稳定、上下文管理不够精细、任务编排不够健壮，最终产品体验依然不会好。模型决定的是能力上限，工程决定的是体验下限。

1.3 为什么是 2.6B 这个规模

参数规模的选择是端侧 Agent 里最实际的问题。

参数太少，比如 0.5B，模型的理解能力、指令遵循能力和工具调用能力都会打折扣。参数太多，比如 7B 甚至 13B，在手机和 IoT 设备上的内存占用、推理延迟、功耗会非常难控制。2.6B 是一个折中区间：模型有足够的语义理解能力来执行复杂指令，同时量化后体积可控，在旗舰手机和边缘设备上具备部署可能性。

LFM2.5-2.6B 定位在 2.6B 级别，说明其目标并不是追求极致的通用能力，而是面向端侧 Agent 场景做能力与资源的最优平衡。对于开发者来说，这个规模意味着可以用更低的工程成本验证端侧智能体的产品逻辑。

2. LFM2.5-2.6B 的技术定位与架构思路

2.1 非 Transformer 路线：一次值得关注的架构探索

LFM 是 Liquid Foundation Model 的缩写，Liquid AI 的模型路线和主流 GPT 风格 Transformer 并不完全相同。LFM 系列从公开信息看，采用了非 Transformer 的架构设计，并融合混合架构与稀疏激活等思路，目标是用更低的推理成本获得可比的语义能力。

这里需要解释一个容易被忽略的背景。过去一年，行业对模型架构的讨论集中在 MoE、Mamba、线性注意力等方向，核心命题都是同一个：当模型规模增长到一定程度，Transformer 的推理效率和显存占用变得非常不友好，能不能在架构层面做结构性优化，让模型在更小的资源消耗下完成同样的任务。

LFM 系列走的是这个方向。对于端侧部署来说，这意味着潜在的好处是显式的：更低的 KV Cache 占用、更少的推理内存峰值、更快的端侧推理速度。当然，这并不意味着非 Transformer 架构全面优于 Transformer，它在长文本能力、生态兼容、工具链成熟度上还需要验证。但从趋势看，架构多样化已经成为一个不可逆的方向。

2.2 从“对话模型”到“工具调用模型”

如果把 LFM2.5-2.6B 仅当作一个聊天模型，那就忽略了这个产品定位里真正重要的信息：On-Device Agents。

端侧 Agent 场景对模型有特殊要求，不只是“能答对”，还需要：

• 能稳定理解用户目标，而不是逐字执行指令。
• 能按固定格式输出工具调用参数，让程序可以解析并执行。
• 能在多轮对话中保持任务状态，不被中间结果带偏。
• 能在工具返回结果后继续推理，形成“推理—行动—观察—再推理”的循环。

这些能力并不是所有小模型都能做到的。很多 1B 以下的小模型在代码任务上表现尚可，但一旦涉及复杂的多步工具调用，格式稳定性和逻辑一致性就会明显下降。LFM2.5-2.6B 需要在 2.6B 这个规模下同时满足以上四点，相比单轮问答，难度是成倍增加的。

2.3 与云端大模型的协作关系

端侧 Agent 的火热，并不代表着云端大模型会被替换。更合理的产品架构是分层协作。

简单、高频、隐私敏感的任务放在端侧，由 LFM2.5-2.6B 这类模型直接完成。复杂推理、常识问答、跨领域规划等任务，端侧模型判断能力不足时，再把请求转给云端大模型。这种混合式架构已经成为端云协同的主流范式。

在这个架构里，端侧模型的价值是明显的：

• 过滤高频请求，降低云端成本。
• 在弱网和离线环境下提供基本能力。
• 保护隐私数据不离开设备。
• 提升响应速度，改善交互体验。

所以，与其问“端侧模型能不能替代云端大模型”，不如问“哪些任务应该在端侧完成，哪些任务必须上云”，这才是 On-Device Agents 产品设计中最值得思考的问题。

3. 端侧 Agent 的关键技术链路解析

在进入实操之前，先把端侧 Agent 的运行链路拆开。理解这条链路，后面碰到问题就知道该往哪里查。

一个最小可用的端侧 Agent 通常包含以下模块：

• 输入处理：把用户指令转换成结构化任务描述。
• 意图规划：模型根据任务描述选择需要的工具和调用顺序。
• 工具调用：Agent 程序解析模型的输出，调用本地或远程工具。
• 结果回填：把工具返回结果送还给模型。
• 状态管理：记录中间步骤和已完成信息，防止上下文丢失。
• 输出生成：向用户反馈执行结果或需要澄清的问题。

这里最核心的环节是“工具调用”。目前主流做法是让模型以 JSON 格式输出工具调用意图，比如{"name": "get_weather", "arguments": {"city": "北京"}}，然后由程序解析、执行、回写结果。这种做法的关键是模型输出的格式稳定性。

如果模型在普通对话时表现很好，但在工具调用场景下经常出现 JSON 格式错误、参数名写错、返回了多余内容，那么 Agent 的可用性就会大打折扣。这也是评测端侧 Agent 模型时最应该关注的点。

4. 环境准备与部署前置条件

下面进入实操部分。由于 LFM2.5-2.6B 的具体部署方式以官方文档发布为准，本文先演示一条通用的端侧模型部署与 Agent 搭建路径，覆盖环境准备、模型加载、推理调用和工具编排四个阶段。

4.1 硬件与操作系统建议

端侧 Agent 验证可以分为两个阶段：

• 第一阶段在开发机上验证模型能力和工具调用效果，建议使用 16GB 内存以上的 PC，搭配带 8GB 以上显存的独立显卡效果更佳。
• 第二阶段迁移到真实端侧设备，建议优先选择 8GB 以上内存的手机或开发板，并开启硬件加速。

如果没有独立显卡，CPU 推理也能完成基本验证，只是速度会偏慢，属于正常现象。

4.2 软件依赖

建议准备以下软件环境，版本请以实际项目要求为准：

• Python 3.10 或更高版本。
• 模型推理框架：推荐使用 ONNX Runtime、llama.cpp 或项目官方指定的推理引擎。
• 模型管理工具：Hugging Face CLI 或 ModelScope CLI。
• 其他依赖：requests、transformers中与目标模型匹配的组件、numpy等。

如果国内网络不稳定，优先使用 ModelScope 拉取模型。

5. 最小部署：本地跑通 LFM2.5-2.6B 级模型

5.1 拉取模型文件

以 Hugging Face 为例，使用命令行下载模型仓库：

# 安装 Hugging Face CLI pip install -U "huggingface_hub[cli]" # 拉取模型仓库，LFM2.5-2.6B 的完整路径请以官方发布为准 huggingface-cli download LiquidAI/LFM2.5-2.6B --local-dir ./models/LFM2.5-2.6B

拉取完成后，模型目录下一般会包含权重文件、配置文件、分词器文件和 README。建议先阅读 README，确认模型支持的输入格式和工具调用协议。

5.2 使用 ONNX Runtime 加载模型

LFM 系列如果要跑在端侧，ONNX Runtime 是一个非常实际的选择。ONNX Runtime 对 Arm、x86、NPU、GPU 等硬件都有较好的支持，同时支持量化模型。

以下是一个最小加载示例：

# 文件路径：scripts/inference_onnx.py # 注意：此处为通用 ONNX Runtime 推理示例 import onnxruntime as ort import numpy as np session = ort.InferenceSession( "models/LFM2.5-2.6B/model.onnx", providers=["CUDAExecutionProvider", "CPUExecutionProvider"] ) input_name = session.get_inputs()[0].name output_name = session.get_outputs()[0].name # 以随机输入做一次前向验证 input_data = np.random.randn(1, 128).astype(np.float32) result = session.run([output_name], {input_name: input_data}) print("输出形状:", result[0].shape)

这个例子的目的是验证模型文件可以正常加载。真实文本生成还需要处理分词、采样、KV Cache 等逻辑，建议直接使用官方提供的推理脚本，避免重复造轮子。

5.3 使用 llama.cpp 快速加载 GGUF 模型

如果模型发布了 GGUF 格式，可以优先选用 llama.cpp。它针对 CPU 和 Metal 做了大量优化，在 Mac 和端侧设备上表现很好。

# 以常规 llama.cpp 命令行方式运行 ./llama-cli \ -m ./models/LFM2.5-2.6B/ggml-model-Q4_K_M.gguf \ -p "用户：今天天气怎么样？\n助手：" \ -n 128 \ --temp 0.7

注意，具体 prompt 模板要以模型的发布说明为准，不同模型的指令格式差异很大。

6. 把模型升级成 Agent：工具调用与任务编排示例

模型跑通之后，下一步是把它封装成 Agent 核心。这一节提供一个相对完整的 Python 示例，不依赖特定框架，方便理解 Agent 的完整链路。

6.1 定义工具

先定义两个简化工具：查询天气和查询日历。

# 文件路径：agent/tools.py import json def get_weather(city: str) -> str: """模拟查询城市天气""" return json.dumps({"city": city, "weather": "晴", "temperature": 26}, ensure_ascii=False) def get_calendar(day: str) -> str: """模拟查询日程""" return json.dumps({"day": day, "events": ["10:00 项目评审", "15:00 客户会议"]}, ensure_ascii=False) TOOLS = { "get_weather": get_weather, "get_calendar": get_calendar, } TOOL_SCHEMA = { "get_weather": { "description": "查询一个城市的天气情况", "parameters": ["city"], }, "get_calendar": { "description": "查询某天的日程安排", "parameters": ["day"], }, }

这个文件模拟了工具注册中心。真实项目里可以在这里加入权限控制、超时处理和日志记录。

6.2 让模型返回结构化工具调用

在很多开源模型里，工具调用是通过统一的 chat template 来完成的。模型根据系统提示和用户消息，输出一个 JSON 结构的调用意图。

# 文件路径：agent/agent_core.py # 简化示例：假设模型接口支持 ChatCompletion 风格 import json def build_messages(task: str): system_prompt = ( "你是一个端侧智能体。请根据用户任务选择工具并返回 JSON 调用。" "可用工具：" + json.dumps(TOOL_SCHEMA, ensure_ascii=False) ) return [ {"role": "system", "content": system_prompt}, {"role": "user", "content": task}, ] def call_model(messages): """调用本地模型服务，具体实现由所用推理框架决定。""" # response = local_model.generate(messages) # 这里用一个假返回模拟模型输出 return '{"name": "get_weather", "arguments": {"city": "上海"}}' def parse_tool_call(response_text: str): """从模型输出中解析工具调用 JSON""" try: return json.loads(response_text) except json.JSONDecodeError: # 生产环境需要增加格式纠错逻辑 raise ValueError("模型输出不是合法 JSON: " + response_text)

这里的call_model是核心抽象层。你可以替换为 llama.cpp 的 HTTP 接口、ONNX Runtime 的直接推理，或者某个 Agent 框架里的模型调用组件。

6.3 完整 Agent 循环

下面实现一个最小但完整的 Agent 循环：生成调用、解析意图、执行工具、回填结果、生成最终回答。

# 文件路径：agent/main.py import json from agent.tools import TOOLS, TOOL_SCHEMA from agent.agent_core import build_messages, call_model, parse_tool_call MAX_STEPS = 3 def run_agent(task: str): messages = build_messages(task) final_answer = "" for step in range(MAX_STEPS): response = call_model(messages) # 如果模型直接返回最终回复，就结束 if not response.strip().startswith("{"): final_answer = response break tool_call = parse_tool_call(response) tool_name = tool_call.get("name") tool_args = tool_call.get("arguments", {}) print(f"[Step {step + 1}] 调用工具: {tool_name}, 参数: {tool_args}") if tool_name not in TOOLS: raise ValueError(f"未知工具: {tool_name}") result = TOOLS[tool_name](**tool_args) print(f"[Step {step + 1}] 工具返回: {result}") # 把工具结果作为新消息回填给模型 messages.append({"role": "assistant", "content": response}) messages.append({"role": "tool", "name": tool_name, "content": result}) # 部分实现要求最终生成自然语言回复 final_answer = call_model(messages) messages.append({"role": "assistant", "content": final_answer}) return final_answer if __name__ == "__main__": result = run_agent("帮我查一下上海明天天气，然后再看看明天的会议安排") print("最终回答:", result)

这个实现里最关键的设计是：模型每输出一次 JSON，程序就执行一次工具，再把结果以tool消息回填。这个循环本质上就是 ReAct 范式的简化版。真实项目需要考虑更复杂的并发工具调用、条件分支和中断恢复，但基础骨架是通用的。

6.4 上下文管理策略

端侧模型的内存窗口有限，上下文管理会直接影响体验。三种常见策略：

• 滑窗裁剪：保留最近 K 轮对话，把最早的部分截断。
• 关键信息抽取：每轮对话结束后，让模型或规则把关键信息压缩成结构化摘要。
• 任务级隔离：一次 Agent 执行使用独立上下文，避免任务之间互相污染。

建议在早期版本采用“任务级隔离 + 滑窗裁剪”组合，既简单又稳定。

7. 运行结果与效果验证

7.1 如何判断部署成功

运行上面的 Agent 循环，如果出现类似输出，说明端侧 Agent 最小闭环已经跑通：

[Step 1] 调用工具: get_weather, 参数: {"city": "上海"} [Step 1] 工具返回: {"city": "上海", "weather": "晴", "temperature": 26} [Step 2] 调用工具: get_calendar, 参数: {"day": "明天"} [Step 2] 工具返回: {"day": "明天", "events": ["10:00 项目评审", "15:00 客户会议"]} 最终回答: 上海明天晴，气温约 26 度。你明天有项目评审和客户会议两个安排。

这一步说明模型已经能根据任务选择合适的工具并正确解析参数。

7.2 更细致的验证方案

建议用一套固定的评测集来验证模型在工具调用场景下的表现，维度包括：

• 工具名选择准确率：模型选对工具的比例。
• 参数填充正确率：参数名和参数值是否正确。
• JSON 格式合规率：输出能否被json.loads直接解析。
• 多步任务成功率：需要两次以上工具调用的任务完成比例。
• 端到端响应延迟：从用户输入到拿到最终回复的总时长。

在真实评测过程中，我把 JSON 格式错误列为最高优先级问题。一个模型如果对话能力看起来不错，但工具调用 JSON 频繁出错，端侧 Agent 的可靠性就不成立。建议在选型阶段先用 100 到 200 条任务样本跑一遍上述指标，再做产品决策。

7.3 失败排查第一顺序

如果 Agent 循环跑不通，按这个顺序排查：

1. 先看模型原始输出，是否真的返回了 JSON。
2. 再看 JSON 里的工具名是否在TOOLS中。
3. 继续看参数名是否被模型改写了，比如city被写成了address。
4. 最后确认工具返回结果有没有超出模型上下文长度。

大部分工具调用失败都不是模型能力问题，而是 prompt 模板和格式约束不够清晰。

8. 常见问题与排查方法

这个表格不是万能清单，但覆盖了端侧 Agent 最常见的几类问题。遇到异常时，先抓模型原始输出，再定位是模型问题、工具定义问题还是框架问题，这个思路能省很多时间。

9. 最佳实践与工程建议

9.1 量化选择不能只看体积

很多团队在端侧部署时直接选择最低比特量化，比如 4-bit 甚至 2-bit，认为只要体积小就行。这个观点存在明显误导。

量化级别直接影响工具调用格式的稳定性。可能对话效果看起来只下降了一点点，但 JSON 输出错误率却成倍上升。建议在项目初期做一组小规模对比实验：同一批任务在 FP16、8-bit、4-bit 下的工具调用成功率。如果没有明显差异，再选择体积更小的版本。

9.2 工具定义最小化

端侧环境下，每一个多余的工具都会增加模型的选择困惑度。工具定义应当坚持最小化原则：

• 能用本地规则完成的，不交给模型。
• 能合并的同类工具，先合并再暴露给模型。
• 工具名称和参数名要符合直觉，避免抽象命名。
• 一个任务的候选工具数量尽量控制在 5 个以内。

工具数量过多，模型的选择错误率会显著上升，这是大模型应用中的常见现象。

9.3 安全与权限边界

端侧 Agent 因为运行在本地，容易被忽略安全问题。实际上它比云端 Agent 更需要谨慎：

• 工具调用必须做权限校验，不能直接把模型指令当命令执行。
• 涉及发送短信、支付、删除文件等敏感操作时，必须二次确认。
• 所有工具调用要写审计日志，便于追踪问题。
• 本地知识库和隐私数据访问需要最小权限策略。

一句话概括：模型可以建议，但执行权力必须由程序控制。

9.4 版本管理与灰度回滚

端侧模型的更新是一次高风险操作。模型文件版本、Prompt 模板、工具定义、解析逻辑四个部分必须同步管理。任何一部分单独升级都可能引入兼容性问题。

建议方案：

• 把模型文件、Prompt 模板、工具 schema、Agent 代码纳入同一个版本分支。
• 发布前在模拟器环境中完整回归一遍工具调用样例集。
• 端侧应用采用热更新机制，模型下载失败时继续使用旧版本。
• 保留上一版本模型文件，支持快速回滚。

9.5 评测集要贴近真实任务

很多端侧 Agent 项目在选型时用的是公开 benchmark，但公开基准和真实用户任务往往偏差很大。更实际的做法是：从目标用户的真实使用流程里抽取 50 到 100 条任务，覆盖高频、中频、低频场景，并把它们固化为自动化评测用例。

每次替换模型、更新 prompt 模板、调整工具 schema 后，都跑一遍这套评测集，用数据而不是感觉来判断效果变化。

10. 总结：端侧 Agent 的落地关键在哪一步

回到开头的判断。LFM2.5-2.6B 这类模型的发布，解决的是端侧 Agent 的“大脑”问题，但大脑再强，还需要身体、神经和反馈系统一起工作。在一个真实的端侧 Agent 产品里，模型只占一部分，工具定义、上下文管理、权限控制、评测体系和版本回滚能力，共同决定了产品能否稳定运行。

从实践路径看，建议开发者按四步推进：

1. 先用 LFM2.5-2.6B 这类模型跑通最小 Agent 闭环，确认工具调用格式足够稳定。
2. 建立与真实任务一致的评测集，用数据选择量化版本和 prompt 模板。
3. 把工程链路补完整，包括上下文管理、权限校验、日志和灰度发布。
4. 再逐步扩展到真实设备，验证功耗、延迟和稳定性。

这套路径不依赖某一个模型或框架，适用于大多数端侧 Agent 项目。对于想深入学习的方向，下一步可以继续研究工具调用协议设计、端侧推理优化，以及 ReAct 类任务编排的变体方案。模型会不断更新，设备会不断升级，但“能力、资源、工程、评测”四者的平衡，才是端侧 Agent 长期迭代的真正主线。