最近一直在折腾 AI Agent，折腾来折腾去，最后停在了一个叫 Open-AutoGLM 的开源项目上。简单说，它是一套让大模型直接操作手机的开源方案：模型跑在本地，手机通过 USB 连到电脑，你给它一句“帮我在日历里建一个明天下午三点的会议”，它就会自己看屏幕、自己点按钮、自己填内容，全程不需要你插手。你的相册、通知、短信这些数据都留在本机，推理过程也在 Mac 本地完成，不需要上传到任何外部服务。这个指南的目标读者很明确：对本地部署有兴趣，但从来没跑通过一个完整 AI Agent 的开发者或爱好者。你不需要多深的前端知识，也不用懂复杂的模型微调，只要会开终端、能照着敲命令就行。我会从最底层的原理开始，一步步把 Mac 本地部署 AI 手机助理的环境准备、部署实操、性能优化和常见坑都讲一遍。尤其是那些文档里不会写的东西——比如为什么模型总是加载失败、为什么手机明明连上了却不执行操作，我会把排查思路和实际处理方式都交代清楚。1. 先搞清楚：Open-AutoGLM 到底是个什么东西1.1 它和普通手机助手的本质区别手机上的语音助手大家都很熟，喊一声“设置提醒”，它就会帮你建个提醒事项。但这类工具背后依赖的是系统开放的固定接口，接口没开放的功能，它再聪明也做不了。你让它“帮我把微信里昨天收到的图片存到相册并重命名”，它大概率只能摊手。Open-AutoGLM 的思路完全不同。它不依赖厂商给你留好“后门”，而是让大模型直接“看懂屏幕”。模型拿到的是手机当前屏幕的截图，识别出哪里是按钮、哪里是输入框、哪里是列表，然后像人一样点击、滑动、输入文字。只要能看到屏幕、能通过系统无障碍服务拿到操作权限，它就能操作大多数应用，不需要对方专门开发接口。这一步差异是本质性的。就好比传统助手是“你按开关，它执行固定的程序”，Open-AutoGLM 则是“给它一副眼睛和一只手，让它看着现场做决定”。所以它的适应面比传统助手宽很多：订酒店、整理相册、填写表单、批量删除截图，几乎凡是人在手机上能完成的重复操作，它都有机会学会。1.2 核心原理：大模型如何“操作”你的手机要理解 Open-AutoGLM，可以先看它的一次任务是怎么循环起来的。整条链路大致分六步：手机端通过无障碍服务或 ADB 截取当前屏幕，生成一张高清截图。截图传到 Mac 本地，交给多模态大模型。模型对截图做视觉解析，把屏幕里的按钮、文本、图标都识别出来，并确认这些元素在屏幕上的坐标。模型结合你给的指令和当前屏幕状态，输出一个结构化的动作指令，比如“点击坐标(120, 480)”“输入文本XXX”“从坐标(300, 500)滑动到坐标(300, 200)”。这个动作指令被发送回手机端，手机端在屏幕上执行对应的点击、输入或滑动操作。执行完成后，手机端再次截图，把新画面传回模型，进入下一轮循环。直到模型判定任务已经完成，输出“结束”。这个循环的核心，是第三步和第四步，行话叫 GUI Grounding（图形界面接地）和动作规划。GUI Grounding 解决的是“屏幕上的东西在哪里”的问题，动作规划解决的是“接下来该做什么”的问题。传统自动化脚本是写死坐标来做这件事，但 App 更新一下排版，坐标全失效；Open-AutoGLM 则根据实时的截图像素去做判断，所以抗界面变化的能力强很多。在本地部署的场景下，这个循环的所有环节都在自己电脑上完成，唯一需要传输的画面是手机截图，且只走 USB 或局域网，不会经过第三方服务器。这也是本地部署最吸引人的点：敏感数据不出设备，能自定义模型，也能自己改动作执行逻辑。1.3 它擅长做什么，边界又在哪里先说清楚它能做什么，避免你对它有过度期待。Open-AutoGLM 最擅长的是那些步骤清晰、靠看屏幕就能完成的重复操作，典型的是：批量清理相册中的截图或重复照片。自动填写网页表单或 App 注册信息。把短信里的验证码提取出来并填入对应应用。在日历中创建事件、设置提醒。按照固定路径浏览某个应用并收集信息。但它不是万能的。涉及密码输入、支付验证、人脸识别这类敏感场景，我建议你不要交给它自动操作。一方面模型识别可能出错，另一方面这类操作往往需要动态安全校验，一旦判断失误就会造成麻烦。另外，如果一个应用有复杂的动画或频繁弹窗，模型的识别准确率也会下降。所以我的建议是：先用它做低风险、可撤销的任务，跑通之后再逐步扩展到核心场景。2. 部署前需要准备的事（环境与硬件）2.1 Mac 上跑本地大模型的最低配置建议很多人对“本地部署”的第一反应是“我电脑行不行”。Open-AutoGLM 的负载主要来自多模态大模型，而多模态模型比纯文本模型吃内存得多。以我实际测试的经验，Apple Silicon 芯片是硬性门槛，M1 起步，M2/M3/M4 当然更好。Intel Mac 也不是完全不能跑，但推理速度会慢到让你怀疑人生，而且内存普遍不够，我不推荐。内存方面，16GB 是及格线，跑小尺寸量化模型勉强能用；想要流畅跑 7B~8B 量级的多模态模型，32GB 内存才算舒服。为什么内存这么重要？因为模型加载后被完整放进内存，同时还要留出一部分给 KV Cache（键值缓存）和推理过程中的中间变量。模型文件 4GB，运行期占用很容易冲到 8GB 以上，如果还要同时跑系统其他软件，16GB 就会捉襟见肘。磁盘方面，模型文件加项目依赖通常需要 15~20GB 空间。如果你选择更大尺寸的模型或者保存多个量化版本，建议预留 30GB。系统版本保持较新即可，macOS 14 以上对 Metal 加速的支持更好。下面这张表是我整理的最低推荐配置，供你参照：配置项建议说明芯片Apple Silicon (M1 及以上)必须启用 Metal 加速，Intel 效率太低内存16GB 起步，32GB 推荐模型驻留 + KV Cache 会占大头磁盘可用空间 20GB 以上模型文件普遍 4~8GB系统macOS 14 以上对 Metal 和 Python 生态更友好2.2 环境依赖清单与安装部署 Open-AutoGLM 需要装一堆基础工具，我不会假装这些步骤可跳过。按我的习惯，先装 Homebrew，它类似 macOS 的应用商店，很多命令行工具都靠它装。打开终端，执行下面的命令，先把基础工具装好：brew install python@3.11 node git brew install android-platform-toolspython@3.11 是推荐版本，因为部分依赖对 Python 3.12 的支持还不完善；node 用于前端调试面板；git 用于拉取项目代码；android-platform-tools 提供 adb 工具，后面连接手机全靠它。如果你还没装 Homebrew，去官网复制安装命令执行即可。新版 macOS 可能会提示安装 Xcode Command Line Tools，这个不要跳过，否则 python 在编译部分依赖时会报错。装完以后可以用python3 --version和adb version验证一下环境。这里有个小坑：很多人在这一步忽略了android-platform-tools，结果后面手机怎么都连不上。建议你现在就装好，免得后来手忙脚乱。2.3 获取模型文件与项目源码Open-AutoGLM 的开源代码在项目主页能找到，用 git 拉下来就行：git clone <open-autoglm 仓库地址> cd open-autoglm如果你对 git 不熟，也可以直接在项目页面下载 zip 包解压。拿到源码后，下一步是准备模型文件。项目通常会在 README 里给出推荐模型和下载方式，建议直接选择量化版本。量化这个概念不懂也没关系，你只需要知道：量化后的模型文件更小、运行更省内存，代价是极小的精度损失。常见后缀是.gguf，比如q4_k_m版本通常只有同参数原始模型的四分之一左右。模型文件下载后放到models/目录下，并在稍后的配置文件里指定路径。下载时注意文件大小是否和页面一致，不完整文件会在加载阶段直接报错。这个基础准备工作做完，就可以开始正式部署了。3. 完整部署实操：从零跑到第一次对话3.1 初始化项目与配置文件进入项目目录后，我先建一个虚拟环境，避免依赖感染系统 Python：cd open-autoglm python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txtrequirements.txt 里包含推理框架、图像处理、API 服务等依赖，安装过程可能需要几分钟。安装完成后，复制一份默认环境配置：cp .env.example .env.env是项目的核心配置文件，你需要重点修改这几项：MODEL_PATH=/Users/你的用户名/models/open-autoglm-q4_k_m.gguf DEVICE=mps HOST=127.0.0.1 PORT=8000 CONTEXT_SIZE=4096DEVICE=mps是让模型使用 Apple Silicon 的 Metal 加速，这是 Mac 本地部署最关键的设置。如果你跑在 CPU 上，速度会差五倍以上。HOST=127.0.0.1表示只在本机开放服务，不对外开放，这样更安全。PORT=8000是后续手机端连接用的端口。3.2 启动本地推理服务配置完成后，启动服务。不同项目入口可能不同，但大多数是跑一个 Python 文件或通过 uvicorn 启动：uvicorn server.api:app --host 127.0.0.1 --port 8000如果项目结构不同，可以参考 README 的启动命令。启动成功后，日志里会显示模型加载完成、服务运行中。为了确认服务已经正常工作，可以用 curl 访问健康检查接口：curl http://127.0.0.1:8000/health如果返回{"status": "ok"}之类的信息，说明推理服务已经就绪。第一次加载模型会慢一些，因为要读磁盘、建立缓存，这时候终端可能卡住十几秒到几十秒，不要着急关掉。3.3 连接手机端并授权手机端连接是整个部署中最容易翻车的环节。我用的是 Android 手机，流程如下：先在手机上开启开发者模式。进入“设置 -> 关于手机”，连续点击“版本号”七次，系统会提示“你已进入开发者模式”。然后去“开发者选项”里打开“USB 调试”，再用数据线把手机连到 Mac。连上后，在 Mac 终端执行：adb devices第一次连接时，手机屏幕会弹出“是否允许 USB 调试”的对话框，勾选“始终允许”并确认。执行adb devices后，列表里看到你的设备序号，并且状态是device，就说明连接成功。如果显示unauthorized，说明你没点弹窗确认；如果什么都没显示，大概率是数据线不支持数据传输，换一根原装线试试。连接成功之后，还需要安装配套的 Agent 应用。这个应用负责截屏、执行点击滑动、接收服务端指令。可以通过 adb 直接安装，命令类似：adb install open-autoglm-agent.apk安装完成后在手机上打开这个应用，开启“无障碍服务”权限。这一步很关键，没有无障碍权限，应用就无法执行点击和滑动手势。到现在，Mac 本地部署的系统已经完整跑通了。你可以先给服务端发一个简单指令，例如“打开计算器”，手机应该会自动回到桌面并启动计算器应用。第一次执行可能需要几秒钟，因为模型需要先看清屏幕，再决定动作。4. 优化与调参：让助理更聪明、更省资源4.1 模型量化与上下文长度调整部署跑通只是第一步，真正的好体验要靠调参。最优先处理的是内存占用。模型量化级别直接影响内存，常见的 GGUF 量化包括q2_k、q4_k_m、q5_k_m、q8_0。我的经验是：7B 模型用q4_k_m性价比最高，视觉理解能力几乎没损失，内存占用还能压到 6GB 左右；q8_0会更准，但内存多出 2~3GB，普通 16GB 的 Mac 会有点吃力。上下文长度CONTEXT_SIZE也很重要。不是越大越好，因为 KV Cache 会随着上下文长度线性增长。Open-AutoGLM 每一步都要塞入截图信息，如果任务环节多，上下文会涨得很快。但你要是把上下文调到 8192，内存又会明显升高。我建议先从 4096 起步，跑复杂任务再往上加，加到多少取决于任务会不会“记不住前文”。显存不足的时候，还可以减少加载到 GPU 的模型层数。有的推理框架支持--n-gpu-layers参数，比如设成 20，意思是前 20 层放到 GPU，其余留在 CPU。这样做会慢一点，但能降低整体内存压力，适合内存较小的机器。4.2 操作延迟与任务拆分的调优本地部署的一个常见问题是“反应慢”。模型每执行一步都要先看截图、思考、再输出动作，这个流程走完通常要 1~3 秒，若是大模型未量化则更慢。延迟调整有两个方向：一是提高推理速度，二是降低无效步骤。提高推理速度可以从截图频率入手。手机端默认会在每次操作后立即截图，但如果遇到页面还在加载中的情况，模型会看到半加载的界面，判断容易出错。我建议在配置文件里把截图间隔设成 500~800 毫秒，给页面渲染留一点缓冲时间，准确率反而更高。不要一味追求“瞬间截图”，动态界面下截图太频繁会让模型看到残影。另一个很有效的优化是任务拆分。所谓“拆分”，不是让模型一口气做十件事，而是把一个大任务切成几个小指令。比如“帮我整理相册里的截图并重命名为日期格式”这个任务，拆成“打开相册”“筛选截图”“按选中时间重命名”三步，每一步单独下指令。这样做的好处是上下文不会太长，模型不容易“走神”，就算中间某步执行失败，你也只需要纠正那一步，而不是整个流程推倒重来。4.3 多轮任务与权限管理的细节Open-AutoGLM 支持多轮任务，意思是它会为了完成一个目标连续执行很多步，中途还会根据屏幕变化调整动作。但多轮任务越复杂，权限风险越高。我的原则是：给 Agent 的权限能少给就少给。你需要特别注意“无障碍服务”权限。这个权限在 Android 系统里是最高级别的辅助权限，相当于替你在屏幕上做任何操作。不要允许 Agent 读取通知、短信和联系人，除非任务确实需要。你可以在系统“应用权限”里单独关闭这些敏感权限，保留屏幕操作能力就好。系统弹窗的处理也要提前想好。如果你让 Agent 去下载文件，系统会弹出“允许存储权限”的通知。这类弹窗如果没有预设，模型可能卡住。比较省事的办法是在测试环境里预先点掉常驻弹窗，或者把弹窗类操作手动完成，只在最终环境里运行 Agent。我在实际使用中还会把“自动点击系统弹窗”的选项关闭，避免误点“允许安装未知应用”这类风险按钮。5. 常见问题与排查记录5.1 模型加载慢 / 内存爆掉这是本地部署最常遇到的问题。表现是启动服务后很久没有反应，或者系统提示内存不足，运行变得很卡。第一步先确认配置文件里的模型路径没有拼错。如果路径错误，服务会在日志里报“file not found”，这不是内存问题。然后查看内存占用：ps aux | grep python你会看到某个进程的内存占用异常高。解决办法按优先级排列：换更小的量化模型 -> 缩小 CONTEXT_SIZE -> 减少 GPU 层数 -> 关掉浏览器等其他内存大户。不要同时开多个模型服务，一个 Agent 任务只对应一个推理服务，多余的都关掉。另外，大模型第一次加载会建立缓存，第二次加载会快一些。如果每次启动都重新加载很慢，可以考虑使用推理框架的持久化缓存特性，或者干脆保持服务进程一直运行，不用的时候挂机也没什么。5.2 手机连接失败或指令不执行adb devices看不到设备，是最让人不耐烦的问题。我踩过几个坑之后总结的经验是：先换数据线，再换 USB 口。很多数据线只能充电不能传数据，USB 口供电不稳也会导致设备反复断开。线材确认没问题后，检查手机上的“USB 调试”是否真的打开了，有些手机还需要额外打开“USB 安装”权限。指令不执行的问题，则要从服务端日志入手。打开终端日志，看看服务端有没有收到请求。如果收到请求却没有动作发出，可能是模型对屏幕的理解输出格式不正确。比如模型返回了一个 JSON 动作，但项目只认特定格式，就会默默失败。这种情况通常升级模型版本或调整指令说法能缓解。还有一个不易察觉的问题：手机端 App 的无障碍服务没开启，服务端指令到了手机，手机却没有执行权限，自然一动不动。去系统设置里确认无障碍服务处于“已开启”状态，再重跑一次。5.3 操作识别不准怎么办当 Open-AutoGLM 识别错按钮、点错位置时，先不要急着怀疑模型能力。最基础也是最容易忽略的，是手机屏幕分辨率问题。如果手机端截图被压缩得太厉害，模型可能看不清小按钮。在配置里把截图质量调高，尽量用原始分辨率，准度会立刻提升。识别不准还和指令的清晰度有关。你让它“打开设置”，它可能点错应用；但如果指令是“打开系统设置应用，找到 WiFi 选项并打开”，模型有了明确路径，动作准确率会高很多。说白了，模型像一个执行力强但理解能力有限的实习生，指令越具体，越不容易跑偏。调低模型温度也能减少随机行为。温度是影响生成随机性的参数，默认可能是 0.7，降到 0.2 左右会让模型输出更保守、更稳定，适合这种需要精确点击的场景。不过温度太低也可能让它过于谨慎，遇到新界面不敢动，所以要在 0.2~0.5 之间试出适合你任务的值。最后说一个我自己用出来的小技巧：在跑复杂任务时，先把手机亮度和字体调成常规状态，不要开深色模式，也不要改超大字体。深色模式下部分屏幕元素识别率会下降，超大字体则可能让按钮位置偏移。让环境“普通”一点，模型识别会稳定很多。这个细节在 Open-AutoGLM 的文档里不一定能找到，但实测省掉了很多烦恼。Open-AutoGLM 这套东西，最大的价值不是“能自动操作手机”这个结果，而是把大模型从“聊天窗口”里放了出来，真正落到物理世界的交互中。你不需要做一个完整的系统接入，只要有一台 Mac、一部 Android 手机、一点耐心，就能在本地拥有一个能看懂屏幕、能动手操作手机的 AI 助理。先从一个小任务开始跑通流程，再逐步优化，你会发现这个领域比想象中好玩得多。
最近一直在折腾 AI Agent，折腾来折腾去，最后停在了一个叫 Open-AutoGLM 的开源项目上。简单说，它是一套让大模型直接操作手机的开源方案：模型跑在本地，手机通过 USB 连到电脑，你给它一句“帮我在日历里建一个明天下午三点的会议”，它就会自己看屏幕、自己点按钮、自己填内容，全程不需要你插手。你的相册、通知、短信这些数据都留在本机，推理过程也在 Mac 本地完成，不需要上传到任何外部服务。这个指南的目标读者很明确：对本地部署有兴趣，但从来没跑通过一个完整 AI Agent 的开发者或爱好者。你不需要多深的前端知识，也不用懂复杂的模型微调，只要会开终端、能照着敲命令就行。我会从最底层的原理开始，一步步把 Mac 本地部署 AI 手机助理的环境准备、部署实操、性能优化和常见坑都讲一遍。尤其是那些文档里不会写的东西——比如为什么模型总是加载失败、为什么手机明明连上了却不执行操作，我会把排查思路和实际处理方式都交代清楚。1. 先搞清楚：Open-AutoGLM 到底是个什么东西1.1 它和普通手机助手的本质区别手机上的语音助手大家都很熟，喊一声“设置提醒”，它就会帮你建个提醒事项。但这类工具背后依赖的是系统开放的固定接口，接口没开放的功能，它再聪明也做不了。你让它“帮我把微信里昨天收到的图片存到相册并重命名”，它大概率只能摊手。Open-AutoGLM 的思路完全不同。它不依赖厂商给你留好“后门”，而是让大模型直接“看懂屏幕”。模型拿到的是手机当前屏幕的截图，识别出哪里是按钮、哪里是输入框、哪里是列表，然后像人一样点击、滑动、输入文字。只要能看到屏幕、能通过系统无障碍服务拿到操作权限，它就能操作大多数应用，不需要对方专门开发接口。这一步差异是本质性的。就好比传统助手是“你按开关，它执行固定的程序”，Open-AutoGLM 则是“给它一副眼睛和一只手，让它看着现场做决定”。所以它的适应面比传统助手宽很多：订酒店、整理相册、填写表单、批量删除截图，几乎凡是人在手机上能完成的重复操作，它都有机会学会。1.2 核心原理：大模型如何“操作”你的手机要理解 Open-AutoGLM，可以先看它的一次任务是怎么循环起来的。整条链路大致分六步：手机端通过无障碍服务或 ADB 截取当前屏幕，生成一张高清截图。截图传到 Mac 本地，交给多模态大模型。模型对截图做视觉解析，把屏幕里的按钮、文本、图标都识别出来，并确认这些元素在屏幕上的坐标。模型结合你给的指令和当前屏幕状态，输出一个结构化的动作指令，比如“点击坐标(120, 480)”“输入文本XXX”“从坐标(300, 500)滑动到坐标(300, 200)”。这个动作指令被发送回手机端，手机端在屏幕上执行对应的点击、输入或滑动操作。执行完成后，手机端再次截图，把新画面传回模型，进入下一轮循环。直到模型判定任务已经完成，输出“结束”。这个循环的核心，是第三步和第四步，行话叫 GUI Grounding（图形界面接地）和动作规划。GUI Grounding 解决的是“屏幕上的东西在哪里”的问题，动作规划解决的是“接下来该做什么”的问题。传统自动化脚本是写死坐标来做这件事，但 App 更新一下排版，坐标全失效；Open-AutoGLM 则根据实时的截图像素去做判断，所以抗界面变化的能力强很多。在本地部署的场景下，这个循环的所有环节都在自己电脑上完成，唯一需要传输的画面是手机截图，且只走 USB 或局域网，不会经过第三方服务器。这也是本地部署最吸引人的点：敏感数据不出设备，能自定义模型，也能自己改动作执行逻辑。1.3 它擅长做什么，边界又在哪里先说清楚它能做什么，避免你对它有过度期待。Open-AutoGLM 最擅长的是那些步骤清晰、靠看屏幕就能完成的重复操作，典型的是：批量清理相册中的截图或重复照片。自动填写网页表单或 App 注册信息。把短信里的验证码提取出来并填入对应应用。在日历中创建事件、设置提醒。按照固定路径浏览某个应用并收集信息。但它不是万能的。涉及密码输入、支付验证、人脸识别这类敏感场景，我建议你不要交给它自动操作。一方面模型识别可能出错，另一方面这类操作往往需要动态安全校验，一旦判断失误就会造成麻烦。另外，如果一个应用有复杂的动画或频繁弹窗，模型的识别准确率也会下降。所以我的建议是：先用它做低风险、可撤销的任务，跑通之后再逐步扩展到核心场景。2. 部署前需要准备的事（环境与硬件）2.1 Mac 上跑本地大模型的最低配置建议很多人对“本地部署”的第一反应是“我电脑行不行”。Open-AutoGLM 的负载主要来自多模态大模型，而多模态模型比纯文本模型吃内存得多。以我实际测试的经验，Apple Silicon 芯片是硬性门槛，M1 起步，M2/M3/M4 当然更好。Intel Mac 也不是完全不能跑，但推理速度会慢到让你怀疑人生，而且内存普遍不够，我不推荐。内存方面，16GB 是及格线，跑小尺寸量化模型勉强能用；想要流畅跑 7B~8B 量级的多模态模型，32GB 内存才算舒服。为什么内存这么重要？因为模型加载后被完整放进内存，同时还要留出一部分给 KV Cache（键值缓存）和推理过程中的中间变量。模型文件 4GB，运行期占用很容易冲到 8GB 以上，如果还要同时跑系统其他软件，16GB 就会捉襟见肘。磁盘方面，模型文件加项目依赖通常需要 15~20GB 空间。如果你选择更大尺寸的模型或者保存多个量化版本，建议预留 30GB。系统版本保持较新即可，macOS 14 以上对 Metal 加速的支持更好。下面这张表是我整理的最低推荐配置，供你参照：配置项建议说明芯片Apple Silicon (M1 及以上)必须启用 Metal 加速，Intel 效率太低内存16GB 起步，32GB 推荐模型驻留 + KV Cache 会占大头磁盘可用空间 20GB 以上模型文件普遍 4~8GB系统macOS 14 以上对 Metal 和 Python 生态更友好2.2 环境依赖清单与安装部署 Open-AutoGLM 需要装一堆基础工具，我不会假装这些步骤可跳过。按我的习惯，先装 Homebrew，它类似 macOS 的应用商店，很多命令行工具都靠它装。打开终端，执行下面的命令，先把基础工具装好：brew install python@3.11 node git brew install android-platform-toolspython@3.11 是推荐版本，因为部分依赖对 Python 3.12 的支持还不完善；node 用于前端调试面板；git 用于拉取项目代码；android-platform-tools 提供 adb 工具，后面连接手机全靠它。如果你还没装 Homebrew，去官网复制安装命令执行即可。新版 macOS 可能会提示安装 Xcode Command Line Tools，这个不要跳过，否则 python 在编译部分依赖时会报错。装完以后可以用python3 --version和adb version验证一下环境。这里有个小坑：很多人在这一步忽略了android-platform-tools，结果后面手机怎么都连不上。建议你现在就装好，免得后来手忙脚乱。2.3 获取模型文件与项目源码Open-AutoGLM 的开源代码在项目主页能找到，用 git 拉下来就行：git clone <open-autoglm 仓库地址> cd open-autoglm如果你对 git 不熟，也可以直接在项目页面下载 zip 包解压。拿到源码后，下一步是准备模型文件。项目通常会在 README 里给出推荐模型和下载方式，建议直接选择量化版本。量化这个概念不懂也没关系，你只需要知道：量化后的模型文件更小、运行更省内存，代价是极小的精度损失。常见后缀是.gguf，比如q4_k_m版本通常只有同参数原始模型的四分之一左右。模型文件下载后放到models/目录下，并在稍后的配置文件里指定路径。下载时注意文件大小是否和页面一致，不完整文件会在加载阶段直接报错。这个基础准备工作做完，就可以开始正式部署了。3. 完整部署实操：从零跑到第一次对话3.1 初始化项目与配置文件进入项目目录后，我先建一个虚拟环境，避免依赖感染系统 Python：cd open-autoglm python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txtrequirements.txt 里包含推理框架、图像处理、API 服务等依赖，安装过程可能需要几分钟。安装完成后，复制一份默认环境配置：cp .env.example .env.env是项目的核心配置文件，你需要重点修改这几项：MODEL_PATH=/Users/你的用户名/models/open-autoglm-q4_k_m.gguf DEVICE=mps HOST=127.0.0.1 PORT=8000 CONTEXT_SIZE=4096DEVICE=mps是让模型使用 Apple Silicon 的 Metal 加速，这是 Mac 本地部署最关键的设置。如果你跑在 CPU 上，速度会差五倍以上。HOST=127.0.0.1表示只在本机开放服务，不对外开放，这样更安全。PORT=8000是后续手机端连接用的端口。3.2 启动本地推理服务配置完成后，启动服务。不同项目入口可能不同，但大多数是跑一个 Python 文件或通过 uvicorn 启动：uvicorn server.api:app --host 127.0.0.1 --port 8000如果项目结构不同，可以参考 README 的启动命令。启动成功后，日志里会显示模型加载完成、服务运行中。为了确认服务已经正常工作，可以用 curl 访问健康检查接口：curl http://127.0.0.1:8000/health如果返回{"status": "ok"}之类的信息，说明推理服务已经就绪。第一次加载模型会慢一些，因为要读磁盘、建立缓存，这时候终端可能卡住十几秒到几十秒，不要着急关掉。3.3 连接手机端并授权手机端连接是整个部署中最容易翻车的环节。我用的是 Android 手机，流程如下：先在手机上开启开发者模式。进入“设置 -> 关于手机”，连续点击“版本号”七次，系统会提示“你已进入开发者模式”。然后去“开发者选项”里打开“USB 调试”，再用数据线把手机连到 Mac。连上后，在 Mac 终端执行：adb devices第一次连接时，手机屏幕会弹出“是否允许 USB 调试”的对话框，勾选“始终允许”并确认。执行adb devices后，列表里看到你的设备序号，并且状态是device，就说明连接成功。如果显示unauthorized，说明你没点弹窗确认；如果什么都没显示，大概率是数据线不支持数据传输，换一根原装线试试。连接成功之后，还需要安装配套的 Agent 应用。这个应用负责截屏、执行点击滑动、接收服务端指令。可以通过 adb 直接安装，命令类似：adb install open-autoglm-agent.apk安装完成后在手机上打开这个应用，开启“无障碍服务”权限。这一步很关键，没有无障碍权限，应用就无法执行点击和滑动手势。到现在，Mac 本地部署的系统已经完整跑通了。你可以先给服务端发一个简单指令，例如“打开计算器”，手机应该会自动回到桌面并启动计算器应用。第一次执行可能需要几秒钟，因为模型需要先看清屏幕，再决定动作。4. 优化与调参：让助理更聪明、更省资源4.1 模型量化与上下文长度调整部署跑通只是第一步，真正的好体验要靠调参。最优先处理的是内存占用。模型量化级别直接影响内存，常见的 GGUF 量化包括q2_k、q4_k_m、q5_k_m、q8_0。我的经验是：7B 模型用q4_k_m性价比最高，视觉理解能力几乎没损失，内存占用还能压到 6GB 左右；q8_0会更准，但内存多出 2~3GB，普通 16GB 的 Mac 会有点吃力。上下文长度CONTEXT_SIZE也很重要。不是越大越好，因为 KV Cache 会随着上下文长度线性增长。Open-AutoGLM 每一步都要塞入截图信息，如果任务环节多，上下文会涨得很快。但你要是把上下文调到 8192，内存又会明显升高。我建议先从 4096 起步，跑复杂任务再往上加，加到多少取决于任务会不会“记不住前文”。显存不足的时候，还可以减少加载到 GPU 的模型层数。有的推理框架支持--n-gpu-layers参数，比如设成 20，意思是前 20 层放到 GPU，其余留在 CPU。这样做会慢一点，但能降低整体内存压力，适合内存较小的机器。4.2 操作延迟与任务拆分的调优本地部署的一个常见问题是“反应慢”。模型每执行一步都要先看截图、思考、再输出动作，这个流程走完通常要 1~3 秒，若是大模型未量化则更慢。延迟调整有两个方向：一是提高推理速度，二是降低无效步骤。提高推理速度可以从截图频率入手。手机端默认会在每次操作后立即截图，但如果遇到页面还在加载中的情况，模型会看到半加载的界面，判断容易出错。我建议在配置文件里把截图间隔设成 500~800 毫秒，给页面渲染留一点缓冲时间，准确率反而更高。不要一味追求“瞬间截图”，动态界面下截图太频繁会让模型看到残影。另一个很有效的优化是任务拆分。所谓“拆分”，不是让模型一口气做十件事，而是把一个大任务切成几个小指令。比如“帮我整理相册里的截图并重命名为日期格式”这个任务，拆成“打开相册”“筛选截图”“按选中时间重命名”三步，每一步单独下指令。这样做的好处是上下文不会太长，模型不容易“走神”，就算中间某步执行失败，你也只需要纠正那一步，而不是整个流程推倒重来。4.3 多轮任务与权限管理的细节Open-AutoGLM 支持多轮任务，意思是它会为了完成一个目标连续执行很多步，中途还会根据屏幕变化调整动作。但多轮任务越复杂，权限风险越高。我的原则是：给 Agent 的权限能少给就少给。你需要特别注意“无障碍服务”权限。这个权限在 Android 系统里是最高级别的辅助权限，相当于替你在屏幕上做任何操作。不要允许 Agent 读取通知、短信和联系人，除非任务确实需要。你可以在系统“应用权限”里单独关闭这些敏感权限，保留屏幕操作能力就好。系统弹窗的处理也要提前想好。如果你让 Agent 去下载文件，系统会弹出“允许存储权限”的通知。这类弹窗如果没有预设，模型可能卡住。比较省事的办法是在测试环境里预先点掉常驻弹窗，或者把弹窗类操作手动完成，只在最终环境里运行 Agent。我在实际使用中还会把“自动点击系统弹窗”的选项关闭，避免误点“允许安装未知应用”这类风险按钮。5. 常见问题与排查记录5.1 模型加载慢 / 内存爆掉这是本地部署最常遇到的问题。表现是启动服务后很久没有反应，或者系统提示内存不足，运行变得很卡。第一步先确认配置文件里的模型路径没有拼错。如果路径错误，服务会在日志里报“file not found”，这不是内存问题。然后查看内存占用：ps aux | grep python你会看到某个进程的内存占用异常高。解决办法按优先级排列：换更小的量化模型 -> 缩小 CONTEXT_SIZE -> 减少 GPU 层数 -> 关掉浏览器等其他内存大户。不要同时开多个模型服务，一个 Agent 任务只对应一个推理服务，多余的都关掉。另外，大模型第一次加载会建立缓存，第二次加载会快一些。如果每次启动都重新加载很慢，可以考虑使用推理框架的持久化缓存特性，或者干脆保持服务进程一直运行，不用的时候挂机也没什么。5.2 手机连接失败或指令不执行adb devices看不到设备，是最让人不耐烦的问题。我踩过几个坑之后总结的经验是：先换数据线，再换 USB 口。很多数据线只能充电不能传数据，USB 口供电不稳也会导致设备反复断开。线材确认没问题后，检查手机上的“USB 调试”是否真的打开了，有些手机还需要额外打开“USB 安装”权限。指令不执行的问题，则要从服务端日志入手。打开终端日志，看看服务端有没有收到请求。如果收到请求却没有动作发出，可能是模型对屏幕的理解输出格式不正确。比如模型返回了一个 JSON 动作，但项目只认特定格式，就会默默失败。这种情况通常升级模型版本或调整指令说法能缓解。还有一个不易察觉的问题：手机端 App 的无障碍服务没开启，服务端指令到了手机，手机却没有执行权限，自然一动不动。去系统设置里确认无障碍服务处于“已开启”状态，再重跑一次。5.3 操作识别不准怎么办当 Open-AutoGLM 识别错按钮、点错位置时，先不要急着怀疑模型能力。最基础也是最容易忽略的，是手机屏幕分辨率问题。如果手机端截图被压缩得太厉害，模型可能看不清小按钮。在配置里把截图质量调高，尽量用原始分辨率，准度会立刻提升。识别不准还和指令的清晰度有关。你让它“打开设置”，它可能点错应用；但如果指令是“打开系统设置应用，找到 WiFi 选项并打开”，模型有了明确路径，动作准确率会高很多。说白了，模型像一个执行力强但理解能力有限的实习生，指令越具体，越不容易跑偏。调低模型温度也能减少随机行为。温度是影响生成随机性的参数，默认可能是 0.7，降到 0.2 左右会让模型输出更保守、更稳定，适合这种需要精确点击的场景。不过温度太低也可能让它过于谨慎，遇到新界面不敢动，所以要在 0.2~0.5 之间试出适合你任务的值。最后说一个我自己用出来的小技巧：在跑复杂任务时，先把手机亮度和字体调成常规状态，不要开深色模式，也不要改超大字体。深色模式下部分屏幕元素识别率会下降，超大字体则可能让按钮位置偏移。让环境“普通”一点，模型识别会稳定很多。这个细节在 Open-AutoGLM 的文档里不一定能找到，但实测省掉了很多烦恼。Open-AutoGLM 这套东西，最大的价值不是“能自动操作手机”这个结果，而是把大模型从“聊天窗口”里放了出来，真正落到物理世界的交互中。你不需要做一个完整的系统接入，只要有一台 Mac、一部 Android 手机、一点耐心，就能在本地拥有一个能看懂屏幕、能动手操作手机的 AI 助理。先从一个小任务开始跑通流程，再逐步优化，你会发现这个领域比想象中好玩得多。