企业官网建设流程全解析

1. 端侧 Agent 到底在解决什么问题

先把话说直白一点：端侧 Agent 不是"把云端 Agent 塞进手机"这么简单。它要解决的是一个非常具体的矛盾——大模型的推理能力很强，但它的运行成本、延迟和隐私代价，在端侧场景下会被无限放大。

我最早接触这个概念是在做一个离线语音助手项目的时候。当时团队的第一反应是"直接调云端 API 不就行了"，结果一测就发现问题：地铁里没信号、工厂车间网络隔离、车载场景对延迟要求是毫秒级、用户对录音上传极度敏感。这些场景下，云端方案不是"不够好"，而是"根本不能用"。端侧 Agent 就是为这类场景准备的。

那它和普通的端侧模型推理有什么区别？区别在于Agent 这个词本身就意味着"自主决策 + 工具调用 + 多步执行"。一个端侧模型只做一次前向推理，那是"模型部署"；而端侧 Agent 要能在本地完成"理解意图 → 规划步骤 → 调用本地工具 → 观察结果 → 决定下一步"这个闭环。这就把问题从"模型能不能跑起来"升级成了"整个决策循环能不能在资源受限的设备上稳定跑起来"。

关键词里的ReAct（Reasoning + Acting）就是这个闭环的经典范式。它的核心思想是让模型交替输出"思考"和"行动"：先想清楚现在该干什么，再决定调用哪个工具，拿到结果后继续想。这个模式在云端已经很成熟了，但搬到端侧，每一步都要重新算账——因为端侧的算力、内存、电量都是硬约束。

所以这篇文章要讲的基础架构，本质上是回答三个问题：端侧 Agent 由哪几层组成、每层的核心职责是什么、层与层之间怎么协作才能既省资源又不丢能力。如果你正在做端侧 AI 硬件部署、Agent 开发，或者只是想知道"端侧 Agent 和云端 Agent 到底差在哪"，这篇应该能给你一个清晰的骨架。

2. 端侧 Agent 的四层基础架构拆解

2.1 为什么是四层而不是三层或五层

我见过不少端侧 Agent 的架构图，有的画得特别复杂，七八个模块互相连线；有的又过于简化，就一个"模型 + 工具"两块钱。实际落地下来，我认为四层是最稳的划分：感知与输入层、决策与推理层、工具与执行层、状态与记忆层。

为什么这么分？因为端侧的核心矛盾是"资源有限但任务开放"。如果层数太少，职责混在一起，优化的时候你根本不知道瓶颈在哪；如果层数太多，层间通信的开销又会吃掉本就紧张的算力。四层刚好对应四个可以独立优化的维度：输入怎么省、推理怎么快、执行怎么稳、记忆怎么小。

这四层不是简单的上下堆叠，而是决策层居中调度，其余三层围绕它服务。感知层把原始输入（语音、图像、文本、传感器数据）转成决策层能吃的格式；工具层提供决策层可以调用的本地能力；记忆层则负责在多次决策之间保持上下文。下面逐层拆。

2.2 感知与输入层：端侧的第一道成本关口

这一层最容易被低估。很多人觉得"输入不就是把用户说的话转成文字吗"，但在端侧，输入处理往往是整个链路里最耗电的环节之一。

以语音输入为例，云端方案通常是"录音上传 → 云端 ASR → 文本返回"，端侧方案则必须在本地完成唤醒词检测、语音活动检测（VAD）、以及本地 ASR。这里有个关键设计点：不是所有输入都需要唤醒决策层。唤醒词检测应该是一个极轻量的常驻模型（通常几百 KB 到几 MB），只有它触发了，才启动更重的 ASR 和决策流程。这个"分级唤醒"的设计，直接决定了设备待机时的功耗水平。

图像输入也是同理。端侧 Agent 如果每帧都跑一遍视觉模型，电池撑不过半小时。常见做法是事件驱动：只有当传感器或轻量检测器发现"画面有变化"时，才触发一次完整的视觉理解。我在一个智能家居项目里就用过这个思路，把摄像头从"持续推理"改成"运动触发推理"，功耗直接降了一个数量级。

注意：感知层的输出格式要提前和决策层约定好。我踩过的坑是 ASR 输出带标点、视觉输出不带标点，结果决策层的 prompt 模板要写两套，维护起来非常痛苦。统一成一种规范化的文本表示，能省掉后面大量适配工作。

2.3 决策与推理层：ReAct 循环在端侧的真实形态

这是端侧 Agent 的心脏。云端 Agent 的 ReAct 循环可以很奢侈——每轮思考都调一次大模型，上下文塞满历史。端侧不行，必须做减法。

端侧 ReAct 的典型形态是这样的：一个较小的本地 LLM 负责推理和规划，但它的输出被严格约束成结构化格式。比如要求模型输出 JSON，包含thought（当前思考）、action（要调用的工具名）、action_input（工具参数）三个字段。这样做的好处是解析稳定，不会因为模型自由发挥导致后续流程崩溃。

这里有个非常关键的工程决策：端侧 Agent 的推理轮数必须设上限。云端可以容忍模型想十轮，端侧想十轮可能就把电量耗光了。我的经验是设 3 到 5 轮，超过就强制返回当前最优结果或提示用户。这个上限不是拍脑袋定的，而是根据单轮推理耗时 × 可接受总延迟算出来的。比如单轮推理 800ms，用户能接受的总等待是 4 秒，那上限就是 5 轮。

另一个重点是工具选择的约束。端侧可用的工具是有限的、预先注册的，所以完全可以在 prompt 里把工具列表写死，甚至用更轻量的方式——比如先用一个小的分类模型判断"这次该用哪类工具"，再让 LLM 只负责填参数。这种"分类 + 填参"的拆分，比让 LLM 从头选工具要稳得多，也快得多。

2.4 工具与执行层：本地能力的注册与隔离

工具层是端侧 Agent 真正"能做事"的地方。它把设备本地的能力——比如设置闹钟、查询本地数据库、控制硬件、读取文件——包装成决策层可以调用的标准化接口。

这里最重要的设计原则是工具必须沙箱化。端侧 Agent 调用的工具直接操作设备资源，一旦模型输出异常参数，可能造成真实损害（比如误删文件、误发消息）。所以每个工具在执行前都要做参数校验，执行时要有超时和权限控制。

工具注册我推荐用声明式的方式，每个工具用一段结构化描述定义：

{ "name": "set_alarm", "description": "设置一个本地闹钟", "parameters": { "time": {"type": "string", "description": "HH:MM 格式"}, "label": {"type": "string", "description": "闹钟标签"} }, "timeout_ms": 2000 }

这段描述会直接进 prompt，所以描述要写得让模型一看就懂。我见过有人把 description 写成"调用系统 API 设置 alarm"，模型根本不知道参数该填什么。描述要用人话，站在模型的角度写。

2.5 状态与记忆层：端侧最需要克制的部分

记忆层是端侧 Agent 和云端 Agent 差异最大的地方。云端可以存全量对话历史，端侧不行——存储空间和上下文窗口都有限。

端侧记忆通常分三级：短期记忆（当前任务的几轮对话，存在内存里）、中期记忆（最近的任务摘要，存在本地轻量数据库）、长期记忆（用户偏好、常用工具等结构化信息）。关键在于，不是所有信息都值得存。我的做法是只存"决策相关"的信息：用户明确表达的偏好、上次任务的结论、工具调用的成功/失败记录。闲聊内容一律不存。

还有一个容易被忽略的点：记忆的写入也要走决策层。不是每轮对话都自动写记忆，而是让模型判断"这条信息未来可能有用吗"，有用才写。这个判断本身也消耗推理，所以通常只在任务结束时做一次总结性写入，而不是每轮都写。

3. 四层之间怎么协作：一次完整请求的生命周期

3.1 从唤醒到响应的完整链路

光看分层还不够，得看它们怎么串起来。我拿一个具体场景走一遍：用户说"帮我看看明天天气，如果下雨就提醒我带伞"。

第一步，感知层收到语音，唤醒词触发，本地 ASR 转成文本"帮我看看明天天气，如果下雨就提醒我带伞"。第二步，决策层拿到文本，进入 ReAct 循环。第一轮思考：需要先查天气，输出action: get_weather, action_input: {date: "明天"}。第三步，工具层执行get_weather，返回"明天中雨"。第四步，决策层第二轮思考：天气有雨，需要设置提醒，输出action: set_reminder, action_input: {content: "带伞", time: "明早"}。第五步，工具层执行提醒设置，返回成功。第六步，决策层生成最终回复"明天有雨，已帮你设置带伞提醒"。第七步，记忆层写入"用户关注天气与出行提醒"。

这个链路里，决策层被调用了两次，工具层被调用了两次，感知层和记忆层各一次。整个过程的资源消耗是可以预估的，这也是分层带来的好处——每一层的耗时和功耗都能单独测量和优化。

3.2 层间通信的格式约定

层与层之间传什么格式，是个看似小但影响很大的决策。我的建议是统一用结构化文本（JSON）作为层间通信格式，原因有三：一是 LLM 天然擅长处理文本；二是 JSON 可读性强，调试方便；三是序列化开销小，端侧扛得住。

但要注意，不是所有层都需要 JSON。感知层到决策层，如果只是纯文本输入，直接传字符串就行，没必要包一层 JSON。工具层返回的结果，如果是简单值（比如一个数字），也可以直接传。过度结构化反而增加解析负担。原则是：需要携带多个字段或需要被模型理解时用 JSON，单一值直接传。

3.3 异常在层间的传播与处理

端侧环境不稳定，异常处理必须设计清楚。我的经验是异常在产生它的那一层就地处理，不要往上抛。比如工具执行超时，工具层应该返回一个结构化的失败结果{status: "timeout", message: "..."}，而不是抛异常中断整个流程。决策层拿到这个失败结果，可以决定重试、换工具、或者告诉用户"这个操作没成功"。

这样做的好处是决策层始终能拿到一个可理解的结果，ReAct 循环不会因为一个工具失败就整个崩掉。我早期的一个版本就是工具抛异常直接中断，结果用户说"设个闹钟"，闹钟服务刚好没起来，整个 Agent 就卡死了，体验极差。改成返回失败结果后，模型会自己说"闹钟设置失败了，你可以手动设置一下"，反而更自然。

4. 端侧 Agent 架构里的几个硬核取舍

4.1 模型大小与能力的平衡点在哪

这是每个做端侧 Agent 的人都要面对的问题。模型越大能力越强，但端侧跑不动。我的实测经验是：对于工具调用类的 Agent 任务，1B 到 3B 参数的模型在量化后已经能覆盖大部分场景，前提是 prompt 设计得当、工具描述清晰。

再大不是不行，但收益递减明显。我对比过 1.5B 和 7B 在同一个工具调用任务上的表现，7B 的准确率大概高 8 到 10 个百分点，但推理耗时是 1.5B 的 4 倍以上。在端侧，这个交换比通常不划算。除非你的场景对推理质量要求极高（比如涉及复杂多步规划），否则优先选小模型 + 好的工程约束，而不是硬上大模型。

量化方面，4-bit 量化基本是端侧标配，能在几乎不损失工具调用准确率的前提下把内存占用降到 1/4。再往下到 3-bit 或 2-bit，准确率下降会开始明显，需要谨慎评估。

4.2 上下文窗口怎么用才不浪费

端侧模型的上下文窗口通常不大（2K 到 8K token 常见）。ReAct 循环每轮都会往上下文里加内容，很容易就撑满了。我的做法是只保留最近 N 轮的完整思考-行动-观察三元组，更早的轮次压缩成一句摘要。

具体来说，如果设 N=3，那么上下文里保留最近 3 轮的完整记录，第 4 轮之前的全部压成"之前已经查过天气，结果是中雨"这样一句话。这样既保留了关键信息，又不会让上下文无限膨胀。这个压缩动作本身可以用一个很小的模型或者规则来做，不一定非要调主模型。

提示：工具返回的结果如果很长（比如查询返回一大段文本），在放进上下文之前要先截断或摘要。我见过工具返回 2000 字，直接把上下文撑爆的情况。工具层应该负责把结果压缩成决策层能用的精简形式。

4.3 并发场景下端侧 Agent 怎么扛

热词里有人问"ai agent 怎么扛并发"，端侧场景下这个问题更尖锐，因为端侧资源本来就少。我的答案是：端侧 Agent 通常不做真并发，而是做任务队列。

原因很简单，端侧只有一个推理引擎，多个任务同时进来只会互相抢资源，导致每个都变慢。正确做法是维护一个优先级队列，任务按优先级串行处理。高优先级任务（比如用户直接指令）插队，低优先级任务（比如后台整理记忆）排队。这样虽然吞吐量不高，但每个任务的延迟是可预期的，体验反而更稳。

如果确实需要"并发"的错觉，可以在感知层做并行——比如语音和视觉同时采集，但决策层始终串行。这个边界要划清楚，不然资源调度会失控。

5. 落地时最容易踩的几个坑

5.1 工具描述写得太"技术"，模型看不懂

这是我见过最高频的问题。工程师习惯用技术语言写工具描述，比如"调用系统 API 获取当前网络状态"。模型看到这种描述，根本不知道什么时候该用它、参数怎么填。正确的写法是站在用户意图的角度："当用户询问网络是否连接、网速如何时使用此工具，无需参数"。

工具描述的质量直接决定 Agent 的工具选择准确率。我做过一个对比实验，同一批工具，描述优化前后，模型的工具选择准确率从 62% 提升到了 89%。这个提升幅度比换更大的模型还明显。

5.2 忘了给推理轮数设上限

前面提过，但值得再强调。没有轮数上限的 ReAct 循环在端侧是灾难。模型可能陷入"思考-调用-再思考"的死循环，尤其是当工具反复返回相似结果时。必须设硬上限，并且在上限触发时有一个优雅的兜底回复，而不是直接报错。

5.3 记忆写入过于频繁

每轮对话都写记忆，会导致存储快速膨胀，而且写入本身也消耗资源。我的做法是只在任务边界写记忆——一个完整任务结束后，总结性地写入一条。任务进行中的临时状态放在内存里，不落盘。

5.4 忽略了冷启动时间

端侧 Agent 的模型加载需要时间，尤其是从存储加载到内存。如果每次唤醒都重新加载模型，用户体验会很差。常见做法是常驻一个轻量模型用于唤醒和简单任务，重量模型按需加载并保持一段时间。这个"保持时间"要根据内存压力和用户使用频率来调，没有万能值。

6. 我对端侧 Agent 架构的一点个人判断

做了几个端侧 Agent 项目之后，我越来越觉得端侧 Agent 的竞争力不在模型本身，而在架构的工程约束。同样的 1.5B 模型，架构设计得好，能稳定完成工具调用和多步任务；架构设计得差，连基本的意图理解都做不好。

四层架构的价值就在于它把"哪些事该在哪一层做"这个问题回答清楚了。感知层负责省，决策层负责想，工具层负责做，记忆层负责记。每层各司其职，优化的时候才有抓手。我见过太多项目把所有这些混在一个大函数里，最后既没法优化也没法调试。

如果你刚开始做端侧 Agent，我的建议是先把四层的边界划清楚，哪怕每层一开始都很简陋。边界清晰比功能完整重要得多。等功能跑通了，再逐层优化——先优化感知层的功耗，再优化决策层的延迟，最后优化记忆层的存储。这个顺序是我踩过坑之后总结出来的，反过来做会非常痛苦。

端侧 Agent 这个方向还在快速演进，基础架构也会不断调整。但"分层解耦、职责清晰、资源可控"这三个原则，我认为在很长一段时间内都不会过时。