企业官网建设流程全解析

最近一直在折腾端侧Agent，原因很现实：公司推理服务器排队排到怀疑人生，云端API又不想把个人数据传出去。正好赶上 MiniCPM5-2B 这个2B参数的端侧模型可以本地跑，还专门优化过工具调用（Function Calling），我就把它当主力，在笔记本上搭了一个能实际干活的本地Agent。这篇文章把整个链路完整摊开：为什么选2B、本地部署怎么做、工具调用代码怎么写、实测效果怎么样，以及我踩过的几个坑。适合正在折腾本地大模型部署、想让Agent真正调用外部工具、又不想被显卡账单绑架的开发者。

1. 为什么端侧Agent偏选2B参数模型——选型逻辑与硬件门槛

1.1 2B模型的能力边界：别拿它当GPT-4用

先说结论：2B模型不是万能药，但做"工具调用型Agent"这件事，它恰恰踩在一个甜点上。

MiniCPM5-2B能做的事包括：理解自然语言指令、做信息抽取、按指定格式输出JSON、写简单代码片段、稳定触发Function Calling。这些是Agent最核心的需求。我的实际测试里，让它"查询北京时间"或者"计算235乘17"，它能非常规整地返回一个工具调用请求，而不是绕来绕去说废话。

但它也有明显短板：复杂多跳推理容易崩，比如"找出三个城市里气温最高的那个，并说明为什么不适合穿羽绒服"这种任务，它经常丢步骤或者直接编一个结论。长文本上下文处理能力也有限，超过一定轮数后，前面的信息会记混。所以选它之前，你得先想清楚自己的Agent到底需要多少"智能"。

下面是我对比过的几个参数档位：

这个表格说明一件事：如果你的核心链路是"用户说一句话 -> 模型决定调用哪个工具 -> 执行 -> 返回结果"，那么2B模型的能力刚好覆盖，而且覆盖得很稳。真正不够的是那些需要模型自己当"大脑"去规划复杂流程的场景。

1.2 端侧运行的真实硬件需求：量化前后差多少

很多人以为"端侧"就是随便一个笔记本都能跑，其实还是得有底线。模型推理时占用内存的机制不复杂：参数数量乘以每个参数占用的字节数，再加上上下文（KV Cache）开销。

以MiniCPM5-2B为例，FP16精度下参数占2B × 2字节 ≈ 4GB显存，看起来不大，但加上KV Cache和其他运行开销，8GB显存会吃紧。如果走量化路线，情况就完全不一样了：

我的测试环境是：R7 6800H处理器 + RTX 4060 Laptop 8GB显存 + 32GB内存，系统用的WSL2。跑Q4_K_M量化版，模型权重约1.4GB，实测推理时显存占用稳定在2.1GB左右，完全不影响我同时开浏览器和IDE。内存32GB是够的，哪怕16GB内存也能跑，因为权重本身不大，系统会动态分配。

如果你只有CPU没有可用GPU，也能跑，但速度要降到5~8 token/s，这种速度做交互式Agent会让人焦躁，不过做个后台批处理任务倒能接受。

1.3 我的选型纠结：7B太大、1.5B太笨、2B刚好

在锁定MiniCPM5-2B之前，我把附近的参数档位都试了一遍，说下真实感受。

先试的是Qwen2.5-7B-Instruct量化版，Agent能力确实强，复杂指令理解得很到位。但问题在于：8GB显存的笔记本，光加载权重就用掉4.7GB，再开个浏览器和IDE，GPU显存告警直接弹出来。而且上下文一长，生成速度掉到十几token/s，体验并没有比2B好到哪去。结论是：7B适合专职跑模型的机器，不适合"既要干活又要跑模型"的日常笔记本。

然后又试了1.5B级别的小模型。它轻是轻，0.9GB内存就能跑，但Function Calling的格式稳定度堪忧。让它调用工具，它经常不返回结构化的tool_calls，而是在content里写"好的，我现在去查一下天气"这种话。对Agent循环来说，这意味着解析失败，整个链路就断了。试了几次都这样，只能放弃。

MiniCPM5-2B正好卡在中间：权重小到可以常驻显存，function calling又经过专门优化。我现在这台笔记本日常开着微信、浏览器、VS Code，加上模型服务，显存占用始终没超过5GB，但Agent的指令遵循和工具调用都比较靠谱。说白了，选型就是算一笔账：你要在"能力、资源占用、稳定性"三个约束里找平衡点，2B是目前端侧Agent里最舒服的落点。

2. MiniCPM5-2B部署链路：从模型文件到可用服务

2.1 GGUF量化版本怎么挑：Q4_K_M是大多数人的最优解

部署MiniCPM5-2B的第一步，是拿到合适格式的模型文件。端侧部署我强烈建议直接用GGUF格式，这是llama.cpp生态的量化格式，Ollama也原生支持，省去了转格式的麻烦。实测下来，Q4_K_M版本是端侧部署的最优平衡点：质量损失很小，工具调用一样稳定，体积才1.4GB左右，下载快，加载也快。

如果你手头资源宽裕，比如有8GB以上专用显存的机器，可以上Q8版本，质量会更好一点，权重在2.3GB左右。但就我的实测对比来看，在工具调用场景下Q4_K_M和Q8的差异微乎其微，Q4_K_M完全够用。Q2这种极端量化我劝你别碰，模型会明显"变傻"，工具调用的JSON格式经常生成不完整，AttributeError和JSONDecodeError轮着来，返工成本比省下的那500MB高多了。

2.2 部署框架选Ollama还是llama.cpp

模型文件有了，下一个问题是：用哪个框架跑。我曾纠结Ollama还是llama.cpp，最后选了Ollama。理由很实际：Ollama提供现成的OpenAI兼容API，还内置Function Calling支持，我可以把openai库的base_url指到本地地址，写Agent业务代码时不用纠结底层细节。

llama.cpp当然也值得尊敬，它比Ollama更底层、更可控，什么新奇的大模型特性往往是llama.cpp先支持，深夜改代码、调参、编译都在里面折腾过。但在端侧Agent这个场景，我要的是"快速起一个稳定服务，然后把精力放在工具和业务逻辑上"，Ollama的体验明显更省心。对比一下就清楚了：

2.3 启动服务并验证API：一条curl命令的事

Ollama安装好之后，先确认服务在跑，然后拉模型：

# 启动服务（如果默认没启动的话） ollama serve # 拉取Q4_K_M量化版 ollama pull minicpm5-2b:q4_k_m # 验证模型已经就绪 ollama list

如果官方模型仓库里还没有这个tag，也可以自己去HuggingFace下载对应GGUF文件，然后用Modelfile导入。MiniCPM系列用的是ChatML模板，Modelfile可以这样写：

FROM ./minicpm5-2b-q4_k_m.gguf TEMPLATE """<|im_start|>system {{ .System }}<|im_end|> <|im_start|>user {{ .Prompt }}<|im_end|> <|im_start|>assistant """ PARAMETER temperature 0.2 PARAMETER top_p 0.8

然后执行ollama create minicpm5-2b -f Modelfile就能建出本地模型。

服务起来后，先不急着写Agent代码，用curl验证一下API是否正常：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "minicpm5-2b:q4_k_m", "messages": [ {"role": "user", "content": "用一句话介绍你自己"} ], "stream": false }'

正常情况下会返回一个包含choices的JSON，里面就是模型生成的回复。走到这一步，部署链路就算通了。我还习惯把OLLAMA_HOST=0.0.0.0设上，方便局域网内其他设备访问，但要注意开放端口的安全风险，只在可信网络里这么干。

3. 让Agent学会调用工具：Function Calling落地全流程

3.1 工具调用的底层逻辑：模型输出一个JSON，剩下交给代码

很多人第一次接触Function Calling会以为是什么高深机制，其实拆开看特别直白。你在请求里给模型传一个"工具清单"，里面描述了每个工具叫什么、参数是什么、什么时候用。模型在生成回复时，会决定"这题需要查一下当前时间"，于是它不直接输出答案，而是输出一个结构化的工具调用请求，比如：

{ "function": { "name": "get_current_time", "arguments": {"location": "北京"} } }

你收到这个请求后，在代码里去执行真正的get_current_time("北京")函数，把结果（比如"2026-05-14 15:30:00"）作为一条tool消息返给模型。模型再结合这个结果，生成最终面向用户的回答。

用个生活化的比喻：模型不是那个亲自跑腿干活的人，它是个聪明的前台。前台拿到你的需求，填好一张申请单（JSON），你把单子转给后面的业务员（代码函数）去执行，结果拿回来后，前台再把结果用你听得懂的话告诉你。整套流程的关键，就是模型必须稳定地输出这张"申请单"——这正是MiniCPM5-2B的强项。

3.2 先定义几个工具：从天气到数学计算

我定义了一个工具模块，包含三个典型函数：查时间、算表达式、查天气。先写真实的Python函数：

import ast import operator from datetime import datetime from zoneinfo import ZoneInfo def get_current_time(location: str) -> str: """返回指定地点的当前时间。""" tz_map = { "北京": "Asia/Shanghai", "上海": "Asia/Shanghai", "东京": "Asia/Tokyo", "纽约": "America/New_York", "伦敦": "Europe/London", } tz = tz_map.get(location, "Asia/Shanghai") return datetime.now(ZoneInfo(tz)).strftime("%Y-%m-%d %H:%M:%S") def calculate(expression: str) -> str: """安全计算数学表达式，只支持加减乘除、乘方等基础运算符。""" allowed_operators = { ast.Add: operator.add, ast.Sub: operator.sub, ast.Mult: operator.mul, ast.Div: operator.truediv, ast.Pow: operator.pow, ast.Mod: operator.mod, ast.USub: operator.neg, } tree = ast.parse(expression, mode="eval").body def eval_node(node): if isinstance(node, ast.Constant) and isinstance(node.value, (int, float)): return node.value if isinstance(node, ast.BinOp) and type(node.op) in allowed_operators: left = eval_node(node.left) right = eval_node(node.right) return allowed_operators[type(node.op)](left, right) if isinstance(node, ast.UnaryOp) and type(node.op) == ast.USub: return -eval_node(node.operand) raise ValueError(f"不支持的表达式: {expression}") return str(eval_node(tree)) def get_weather(city: str, date: str = "今天") -> str: """查询城市天气（模拟数据，真实环境可替换为API调用）。""" mock_data = { "北京": "晴，18~28℃，北风2级", "上海": "多云，20~27℃，东南风3级", "广州": "阵雨，23~30℃，南风2级", } weather = mock_data.get(city, "暂无数据") return f"{city}{date}：{weather}"

这些函数本身不复杂，但有几个设计点值得说。一是calculate用ast来解析表达式，而不是直接eval，避免用户输入恶意代码被当成Python执行——端侧Agent一样要防注入。二是所有函数都返回字符串，方便直接塞回模型上下文。三是工具返回信息尽量简洁，因为2B模型的上下文处理能力有限，返回一大段JSON反而容易让它迷失重点。

3.3 完整Agent循环：用Python把工具调用串起来

现在到了核心部分，把整个Agent循环写出来。我用的还是openai库，只不过把base_url指到了本地Ollama：

import json from openai import OpenAI from tools import get_current_time, calculate, get_weather client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama") MODEL = "minicpm5-2b:q4_k_m" TOOLS = [ { "type": "function", "function": { "name": "get_current_time", "description": "获取指定城市或时区的当前时间", "parameters": { "type": "object", "properties": { "location": {"type": "string", "description": "城市名，例如北京、东京"} }, "required": ["location"] } } }, { "type": "function", "function": { "name": "calculate", "description": "计算数学表达式，例如 235 * 17", "parameters": { "type": "object", "properties": { "expression": {"type": "string", "description": "要计算的数学表达式"} }, "required": ["expression"] } } }, { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的天气情况", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名"}, "date": {"type": "string", "description": "日期，默认今天"} } } } } ] TOOL_MAP = { "get_current_time": get_current_time, "calculate": calculate, "get_weather": get_weather, } def call_llm(messages): resp = client.chat.completions.create( model=MODEL, messages=messages, tools=TOOLS, temperature=0.2, ) return resp.choices[0].message def run_agent(user_input): messages = [ { "role": "system", "content": "你是一个端侧智能助手。当需要外部信息时，请调用工具；" "如果已经有足够信息，直接回答用户。", }, {"role": "user", "content": user_input}, ] for _ in range(5): msg = call_llm(messages) # 没有工具调用，说明模型已经给出最终回答 if not getattr(msg, "tool_calls", None): return msg.content # 把带有tool_calls的消息记录到上下文 messages.append({ "role": "assistant", "content": msg.content or "", "tool_calls": [ { "id": tc.id, "type": "function", "function": { "name": tc.function.name, "arguments": tc.function.arguments, }, } for tc in msg.tool_calls ], }) # 逐个执行工具，把结果作为tool消息回填 for tc in msg.tool_calls: tool_name = tc.function.name args = json.loads(tc.function.arguments or "{}") print(f"[Action] 调用工具 {tool_name}，参数 {args}") result = TOOL_MAP[tool_name](**args) messages.append({ "role": "tool", "tool_call_id": tc.id, "content": result, }) return "超过最大工具调用轮数，已终止。" if __name__ == "__main__": reply = run_agent("北京现在几点？顺便帮我算一下 235 * 17") print(reply)

这段代码有几个关键点需要特别注意。

第一，assistant消息里要原样带上tool_calls字段，这是很多人的坑。如果你在把消息追加回上下文时丢掉tool_calls，模型根本不知道刚才自己调用了工具，后续就可能重复调用或者混乱。

第二，tool消息必须用tool_call_id关联到对应的工具调用。这样模型才知道这个结果对应的是哪次调用。

第三，循环上界设成5轮，是防止模型在工具调用里无限打转。2B模型偶尔会犯"调用工具看结果，看完又调用同一个工具"的毛病，设置上界能及时止损。

跑一下上面的测试输入，正常情况下输出会是这样：

[Action] 调用工具 get_current_time，参数 {'location': '北京'} [Action] 调用工具 calculate，参数 {'expression': '235 * 17'} 北京现在的时间是 2026-05-14 15:30:22。 235 乘以 17 等于 3995。

它能一次性规划两个工具调用，还能把两个结果组织成一句自然回复，这就是MiniCPM5-2B针对Function Calling做优化的效果。我之前用其他同规格模型，很多只能识别一个工具，或者干脆把所有参数挤到同一个工具里。这个差距在Agent场景里是决定性的。

4. 实测记录：这个端侧Agent干起活来什么样

4.1 三个真实任务：查时间、算数、模拟查天气

我把上面的Agent部署好之后，先跑了一组基础任务来压测它的"工具调用稳定性"。

任务一：查时间

用户输入："东京现在几点？"

Agent输出：

[Action] 调用工具 get_current_time，参数 {'location': '东京'}

工具返回："2026-05-14 16:30:22"

最终回答："东京当前时间是 2026-05-14 16:30:22。"

整个过程一个来回，完美。

任务二：数学计算

用户输入："帮我算一下 (2 + 3) * 4 的平方。"

Agent输出：

[Action] 调用工具 calculate，参数 {'expression': '(2 + 3) * 4 ** 2'}

工具返回："80"

最终回答："(2 + 3) * 4 的平方是 80（即 5 * 16 = 80）。"

这里有个细节：模型自己把"的平方"转成了** 2，虽然表达式解释得略有偏差，但结果对了。这也提醒我，工具description写得越清楚，模型构造参数越准确。

任务三：天气查询

用户输入："杭州明天天气怎么样？"

Agent输出：

[Action] 调用工具 get_weather，参数 {'city': '杭州', 'date': '明天'}

工具返回："杭州明天：暂无数据"

最终回答："抱歉，目前还没有杭州明天的天气数据，建议换个渠道查询。"

这里可以看到2B模型的优点和边界同时显现：它会主动调用工具、遵守参数结构，但由于我的模拟数据里没有杭州，它没有硬编一个天气出来，而是选择诚实告诉你没有数据。这个"知道自己不知道"的表现，比很多更大参数的模型还靠谱。

4.2 性能账单：延迟、显存、Token消耗

实测环境还是RTX 4060 Laptop 8GB + Q4_K_M量化版，我记录了三个任务的性能数据：

这个速度在端侧场景里已经可用。平时用ChatGPT类应用，从提问到收到第一个字的等待时间差不多也是这个量级。而且完全不依赖外网，模型常驻显存后，首轮推理时间会进一步缩短，因为省去了加载模型的时间。

显存占用稳定在2.1GB左右，加上上下文增长会有小幅波动。这也意味着，在8GB显存的机器上，你完全可以再同时跑一个embedding模型或者OCR服务，资源余量依然很大。

4.3 会翻车的地方：复杂指令和多工具组合

当然，这只Agent也不是什么时候都靠谱。我专门试了几个刁钻场景，记录一下翻车规律。

翻车场景一：复杂规划

用户输入："帮我对比北京、上海、广州的天气，然后告诉我哪个最适合跑步。"

模型需要连续调用三次get_weather，再综合推理。实际运行结果是：只调用了北京和上海两个城市，然后就开始回答"广州天气未知，但根据我的判断……"，直接开始编。这种多步规划+多工具组合的任务，确实是2B模型的硬伤，它会在中途"忘记"还没完成的动作。

翻车场景二：参数理解偏差

用户输入："查询北京时间。"模型把location构造为{"location": "北京时间"}，而不是"北京"。我的函数拿这个去查时区映射表，查不到，返回默认的上海时区。好在结果是时间没差多少，但这个细节说明2B对"城市名"和"时间"的词性区分还不够稳定。所以我后来在工具description里加了"城市名必须是一个地点名称，不能包含'时间'等字眼"，情况好多了。

翻车场景三：过度调用工具

用户输入："你好。"理论上应该直接回答"你好"，不需要任何工具。但有时模型会画蛇添足地去调用get_current_time，然后在回答里带上当前时间。这个现象在上下文变长之后尤其明显。解决办法是在system prompt里强化一句："只有在必要时才调用工具，普通问候直接回答。"

所以我的最终结论是：MiniCPM5-2B最适合做"单次工具调用"和"有限次并列工具调用"的Agent，比如查信息、算数、查询状态。如果要让它做多步骤规划器，多轮追问、逐步分解，那不如把它当执行层，前面再挂一个大模型做规划。这也是我后面做扩展时的核心思路。

5. 端侧部署避坑实录：五条真实踩坑与排查过程

5.1 输出乱码与无限重复：采样参数背锅

第一周用的时候，我一度以为模型文件损坏了，因为它的输出经常变成"好的好的好的好的好的好的"无限重复，偶尔还夹杂乱码。

排查链路是这样的。先看原始输出，发现重复集中在尾段。再看采样参数，Ollama默认的temperature是0.8——这个值在大模型上通常没问题，但在2B这种小参数模型上，高温会让注意力分布变散，模型越生成越"忘"了前面的内容，于是陷入重复循环。然后我把temperature降到0.2，repeat_penalty保持默认，问题立刻消失。之后跑了上百次任务，再没出现过无限重复。

所以如果你也遇到输出重复，不用急着怀疑模型文件，先把temperature降到0.2甚至0.1试试。端侧小模型玩的是稳定性，不是创造力。

5.2 Function Calling时返回的不是JSON怎么办

另一个高频问题：模型不返回tool_calls结构，而是在普通content里写"我将调用get_weather，查询杭州天气"。对Agent循环来说，这等于工具调用失败。

我把排查过程复盘一下。第一步，用curl走Ollama原生/api/chat接口，只传tools参数，不加任何prompt工具描述。结果正常返回tool_calls。这说明模型本身没问题，问题出在我自己的代码或提示词上。

第二步，翻看我的system prompt，里面写了一长串"你有以下工具可用..."，等于把工具信息又重复了一遍。这反而干扰了模型的原生Function Calling能力——它以为在content里说明就够了，不需要走结构化输出。删掉手动工具清单，只通过tools参数传，问题解决。

这里有个通用经验：用原生Function Calling时，不要在system prompt里重复工具描述，否则等于让模型在"结构化路线"和"自由文本路线"之间做选择，而小模型的选择往往不稳定。

5.3 Ollama内存不释放：keep_alive参数

跑了一段时间后，我用nvidia-smi一看，显存被占了2GB多，很久不释放。一开始以为程序泄漏了，排查后发现是Ollama的机制：默认keep_alive是5分钟，模型5分钟内没请求，会自动从显存卸载。如果你频繁小请求，它会一直保持加载，显存占用看起来就像泄漏。

如果想让模型用完后立刻释放显存，调用接口时带一个参数：

curl http://localhost:11434/api/generate \ -H "Content-Type: application/json" \ -d '{ "model": "minicpm5-2b:q4_k_m", "keep_alive": 0 }'

如果想让模型常驻显存、减少首轮加载延迟，把keep_alive设为-1即可。根据自己的场景选，交互频繁的Agent建议常驻，批处理任务用0。

5.4 多个工具调用并行：串行还是并发？

模型在一次回复里返回多个tool_calls很常见，比如"查北京时间和上海天气"这种输入，它可能同时生成两个工具调用。我最初的想法是，多工具调用当然用多线程并发执行，能省时间。

实测发现一个反直觉的现象：在端侧本地推理场景下，并发执行工具并不总是更快。因为Ollama对同一模型的并发请求是排队处理的，如果你用线程池把两个工具并发执行，而且其中一个函数内部又要调用模型（比如二次推理），反而会因为抢占推理资源变得更慢。但如果工具是查天气、查数据库这种纯外部IO，并发没问题，省的是网络等待时间。

所以我的建议是：外部API类型的工具可以并发；所有需要触碰本地模型上下文的操作，一定要串行。在Agent循环里，我给每类工具分别标注了是否支持并发，避免无脑线程池带来的隐形坑。

5.5 上下文一长就变蠢：窗口管理与历史裁剪

最后一个坑，也是2B模型用户迟早会撞上的：多轮对话之后，模型突然开始答非所问，甚至无视工具调用结果。

我监控了messages数组，发现几轮工具调用加上结果回填，上下文token很快涨到2000以上。2B模型的注意力能力有限，上下文窗口塞太满，它就会"淹没"在细节里，抓不住当前的用户意图。

我的处理办法有三个。一是历史裁剪，只保留最近4轮对话，更早的对话做成摘要存起来；二是工具结果精简，函数返回的字符串控制在50字以内，防止无关细节占窗口；三是把num_ctx设置成2048或4096，但不要盲目开大，窗口越大，模型注意力越分散，速度也越慢。做完这三件事后，连续聊20轮的稳定性提高了很多。

6. 从Demo到真实应用：继续往哪走

6.1 给Agent加一个FastAPI外壳

Agent循环跑通后，我把它包成了一个轻量HTTP服务，这样其他应用就能通过网络调用这个本地助手。用FastAPI非常直接：

from fastapi import FastAPI from pydantic import BaseModel from agent import run_agent app = FastAPI(title="MiniCPM5-2B 端侧 Agent") class Query(BaseModel): text: str @app.post("/agent") def agent_endpoint(query: Query): reply = run_agent(query.text) return {"reply": reply}

加上CORS中间件后，前端页面也可以直接调用。实际使用中，比直接在命令行里跑Agent舒服多了。我用一个Web聊天界面连上这个服务，手机上也能通过局域网访问，本质上是把模型变成了家庭内部的一个"AI小管家"。

这里提醒一点：把服务暴露到局域网后，一定要加一层认证或只监听本地回环地址，因为你无法控制局域网里谁会来调用你的函数接口。Agent再小，也是个能执行工具的存在，入口防护不能省。

6.2 后续可扩展的方向：记忆、RAG、子Agent

这套东西目前只实现了"工具调用"这个核心能力，但Agent要做实用，还得扩三块。

记忆持久化：现在的Agent是无状态的，每轮对话都不知道上一轮聊了什么。我在本地装了SQLite，每轮结束把对话摘要存进去，下次启动前先检索相关记忆再塞进system prompt。2B模型不需要记太多，只要能记住用户偏好就够了。

RAG知识库：本地部署最大的红利就是可以放心把私有文档交给模型。我把自己的笔记、API文档切块后做了本地向量库，然后给Agent新增一个search_knowledge工具，用户问"我们的服务器部署流程是什么"时，它先去检索再回答。实测下来，2B模型做"检索后问答"效果不错，比让它凭空生成靠谱得多。

子Agent架构：如前面说的，2B模型不适合做复杂规划，但可以当执行器。我现在的前端是一个名义上的"主管"角色，它用更大的模型（云端）负责意图理解和任务拆分，把具体动作交给MiniCPM5-2B去执行。这个组合既保住了复杂场景的智能，又把日常简单操作放在本地，兼顾了隐私和速度。

用MiniCPM5-2B搭端侧Agent这件事，我前后折腾了三周。最大的体会是：端侧Agent不是大模型的缩水版，而是另一类产品。它把隐私、延迟、成本控制在自己手里，适合做一个永远在线、随叫随到的小助手。2B模型就像一个踏实的新员工：你交代清楚单子，他能执行到位，但别指望他独立做复杂的项目规划。所以我最后想分享一个选型心得：别盲目追求大模型，先想清楚你的应用真正需要多少"智能"，用最小的模型干完，把多出来的资源留给流程设计和工具质量。毕竟Agent的靠谱程度，一半看模型，另一半看你给它配的工具和兜底逻辑。