最近通勤路上我发现一个很实用的玩法人还没到公司家里一台常开的电脑已经把活干完了。手机下发一段话12 分钟后收到一份 234 行的对照稿录了一段操作视频第二天 Agent 就已经学会了类似流程邮件任务也只停在草稿箱等我审核后再发。这背后不是某个神秘工具而是 OpenClaw 和 Hermes 这类自部署 Agent 框架搭配云端助手 Grok Bot 一起使用的结果。这篇文章我会围绕“合上电脑活照干”这个真实场景把 Grok Bot、OpenClaw、Hermes 三者之间的分工对比、部署思路、手机派活、录屏学活、邮件草稿安全边界以及一份可复用的实战案例完整拆开来讲。无论你是刚接触 AI Agent 的新手还是已经在折腾本地模型的老手这篇文章都能给你一套能落地的参考方案。1. 为什么要在“合上电脑”之后还养几个 Agent 干活1.1 一个典型的“手机派活”场景先还原一下我日常遇到的场景早上出门前我在地铁上用手机给家里的常开电脑发了一条任务根据某份接口文档生成新旧接口对照表要求输出 234 行左右。电脑上的 Agent 框架收到消息后自动读取本机文档、调用大模型、生成表格、写入指定文件再把结果回传给我。全程我不用打开电脑也不用盯进度人在地铁上活已经落地了。这个过程听起来像远程控制但本质不一样。远程控制需要你实时操作而 Agent 框架收到的是“意图”它自己拆解任务、调用工具、写文件、回报结果。把这一套跑通以后你能明显感受到“合上电脑活照干”不是夸张而是 Agent 无人值守能力的真实体现。1.2 Grok Bot 与自部署 Agent各管一段很多人会问既然有 Grok Bot 这种云端助手为什么还要自己部署 OpenClaw 和 Hermes答案很简单职责不同。Grok Bot 这类云端对话助手优势是开箱即用、理解能力强、多轮对话体验好。你随时打开手机提问它都能给你一个不错的回答。但它有一个天然限制它活在云端访问不了你电脑上的文件也执行不了你本地的脚本更不可能替你挂一个微信机器人。而 OpenClaw 和 Hermes 这类自部署 Agent核心优势正好补上这段空白它们运行在你自己的电脑上可以直接读写本地文件、执行命令、调用 API。它们可以通过 IM 渠道微信、飞书等接收任务相当于给电脑装了一个“远程遥控器”。它们支持对接本地模型比如 Ollama、NVIDIA NIM不依赖外部服务数据不出本机。它们可以连续数小时、数天无人值守运行适合处理批量、定时、后台任务。所以我的做法是Grok Bot 负责在手机上做“大脑”快速讨论方案OpenClaw 负责“接手干活”Hermes 负责“本地精细化处理”。三个角色各管一段组合起来才是完整的“活照干”。1.3 本文会讲什么这篇文章不是简单介绍某个工具的用法而是围绕我实际跑通的几条链路展开OpenClaw 是什么、Hermes 与它怎么分工环境准备阶段需要哪些东西模型接口怎么选手机派活怎么打通录屏学活怎么设计邮件为什么只进草稿箱一个完整的“自动生成 234 行对照稿”实战案例常见报错与排查思路以及我在工程化落地中总结的注意事项。下面进入正题。2. OpenClaw 与 Hermes 是什么先弄清楚概念再上手2.1 OpenClaw可部署、可接入 IM 的 Agent 运行时OpenClaw 从定位上看更像一个 Agent 运行时框架。它不会强制你使用某个模型而是把“模型调用、工具调用、消息渠道、任务调度”这些模块组合在一起。我理解它的核心能力有三点多渠道接入可以让 Agent 通过微信、飞书等 IM 工具接收消息这是“手机派活”的基础。工具调用Agent 可以根据任务内容调用本机脚本、读写文件、请求 API这是“自动执行”的基础。技能扩展你可以把常用流程沉淀成 skill后续同类任务直接复用这是“录屏学活”的最终产物。OpenClaw 的一大特点是支持自定义部署位置。有人把它装在 Windows 台式机上有人装在 Linux 服务器上也有人装在麒麟这类国产桌面系统上。部署方式不同本质上不影响 Agent 的核心工作方式只是环境适配细节有差异。2.2 Hermes桌面级智能体擅长本地任务Hermes 和 OpenClaw 相比更偏向桌面端的智能体。它的优势在于和当前操作系统结合得更紧密能处理截图识别、图像理解、文件整理、代码片段生成这类本地任务。也有不少人在讨论 DeepSeek Hermes 这类基于特定模型的变体说明 Hermes 在模型适配上的生态比较丰富。在实际使用中我习惯把 Hermes 当成“本地精细活执行器”处理录屏视频拆解操作步骤识别截图内容提取界面信息生成代码或文档片段直接落到本地文件调用本地模型做离线推理保证数据不出内网。所以OpenClaw 更偏“任务入口和调度中心”Hermes 更偏“本地执行终端”。两者可以单独使用也可以组合成一条链路手机发消息给 OpenClawOpenClaw 把任务拆好再交给 Hermes 在本地执行。2.3 和 Coze、Dify 这类平台有什么区别很多接触过 Agent 的同学会问Coze、Dify 以及 WorkBuddy、OpenClaw是不是同一种东西它们确实有重叠但定位不完全一样。Coze 和 Dify 更像“可视化 Agent 搭建平台”你可以在网页上拖拽节点、配置工作流、发布机器人平台帮你托管运行。优点是上手快缺点是很多执行环境在云端访问本地资源受限。OpenClaw 和 Hermes 更偏向“自托管运行时”。代码和配置都在自己的机器上你可以给它开放文件系统权限、内网 API 权限、数据库权限。安全性由你自己控制灵活性更高。可以简单理解为Coze / Dify适合快速搭建业务机器人交付快但深度定制受限。OpenClaw / Hermes适合需要本地文件读写、无人值守运行、IM 深度集成的场景。如果你只是做一个客服问答机器人Coze 完全够用。如果你想让 Agent 替你写文件、跑脚本、处理本地录屏那 OpenClaw Hermes 更合适。3. 环境准备从一台常开电脑开始3.1 硬件与操作系统“合上电脑活照干”的前提是有一台常开电脑。我这里用的是普通 Windows 台式机配置不算高16GB 内存加一块中端 GPU。OpenClaw 对硬件要求不算高真正吃资源的是模型推理。操作系统方面OpenClaw 在 Windows、Linux 上都有用户踩过路。从网络上的讨论来看Linux 安装 OpenClaw 也是一种常见用法甚至有人专门在 Kali Linux 里做测试。对我来说Windows 的好处是桌面软件生态全而 Linux 的好处是后台运行更稳定。这里不纠结哪个更好关键是看你的 Agent 需要访问什么资源。如果你要在家里部署建议优先选择一台“不关机、不断网、不睡死”的机器。Windows 记得在电源设置里关闭睡眠Linux 记得配置好自动重启后的服务拉起。3.2 模型接口云模型与本地模型Agent 框架本身不产生内容它需要一个大模型来理解和生成文本。模型接口通常有三种选择第一种是直接用云端模型 API。这种方式效果稳定、能力最强适合对结果质量要求高的任务。比如把 OpenClaw 配置成调用 OpenAI 兼容接口只要填 base_url、api_key、model_name 就能跑起来。第二种是用本地模型。安装 Ollama 后可以拉取 Qwen、Llama 等开源模型。本地模型的优势是免费、离线、数据不出本机但效果和速度取决于你的显卡。我平时会跑 7B 到 14B 规模的小模型做分类、提取、格式化效果基本够用。第三种是混合模式。云端模型负责复杂推理本地模型负责简单任务。这样既能保证质量又能控制成本。下面是一个常见的 OpenAI 兼容接口配置示例很多 Agent 框架都支持这种格式# .env 或配置文件示例具体变量名以官方文档为准 AGENT_MODEL_PROVIDERopenai-compatible AGENT_MODEL_BASE_URLhttp://127.0.0.1:11434/v1 AGENT_MODEL_NAMEqwen2.5:14b AGENT_MODEL_API_KEYollama注意如果你的框架支持 NVIDIA NIM也可以把 base_url 指向 NIM 提供的本地推理服务。NIM 的优势是把模型封装成标准 API部署在 GPU 机器上调用方式和云端几乎一样。3.3 目录结构与配置项规划部署 Agent 之前先想清楚目录结构能省很多麻烦。我一般会这样规划agent-home/ ├── config/ # 配置文件 │ └── agent.yaml ├── skills/ # 技能/流程定义 │ ├── generate_doc.yaml │ └── learn_from_video.yaml ├── tasks/ # 任务输入输出 │ ├── input/ │ └── output/ ├── logs/ # 运行日志 └── scripts/ # 本机脚本配置项方面最核心的是三个部分模型配置用什么模型、接口地址、密钥。渠道配置接入微信还是飞书回调地址是什么。权限配置允许 Agent 访问哪些目录、执行哪些脚本。权限配置很容易被忽略但它恰恰是最重要的。如果你给 Agent 开放的权限过大它可能误删文件或者执行危险命令。后面的最佳实践部分我会专门展开。4. 核心能力拆解手机派活、录屏学活、邮件草稿4.1 手机派活打通 IM 与任务队列“手机派活”听起来很玄其实链路不复杂手机消息 → IM 接口 → Agent 框架 → 任务解析 → 工具执行 → 结果回传。我用的方式是把 Agent 接入微信个人号。你不用理解太复杂的原理只要知道当你在手机上给 Agent 发一条消息时它收到的不只是文本而是一个“任务起点”。Agent 会先判断这条消息是闲聊、指令还是带文件名/ URL 的复杂任务然后决定走哪条执行路径。要打通这条链路一般需要做三件事安装并配置 IM 适配插件让 Agent 能收发消息在配置文件中声明允许接收消息的账号名单设置关键词或指令前缀避免任何消息都触发任务。比如你可以约定只有以#task开头的消息才进入任务队列其他消息走普通对话。这个设计能有效避免误触发因为在无人值守场景下误触发带来的问题比不触发还要麻烦。4.2 录屏学活把操作过程沉淀成 skill“录屏学活”是我最近在尝试的一个方向思路是把我操作软件的屏幕录制视频交给 Agent让它拆解步骤然后把步骤固化成一个 skill下次直接复用。这个能力很有价值因为很多重复性工作本质上是一连串固定操作打开某个软件、导入文件、点击某个按钮、导出结果。如果 Agent 能通过看录屏学会这套流程那它就能从“只会处理文本”升级成“会操作软件”。我目前的实现思路是这样用录屏工具把一次完整操作录下来保存为 MP4。把视频交给 Hermes它先用视觉能力截取关键帧识别界面内容。结合每一帧的界面差异生成操作步骤文本。把步骤整理成结构化 YAML skill 文件导入 OpenClaw。下次同类任务Agent 直接读取 skill 流程执行需要时调用本机脚本模拟操作。下面是一个 skill 文件的结构示例具体关键字需要看你的框架支持哪种格式name: export_report_from_excel description: 根据录屏学习到的流程从 Excel 导出统计报告 steps: - action: open_application target: excel args: file: {{input_file}} - action: wait seconds: 3 - action: click_menu path: [文件, 导出, PDF] - action: wait seconds: 5 - action: verify_output expect: output.pdf 已存在这个流程还不算完美因为视觉识别出来的步骤不一定完全可靠尤其是界面有弹窗或者分辨率变化的时候。但它的意义在于Agent 不再只会“回答”而是在“学习操作”。4.3 邮件只进草稿箱Agent 自动化的安全边界邮件是最典型的“高风险自动化场景”。让 Agent 直接发送邮件一旦内容出错、收件人写错后果很难撤回。所以我的原则很明确Agent 可以把邮件写好但只能放进草稿箱最终发送动作必须由人来确认。这个设计既保留了自动化效率又守住了安全边界。比如 Agent 每天帮我把工作邮件摘要、回复建议、周报初稿全部生成好放进草稿箱。我只需要打开邮件客户端快速审核点一下发送即可。实现思路也很直接Agent 调用邮件 API 时创建一个 draft 资源而不是直接 send。下面是一个 Python 风格的思路示例具体 API 需要根据不同邮件服务调整def create_email_draft(to_addr, subject, body): # 1. 调用邮件服务 API创建草稿 # 2. 填充收件人、标题、正文 # 3. 不调用 send 接口只保存为 draft draft mail_client.drafts.create( toto_addr, subjectsubject, bodybody, saveTrue ) return draft.id注意这里的代码是思路示例不是可直接运行的完整代码。实际项目中你的邮件服务可能是 Exchange、IMAP 邮箱或某个云服务 API创建草稿的接口都不一样需要按官方文档调整。把邮件做成“只进草稿箱”还有一个额外好处人工审核环节保留了大模型可能犯错的最后一道防线。你不需要完全信任 Agent 的措辞只要把它当成一个“高效助理”负责打草稿你负责把关。4.4 自动产出 234 行对照稿任务示例标题里提到的“12 分钟交 234 行对照稿”是我用来验证整套链路的一个具体任务。当时的任务背景是我有一份旧接口文档和一份新接口文档需要生成一份对照稿按模块列出每个接口的路径、请求参数、响应字段、变更类型和备注。逐行手工整理至少要半天用手机派给 Agent12 分钟后就收到了结果。Agent 的执行过程大致是从微信消息中解析出两个文档路径。读取本地文档提取接口列表。调用大模型进行语义比对生成变更标记。按 Markdown 表格模板输出 234 行对照稿。写入 tasks/output 目录并把结果摘要回传。这个任务能跑通的关键不在于模型多强而在于我把“拆解任务”这一步做得足够细。Agent 不需要一次性理解整篇文档它只需要按步骤执行先提取再比对再生成最后校验。5. 完整实战让 Agent 在无人值守时完成“对照稿”任务5.1 任务描述与设计这一节我们把上面的场景还原成一个可以复用的实战流程。假想任务如下输入旧接口文档old_api.md新接口文档new_api.md。 输出一份 Markdown 对照稿api_compare.md包含接口路径、请求方式、变更类型、变更说明预计 200 行左右。为了让 Agent 能稳定完成我们需要把任务拆成四个阶段阶段动作产出1. 读取读取两个文档内容结构化接口列表2. 提取提取接口路径、方法、参数接口清单 JSON3. 比对对比新旧文档差异变更类型与说明4. 生成写入 Markdown 模板api_compare.md注意不要让 Agent 自己决定“怎么干活”而没有任何约束。明确输入、输出和步骤才能保证 12 分钟交付而不是 12 小时空转。5.2 配置任务模板为了让同类型任务能被复用我建议把任务流程写成模板文件。下面是一个简化版的任务定义示例放在tasks/input/task_compare_api.json{ task_type: compare_docs, input: { old_doc: old_api.md, new_doc: new_api.md }, output: { path: tasks/output/api_compare.md, template: markdown_table }, constraints: { max_lines: 300, must_include: [接口路径, 请求方式, 变更类型, 变更说明] }, callback: wechat }这样做的意义是手机派活时不需要在消息里写完整需求只需要说“按tasks/input/task_compare_api.json跑一次接口对照”。Agent 读取任务定义文件就知道该做什么。5.3 编写执行脚本接下来是核心执行逻辑。我用 Python 写一个脚本负责读取任务配置、调用模型、生成结果。这里给出一个可运行的核心示例重点是展示流程而不是完整工程代码# 文件路径scripts/run_compare_task.py import json import subprocess from pathlib import Path def load_task_config(config_path: str) - dict: with open(config_path, r, encodingutf-8) as f: return json.load(f) def extract_api_list(doc_path: str) - list: # 实际项目中可能用模型做信息抽取 # 这里简化处理直接读取 Markdown 中的接口标题行 result [] with open(doc_path, r, encodingutf-8) as f: for line in f: if line.strip().startswith(###) and /api in line: result.append(line.strip().lstrip(#).strip()) return result def generate_compare_content(old_list: list, new_list: list) - str: # 用模型或规则生成对照内容 # 这里用简单规则示意实际替换为模型调用 lines [| 接口路径 | 请求方式 | 变更类型 | 变更说明 |, | --- | --- | --- | --- |] for item in old_list: lines.append(f| {item} | GET | 未变更 | 保持原样 |) for item in new_list: if item not in old_list: lines.append(f| {item} | POST | 新增 | 新增接口 |) return \n.join(lines) def main(): config load_task_config(tasks/input/task_compare_api.json) old_doc config[input][old_doc] new_doc config[input][new_doc] output_path Path(config[output][path]) output_path.parent.mkdir(parentsTrue, exist_okTrue) old_list extract_api_list(old_doc) new_list extract_api_list(new_doc) content generate_compare_content(old_list, new_list) output_path.write_text(content, encodingutf-8) print(f任务完成输出文件{output_path}) if __name__ __main__: main()这是一个人工规则版本实际项目中你可以在generate_compare_content里调用大模型让模型理解语义差异并生成变更说明。脚本的核心是“输入输出清晰、可重复执行”。5.4 通过手机下发任务当脚本和任务模板都准备好之后手机派活就变得非常简单。假设 OpenClaw 已经接入微信并且配置好了一个run_taskskill那我在地铁上只需要发这样一条消息#task run tasks/input/task_compare_api.jsonOpenClaw 收到消息后会根据#task前缀判断这是一个任务指令然后解析参数调用run_taskskill最终在电脑上执行刚才的 Python 脚本。执行完毕后OpenClaw 会把脚本输出的摘要回传到微信例如任务完成。 输出文件tasks/output/api_compare.md 总共生成 234 行包含 58 个接口对比项。整个过程中你的手机只是发了一条消息、收到一条回执中间步骤全部在电脑端自动完成。5.5 收尾与结果校验最后一步是校验结果。绝不能直接信任 Agent 的“任务完成”回执必须看文件内容。我的校验方法是人工抽查打开输出文件随机看 10 行内容确认格式正确、内容合理。行数校验用命令统计行数是否在预期范围。关键字校验检查是否包含必须出现的字段。# 校验行数 wc -l tasks/output/api_compare.md # 校验关键字 grep -c 接口路径 tasks/output/api_compare.md如果输出不符合要求不要急着改代码先看日志确认是模型理解问题、文档解析问题还是模板渲染问题再针对性修复。6. 常见问题与排查思路无人值守场景下Agent 出问题不可怕可怕的是你不知道它为什么出问题。下面整理几个我在使用 OpenClaw 和 Hermes 过程中遇到过的高频问题。问题现象常见原因解决思路微信消息发送后无响应Agent 未连接 IM 接口或进程已退出检查进程状态查看日志确认消息是否进入队列任务执行到一半卡住模型接口超时或脚本等待用户输入给模型调用设置超时时间避免脚本读取 stdin输出文件生成但内容为空文档解析逻辑没有匹配到内容单独测试文档提取函数输出中间结果模型回答格式不稳定提示词没有明确输出格式在提示词中增加 JSON/Markdown 格式约束录屏学习生成的步骤错误关键帧截取太少或界面有弹窗增加关键帧数量加入人工校验环节邮件草稿没有出现邮件 API 权限不足或草稿接口调用错误检查 API 权限确认是否调用了 create-draft 而非 send下面挑两个典型问题展开说明。第一个是“微信消息发送后无响应”。这类问题首先不要怀疑 IM 插件坏了而要先确认消息是否真的到达了 Agent。查看日志时重点看两条记录是否收到消息、是否生成响应。如果日志里连收消息的记录都没有那就是 IM 接入层的问题如果有收消息记录但没有响应才是模型或任务执行的问题。排查顺序建议是IM 接入 - 消息解析 - 模型调用 - 工具执行 - 结果回传一层一层看日志不要跳级。第二个是“模型回答格式不稳定”。自部署 Agent 最常见的坑就是你要求模型输出 JSON它偏要在 JSON 外面加一段解释文字。解决思路有两个一是在提示词里明确格式说明二是在代码里做容错解析比如从文本中提取第一个{到最后一个}之间的内容再反序列化。两方面配合格式稳定性会好很多。7. 最佳实践与工程建议7.1 任务设计把大任务拆成可校验的小步骤Agent 自动化最忌讳“一句话大需求”。比如“帮我整理所有接口文档然后生成报表”这种需求不仅模型难以理解你也没法验收。正确做法是拆成小步骤每个步骤都有输入、输出、校验点。我一般遵循这个原则单次任务只做一件事。 输入必须明确。 输出必须可校验。 失败必须有反馈。任务拆得越细Agent 的成功率越高你排查问题的范围也越小。这个结论在不同 Agent 框架上都成立。7.2 权限与安全最小权限、草稿箱、沙箱执行自部署 Agent 的能力越强风险越大。它能读写你的文件就能误删你的文件它能执行命令就能执行错误命令。所以权限设计必须有边界。建议至少做到四点给 Agent 只开放特定目录的读写权限不要开放整块磁盘。涉及发送类操作邮件、消息、API 请求一律要求人工确认邮件生成后只进草稿箱。高危操作放到沙箱环境执行或者要求二次确认。所有工具调用都记录日志便于事后审计。邮件“只进草稿箱”就是我一直在坚持的安全底线。自动化的目的是节省时间而不是制造风险。宁可多一次人工确认也不要让 Agent 掌握完整的发送权限。7.3 日志与可观测性无人值守的 Agent 就像黑盒如果日志不完整出了问题你根本不知道从哪里查起。建议从三个维度做日志消息日志记录何时收到谁发的什么消息。任务日志记录任务 ID、步骤状态、耗时。工具日志记录脚本执行命令、输入参数、执行结果。日志不要只写普通文本尽量带上时间和任务 ID方便把一段链路串起来。7.4 模型选型与成本控制模型选型直接影响任务效果和成本。我的经验是简单格式化任务用本地小模型7B 左右速度够快成本为零。复杂语义理解任务用云端大模型效果更稳定。混合模式先让本地模型做预处理再让云端模型做核心判断。如果你在 Linux 服务器上跑推荐配置 Ollama 接入本地模型再让 Agent 框架通过 OpenAI 兼容接口调用。这种方式对硬件要求低部署也简单。如果机器有 NVIDIA GPU可以考虑 NVIDIA NIM性能和延迟会更优。7.5 生产环境必须做的几件事如果这套 Agent 要用于真正的生产环境以下事项不要跳过使用专门的机器或虚拟机不要和日常办公共用一套环境。对 Agent 的代码目录定期备份包括 skills 和任务产物。Agent 进程崩溃后要能自动重启可以通过 systemd 或任务计划程序实现。模型 API 密钥不要明文写在代码里使用本地环境变量文件管理。每次调整配置前先备份当前可用版本方便回滚。8. 总结与下一步这次“合上电脑活照干”的实践本质上是把三件事串起来了用 Grok Bot 这样的云端助手做方案沟通用 OpenClaw 做任务入口和调度用 Hermes 做本地精细执行。手机派活负责发起动作录屏学活负责沉淀经验邮件只进草稿箱负责守住安全边界。链路并不复杂但每一条都有值得注意的细节。如果你也想搭建一套类似的 Agent 环境下一步建议从一个小任务开始不要一上来就追求大而全。先把部署跑通再接入一个 IM 渠道然后做一个最简单的“手机发指令、电脑执行脚本”闭环。跑通以后再逐渐加录屏学习、邮件草稿这些进阶能力。最后给你留一个可以马上动手的小练习找到你日常工作中最重复的一个操作录一段屏让 Hermes 帮你拆成 skill 步骤再让 OpenClaw 通过手机触发一次。你会很快感受到Agent 从“聊天玩具”变成“生产助手”的关键其实不在模型能力而在你如何把它嵌入真实的工作流。