企业官网建设流程全解析

• 文档
• 教程
• 后端

导读

在基于 Android 手机网关（MobileOpenClaw）的 AI Agent 场景中，智能体需要一边与用户保持长会话、一边通过 Socket 向手机端下发操作指令。随着对话轮次增加，autoglm-phone 这类专属模型的上下文 Token 会迅速耗尽并直接报错；同时新版安卓系统还会在应用隐藏后限制对其他应用的截屏。本节围绕这两个真实痛点，给出「自实现记忆上下文 + 模型侧历史信息精简」与「录屏取一帧替代截图」两套细化处理方案，帮助读者在手机智能体这类多轮、多模态场景下稳定运行。读完本文，你将掌握会话上下文超限的两种工程化解法，以及绕过安卓高版本截屏限制的录屏取帧思路。

一、背景：MobileOpenClaw 场景下的两个真实痛点

在《AI Agent 场景应用 - MobileOpenClaw》这一系列中，整体架构分为两条链路（可参考 第5-5节：智能体工作流设计）：

• 服务端：基于 Spring AI 等框架装配智能体，通过 Netty 与手机网关通信，下发「点击坐标、滑动、输入文本、启动应用」等动作指令（详见 第5-3节：服务端网络通信设计(Netty).md) 与 第5-2节：手机网关动作调度设计）。
• 安卓端（网关终端）：接收智能体指令执行动作，并回传截图供模型做视觉决策（详见 第5-7节：使用AutoGLM-Phone-9B构建手机智能体）。

在真实测试验证中，这套链路暴露出两类必须细化处理的问题：

1. 服务端上下文对话内容超长报错：手机智能体每轮操作都要携带「用户请求 + 历史对话 + 截图 + 模型输出」，多轮之后极易突破模型上下文窗口。
2. 安卓端截图被系统限制：不少新版安卓设备，在应用（网关应用）被隐藏到后台后，会限制网关对当前前台应用进行截屏，导致模型拿不到「当前屏幕长什么样」，决策链断裂。

本节要解决的就是这两个场景问题。以下分别给出设计思路与实施方案。

二、问题一：上下文 Token 超长，历史消息不能全量携带

1. 现象与报错定位

当对话轮次累积到一定程度，调用 autoglm-phone 模型时会直接报出上下文超限错误，例如：

You requested a total of 26891 tokens: 25867

这条错误意味着本次请求携带的 Token 总量（26891）已经超出模型上下文窗口的限制（25867）。autoglm-phone 是智谱面向手机操作场景发布的专属视觉模型，它既要吃进屏幕截图这类多模态输入，又要承载系统提示词与多轮历史，上下文预算本身就非常紧张。

因此结论很明确：不能把过多的历史信息在每次对话中都完整发送给模型，必须对会话上下文做细化处理，让每次请求只携带「必要且精简」的信息。

2. 方案一：自实现 InMemoryMemoryService 记忆上下文

一种做法是采用InMemoryMemoryService的方式，自己实现一套记忆上下文服务。核心设计如下：

• 每次只记录用户请求（User Message）与最后 N 条模型处理结果数据（Assistant Message / 动作执行结果）；
• 超出 N 条的历史数据在内存中被淘汰，保证每次构造模型请求时，历史集合始终是一个有上限的滑动窗口；
• 不依赖外部存储，实现简单、速度快，适合会话状态本来就常驻内存的场景（该场景下服务端通过 Netty 长连接维护手机网关会话，天然适合内存级记忆）。

这种方式的本质是**「以最近 N 条为窗口的短期记忆」**：手机智能体的每一步操作都强依赖「上一步截图与上一步动作」的连续性，最近几轮的上下文足以支撑动作决策，而早期轮次的信息价值衰减很快，可以安全丢弃。

3. 方案二：复用 MySpringAI 处理历史信息

另一种做法是复用本项目在前面开发阶段自行实现的MySpringAI类。这个类本身已经具备「把历史信息处理到模型请求里」的能力，其内部通过集合保存会话数据。因此我们不需要再重复造一套记忆组件，而是直接：

1. 从该类的集合中遍历历史会话数据；
2. 按需取出必要的信息（如最近几轮的用户输入、模型动作输出、关键截图引用）；
3. 再组装进本次模型请求。

相比方案一，方案二更贴合「已有工程资产复用」的思路：历史信息的存放、遍历、拼装逻辑都已经在MySpringAI中实现，本节的细化工作只是控制“取哪些、取多少”，从而在保持代码结构不变的前提下压缩上下文体积。

4. 两种方案怎么选

两种方式都服务于同一个目标：让每次发给 autoglm-phone 的请求“瘦身”到上下文窗口之内。从架构角度，记忆上下文的抽象边界建议放在会话服务层（会话服务接口的实现在 第2-17节：会话服务接口实现-service 中有详细说明），这样 trigger 层与智能体调用层无需感知记忆细节。

三、问题二：新版安卓 API 限制截屏，改用「录屏取一帧」

1. 现象与原因

在第5-8节 多版本安卓版本策略支持 中已经处理了「低版本截图方法在高版本不可用」的 API 差异问题。但在进一步测试验证中发现，即便做了版本策略兼容，不少新版安卓设备仍会在应用隐藏后限制对当前前台应用的截屏——即网关应用退到后台，截屏 API拿不到前台应用画面。

对手机智能体而言，截图是模型“看屏幕”的唯一途径（视觉决策输入）。截图被限制，等同于模型“失明”，后续的点击、滑动、输入等动作都无从规划。

2. 方案：开启视频录制，需要时取一帧

针对这一限制，本节采用「录屏取一帧」的方案绕过：

1. 开启视频录制：在合适的时机（如会话开始或需要视觉感知前）通过系统录屏能力启动屏幕录制，得到持续的屏幕画面流；
2. 需要时取一帧：当智能体需要“看到”当前屏幕时，直接从录屏画面流中取出一帧作为截图使用，替代被限制的截屏 API；
3. 无缝接入既有链路：取出的帧仍按原有截图数据的格式回传给服务端，模型的视觉输入方式不变，因此服务端与智能体侧无需额外适配。

这一方案的要点在于：

• 时机管理：录屏是持续开销（系统资源、电量），需要在「什么时候开始录、什么时候停止」之间做好控制，避免一直录制的浪费；
• 帧提取：从视频流中提取当前帧，本质上拿到的是“此刻的屏幕快照”，与截屏 API 的画面内容一致，但对系统截屏限制免疫；
• 与版本策略协同：该方案与第5-8节的「按 API 版本选择不同截屏方法」互为补充——低版本走原截屏方法，高版本受限制时切到录屏取帧，形成「双保险」。

从实现层面看，这是典型的「用另一种系统能力绕过权限限制」的思路：既然系统禁止“隐藏时截屏”，那就用系统允许的“隐藏时录屏”来获取同等的画面信息，在功能等价的前提下完成替代。

四、落地要点与验证建议

结合本系列的整体工程结构，落地本节两处细化处理时建议关注以下要点：

1. 上下文窗口的余量设计

• 不要顶着模型上下文窗口的极限发送请求，建议预留安全余量（例如控制在窗口的 80% 以内），因为系统提示词、工具定义、截图多模态 Token 都是“隐形消耗”；
• 报错信息中的数字（26891与25867）可以作为调参依据：记录历史 N 条前后的 Token 变化，反向确定 N 的取值。

2. 记忆与截图数据的边界

• 截图属于多模态输入，单张图片的 Token 占用通常远高于一段文本，历史截图的保留策略（保留最近几张、是否压缩）对总 Token 影响很大，应纳入记忆裁剪规则一并考虑；
• 用户请求与模型处理结果是记忆的核心，动作执行结果（如「点击成功」这类状态反馈）是否纳入历史，取决于模型决策是否需要，可以在遍历集合取数时按需过滤。

3. 异步响应链路上的验证

• 本系列的对话接口已升级为异步响应式（见 第5-6节：智能体异步响应展示执行过程），上下文精简后，每轮请求的组装耗时与 Token 消耗都会变化，建议结合异步链路观察整体响应节奏；
• 在接入 autoglm-phone-9b 专属模型后（见 第5-7节：使用AutoGLM-Phone-9B构建手机智能体），务必回归验证多轮连续操作（如“点赞、下单、刷抖音”这类长链路），确认上下文裁剪没有破坏动作连续性。

五、小结

本节针对 MobileOpenClaw 场景中最现实的两个稳定性问题给出了细化处理方案：

• 服务端：面对 autoglm-phone 的 Token 上限，不盲目全量携带历史，而是通过InMemoryMemoryService自实现「用户请求 + 最后 N 条模型结果」的记忆窗口，或复用MySpringAI从历史集合中遍历取必要信息，让每次请求都落在上下文窗口之内；
• 安卓端：针对新版安卓「隐藏应用后禁止截屏」的限制，采用「开启视频录制、需要时取一帧」的方式，以录屏画面流替代截屏 API，既绕过了系统限制，又保持了服务端视觉输入的兼容性。

这两个方案的共同思路值得沉淀：在资源受限（Token 窗口、系统权限）的条件下，用“精简输入”和“能力替代”保持 Agent 链路的稳定闭环。这也是手机智能体这类重多模态、重交互场景能否从 Demo 走向稳定运行的关键细节所在。

更多关于本项目的整体架构、脚手架装配与会话服务设计，可继续阅读 ai-agent-scaffold 项目总览，以及本系列的 第5-5节：智能体工作流设计、第5-8节：多版本安卓版本策略支持。

• 文档
• 教程
• 后端