企业官网建设流程全解析

1. 从"设备即环境"这个说法说起：端侧模型到底在赌什么

第一次看到"设备即环境"这个提法，我愣了几秒。过去几年我们聊端侧模型，聊的都是"把模型塞进手机""本地推理省流量"这类工程视角的事，很少有人把它上升到一个环境层面的判断。但仔细想想，这个说法其实点破了一件被行业长期忽略的事：当模型跑在设备上，设备本身就不再只是一个计算载体，它变成了模型感知世界、理解用户、做出决策的完整上下文。

这个判断背后有一个很硬的逻辑。云端模型再强，它对用户的理解始终隔着一层——它看到的是你上传的片段、你授权的数据、你主动发起的请求。而端侧模型不一样，它天然就活在设备里，能接触到传感器数据、使用习惯、本地文件、应用状态、时间地点这些连续信号。这些信号单独看都不值钱，但拼在一起，就是一个人的数字生活全貌。

我拿一个具体场景来说明。假设你想做一个真正懂你的日程助手。云端方案的做法是：你告诉它"我明天下午要开会"，它记下来，到点提醒你。端侧方案的做法是：它发现你最近三天晚上都在改一份文档，日历上有个"项目评审"的标记，手机定位显示你明天上午要去客户那边，于是它主动问你"要不要把评审材料提前同步到平板，路上可以过一遍"。后者不是更聪明，而是它拿到的上下文更完整。

这就是"设备即环境"的核心：端侧模型的价值不在于参数规模，而在于它和用户之间没有数据搬运的损耗。云端模型要理解你，得先把你"数字化"再传上去；端侧模型直接就在你的数字生活现场。

那为什么是现在这个时间点？三个条件同时成熟了。第一，小模型的能力上来了，几B参数的模型在特定任务上已经能打；第二，设备算力上来了，手机、PC、车机的NPU不再是摆设；第三，用户对数据隐私的敏感度上来了，越来越多的人不愿意把聊天记录、照片、位置这些数据往云端送。这三个条件缺一个，端侧模型都只能是demo。

北大系这家公司押注这个方向，本质上是在赌一个判断：未来的AI入口不在云端，而在每一台设备里。这个判断对不对，现在下结论还早，但它至少解释了一个现象——为什么大厂都在做端侧模型，却很少有人真正把"设备即环境"当成产品哲学来做。

2. 端侧模型和Agent结合之后，事情变得不一样了

单独聊端侧模型，容易陷入"参数小、跑得快"这种技术指标的比较。但端侧模型真正的想象力，是和Agent结合之后才打开的。我甚至觉得，端侧模型如果没有Agent，价值要打对折。

2.1 为什么Agent是端侧模型的放大器

Agent的本质是"感知-决策-执行"的循环。云端Agent的问题在于，它的感知依赖用户主动输入，决策依赖云端算力，执行依赖API调用。这三个环节每一个都有延迟、有损耗、有隐私风险。端侧Agent把这三个环节都拉到了本地：感知来自设备传感器和应用状态，决策来自本地模型推理，执行来自本地系统权限。

我举个实际例子。你在写一份报告，端侧Agent可以做到：检测到你打开了文档应用（感知），判断你正在写的是季度总结（决策），自动把上季度的数据文件调出来放在侧边（执行）。整个过程没有一次网络请求，没有一次数据上传。这种体验云端Agent给不了，因为它根本不知道你打开了什么应用。

2.2 端侧Agent的三个能力层级

我把端侧Agent的能力分成三层，这个分层是我自己在做项目时总结的，不一定严谨，但很好用：

大部分号称"端侧Agent"的产品停在L1，少数能做到L2，L3基本还在实验室阶段。北大系这家公司如果真想做"设备即环境"，目标显然是L3。但L3的难点不在模型，在于如何在不侵犯隐私的前提下，让Agent持续理解环境。这是一个产品设计问题，不是技术问题。

2.3 端侧Agent的并发问题比云端更棘手

热词里有个"ai agent 怎么扛并发"，这个问题在端侧其实更复杂。云端Agent的并发是请求级别的，加机器就能扛。端侧Agent的并发是任务级别的——同一个设备上，可能有多个Agent同时在跑：一个在监听通知，一个在处理语音输入，一个在后台整理文件。这些任务共享同一个模型实例、同一块内存、同一个电池。

我实测过一个方案：用任务优先级队列来调度端侧Agent。高优先级任务（比如用户主动发起的语音指令）抢占模型实例，低优先级任务（比如后台文件整理）排队等待。这个方案的问题在于，低优先级任务可能永远等不到执行机会。后来改成时间片轮转，每个任务分配固定的推理时间片，效果好了很多，但实时性又下降了。

端侧Agent的并发调度，本质上是在算力、电量、实时性三者之间做权衡。没有银弹，只有取舍。

3. 拆解端侧模型落地的四个硬骨头

聊完方向，得聊落地。端侧模型从论文到产品，中间隔着四道坎。这四道坎我在不同项目里都踩过，每一道都能让项目延期三个月。

3.1 模型压缩：不是越小越好，而是越合适越好

端侧模型的第一反应是"压缩"。量化、剪枝、蒸馏，三板斧下去，模型是小了，但能力也掉了。我见过太多团队为了把模型塞进设备，把量化做到4bit甚至2bit，结果模型连基本的指令遵循都做不到。

我的经验是：先确定任务边界，再选压缩策略。如果你的端侧Agent只做意图识别和槽位填充，那模型可以压得很狠；如果要做多轮对话和工具调用，那压缩就得保守。具体来说：

• 意图分类任务：4bit量化通常够用，模型可以压到1B以下
• 单轮问答：8bit量化比较稳，模型在3B左右
• 多轮对话+工具调用：建议保持FP16或8bit，模型至少7B

这个对应关系不是绝对的，但可以作为一个起点。关键是不要为了压缩而压缩，要先明确模型要干什么，再决定压到什么程度。

3.2 内存管理：端侧最容易被低估的瓶颈

云端推理，内存不够加内存。端侧推理，内存是焊死的。我做过一个统计，在端侧跑7B模型，光是模型权重就要占14GB（FP16），加上KV Cache和运行时开销，20GB起步。而大部分手机的可用内存也就8-12GB。

所以端侧模型的内存管理，核心是KV Cache的优化。KV Cache是Transformer推理时缓存的历史键值对，对话越长，缓存越大。优化手段有几个：

• 滑动窗口：只保留最近N轮对话的KV Cache，超出部分丢弃。简单有效，但会丢失长期记忆。
• KV Cache量化：把缓存也做量化，8bit通常不影响效果，4bit会有明显下降。
• 分页管理：借鉴操作系统的虚拟内存思路，把不常用的KV Cache换出到存储，需要时再换入。

我实测下来，滑动窗口+8bit量化是最实用的组合，能把7B模型的内存占用压到10GB以内，基本能跑在高端手机上。

3.3 功耗控制：用户不会为了AI牺牲续航

端侧模型跑起来，功耗是绕不开的。我测过，手机NPU满负荷跑7B模型，功耗在5-8W，相当于玩游戏的水平。如果Agent在后台持续运行，续航直接崩。

功耗优化的思路有两个方向。一是任务调度，把推理任务集中在设备充电时或高性能模式下执行，平时只做轻量级的感知和缓存。二是模型分级，用一个小模型做常驻感知，检测到需要复杂推理时再唤起大模型。这个思路类似CPU的大小核架构，小核常驻，大核按需唤醒。

我见过一个团队的做法很聪明：他们把端侧Agent的"感知"和"决策"拆开，感知用规则引擎做，几乎不耗电；决策才调用模型，而且只在特定触发条件下调用。这样平均功耗降到了1W以下。

3.4 隐私边界：端侧不等于绝对安全

很多人觉得数据不出设备就安全了，这个想法太天真。端侧模型本身可能成为隐私泄露的渠道。比如，模型可能被诱导输出训练数据中的敏感信息；Agent的日志可能记录用户行为；模型更新时可能上传数据。

端侧隐私保护要做三件事：输入过滤、输出审查、日志脱敏。输入过滤是防止恶意prompt注入；输出审查是防止模型泄露敏感信息；日志脱敏是确保调试信息不包含用户数据。这三件事听起来简单，但做起来很琐碎，而且很容易在迭代中被忽略。

4. 一个端侧Agent项目的完整搭建思路

前面聊的都是判断和原理，这一节聊点能直接上手的东西。我以一个"本地文件智能整理Agent"为例，把端侧Agent的搭建流程走一遍。这个例子足够具体，又不会太复杂，适合作为第一个端侧Agent项目。

4.1 需求定义：先想清楚Agent要解决什么问题

本地文件整理这个需求，看起来简单，其实可以拆成好几个层次：

• L1：根据文件类型自动分类（图片、文档、视频）
• L2：根据文件内容自动命名和打标签
• L3：根据用户习惯自动归档和清理

我建议从L1开始做，跑通了再往上加。原因很简单：L1不依赖模型，用规则就能做，可以先把工程框架搭起来。L2开始需要模型，但任务边界清晰，容易评估。L3最复杂，涉及用户习惯学习，容易做成四不像。

4.2 技术选型：模型、框架、运行时

模型选型上，我推荐从3B级别的模型起步。这个规模的模型在意图识别和简单生成上够用，内存占用可控，推理速度也能接受。具体选哪个，取决于你的设备平台：

框架选型上，我建议用现成的推理框架，不要自己造轮子。llama.cpp在PC端很成熟，MNN在移动端生态好，ONNX Runtime跨平台支持好。选一个社区活跃的，遇到问题能搜到答案。

4.3 感知层实现：Agent怎么知道发生了什么

感知层是端侧Agent和云端Agent最大的区别。云端Agent的感知靠用户输入，端侧Agent的感知靠系统事件。以文件整理Agent为例，它需要感知的事件包括：

• 文件创建、修改、删除
• 应用打开、关闭、切换
• 用户操作（点击、输入、拖拽）
• 设备状态（时间、位置、网络、电量）

这些事件通过系统API获取，然后经过过滤和聚合，形成Agent的"环境上下文"。这里有个关键设计：上下文不是越多越好，而是要分层。我通常分成三层：

• 即时上下文：最近几秒的事件，用于响应式决策
• 会话上下文：最近几分钟的事件，用于理解当前任务
• 长期上下文：历史统计和用户画像，用于个性化决策

三层上下文的更新频率和存储方式都不一样，即时上下文放内存，会话上下文放本地数据库，长期上下文做聚合存储。

4.4 决策层实现：模型怎么用上下文做判断

决策层的核心是prompt工程。端侧模型的prompt和云端不一样，因为端侧模型的指令遵循能力通常弱一些，prompt要更直接、更结构化。

我常用的端侧prompt模板是这样的：

[系统指令] 你是一个文件整理助手。根据以下上下文，判断是否需要执行操作。 可用操作：分类、重命名、归档、删除、无操作。 输出格式：{"action": "操作名", "target": "文件路径", "reason": "原因"} [环境上下文] 当前时间：2024-01-15 14:30 最近事件： - 14:28 创建文件 /Downloads/报告_v3.docx - 14:29 修改文件 /Downloads/报告_v3.docx - 14:30 切换到浏览器 [用户习惯] - 用户通常将报告类文件归档到 /Documents/Reports/ - 用户习惯在文件修改后5分钟内归档 [输出]

这个模板的关键是输出结构化。端侧模型容易跑偏，结构化输出能约束它的行为。另外，把用户习惯作为上下文传入，能让决策更个性化。

4.5 执行层实现：操作怎么落地

执行层相对简单，就是调用系统API执行操作。但有几个坑要注意：

• 权限管理：文件操作需要权限，要提前申请，并且做好权限被拒绝的降级处理
• 操作确认：删除类操作建议二次确认，或者先移到回收站
• 失败回滚：操作失败要有回滚机制，避免文件丢失
• 操作日志：记录操作历史，方便用户追溯和撤销

我踩过的一个坑是：Agent在后台自动整理文件，用户不知情，结果把用户正在编辑的文件移走了。后来加了"文件被占用时跳过"的判断，问题才解决。

5. 端侧模型和云端模型的分工，不是替代而是互补

聊端侧模型，很容易陷入"端侧取代云端"的叙事。我的判断是：端侧和云端不是替代关系，而是分工关系。搞清楚这个分工，比争论谁更强有意义得多。

5.1 什么任务适合端侧，什么任务适合云端

我总结了一个简单的判断标准：

按这个标准，端侧适合做感知、过滤、预处理、简单决策，云端适合做复杂推理、知识问答、内容生成。两者结合的方式是：端侧做第一道处理，把需要云端处理的部分脱敏后上传，云端返回结果，端侧再做后处理。

5.2 端云协同的三种模式

我见过三种端云协同模式，各有适用场景：

模式一：端侧优先，云端兜底。端侧模型先处理，置信度低时再调云端。这个模式适合对延迟敏感的场景，比如语音助手。缺点是端侧模型能力有限，兜底频率可能很高。

模式二：云端优先，端侧缓存。云端处理，结果缓存在端侧，下次遇到类似请求直接返回缓存。这个模式适合重复性高的场景，比如FAQ问答。缺点是首次响应慢，且缓存命中率依赖场景。

模式三：端云并行，结果融合。端侧和云端同时处理，结果做融合。这个模式适合对质量要求高的场景，比如内容生成。缺点是成本高，且融合逻辑复杂。

我实际项目中用得最多的是模式一，因为它在延迟和成本之间平衡得最好。模式二适合客服类场景，模式三我还没见过真正跑通的案例。

5.3 端侧模型的更新策略

端侧模型不是一次部署就完事，需要持续更新。更新策略有三个选择：

• 全量更新：直接替换模型文件。简单，但下载量大，用户体验差。
• 增量更新：只更新变化的参数。下载量小，但需要差分算法支持。
• 热更新：模型分片加载，按需更新。体验最好，但工程复杂度高。

我建议从全量更新开始，配合后台下载和静默替换。等用户量上来了，再考虑增量更新。热更新除非有强需求，否则不建议碰，坑太多。

6. 踩过的坑和实测有效的经验

这一节聊点实在的。下面这些经验都是我在实际项目中踩坑踩出来的，文档里不会写，但每一个都能帮你省下几周时间。

6.1 模型量化后效果下降，先别急着换模型

模型量化后效果下降，第一反应往往是"量化太狠了，换个模型"。但我的经验是，先检查量化校准集。量化不是简单的数值截断，而是需要校准集来确定量化参数。如果校准集和实际使用场景不匹配，量化效果就会很差。

我遇到过一个案例：模型在通用校准集上量化后，意图识别准确率从95%掉到70%。后来换成业务场景的校准集，准确率恢复到92%。所以量化前，一定要准备和实际场景匹配的校准数据，哪怕只有几百条。

6.2 端侧推理速度慢，先看是不是内存带宽瓶颈

端侧推理慢，很多人第一反应是算力不够。但实际上，内存带宽往往是更大的瓶颈。模型推理需要频繁读写内存，如果内存带宽不够，算力再强也发挥不出来。

判断方法很简单：用性能分析工具看推理过程中的内存带宽利用率。如果带宽利用率接近100%，那就是带宽瓶颈，换更强的NPU也没用，得从模型结构上优化，比如减少内存访问次数、用更紧凑的数据格式。

6.3 Agent行为不可控，加约束比调prompt有效

端侧Agent行为不可控，比如该分类的时候去删除，该沉默的时候乱说话。调prompt能解决一部分问题，但更有效的方法是加硬约束。

硬约束包括：操作白名单、参数校验、频率限制、二次确认。比如删除操作，不管模型怎么输出，执行层都强制走二次确认。这样即使模型跑偏，也不会造成严重后果。

我的原则是：模型负责判断，规则负责兜底。不要指望模型100%可靠，要用工程手段把不可靠的后果限制在可接受范围内。

6.4 端侧Agent的测试比云端难十倍

云端Agent的测试可以自动化，端侧Agent的测试很难自动化，因为环境太复杂。不同设备、不同系统版本、不同使用习惯，都会影响Agent行为。

我的做法是：建一个场景库，人工跑回归。场景库包含典型使用场景和边界场景，每次模型或规则更新，都人工跑一遍。这个做法很笨，但很有效。自动化测试只能覆盖30%的场景，剩下70%得靠人工。

端侧Agent的测试，本质上是在测试"环境理解能力"，而环境是测不完的。所以测试策略应该是"覆盖典型场景+监控线上异常"，而不是追求100%覆盖。

6.5 用户不信任Agent，从"可解释"和"可撤销"入手

端侧Agent最大的障碍不是技术，是信任。用户不信任一个在后台自动操作文件的Agent，这很正常。建立信任的方法有两个：可解释和可撤销。

可解释是指Agent每次操作都给出理由，比如"我把这份报告归档到Reports文件夹，因为你上次也是这么做的"。可撤销是指用户能一键撤销Agent的操作，而且撤销要彻底，不能有残留。

我实测下来，加了可解释和可撤销之后，用户对Agent的接受度明显提升。这两个功能技术上不难，但很多团队不做，因为他们觉得"用户不需要知道细节"。这个想法是错的，用户需要知道细节，尤其是在Agent犯错的时候。

7. 端侧模型的未来，取决于三个问题的答案

聊到最后，我想把视角拉高一点。端侧模型能不能成为未来，不取决于技术多先进，而取决于三个问题能不能回答好。

第一个问题：端侧模型的能力边界在哪里？现在大家都在试探，有人觉得3B够用，有人觉得要7B，有人觉得要13B。这个边界不是固定的，会随着模型架构和压缩技术的进步而变化。但有一点是确定的：端侧模型不可能在所有任务上追平云端模型，它必须找到自己的生态位。

第二个问题：端侧Agent的商业模式是什么？云端模型按token收费，商业模式清晰。端侧模型跑在用户设备上，怎么收费？卖模型？卖服务？卖硬件？这个问题现在没有答案，但必须有答案，否则端侧模型只能是巨头的游戏。

第三个问题：用户愿意为端侧AI付出多少？端侧AI消耗设备算力、电量、存储，这些都是用户成本。用户愿意为"数据不出设备"付出多少成本？愿意为"离线可用"付出多少成本？这个问题的答案，决定了端侧模型的市场规模。

我个人判断，端侧模型不会取代云端模型，但会吃掉云端模型的一部分场景——那些对隐私、实时性、离线可用性要求高的场景。这部分场景有多大，现在不好说，但肯定不小。北大系这家公司押注这个方向，赌的就是这部分场景会越来越大。

至于"设备即环境"这个提法，我觉得它更像是一个愿景，而不是一个技术路线。它描述的是端侧模型的终极形态：模型不再是设备上的一个应用，而是设备本身的一部分，像操作系统一样无处不在，又像空气一样感觉不到存在。这个愿景能不能实现，取决于上面三个问题能不能回答好。但至少，它指出了一个方向，一个和"堆参数、拼算力"不同的方向。