模型塞进手机之后，仗才开始打

——端侧 Agent 的内存账本，和为什么记忆系统是地基

最近端侧模型的发布会看多了，叙事都长一个样：参数量、量化后体积、NPU 峰值算力、每秒多少 token。仗，都打在“把模型塞进设备”上。

这场仗快打完了。3B 级模型在旗舰机上跑出可用速度，已经是工程问题，不是科学问题——花钱、堆人、磨 scheduler，总能磨出来。

但产品化的仗才刚开始：模型塞进设备之后，Agent 怎么做？

做 demo 很容易，接个工具、跑个对话就行。难的是三件事：

• 8K 窗口的 Agent，怎么有跨会话记忆？
• 一次工具调用刷出几千 token 日志，怎么管？
• 3B 模型不听话、记不住、算不清日期，怎么办？

这三个问题不是端侧独有的。上一篇里，四款桌面 Agent——Claude Code、腾讯 WorkBuddy、Qoder 的 QoderWork、字节的 TRAE CN——在资源远比端侧富裕的环境里，为同样的问题头疼，而且每家都交了卷子。这篇先把他们的答案收拢成几句话，然后干一件更硬的事：把端侧的账，用真实芯片数据，一笔一笔算给你看。

算完会得到一个反直觉的结论：端侧 Agent 的有效窗口由内存预算决定，不由模型卡决定。 顺着这个结论走到底，记忆系统在端侧就不是增值功能，是地基。

一、桌面四家的答案，收拢成三句话

上一篇文章里有细节，这里只留骨架，因为端侧要抄的就是这套作业。

记忆：搬出窗口，落成文件。 Claude Code 用 CLAUDE.md，项目级加用户级，会话开始读进来，结束沉淀回去。WorkBuddy 干得更重：每晚从当天会话里抽取事实、偏好、人物关系、跟进事项，形成记忆数据，后续任务注入系统提示词，还能回答“上周做过什么”这类问题，甚至支持从别家 AI 导入记忆——提取成本官方自费，不耗用户 token。Qoder 分三层：个人偏好（Memory）、从代码库自动生成的项目知识（Repo Wiki）、团队维护的资料库（Knowledge Base）。TRAE 走得更远，让 AI 自己管记忆，自动创建、更新、删除。

日志：压缩，隔离，渐进读取。 Qoder 的文档有一句话说透了整个行业的态度——“压缩设计上就是有损的，持久事实请写进文件，别依赖聊天历史。”TRAE 的子智能体（Subagent）每个带独立上下文窗口，干完活只把结论带回来。Claude Code 读文件强制分页，命令输出超长自动截断落盘。

可靠性：不信任模型。 规则文件、Spec 先行、沙箱、权限审批。凡是模型容易飘的地方——格式、流程、边界——全用确定性结构框死，模型只负责判断。

有意思的是收敛速度。Claude Code 的 CLAUDE.md 是这套范式的源头，如今 Qoder CLI 和 TRAE CLI 都直接采用了 AGENTS.md 当记忆文件。一家发明，四家跟进，收敛成事实标准，前后不到两年。

桌面交了卷子。端侧拿到的是同一张卷子，十分之一的答题时间：窗口从 200K 缩到 8K，模型从前沿缩到 3B。要在这张卷子上答题，得先搞清楚一件事——8K 这个数字，到底是谁定的。

二、窗口不是模型定的，是内存分配表定的

先建立一个心智模型：上下文窗口是一张桌子。模型每轮干活，必须把系统指令、对话历史、工具返回的所有东西摊在桌面上。桌面之外的，一律看不见。

桌子的大小，直觉上由木匠定——木匠就是模型。模型卡上写着 128K，桌子就该有 128K。云端的逻辑确实如此：KV cache 放在数据中心的 HBM 里，用户无感知，标称 200K 就是 200K。

端侧不是这个逻辑。

因为桌子要占地板。

Transformer 每生成一个字，都要回看前文所有 token 的注意力中间结果。这块缓存叫 KV cache，体积随上下文长度线性增长，跟模型权重一样实打实占内存：

KV cache ≈ 2（K和V）× 层数 × KV头数 × 头维 × 每元素字节数 × token 数

拿端侧真在部署的模型算这笔账。Qwen3-4B，参数 3.7B，36 层，GQA 8 个 KV 头，头维 128——FP16 下每 token 144 KB。这个模型 4-bit 量化后权重大约 2.3GB（含开销的粗算）。记住这个数，下面全靠它做对比：

三个立得住的结论：

FP16 下，8K 窗口的 KV cache 相当于半个模型的权重。窗口从 8K 加到 16K，等于把模型在内存里再放一份——模型只让体验变好一次，窗口加宽是每一轮推理都要重复付的钱。

Model card 上的 128K，在手机上物理不可行。18.9GB 的 KV cache，只比骁龙 8 Elite Gen 5 内存控制器支持的整机最大 RAM（24GB）小一点。换句话说：拿一台根本不存在的、24GB 且什么都不跑的手机，全部内存给 KV 都装不下，权重还没地方放。天玑 9500、A19 Pro 上同样不成立。

所以厂商只剩两条路：KV 量化（INT8/INT4，代价是本就脆弱的小模型长文本注意力进一步劣化），加窗口裁剪。“有效窗口 8K”不是模型不行，是预算表算出来的。

那预算表长什么样？一台 16GB 安卓旗舰（8 Elite Gen 5 / 天玑 9500 机型）的常态：

对照上一张表：FP16 只够 8–16K，INT8 勉强 32K，INT4 才敢说 32K 有余量。

iPhone 17 Pro 更紧。12GB 里 iOS 和系统进程占 3–4GB，Apple Intelligence 的端侧模型（苹果公开过，约 3B）整个运行包被压在 2GB 上下——端侧窗口必然只有几 K，长上下文任务一律路由到 Private Cloud Compute。苹果那套端云分工架构，说到底就是这张预算表的产物。标准版 iPhone 8GB，从硬件上就钉死在小窗口上。Apple Intelligence 的 8GB 起步门槛，本身就是这个约束最诚实的广告。

三、两道闸：装得下，还要跑得动

把 2025–2026 三大旗舰平台的家底摆出来看（数据来自 Notebookcheck、HMC、联发科和高通官网，2025 年 9–10 月发布的平台）：

一个读数先记下：手机统一内存带宽 76–85 GB/s。数据中心 H100 单卡 HBM 带宽 3350 GB/s，40 倍；B200 是 8000 GB/s，近百倍。另外，NPU 的 80–100 TOPS 是 INT8/INT4 峰值营销值，跑 LLM 实际利用率三到六成。

现在算速度。解码时每生成一个 token，注意力要把全部 KV cache 从内存读一遍，外加模型权重。每 token 的读取量 ≈ 权重 2.3GB + 全部 KV：

第一行就是发布会 demo 的真实工况，跟第三方实测对得上。往下看就明白了：窗口每翻一倍，速度接近减半。128K 在 FP16 下连理论值都只有 4 t/s，实际 2–3 t/s，从“可用”直接掉进“不能忍”。A19 Pro 带宽还低一成，更慢。

这就是“标称窗口是摆设”的完整含义：内存容量是第一道闸，装不装得下；带宽是第二道闸，跑不跑得动。两道闸都过，窗口才算有效。

四、第三道闸，和一张随时被撤走的桌子

还有一笔账不常被算：首 token 延迟。

Agent 每轮开始，要把系统提示、记忆、任务拼进窗口。这是一次 prefill，计算量约等于 2 × 参数量 × 输入 token 数。8K 上下文 × 3.7B 模型 ≈ 60 TFLOPs；80 TOPS 的 NPU 按一半利用率跑，首 token 要 1.5–3 秒。32K 上下文 ≈ 240 TFLOPs，6–12 秒才吐第一个字。

这笔账带来一个很端侧的推论：记忆系统注入的每一个 token，都是真金白银的 prefill 算力，外加永久性的 KV 带宽拖累。 桌面 Agent 可以把整份 CLAUDE.md 每轮全量塞进上下文——窗口大，云端带宽不要钱。端侧的记忆系统必须做外科手术式检索，按轮拼装。多记不如记对。

最后是“桌子被撤走”的问题，落到芯片上是三个具体机制。手机 LPDDR 是统一内存，OS、GPU、ISP、应用、NPU 共抢同一条 84.8GB/s 的总线，拍张照、切个应用都在实时挤压推理进程。内存压力一高，Android 的 LMK、iOS 的 jetsam 会直接杀掉推理进程——KV cache 整体消失，窗口连“小”都谈不上，是清零。还有热：8 Elite Gen 5 峰值功耗约 19W，手机散热撑几十秒就把 NPU 压到几瓦。发布会测的是跑 30 秒的成绩，Agent 要跑 30 分钟。

把发布会参数表翻译成工程真相，大概是这个样子：

所以“有效窗口由内存预算决定”的完整表述，是一个四重夹逼：

有效窗口 = min（model card 标称值，内存预算 ÷ 每token KV，带宽预算，用户能忍的首 token 延迟）

四条约束里最紧的，几乎总是内存预算那条。顺带交代一个我自己的误判：动笔算账之前，我一直以为端侧的瓶颈是 NPU 算力——毕竟发布会上数的就是 TOPS。算完才发现，算力是三道闸里最松的一道。装不下、跑不动的都是内存，算力只在 prefill 那一段卡脖子。

五、所以记忆系统是地基

现在可以回答篇头那个问题了：8K 窗口的 Agent 怎么有跨会话记忆？

在云端和桌面，记忆是桌面上添的一个文件架。200K 的大桌摆得下一个完整工作会话，记忆坏了，产品照样能用，只是少一点个性化。记忆坐在窗口之上，是增值功能。

端侧把这个关系倒过来了。窗口小到装不下任何持久的东西——8K 连昨天一次对话都装不下；窗口还随时被清空——进程被杀、会话结束、内存回收。于是窗口内的一切都必须视为易失的。唯一能长期持有信息的地方，只剩窗口之外：磁盘上的记忆系统。

端侧 Agent 只能长成这个形状：

记忆系统为主，窗口为临时草稿区。 每一轮，框架把“系统提示 + 检索到的记忆 + 当前任务”拼进 8K，用完即弃。

窗口的角色降级成 CPU 寄存器，记忆系统才是硬盘。Agent 的连续性、对用户的了解、项目的上下文，全部住在记忆系统里。

“地基”有两层含义。第一层：它不是让产品更好，是让产品成立。没有记忆系统，端侧 Agent 每次醒来都失忆，作为产品等于不存在。第二层：别的子系统全压在它上面。日志转存和检索，走的是记忆系统那套基础设施；进程被杀后的会话恢复，靠记忆系统的持久化；给 3B 模型检索过往成功范例做 few-shot 示范，是记忆；隐私前提下的个性化，本质是本地记忆的积累。地基没法等封顶之后补打——它是架构决策，不是设置页里一个可以后加的开关。

再算一层账就更清楚：窗口里的每个 token，都是用 RAM、带宽、NPU 算力三重成本买来的。记忆系统就是决定“这 8K 里，哪些信息值得花钱买进来”的那个资源调度器。

它不是给 Agent 加的技能。它是 Agent 的财政部长。

而手机恰恰是个人数据密度最高的设备——文件、日程、聊天、相册全在里面。本地记忆，加数据不出设备，是云端 Agent 最难抄走的那条护城河。

末尾

我的判断：端侧 Agent 这场仗，胜负手不在 NPU 优化，在记忆系统的工程——检索的精准度、注入的克制、持久化的可靠性。发布会还会继续数 TOPS，但 TOPS 决定的是模型跑多快，记忆系统决定的是这个产品配不配叫 Agent。

给个边界条件，免得这篇显得什么都能解释：如果你做的端侧产品是单轮问答、输入法补全、相册语义搜索这类短上下文场景，以上全部作废，去优化 prefill 就好。但如果要做的是跨会话、带工具、有记忆的 Agent——先招做记忆检索的工程师，再招调 NPU 的。

顺序别搞反了。