手机派活、电脑合盖、12 分钟交 234 行对照稿这套流程最关键的并不是哪一个模型更聪明而是你到底让谁来当执行端。最近我把 Grok Bot 当成对话助手把自己部署的 OpenClaw 和 Hermes 当成两个 agent 执行端完整跑了一遍“手机下发任务、agent 自主执行、结果回传、邮件只进草稿箱”的流程。跑下来的结论是Grok Bot 适合做临场问答和思路校核OpenClaw 和 Hermes 这样的本地 agent 框架才适合做“合上电脑活照干”的自动化底座。这篇文章会把三个角色的分工、部署条件、单条任务跑通、录屏生成技能、邮件草稿审批以及常见坑按实操顺序写清楚。适合正在纠结“要不要自己部署 agent 框架”的人看也适合已经有 agent 但任务交付不稳定的人对照排查。这里先说一个核心判断手机派活不是把手机当成电脑而是把手机当成遥控器真正干活的执行端必须放在一台 7x24 小时在线的机器上。1. 先把三个角色分清楚谁是助手谁是执行者谁是安全阀1.1 三者的定位差异很多人看到“Grok Bot 对照 OpenClaw 和 Hermes”会默认这是三家公司的同类产品接着就会问“哪个更强”。但这次实测下来最值得先纠正的就是这个问题这三样东西根本不在同一个工作层。Grok Bot 更接近一个对话式助手它的优势是交互直接、理解意图快、适合临时问答、写文案、做思路梳理。你在手机上问一句它回一段这属于“人在回路里”。它不太适合长时间自主跑任务也不适合你合上电脑后还在后台连续干活。OpenClaw 是一个可以自己部署、自己配置、自己挂载各种 skill 的 agent 运行框架。它的重点不是“某一句话回得好不好”而是“能不能把一条任务拆成步骤、调工具、读文件、写文件、回传结果”。社区里大量讨论集中在安装、配置、接入本地模型、接微信和飞书这正好说明它是给想长期运行自动化任务的人准备的。Hermes 这次的定位也很明确它是另一套可以安装部署的 agent 或模型服务方案。从社区关注度来看大家关心的是 Hermes 怎么在 Ubuntu、Windows、桌面端跑起来能不能接 DeepSeek、Ollama、NVIDIA NIM 这类模型服务。它和 OpenClaw 一样走的都是“自己搭、自己养、自己控制数据”的路线而不是纯在线聊天。1.2 为什么“合上电脑活照干”需要一个独立的执行端“合上电脑活照干”这句话听起来很轻松但很多人第一步就理解错了。我一开始也在自己的笔记本上跑 agent结果发现只要电脑一合盖、Wi-Fi 一断、系统一休眠任务就全部中断。后来才明白手机派活的前提是执行端不在你的个人电脑上而是在一台独立、常开、有稳定网络的机器上。这台机器可以是云主机也可以是家里一台不关机的 Mini 主机甚至是办公室一台长期开着的桌面机。手机只是消息入口负责把“帮我写对照稿”“帮我把这份邮件整理成草稿”这类指令发给 agentagent 在执行端上调用模型和工具最后再把结果回传到你手机上。这个架构想清楚之后后面很多选择就顺了为什么需要 agent 框架而不是直接用手机 App为什么要考虑消息通道、任务队列、日志、失败重试为什么邮件要先进草稿箱而不是直接发送。因为这些都属于“执行稳定性”和“安全边界”问题不是聊天模型能单独解决的。1.3 谁适合用这套组合谁不需要如果你的需求只是“偶尔让 AI 帮我想一段话、翻译、润色”那直接用 Grok Bot 这类对话助手就够了自己部署 OpenClaw 或者 Hermes 属于纯折腾。如果你需要的是“每天固定处理一批文档”“定时抓取信息”“让 AI 自动生成邮件草稿并等人工确认”那你需要一个能长期运行的执行端。OpenClaw 和 Hermes 这类自部署 agent 的价值就在这里。还有一种情况也适合自己部署数据敏感不想把内部文档直接贴进在线聊天框。自部署 agent 配合本地模型服务可以做到任务执行和数据处理都在自己的机器上完成。2. 部署前先看清条件执行端比模型更重要2.1 最小可用环境清单我在部署 OpenClaw 和 Hermes 时踩过很多预想不到的坑后来总结了一套最小可用环境清单按这个顺序检查能省掉大量排查时间。第一是机器系统。Windows、Linux、Ubuntu、Kali、麒麟这类系统都有人跑但依赖行为和默认权限差异很大。Windows 上常见的问题是路径分隔符、防火墙弹窗、PowerShell 执行策略Linux 上常见问题是缺系统库、Python 版本不对、服务无法常驻。第二是运行时版本。OpenClaw 和 Hermes 这类框架通常依赖 Python 或 Node.js社区用的版本范围有要求。我的建议是先看仓库 README 里写的版本区间再用版本管理工具隔离不要直接用系统自带的 Python否则容易和系统包冲突。第三是网络条件。执行端需要能访问模型服务的 API 端点也需要能被手机侧的消息通道触达。如果你用的是本地模型比如 Ollama 或者 NIM那还要确认内网端口能通。这里最容易出问题的是只测了本机访问没有测局域网或公网回调。第四是磁盘和内存。agent 跑批处理任务时会写日志、缓存、中间文件、输出文件。如果磁盘剩余空间不足或者日志无限增长任务跑到一半就会莫名失败。内存方面模型如果在本地跑建议按模型体积和上下文长度预留充足空间。2.2 模型接口怎么接云端 API 与本地模型两条路线部署 OpenClaw 或 Hermes 时模型接口是必选配置项。这里分两条路线。云端 API 路线最简单配置 base_url 和 API Key 就能跑。你可以在里面接 Grok 的接口也可以接 DeepSeek、OpenAI 兼容接口等。判断标准只有一个agent 框架发出的模型请求格式是否是 OpenAI 兼容格式如果不是需要看框架有没有专门的适配器。本地模型路线适合对数据隐私和成本更敏感的人。最常见的是 Ollama 加本地模型社区里“openclaw ollama 本地部署”的讨论很多。另外也有 NVIDIA NIM 这类统一推理服务可以把多种模型挂在同一个端点后面agent 只需要对接一个统一入口。我的建议是第一轮验证用云端 API跑通之后再切本地模型。原因很简单云端 API 的可用性和返回格式更稳定方便你确认问题出在 agent 还是模型服务。如果一开始就用本地模型经常会出现模型服务没起来、显存不够、上下文太长导致超时混在一起很难定位。2.3 不同系统下的安装差异和前置检查社区里问得最多的几个安装问题是Windows 怎么装、Linux 怎么装、麒麟系统怎么装、U 盘怎么装、Kali 怎么装。这类问题看起来是“安装步骤不同”实际上核心差异只有三点依赖管理器、服务常驻方式、权限控制。Windows 部署时建议先把执行策略调成允许当前用户运行脚本然后注意路径不要带中文和空格。很多初始化失败都是因为目录权限不够或者杀毒软件把 agent 的可执行文件当风险文件处理了。Linux 系部署时优先用虚拟环境或者容器避免污染系统 Python。常驻运行建议用 systemd 或进程管理器来托管不要直接用 nohup 挂在终端里否则一断 SSH 任务就没了。Kali 这类安全测试系统也可以装但默认环境精简依赖缺失概率更高需要按报错提示逐个补。麒麟这类国产桌面系统本质还是 Linux安装思路和 Ubuntu 接近但要确认系统自带的库源是否有对应包。U 盘安装本质上就是离线安装需要提前把依赖包下载好安装时走本地包源不要指望在线拉取。3. 手机派活跑通12 分钟交 234 行对照稿是怎么完成的3.1 一条任务从手机到大模型再到回传的完整链路这次实测里最有代表性的一条任务是用手机向 agent 下发“生成一份 234 行的对照稿”从指令发出到结果回传大概 12 分钟。很多人听到这个第一反应是“模型写得好快”但真正让这个流程能跑通的是整条链路而不是单纯生成文本的那一步。链路大概是这样的你的手机通过微信、飞书或者自建 Webhook把一段指令发给 agent。agent 收到指令后先做任务解析判断这是一个“文本处理 格式整理 输出文件”的任务。它随后调用模型接口生成正文同时调用文件工具把内容写入指定目录最后再按行数、段落完整性做一次校验把结果回传到你的手机。这里的每一个环节都可能坏掉指令没有落到 agent 对应的 handler 里模型返回内容被截断文件写入权限不足回传消息时格式丢失。所以收到任务后不要直接看最终文本漂不漂亮先看任务日志里的执行路径确认每一步都标记为成功。3.2 234 行对照稿的验收标准“234 行”听起来是一个很具体的数字但实际跑任务时更重要的是行数之外的结构标准。我这次的对照稿要求是原文段落与产出内容逐行对应每一行都有明确的行号不能出现段落合并、内容丢失、序号错乱。我把验收标准拆成以下几条行数是否精确匹配多一行或少一行都要查原因。行号是否连续中间不能因为换行符处理不当跳号。段落内容是否完整长文本不能被模型截断到一半。输出文件的编码格式是否正常用 Excel 或文本编辑器打开不出现乱码。回传结果里是否包含文件路径方便在电脑上二次检查。这也是我建议用 agent 跑生成任务时一定要做的事先定义验收指标再跑生成。不要只给模型一句“生成一份 234 行对照稿”而是告诉它每一行需要包含什么、行号怎么编号、文件输出到哪个目录。3.3 第一次跑任务时最容易卡住的位置第一次跑手机派活最容易卡住的不是模型回复而是任务根本没有被正确触发。我自己遇到过三种典型情况。第一种手机消息发出去了agent 没有任何反应。排查后发现是消息通道的 webhook 配置错了手机端发的消息根本没有到达 agent 服务。第二种任务开始执行了但输出目录没有权限生成到一半就报错。第三种模型返回正常但 agent 在写文件时用了错误的编码导致中文字符全部乱码。我建议第一次跑任务时不要用完整内容先给模型一小段样例路径也尽量用本地绝对路径。跑通之后再把任务规模和输入内容放大。这样每次只引入一个变量问题定位会快很多。注意不要一开始就跑到 234 行先用 10 行样例验证链路。链路通再上规模链路不通再多的生成能力也白搭。4. 录屏学活把操作流程变成可复用的技能4.1 录屏学活到底在解决什么问题“录屏学活”是这次标题里另一个值得拆开讲的能力。它听起来很像“AI 看视频学会操作”但在工程上更准确的表述是把一段操作录屏作为参考素材让 agent 拆解出关键步骤再生成一个可复用的 skill 文件。这个能力解决的是“重复操作沉淀”的问题。比如你每天都要在某个后台里导出表格、改文件名、上传到指定目录如果每跑一次都重新描述一遍agent 每次都要重新理解效率很低。把操作过程录下来让 agent“学”一遍它就能把步骤结构化之后同类任务直接调用技能。4.2 从录屏到 skill 的四个步骤我这里用 OpenClaw 的 skill 机制举例Hermes 如果有类似能力思路也通用。第一步录制一段 30 到 60 秒的短操作视频。录屏内容要单一一个视频只做一件事不要夹杂多个不相关流程。画面清晰度不用太高但关键点击位置、界面字段要能看清。第二步把录屏文件放到 agent 指定的素材目录并写一段任务描述。描述里要说明这个操作的目标是什么、输入是什么、输出是什么。你不能只放一段录屏让 agent 自己猜agent 不是人它需要上下文。第三步让 agent 抽取关键步骤。它会把录屏里的操作转成文字步骤比如“打开页面 - 点击导出 - 等待下载完成 - 修改文件名为日期格式”。这一步完成后你要人工检查步骤是否准确有没有漏掉等待时间、异常判断等隐性操作。第四步把确认后的步骤写成 skill 文件。skill 文件里一般会包括触发场景、输入描述、执行步骤、输出结果、常见错误处理。之后你再发一条新任务测试这个 skill 能不能被正确识别和调用。4.3 录屏素材的边界和隐私处理录屏学活不是万能的它对任务类型有明显边界。适用的是规则明确、重复性高、界面稳定的操作。不适用的情况包括操作界面经常变化、需要大量模糊判断、录屏里有大量无关信息、操作依赖人的直觉。还有一个必须重点提醒的点隐私和合规。录屏前先检查屏幕内容确保没有密码、个人敏感信息、内部数据、客户信息。如果业务环境敏感建议用模拟数据录制或者录制前先脱敏。录屏文件也不要长期保存在 agent 的数据目录里学完步骤确认 skill 可用后就可以把原始录屏归档或者删除。5. 邮件只进草稿箱自动化也要留人工审批口5.1 为什么不能直接让 agent 点发送这次流程里我最坚持的一个设计就是邮件只进草稿箱绝不让 agent 直接发送。原因不是 agent 写不了邮件而是你无法完全控制它不会在错误的时间、把错误的内容发给错误的人。AI 生成邮件时收件人、主题、正文、附件都可能出问题。收件人解析错误、正文里出现幻觉信息、附件路径写错这些都是真实可能发生的。如果走的是直接发送一旦出错就没有挽回余地。让邮件只进草稿箱等于在自动化和人工控制之间加了一道闸门。agent 负责完成 90% 的重复劳动生成草稿、填好主题和收件人然后把决定权交还给人。人只需要打开草稿箱快速扫一遍检查没有问题再点发送。5.2 草稿流程怎么实现实现思路并不复杂。核心是agent 调用邮件服务时只走“创建草稿”接口不走“发送”接口。如果你用的是 SMTP/IMAP 这类协议可以让 agent 上传到 Drafts 文件夹但不调用 send 指令。如果你用的是邮件服务商的 API通常有单独的 createDraft 方法agent 只需要调用这个方法创建成功后会返回草稿 IDagent 把草稿 ID 回传给你。判断是否成功有三条标准草稿箱里能看到这封邮件收件人、主题、正文、附件都不缺邮件系统没有任何自动发送逻辑。比如某些服务商的定时发送功能可能默认开启需要检查一下。5.3 草稿不等于不会发常见误区和检查点“进入草稿箱”不等于“绝对安全”我自己就遇到过几个坑。第一个坑是某些邮件 API 创建草稿之后如果配置了规则或者自动转发草稿可能会被自动处理。第二个坑是agent 在批量创建多封草稿时如果命名没有加任务 ID 或时间戳人工在草稿箱里根本分不清哪封对应哪个任务。第三个坑是某些平台的草稿接口和发送接口共用权限一旦权限范围过大误调发送接口的风险也变大。所以我在落地时额外做了几件事每一封草稿的主题前加固定前缀比如“【Agent 草稿】任务编号”。草稿创建后agent 必须回传草稿标题、收件人、创建时间方便手机端快速核对。权限设置只授予创建草稿所需的范围不授予发送权限。定时检查草稿箱里是否有异常草稿避免 agent 因重复执行任务生成大量重复邮件。注意邮件只进草稿箱核心不是“能不能生成”而是“不能乱发”。宁可多一道人工确认也不能把发送权完全交给自动化流程。6. Grok Bot 与 OpenClaw、Hermes 的对照结论6.1 三组关键能力对照跑完这一轮我把三个角色放在几个维度上做了一个对照列出来给同样在选型的人参考。对比维度Grok BotOpenClawHermes主要定位对话式助手自部署 agent 执行框架自部署 agent / 模型服务方案部署复杂度低开箱即用中高需要规划环境中高需要按系统适配自主任务能力弱依赖人提问强可以拆步骤调工具强可按框架能力实现本地数据控制一般可以完全本地可以完全本地消息通道接入不擅长可接微信、飞书、Webhook按部署方式接入技能沉淀基本没有skill 文件可复用看框架是否支持安全审批机制弱可以设计可以设计适合场景临时问答、思路讨论长期自动化执行长期自动化执行或模型服务这个表格不是想做“谁赢谁输”而是告诉你这三样东西完全可以组合起来用。Grok Bot 负责你坐在电脑前的高频问答OpenClaw 和 Hermes 负责你不在电脑前的时候自主干活。6.2 我最后是怎么分工的这次实测我最后的分工是Grok Bot 放在对话入口处理临时性、探索性的问题。比如“这个方案有没有漏洞”“这句话换个说法更好吗”它给我的价值是即时反馈不需要我打开另一个系统。OpenClaw 承担主要执行任务。手机派活、生成对照稿、调用 skills、处理文件、通过消息通道回传结果都交给它。原因是它的 skill 机制让重复任务能沉淀我只需要维护好 skill 文件新任务新轮次都能复用。Hermes 我主要用于对照验证。同一个任务我会在 OpenClaw 上跑一遍再在 Hermes 上跑一遍对比结果稳定性和执行日志。遇到奇怪的报错时这个双跑对照能帮我快速确认是模型问题还是框架问题。6.3 判断一个 agent 框架能不能用别只看聊天界面很多人评测 agent 时只看“对话回得好不好”这是最容易误判的地方。真正决定 agent 能不能用的是以下几个更底层的能力任务能不能稳定触发10 次里有几次成功。日志是否可读出问题的时候能不能快速定位。有没有失败重试任务中断后能不能断点续跑。输出命名是否规范批量任务里能不能区分每个结果。权限边界是否清晰agent 能碰什么、不能碰什么都要明确。我在部署 OpenClaw 和 Hermes 时最深的感受是模型能力大家都差不多差距主要在执行稳定性。能稳定跑完 100 个任务比单次生成效果惊艳重要得多。7. 常见问题与排查链路7.1 部署、初始化与模型连接问题社区里被问得最多的部署问题我这里按频率整理一下。“初始化失败”是最高频的问题。原因是多方面的最常见的三个是目录权限不足、依赖版本不对、网络无法访问模型端点。排查时先看初始化日志日志里通常直接写了失败在哪一步不用瞎猜。“模型连接超时”排在第二位。如果你用的是本地模型先确认 Ollama 或 NIM 服务是否在监听对应端口如果用云端 API先确认 API Key 是否正确、网络是否放开。有一个判断技巧先用 curl 直接请求模型端点如果返回正常问题大概率出在 agent 的配置上。“不知道装哪个版本”也是高频问题。我建议直接看仓库当前分支和 release 说明不要用网上零散的旧命令。版本不一致导致的诡异报错比功能本身的问题更难查。“麒麟、Kali、U 盘安装失败”本质是环境依赖缺失。解决办法是安装时打开详细日志遇到缺什么库就补什么库不要跳过依赖检查。7.2 消息通道、任务执行与输出异常部署完 agent 之后真正进入长期使用阶段问题更多集中在消息通道和任务执行上。“手机发消息 agent 没反应”先查消息通道配置。微信、飞书、Webhook 三者的消息格式和回调机制都不同不能混用。先用一条最简单的文本消息测试不要一上来就发复杂指令。“任务启动了但输出为空”先查输入文件和提示词。很多情况下不是 agent 没干活而是它读到的文件是空的或者输入路径错了。打开日志看它实际读取的文件路径比反复调整提示词更高效。“输出内容被截断”先看模型上下文长度限制和输出最大 token 设置。长文本任务要提前判断内容是否超出单次输出能力如果超出就要拆成多段处理不能硬让模型一次写完整篇。“文件写入乱码”先看编码配置。Windows 和 Linux 的默认编码不同agent 写文件时如果没指定 UTF-8很容易出现中文乱码。统一在配置里写死编码格式能避免这一类问题。7.3 我优先排查的顺序如果你只记住一个排查原则那就是先看现象能不能稳定复现再看日志再看输入再看环境最后改参数。每次任务异常我按下面这个顺序来先确认现象是完全没执行还是执行到一半失败还是执行完但结果不对。打开任务日志找到对应时间段的执行记录。检查输入文件路径、格式、内容是否完整。检查环境磁盘空间、内存、端口、权限。检查参数并发数、超时时间、输出目录、模型端点。最后再考虑是不是框架版本的兼容问题。这个顺序能覆盖绝大多数问题。不要一上来就怀疑模型能力很多时候只是路径错了或者权限不够。8. 落地时最值得盯住的几个判断点这套“手机派活、agent 执行、邮件只进草稿箱”的工作流真正落地时最该盯住的不是功能列表而是四个判断点任务能不能稳定触发结果能不能稳定回传技能能不能沉淀复用安全边界是不是清楚。如果你正在自己部署 OpenClaw 或 Hermes我的建议是先跑两周小规模任务每天只跑几条重点观察日志和失败率。不要一上来就接微信、飞书、批量任务先把单条任务跑稳再把通道接进来最后再考虑复杂审核流程。踩过几次坑之后我发现这类 agent 项目真正磨人的不是“模型写得不够好”而是前置环境、消息通道和输入材料没有处理干净。把这些基础问题解决掉12 分钟交稿、邮件只进草稿箱、录屏生成技能这些能力都是水到渠成的事。
手机派活、电脑合盖、12 分钟交 234 行对照稿这套流程最关键的并不是哪一个模型更聪明而是你到底让谁来当执行端。最近我把 Grok Bot 当成对话助手把自己部署的 OpenClaw 和 Hermes 当成两个 agent 执行端完整跑了一遍“手机下发任务、agent 自主执行、结果回传、邮件只进草稿箱”的流程。跑下来的结论是Grok Bot 适合做临场问答和思路校核OpenClaw 和 Hermes 这样的本地 agent 框架才适合做“合上电脑活照干”的自动化底座。这篇文章会把三个角色的分工、部署条件、单条任务跑通、录屏生成技能、邮件草稿审批以及常见坑按实操顺序写清楚。适合正在纠结“要不要自己部署 agent 框架”的人看也适合已经有 agent 但任务交付不稳定的人对照排查。这里先说一个核心判断手机派活不是把手机当成电脑而是把手机当成遥控器真正干活的执行端必须放在一台 7x24 小时在线的机器上。1. 先把三个角色分清楚谁是助手谁是执行者谁是安全阀1.1 三者的定位差异很多人看到“Grok Bot 对照 OpenClaw 和 Hermes”会默认这是三家公司的同类产品接着就会问“哪个更强”。但这次实测下来最值得先纠正的就是这个问题这三样东西根本不在同一个工作层。Grok Bot 更接近一个对话式助手它的优势是交互直接、理解意图快、适合临时问答、写文案、做思路梳理。你在手机上问一句它回一段这属于“人在回路里”。它不太适合长时间自主跑任务也不适合你合上电脑后还在后台连续干活。OpenClaw 是一个可以自己部署、自己配置、自己挂载各种 skill 的 agent 运行框架。它的重点不是“某一句话回得好不好”而是“能不能把一条任务拆成步骤、调工具、读文件、写文件、回传结果”。社区里大量讨论集中在安装、配置、接入本地模型、接微信和飞书这正好说明它是给想长期运行自动化任务的人准备的。Hermes 这次的定位也很明确它是另一套可以安装部署的 agent 或模型服务方案。从社区关注度来看大家关心的是 Hermes 怎么在 Ubuntu、Windows、桌面端跑起来能不能接 DeepSeek、Ollama、NVIDIA NIM 这类模型服务。它和 OpenClaw 一样走的都是“自己搭、自己养、自己控制数据”的路线而不是纯在线聊天。1.2 为什么“合上电脑活照干”需要一个独立的执行端“合上电脑活照干”这句话听起来很轻松但很多人第一步就理解错了。我一开始也在自己的笔记本上跑 agent结果发现只要电脑一合盖、Wi-Fi 一断、系统一休眠任务就全部中断。后来才明白手机派活的前提是执行端不在你的个人电脑上而是在一台独立、常开、有稳定网络的机器上。这台机器可以是云主机也可以是家里一台不关机的 Mini 主机甚至是办公室一台长期开着的桌面机。手机只是消息入口负责把“帮我写对照稿”“帮我把这份邮件整理成草稿”这类指令发给 agentagent 在执行端上调用模型和工具最后再把结果回传到你手机上。这个架构想清楚之后后面很多选择就顺了为什么需要 agent 框架而不是直接用手机 App为什么要考虑消息通道、任务队列、日志、失败重试为什么邮件要先进草稿箱而不是直接发送。因为这些都属于“执行稳定性”和“安全边界”问题不是聊天模型能单独解决的。1.3 谁适合用这套组合谁不需要如果你的需求只是“偶尔让 AI 帮我想一段话、翻译、润色”那直接用 Grok Bot 这类对话助手就够了自己部署 OpenClaw 或者 Hermes 属于纯折腾。如果你需要的是“每天固定处理一批文档”“定时抓取信息”“让 AI 自动生成邮件草稿并等人工确认”那你需要一个能长期运行的执行端。OpenClaw 和 Hermes 这类自部署 agent 的价值就在这里。还有一种情况也适合自己部署数据敏感不想把内部文档直接贴进在线聊天框。自部署 agent 配合本地模型服务可以做到任务执行和数据处理都在自己的机器上完成。2. 部署前先看清条件执行端比模型更重要2.1 最小可用环境清单我在部署 OpenClaw 和 Hermes 时踩过很多预想不到的坑后来总结了一套最小可用环境清单按这个顺序检查能省掉大量排查时间。第一是机器系统。Windows、Linux、Ubuntu、Kali、麒麟这类系统都有人跑但依赖行为和默认权限差异很大。Windows 上常见的问题是路径分隔符、防火墙弹窗、PowerShell 执行策略Linux 上常见问题是缺系统库、Python 版本不对、服务无法常驻。第二是运行时版本。OpenClaw 和 Hermes 这类框架通常依赖 Python 或 Node.js社区用的版本范围有要求。我的建议是先看仓库 README 里写的版本区间再用版本管理工具隔离不要直接用系统自带的 Python否则容易和系统包冲突。第三是网络条件。执行端需要能访问模型服务的 API 端点也需要能被手机侧的消息通道触达。如果你用的是本地模型比如 Ollama 或者 NIM那还要确认内网端口能通。这里最容易出问题的是只测了本机访问没有测局域网或公网回调。第四是磁盘和内存。agent 跑批处理任务时会写日志、缓存、中间文件、输出文件。如果磁盘剩余空间不足或者日志无限增长任务跑到一半就会莫名失败。内存方面模型如果在本地跑建议按模型体积和上下文长度预留充足空间。2.2 模型接口怎么接云端 API 与本地模型两条路线部署 OpenClaw 或 Hermes 时模型接口是必选配置项。这里分两条路线。云端 API 路线最简单配置 base_url 和 API Key 就能跑。你可以在里面接 Grok 的接口也可以接 DeepSeek、OpenAI 兼容接口等。判断标准只有一个agent 框架发出的模型请求格式是否是 OpenAI 兼容格式如果不是需要看框架有没有专门的适配器。本地模型路线适合对数据隐私和成本更敏感的人。最常见的是 Ollama 加本地模型社区里“openclaw ollama 本地部署”的讨论很多。另外也有 NVIDIA NIM 这类统一推理服务可以把多种模型挂在同一个端点后面agent 只需要对接一个统一入口。我的建议是第一轮验证用云端 API跑通之后再切本地模型。原因很简单云端 API 的可用性和返回格式更稳定方便你确认问题出在 agent 还是模型服务。如果一开始就用本地模型经常会出现模型服务没起来、显存不够、上下文太长导致超时混在一起很难定位。2.3 不同系统下的安装差异和前置检查社区里问得最多的几个安装问题是Windows 怎么装、Linux 怎么装、麒麟系统怎么装、U 盘怎么装、Kali 怎么装。这类问题看起来是“安装步骤不同”实际上核心差异只有三点依赖管理器、服务常驻方式、权限控制。Windows 部署时建议先把执行策略调成允许当前用户运行脚本然后注意路径不要带中文和空格。很多初始化失败都是因为目录权限不够或者杀毒软件把 agent 的可执行文件当风险文件处理了。Linux 系部署时优先用虚拟环境或者容器避免污染系统 Python。常驻运行建议用 systemd 或进程管理器来托管不要直接用 nohup 挂在终端里否则一断 SSH 任务就没了。Kali 这类安全测试系统也可以装但默认环境精简依赖缺失概率更高需要按报错提示逐个补。麒麟这类国产桌面系统本质还是 Linux安装思路和 Ubuntu 接近但要确认系统自带的库源是否有对应包。U 盘安装本质上就是离线安装需要提前把依赖包下载好安装时走本地包源不要指望在线拉取。3. 手机派活跑通12 分钟交 234 行对照稿是怎么完成的3.1 一条任务从手机到大模型再到回传的完整链路这次实测里最有代表性的一条任务是用手机向 agent 下发“生成一份 234 行的对照稿”从指令发出到结果回传大概 12 分钟。很多人听到这个第一反应是“模型写得好快”但真正让这个流程能跑通的是整条链路而不是单纯生成文本的那一步。链路大概是这样的你的手机通过微信、飞书或者自建 Webhook把一段指令发给 agent。agent 收到指令后先做任务解析判断这是一个“文本处理 格式整理 输出文件”的任务。它随后调用模型接口生成正文同时调用文件工具把内容写入指定目录最后再按行数、段落完整性做一次校验把结果回传到你的手机。这里的每一个环节都可能坏掉指令没有落到 agent 对应的 handler 里模型返回内容被截断文件写入权限不足回传消息时格式丢失。所以收到任务后不要直接看最终文本漂不漂亮先看任务日志里的执行路径确认每一步都标记为成功。3.2 234 行对照稿的验收标准“234 行”听起来是一个很具体的数字但实际跑任务时更重要的是行数之外的结构标准。我这次的对照稿要求是原文段落与产出内容逐行对应每一行都有明确的行号不能出现段落合并、内容丢失、序号错乱。我把验收标准拆成以下几条行数是否精确匹配多一行或少一行都要查原因。行号是否连续中间不能因为换行符处理不当跳号。段落内容是否完整长文本不能被模型截断到一半。输出文件的编码格式是否正常用 Excel 或文本编辑器打开不出现乱码。回传结果里是否包含文件路径方便在电脑上二次检查。这也是我建议用 agent 跑生成任务时一定要做的事先定义验收指标再跑生成。不要只给模型一句“生成一份 234 行对照稿”而是告诉它每一行需要包含什么、行号怎么编号、文件输出到哪个目录。3.3 第一次跑任务时最容易卡住的位置第一次跑手机派活最容易卡住的不是模型回复而是任务根本没有被正确触发。我自己遇到过三种典型情况。第一种手机消息发出去了agent 没有任何反应。排查后发现是消息通道的 webhook 配置错了手机端发的消息根本没有到达 agent 服务。第二种任务开始执行了但输出目录没有权限生成到一半就报错。第三种模型返回正常但 agent 在写文件时用了错误的编码导致中文字符全部乱码。我建议第一次跑任务时不要用完整内容先给模型一小段样例路径也尽量用本地绝对路径。跑通之后再把任务规模和输入内容放大。这样每次只引入一个变量问题定位会快很多。注意不要一开始就跑到 234 行先用 10 行样例验证链路。链路通再上规模链路不通再多的生成能力也白搭。4. 录屏学活把操作流程变成可复用的技能4.1 录屏学活到底在解决什么问题“录屏学活”是这次标题里另一个值得拆开讲的能力。它听起来很像“AI 看视频学会操作”但在工程上更准确的表述是把一段操作录屏作为参考素材让 agent 拆解出关键步骤再生成一个可复用的 skill 文件。这个能力解决的是“重复操作沉淀”的问题。比如你每天都要在某个后台里导出表格、改文件名、上传到指定目录如果每跑一次都重新描述一遍agent 每次都要重新理解效率很低。把操作过程录下来让 agent“学”一遍它就能把步骤结构化之后同类任务直接调用技能。4.2 从录屏到 skill 的四个步骤我这里用 OpenClaw 的 skill 机制举例Hermes 如果有类似能力思路也通用。第一步录制一段 30 到 60 秒的短操作视频。录屏内容要单一一个视频只做一件事不要夹杂多个不相关流程。画面清晰度不用太高但关键点击位置、界面字段要能看清。第二步把录屏文件放到 agent 指定的素材目录并写一段任务描述。描述里要说明这个操作的目标是什么、输入是什么、输出是什么。你不能只放一段录屏让 agent 自己猜agent 不是人它需要上下文。第三步让 agent 抽取关键步骤。它会把录屏里的操作转成文字步骤比如“打开页面 - 点击导出 - 等待下载完成 - 修改文件名为日期格式”。这一步完成后你要人工检查步骤是否准确有没有漏掉等待时间、异常判断等隐性操作。第四步把确认后的步骤写成 skill 文件。skill 文件里一般会包括触发场景、输入描述、执行步骤、输出结果、常见错误处理。之后你再发一条新任务测试这个 skill 能不能被正确识别和调用。4.3 录屏素材的边界和隐私处理录屏学活不是万能的它对任务类型有明显边界。适用的是规则明确、重复性高、界面稳定的操作。不适用的情况包括操作界面经常变化、需要大量模糊判断、录屏里有大量无关信息、操作依赖人的直觉。还有一个必须重点提醒的点隐私和合规。录屏前先检查屏幕内容确保没有密码、个人敏感信息、内部数据、客户信息。如果业务环境敏感建议用模拟数据录制或者录制前先脱敏。录屏文件也不要长期保存在 agent 的数据目录里学完步骤确认 skill 可用后就可以把原始录屏归档或者删除。5. 邮件只进草稿箱自动化也要留人工审批口5.1 为什么不能直接让 agent 点发送这次流程里我最坚持的一个设计就是邮件只进草稿箱绝不让 agent 直接发送。原因不是 agent 写不了邮件而是你无法完全控制它不会在错误的时间、把错误的内容发给错误的人。AI 生成邮件时收件人、主题、正文、附件都可能出问题。收件人解析错误、正文里出现幻觉信息、附件路径写错这些都是真实可能发生的。如果走的是直接发送一旦出错就没有挽回余地。让邮件只进草稿箱等于在自动化和人工控制之间加了一道闸门。agent 负责完成 90% 的重复劳动生成草稿、填好主题和收件人然后把决定权交还给人。人只需要打开草稿箱快速扫一遍检查没有问题再点发送。5.2 草稿流程怎么实现实现思路并不复杂。核心是agent 调用邮件服务时只走“创建草稿”接口不走“发送”接口。如果你用的是 SMTP/IMAP 这类协议可以让 agent 上传到 Drafts 文件夹但不调用 send 指令。如果你用的是邮件服务商的 API通常有单独的 createDraft 方法agent 只需要调用这个方法创建成功后会返回草稿 IDagent 把草稿 ID 回传给你。判断是否成功有三条标准草稿箱里能看到这封邮件收件人、主题、正文、附件都不缺邮件系统没有任何自动发送逻辑。比如某些服务商的定时发送功能可能默认开启需要检查一下。5.3 草稿不等于不会发常见误区和检查点“进入草稿箱”不等于“绝对安全”我自己就遇到过几个坑。第一个坑是某些邮件 API 创建草稿之后如果配置了规则或者自动转发草稿可能会被自动处理。第二个坑是agent 在批量创建多封草稿时如果命名没有加任务 ID 或时间戳人工在草稿箱里根本分不清哪封对应哪个任务。第三个坑是某些平台的草稿接口和发送接口共用权限一旦权限范围过大误调发送接口的风险也变大。所以我在落地时额外做了几件事每一封草稿的主题前加固定前缀比如“【Agent 草稿】任务编号”。草稿创建后agent 必须回传草稿标题、收件人、创建时间方便手机端快速核对。权限设置只授予创建草稿所需的范围不授予发送权限。定时检查草稿箱里是否有异常草稿避免 agent 因重复执行任务生成大量重复邮件。注意邮件只进草稿箱核心不是“能不能生成”而是“不能乱发”。宁可多一道人工确认也不能把发送权完全交给自动化流程。6. Grok Bot 与 OpenClaw、Hermes 的对照结论6.1 三组关键能力对照跑完这一轮我把三个角色放在几个维度上做了一个对照列出来给同样在选型的人参考。对比维度Grok BotOpenClawHermes主要定位对话式助手自部署 agent 执行框架自部署 agent / 模型服务方案部署复杂度低开箱即用中高需要规划环境中高需要按系统适配自主任务能力弱依赖人提问强可以拆步骤调工具强可按框架能力实现本地数据控制一般可以完全本地可以完全本地消息通道接入不擅长可接微信、飞书、Webhook按部署方式接入技能沉淀基本没有skill 文件可复用看框架是否支持安全审批机制弱可以设计可以设计适合场景临时问答、思路讨论长期自动化执行长期自动化执行或模型服务这个表格不是想做“谁赢谁输”而是告诉你这三样东西完全可以组合起来用。Grok Bot 负责你坐在电脑前的高频问答OpenClaw 和 Hermes 负责你不在电脑前的时候自主干活。6.2 我最后是怎么分工的这次实测我最后的分工是Grok Bot 放在对话入口处理临时性、探索性的问题。比如“这个方案有没有漏洞”“这句话换个说法更好吗”它给我的价值是即时反馈不需要我打开另一个系统。OpenClaw 承担主要执行任务。手机派活、生成对照稿、调用 skills、处理文件、通过消息通道回传结果都交给它。原因是它的 skill 机制让重复任务能沉淀我只需要维护好 skill 文件新任务新轮次都能复用。Hermes 我主要用于对照验证。同一个任务我会在 OpenClaw 上跑一遍再在 Hermes 上跑一遍对比结果稳定性和执行日志。遇到奇怪的报错时这个双跑对照能帮我快速确认是模型问题还是框架问题。6.3 判断一个 agent 框架能不能用别只看聊天界面很多人评测 agent 时只看“对话回得好不好”这是最容易误判的地方。真正决定 agent 能不能用的是以下几个更底层的能力任务能不能稳定触发10 次里有几次成功。日志是否可读出问题的时候能不能快速定位。有没有失败重试任务中断后能不能断点续跑。输出命名是否规范批量任务里能不能区分每个结果。权限边界是否清晰agent 能碰什么、不能碰什么都要明确。我在部署 OpenClaw 和 Hermes 时最深的感受是模型能力大家都差不多差距主要在执行稳定性。能稳定跑完 100 个任务比单次生成效果惊艳重要得多。7. 常见问题与排查链路7.1 部署、初始化与模型连接问题社区里被问得最多的部署问题我这里按频率整理一下。“初始化失败”是最高频的问题。原因是多方面的最常见的三个是目录权限不足、依赖版本不对、网络无法访问模型端点。排查时先看初始化日志日志里通常直接写了失败在哪一步不用瞎猜。“模型连接超时”排在第二位。如果你用的是本地模型先确认 Ollama 或 NIM 服务是否在监听对应端口如果用云端 API先确认 API Key 是否正确、网络是否放开。有一个判断技巧先用 curl 直接请求模型端点如果返回正常问题大概率出在 agent 的配置上。“不知道装哪个版本”也是高频问题。我建议直接看仓库当前分支和 release 说明不要用网上零散的旧命令。版本不一致导致的诡异报错比功能本身的问题更难查。“麒麟、Kali、U 盘安装失败”本质是环境依赖缺失。解决办法是安装时打开详细日志遇到缺什么库就补什么库不要跳过依赖检查。7.2 消息通道、任务执行与输出异常部署完 agent 之后真正进入长期使用阶段问题更多集中在消息通道和任务执行上。“手机发消息 agent 没反应”先查消息通道配置。微信、飞书、Webhook 三者的消息格式和回调机制都不同不能混用。先用一条最简单的文本消息测试不要一上来就发复杂指令。“任务启动了但输出为空”先查输入文件和提示词。很多情况下不是 agent 没干活而是它读到的文件是空的或者输入路径错了。打开日志看它实际读取的文件路径比反复调整提示词更高效。“输出内容被截断”先看模型上下文长度限制和输出最大 token 设置。长文本任务要提前判断内容是否超出单次输出能力如果超出就要拆成多段处理不能硬让模型一次写完整篇。“文件写入乱码”先看编码配置。Windows 和 Linux 的默认编码不同agent 写文件时如果没指定 UTF-8很容易出现中文乱码。统一在配置里写死编码格式能避免这一类问题。7.3 我优先排查的顺序如果你只记住一个排查原则那就是先看现象能不能稳定复现再看日志再看输入再看环境最后改参数。每次任务异常我按下面这个顺序来先确认现象是完全没执行还是执行到一半失败还是执行完但结果不对。打开任务日志找到对应时间段的执行记录。检查输入文件路径、格式、内容是否完整。检查环境磁盘空间、内存、端口、权限。检查参数并发数、超时时间、输出目录、模型端点。最后再考虑是不是框架版本的兼容问题。这个顺序能覆盖绝大多数问题。不要一上来就怀疑模型能力很多时候只是路径错了或者权限不够。8. 落地时最值得盯住的几个判断点这套“手机派活、agent 执行、邮件只进草稿箱”的工作流真正落地时最该盯住的不是功能列表而是四个判断点任务能不能稳定触发结果能不能稳定回传技能能不能沉淀复用安全边界是不是清楚。如果你正在自己部署 OpenClaw 或 Hermes我的建议是先跑两周小规模任务每天只跑几条重点观察日志和失败率。不要一上来就接微信、飞书、批量任务先把单条任务跑稳再把通道接进来最后再考虑复杂审核流程。踩过几次坑之后我发现这类 agent 项目真正磨人的不是“模型写得不够好”而是前置环境、消息通道和输入材料没有处理干净。把这些基础问题解决掉12 分钟交稿、邮件只进草稿箱、录屏生成技能这些能力都是水到渠成的事。
算法精解与面试技巧)
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
