子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）
大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向： 前端 / 跨端 / 小程序 / 移动端工程化 内容平台： 掘金、知乎、CSDN、简书 创作特点： 实战导向、源码拆解、少空谈多落地 **文章状态：**长期稳定更新，大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在"API 怎么用"，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学"明白"，也用"到位"
持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
-
- 引言
- [一、问题本质：端侧 AI 的三大约束](#一、问题本质：端侧 AI 的三大约束)
- [二、OpenClaw 的启发：低算力 ≠ 低智能](#二、OpenClaw 的启发：低算力 ≠ 低智能)
- [三、端侧 AI 的分层架构](#三、端侧 AI 的分层架构)
- 四、关键设计一：小模型只做"理解"
- 五、关键设计二：规则系统承担"智能"
- 六、关键设计三：状态机驱动行为
-
- [FSM 示例](#FSM 示例)
- [在端侧 AI 中的应用](#在端侧 AI 中的应用)
- 优势
- 七、关键设计四：时间分片执行
- 八、关键设计五：事件驱动，而不是轮询
-
- [端侧 AI 同样适用](#端侧 AI 同样适用)
- 优势
- [九、关键设计六：分层执行（Edge + Cloud）](#九、关键设计六：分层执行（Edge + Cloud）)
- 十、关键设计七：可控优先，而不是智能优先
- 十一、一个完整架构示例
- [十二、为什么 OpenClaw 是最佳参考](#十二、为什么 OpenClaw 是最佳参考)
- 总结
引言
过去几年，AI 的发展路径几乎是：
更大的模型
更多的参数
更强的算力但现实世界正在发生一个反向趋势：
AI 正在从"云端"，走向"端侧"。
手机、IoT、嵌入式设备，甚至离线系统，都开始需要：
本地推理
实时响应
低延迟
隐私保护问题来了：
在没有 GPU、算力受限的情况下，怎么做"智能体"？
这时候，如果你重新看 OpenClaw 你会发现：
它早就给出了答案。
一、问题本质：端侧 AI 的三大约束
在端侧（Device-side），系统天然受限：
1、算力有限
CPU 为主
无 GPU / 弱 GPU
无法跑大模型2、内存有限
几十 MB ~ 几百 MB
模型必须极小3、实时性要求高
毫秒级响应
不能卡顿
不能阻塞 UI核心矛盾
想要"智能"，但不能"重计算"。
二、OpenClaw 的启发：低算力 ≠ 低智能
在 Claw 中：
没有大模型
没有推理系统
没有高算力但它依然实现了：
复杂行为
动态世界
多 Agent 系统关键结论
智能不等于模型，而是系统设计。
三、端侧 AI 的分层架构
我们可以从 OpenClaw 抽象出一个适用于端侧 AI 的架构：
┌──────────────┐
│ 轻量模型层 │（Small Model）
├──────────────┤
│ 规则系统层 │（Rules / FSM）
├──────────────┤
│ 行为执行层 │（Action）
├──────────────┤
│ 环境感知层 │（Perception）
└──────────────┘核心思想
用"小模型 + 强规则"，替代"大模型 + 强算力"。
四、关键设计一：小模型只做"理解"
在端侧，模型的职责必须收敛：
错误方式
模型负责：
理解 + 推理 + 决策 + 执行正确方式
模型只负责：
意图识别（Intent）示例
json
输入： "帮我创建3个敌人"
输出：
{
"intent": "spawn_enemy",
"count": 3
}优势
模型小（可量化）
推理快
成本低五、关键设计二：规则系统承担"智能"
真正的"决策"，交给规则系统：
示例
ts
if (scene === "battle" && count > 5) {
count = 5;
}为什么？
规则：
确定性强
可控
低成本本质
用规则代替推理。
六、关键设计三：状态机驱动行为
延续 OpenClaw 的思路：
FSM 示例
ts
state = "idle";
if (seeUser) state = "respond";
if (error) state = "recover";在端侧 AI 中的应用
idle → listening → processing → acting优势
无需复杂推理
逻辑清晰
可调试七、关键设计四：时间分片执行
端侧必须避免"卡顿"。
示例
ts
if (frame % 5 === 0) {
runHeavyTask();
}应用场景
模型推理降频
AI 决策分帧执行
后台任务延迟处理本质
用时间换性能。
八、关键设计五：事件驱动，而不是轮询
OpenClaw 的核心是：
Trigger → Action端侧 AI 同样适用
用户点击 → 触发 AI
语音输入 → 触发识别
传感器变化 → 触发行为优势
减少无效计算
节省资源
响应更快九、关键设计六：分层执行（Edge + Cloud）
端侧不等于"全部在本地"。
推荐架构
端侧：
- 快速响应
- 简单决策
云端：
- 复杂推理
- 长期规划示例
本地：识别指令
云端：生成复杂策略
本地：执行本质
把算力"分布化"。
十、关键设计七：可控优先，而不是智能优先
端侧 AI 最大的风险是：
不可控行为
资源失控
系统崩溃所以必须：
限制执行范围
限制资源使用
限制行为复杂度对应机制
Guardrails
Policy Engine十一、一个完整架构示例
我们把所有设计组合起来：
流程
用户输入
↓
小模型（Intent）
↓
Policy Engine（策略）
↓
Guardrails（约束）
↓
Action Gateway（执行）
↓
端侧系统（OpenClaw-like）特点
轻量
可控
实时
可扩展十二、为什么 OpenClaw 是最佳参考
在 OpenClaw中，你可以直接看到：
低算力系统
多 Agent 运行
规则驱动世界
高性能实时系统这些特性，和端侧 AI 完全一致。
总结
从 OpenClaw 到端侧 AI，我们可以总结出一套通用架构：
小模型负责理解
规则系统负责决策
状态机驱动行为
时间分片优化性能
事件驱动减少计算
端云协同提升能力端侧 AI 的核心，不是"让模型更强"，而是"让系统更聪明"。