如果你最近在关注端侧 AI，大概率听说过那套被圈内俗称“大龙虾”的开源 Agent 框架——功能真叫一个全：意图识别、任务规划、工具调用、记忆管理、云端模型网关，几乎把 Agent 全家桶都塞进了一个进程，钳子够大、壳也够厚。前阵子我拿到一台 6.0 大版本的国产移动系统测试机，一上来就想把“大龙虾”整套部署上去，实现完全本地化运行。
结果比预想的惨烈得多：应用刚初始化到一半，系统直接弹内存不足，五分钟内被杀了三轮。之后我把思路从“硬塞部署”转向“拆壳重构”，花了大概三周，把大龙虾的核心逻辑拆出来重新设计，最终落地成一个只有原来体积四分之一、能稳定常驻后台的轻量版 Agent——我给它取名 NanoClaw。这篇文章就是完整的过程记录，包括资源账、架构取舍、系统适配、实测数据和踩坑记录，适合正在做端侧 Agent 落地、或者打算把云端 Agent 搬到移动端的开发者参考。
1. “大龙虾”为什么死在移动端：先算清这笔资源账
1.1 大龙虾的架构底色
先说清楚大龙虾原本的设计前提。这套框架诞生的时候，目标场景是服务器、开发机或者高性能笔记本，设计假设是“内存不设上限、网络随时在线、后台调度由我掌控”。所以它的架构天然向着“大而全”走：
- Runtime 核心只负责意图识别和状态流转，真正的能力全部外置成工具插件。
- 工具层预置了几十个模块，从天气查询、网页抓取、日历日程到文件处理，应有尽有。
- 模型层默认走云端 API 网关，也就是所有推理请求都要发到远端大模型。
- 插件机制是动态加载的，运行时通过反射扫描工具类，再用依赖注入容器装配。
这套设计在服务器上没毛病，有问题的是，它把所有“资源无限”的假设都带到了移动端。手机不是一台小型服务器，它是一个内存有限、后台随时会被回收、权限被沙箱限制、CPU 还要兼顾 UI 渲染的终端设备。两种环境的前提不一样，代码写得再优雅也跑不起来。
1.2 实测资源账：一测就原形毕露
我当时在一台中端测试机（8 核 CPU、12GB 内存、256GB 存储）上做了一次压测，记录大龙虾跑起来之后的资源占用。结果非常难看。
| 性能指标 | 大龙虾实测 | 移动端可接受参考线 |
|---|---|---|
| 应用安装体积 | 1.2GB | 300MB 以内 |
| 冷启动时间 | 11s | 3s 以内 |
| 初始化峰值内存 | 1.4GB | 600MB 以内 |
| 常驻内存 | 1.8GB | 700MB 以内 |
| 首响应时间（用户说第一句话到 Agent 回话） | 8s | 2s 以内 |
| 断网可用性 | 不可用 | 完全可用 |
这个表格出来之后我就明白了，不是“优化一点点”能解决的问题。常驻内存 1.8GB 在手机上意味着什么？意味着 App 一进后台，系统回收内存时第一个杀的就是它；意味着用户同时开着导航、听歌、聊天，系统会毫不犹豫地把你的 Agent 进程按下去。这已经不是调参能解决的，必须动架构。
1.3 真正压垮它的三根稻草
资源账只是表象，真正要命的是三个更深的设计冲突。
第一根稻草是动态加载机制。大龙虾的插件系统依赖运行时反射扫描和动态加载，在服务器上这没问题，但在移动系统里，应用包体积、APK 安装策略、运行时文件读取权限都受到限制。你很难在安装之后让 App 动态拉取一段代码再执行，更别说还涉及签名校验。整个插件体系在移动端就是水土不服。
第二根稻草是模型服务强耦合。大龙虾默认把推理请求发到云端 API，本地只做业务编排。为了实现“完全本地化”，我必须先把这条路径整个换掉，用一个能在手机上跑起来的本地推理引擎替代云端网关。这个替换不是改一个接口那么简单，它牵动提示词策略、上下文长度、响应协议、错误处理整个链路。
第三根稻草是工具层的“无限假设”。大龙虾的工具执行逻辑假设自己可以随意访问网络、文件系统、外部服务。但在移动端，网络权限要申请、文件目录被沙箱隔离、敏感能力需要用户确认，每一样都在给 Agent 的执行链路上加锁。工具层不重构，Agent 就是个半瘫状态。
所以结论很清楚：移动端跑这种重框架，不是“移植”而是“重写”。留下的是思想，丢掉的是躯壳。
2. 裁剪而不是硬塞：NanoClaw 的架构设计与取舍
2.1 保留的三件套：意图、工具、记忆
拆解大龙虾之后，我把整个框架的职责归纳成三件必须保留的核心：意图识别与任务规划、工具编排与执行、记忆与上下文管理。这三件事是一个 Agent 之所以为 Agent 的底线，缺了任何一个，剩下的都只是问答机器人或者自动化脚本。
- 意图识别与任务规划：负责理解用户说的话，拆解成可执行的步骤。
- 工具编排与执行：负责把“步骤”映射到具体的系统能力上，比如查日程、发通知、开关蓝牙。
- 记忆与上下文管理：负责跨轮对话保持一致性，让 Agent 记得用户五分钟前说过什么。
NanoClaw 围绕这三件事重新设计，但每一件都做了移动端适配。最核心的变化是把大龙虾擅长的那套“深度多轮规划”降级成“一次性规划 + 失败修正”。在服务器上，大模型可以反复推理、逐层拆解任务，但在手机上，每一次多余推理都要烧电、等时间、占内存。NanoClaw 的策略是：先用本地小模型做一次紧凑规划，如果执行中遇到参数缺失或者工具返回异常，再触发局部修正任务，而不是从头重新规划一遍。
2.2 丢掉的东西：云网关、插件体系、重量级记忆库
有保留就有舍弃。NanoClaw 明确丢掉了四样东西，每一样都是在移动端“得不偿失”的典型：
云端模型网关被本地推理接口替代，所有推理请求都走端侧模型，彻底摆脱网络依赖。大龙虾的动态插件体系被 6 个静态模块替代，换来的是安装包体积骤降和启动速度大幅提升。重量级向量记忆库被一个轻量级混合索引替代，后续我会单独展开讲。最后是贯穿全局的重量级事件总线，大龙虾用它做模块间通信，NanoClaw 把它换成了基于协程的轻量消息队列，开销降低了一个数量级。
这里最需要想清楚的是记忆方案。大龙虾用的向量数据库在服务器上是标配，但手机端的实际诉求只是：记住上一轮聊了什么、记住用户一些长期偏好、在合适的时候把相关记忆重新取出来。NanoClaw 的方案是 SQLite 做主存储，短期会话直接存结构化记录，长期记忆用关键词索引加轻量向量近似检索。这套组合在几十万条记忆的规模内表现足够好，内存开销比纯向量库低了差不多 80%。
2.3 模型层换血：从云端大模型到端侧量化小模型
模型层是整个重构里最关键的部分。大龙虾跟云端大模型对接，上下文窗口动辄几十 K，思考链可以写一大段。NanoClaw 用的是 1B 到 3B 参数的量化模型，推理在端侧完成。
量化我选了 4-bit，这是端侧部署里性价比最高的档位。对比下来，8-bit 模型质量最好但内存和算力要求偏高，手机运行起来发热明显；2-bit 体积最省但输出质量下滑得厉害，中文场景尤其明显。4-bit 属于“牺牲少量质量，换来能日常稳定运行”的甜蜜点。
模型小了，提示词策略必须跟着改。大龙虾给模型的系统提示词动辄三四千 token，描述里塞满各种工具的调用说明。NanoClaw 把系统提示词压到 800 token 以内，做法是“角色卡片 + 工具签名”。角色卡片用三行定义 Agent 的身份、能力和边界；工具签名则把每个工具的用途、参数、返回值浓缩成几行结构化描述。事实证明，小模型在上下文短、指令集中的情况下，表现远比“塞一堆内容然后指望它理解”要好。
2.4 工具调用协议瘦身：从动态反射到静态注册表
大龙虾的工具调用协议走的是“通用型”路线：框架不关心工具具体做什么，只负责把模型输出的 JSON 解析出来，再通过反射动态调用对应方法。这种方式灵活，但有三宗罪：解析复杂、运行时开销大、出错难排查。
NanoClaw 重新设计了工具调用协议，核心是静态注册表。每个工具在编译期注册自己的名称、参数类型、参数范围、返回格式，模型输出一个严格匹配的调用指令，框架直接查表执行，不做任何反射操作。
打个比方，大龙虾的方式是“你给我一个指令，我翻遍整栋楼的工具箱找到对应那件工具再递给你”，NanoClaw 是“所有工具都在前台柜台上贴着标签，你说名字我就递给你”。前者能处理没见过的工具，但代价是慢；后者快、稳、省电，代价是不支持动态扩展。对移动端来说，这个取舍非常划算。
举个例子。用户说“帮我看看明天上午有没有会”，NanoClaw 模型输出的是一个紧凑的工具调用指令，对应本地日程查询工具。框架收到后直接查表、调接口、拿结果、组织回答，全程不过两次本地推理，耗时能压在 1 秒上下。
3. 把 NanoClaw 落到 6.0 移动生态：系统适配的四个关键战场
3.1 后台常驻：前台服务加通知栏的保活组合
完全本地化的 Agent 有一个天然需求：它得活着，用户切走 App 之后它还得在后台继续响应。但在移动系统上，普通应用进程在后台待太久会被系统按内存回收策略杀掉，这不是 bug，是设计。
NanoClaw 的解法是前台服务加常驻通知栏。它启动后立刻绑定前台服务，在通知栏显示一个常驻卡片，告诉系统“这个应用正在为用户提供持续服务”，这样系统在内存回收时会把它放在优先级较高的区域。代价是通知栏里会常驻一条消息，但 6.0 大版本里通知卡片支持自定义折叠，我可以把状态信息、当前任务、快捷操作全部放在卡片里，让这条通知本身变成 Agent 的信息面板，用户不觉得碍眼，反而觉得有用。
这里要强调一个经验：千万不要去挖各种“黑科技保活”的歪路，什么双进程互相拉活、定时唤醒、隐藏图标，这些在 6.0 生态里全部行不通，还容易被系统标记为异常应用。老老实实做前台服务、做好状态展示，才是可持续发展的路线。
3.2 推理与 UI 的线程隔离：别让模型思考卡住手指滑动
端侧推理是 CPU 密集任务，如果你让模型在 UI 主线程里跑，用户会体验到什么？触摸了屏幕，它等半天才有反应，这是移动开发里最不能容忍的事故类型。
NanoClaw 的处理是把推理放到独立的专用线程，并设置线程优先级低于 UI 渲染线程。在 6.0 生态里，线程调度还可以配合系统提供的性能模式调整，让推理线程在 Agent 处于活跃对话状态时提升优先级，在用户正在滑动界面时把资源让给渲染管线。
实现上我加了一个简单但有效的机制：UI 交互检测。当系统检测到用户的触摸事件时，NanoClaw 会暂时降低推理线程的占空比，甚至暂停当前正在执行的生成步骤，等界面操作结束再继续。实测下来，对话流畅度和 UI 滑动流畅度都保住了，代价只是每轮回答偶尔多几百毫秒，完全值得。
3.3 系统能力桥接：最小权限与能力发现
一个本地 Agent 要发挥真正价值，必须能调用系统能力：查日程、发通知、控制勿扰模式、读取剪贴板等等。这一步的关键不是“怎么实现”，而是“权限怎么管理”。
NanoClaw 没有一开始就把所有权限拉满。它设计了一个分层的系统能力框架：基础能力无需敏感权限，比如读取应用内数据、展示通知卡片；标准能力需要普通权限，比如网络状态、存储读取，这部分在用户首次启用时一次申请；敏感能力则采用按需动态申请，比如访问通讯录、定位、读取剪贴板，用户不明确授权，Agent 就不能碰。
这个分层设计的实际收益是：安装后首次启动，NanoClaw 只申请两三个基础权限，用户不会被权限弹窗吓跑；等到真正用到敏感能力时，再以具体任务为上下文弹出授权请求，用户理解度高，同意率也高。
3.4 冷启动与功耗策略：别让 Agent 变成电老虎
本地 Agent 的功耗是一个容易被低估的问题。手机电池本来就是寸土寸金，如果 Agent 在后台一直保持推理线程活跃，用户可能会发现手机掉电速度肉眼可见地加快，然后果断卸载你的应用。
NanoClaw 的冷启动做了分段加载：先把轻量 UI 拉起来，让用户感觉“应用已经打开”，然后异步加载本地模型。模型加载完成之前，Agent 处于“降级模式”，只能用简单规则响应通用指令，比如打开某个功能、查看版本信息。等模型就绪，再切换成完整模式。这套方案把用户感知的启动时间从 5 秒左右压到了 1 秒以内。
功耗方面，NanoClaw 会在推理任务结束后立即释放模型占用的计算资源，只保留轻量监听组件。系统进入低电量模式时，Agent 会自动关闭本地大模型服务，降级为纯规则引擎，只执行用户明确设置的自动化任务，保证关键时刻不添乱。
4. 实测数据与三个让我失眠的坑
4.1 基准测试：NanoClaw 与大龙虾的最终对比
在同样的测试机上，重构完成后的 NanoClaw 与大龙虾的对比数据如下。
| 性能指标 | 大龙虾（重构前） | NanoClaw（重构后） |
|---|---|---|
| 应用安装体积 | 1.2GB | 280MB |
| 冷启动时间 | 11s | 0.9s（UI） / 4s（完整模式） |
| 初始化峰值内存 | 1.4GB | 480MB |
| 常驻内存 | 1.8GB | 620MB |
| 首响应时间 | 8s | 1.2s（本地模型） |
| 断网可用性 | 不可用 | 完全可用 |
| 连续对话 30 分钟功耗 | 无法测试（已崩溃） | 7% 电量 |
安装体积差了四倍多，内存占用差了接近三倍，首响应时间从 8 秒压到 1.2 秒，而且全程不依赖网络。这不是优化出来的，是重构成了另一个东西才得到的。
4.2 坑一：进程被杀到怀疑人生
第一版 NanoClaw 跑起来之后，我遭遇了最经典的问题：App 退到后台，用户重新打开，发现整个进程已经被系统回收，对话记录全丢。
排查链路是这样的。先怀疑前台服务没有正确绑定，检查之后确认绑定没问题；然后怀疑通知栏常驻卡片被用户手动清除，测试发现即使不清除，系统在内存压力大的时候依然会回收；最后查看系统回收日志，才发现问题根源是常驻内存还是偏高，峰值达到 800MB，稳居所有应用内存占用榜首，成了回收算法的首要目标。
解决办法分两步。第一步是继续压缩内存，把模型从 3B 换成 1.8B 量化版，常驻内存降到 620MB；第二步是实现了状态持久化，每轮对话结束就把会话快照写入本地存储，即使进程被杀，重新打开也能从最后一条记录恢复。这套组合之后，连续压测一周，没有再出现用户可见的数据丢失。
4.3 坑二：推理线程让设备发热降频
另一个让我熬夜的问题是设备发热。刚开始测试的时候，每次和 Agent 连续聊到第五六轮，手机背部就开始发烫，然后系统主动降频，推理速度骤降，用户体验从“流畅”直接掉到“卡顿”。
根因是推理线程的 CPU 占用太高。大模型生成时每个 token 都要经过大量计算，如果线程一直跑在性能核心上，热量积累非常快。NanoClaw 的解法是引入了推理任务预算：每一轮对话设定一个最大 token 生成数，每生成一个 token 之后做一次温度感知，一旦设备温度超过阈值，就主动降低生成速度，甚至暂停让设备先凉下来。
实测效果很明显。加入温度控制之后，连续对话 30 分钟，设备背面只是温热，功耗控制在 7% 电量，推理速度在温度超标时略有下降，但不再出现降频卡死的情况。
4.4 坑三：流式输出把 UI 卡成了幻灯片
NanoClaw 回答用户时采用了流式输出，也就是模型每生成几个字就推一次 UI 更新，这样用户不用等整段回答生成完，体验好很多。结果第一次实测就发现问题：模型生成速度快的时候，UI 更新频率过高，导致界面帧率掉到 20 帧以下，看起来像幻灯片。
这个坑的关键在于“更新频率”和“渲染效率”之间的平衡。NanoClaw 我加了一个节流机制：无论模型生成了多少内容，UI 层最多每 100 毫秒刷新一次，并且把增量文本缓冲到累积段落中，一次性渲染。这样既保留了流式输出的即时感，又把刷新频率限制在框架能承受的范围内。修复后帧率稳定在 55 帧以上，几乎感知不到刷新延迟。
5. 留给后来者的参数与经验
5.1 可复用的参数速查表
在多次验证之后，我把自己用得最顺的参数组合整理成了速查表，新项目可以直接抄。
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| 模型参数量 | 1B 至 3B | 任务简单选 1B，复杂对话选 3B |
| 量化位宽 | 4-bit | 质量与资源占用平衡最佳 |
| 上下文窗口 | 内 2048 至 4096 | 过长内存压力大，过短对话不连贯 |
| 系统提示词 | 800 token 以内 | 角色卡片 + 工具签名 |
| 工具注册表 | 静态编译期注册 | 不做运行时动态加载 |
| UI 刷新节流 | 100ms 一次 | 避免高频刷新掉帧 |
| 推理线程 | 独立线程 + 低优先级 | 低于 UI 渲染优先级 |
| 温度保护阈值 | 设备表面 45℃ 左右启动降速 | 具体阈值按机型调 |
| 记忆存储 | SQLite + 关键词索引 | 轻量、可靠、可持久化 |
| 冷启动策略 | UI 先行 + 模型异步加载 | 用户感知启动时间最短 |
5.2 端侧 Agent 的资源设计五原则
这段重构经历让我总结出五条原则，适用于任何端侧 Agent 项目。
第一，默认资源有限。每增加一个功能模块，先算内存和功耗账单，不要等功能做完再回头优化，回头优化基本等于重构。第二，能静态加载的不要动态加载。反射、动态代码、运行时扫描这些机制在服务端可以作为便利，在端侧就是性能杀手。第三，把断网当作常态。所有功能和数据流设计都要考虑“网络不存在”的情况，本地 Agent 的核心优势就是离线可用，如果隔三差五还是依赖云端，这个优势就不成立。第四，受控降级优先于崩溃。系统内存不足、电量低、后台受限，这些情况下不要试图硬扛，主动降级服务，保证核心会话和用户数据不丢。第五，体验要以温度和帧率为准。CPU 占用率、内存占用再好看，设备发烫、界面卡顿就是不合格。
5.3 NanoClaw 下一步还能往哪走
目前 NanoClaw 已经把文本对话、本地记忆、工具调用这三块完整跑通了。我计划中的下一步是端侧多模态输入——做本地图片理解，这样用户可以直接丢一张屏幕截图给 Agent，让它帮忙分析。再往后是设备协同，也就是让手机上的 NanoClaw 与平板、电脑端组成一个轻量分布式 Agent 网络，任务在多个设备之间编排。这条路还很长，但至少第一版已经站稳了。
最后再分享一个小细节。整个重构过程中，我最满意的不是内存降了多少，而是把“出发点是解决问题、而不是保留代码”这个态度真正执行到最后。大龙虾有的模块确实写得很优雅，比如它的事件分发设计，但优雅不等于合适。移动端的现实是资源有限、环境苛刻，懂得取舍，比懂得堆料重要得多。
