上周出差客户临时要改汇总口径我在地铁上掏出手机打开微信里的邮件提醒把需求写进邮件正文发到工作邮箱。三分钟后办公室那台电脑上的 WorkBuddy 已经把数据重新跑完、表格改好把结果回信给我了。整个过程中我没开远程桌面没喊同事帮忙甚至没碰电脑。这套东西做出来之后我用了一年多也算踩了不少坑今天干脆把完整的思路、架构和实现细节都摊开来讲清楚。这套方案的核心就一句话把“远程操控电脑”从“人肉远程”变成“AI 代劳”。你在微信里顺手写一封邮件邮件就是指令电脑上常驻的 WorkBuddy 负责收信、理解任务、调用 AI 规划步骤、执行脚本、回传结果。它适合所有需要在外面让家里或办公室电脑干活的场景改表格、跑脚本、批量整理文件、生成报告、定时备份数据等等。不需要你有很深的编程功底但如果你会一点 Python下面这套东西基本可以照着抄。1. 为什么要做“邮件遥控电脑”这件事1.1 一个真实的远程救火场景先说一个很多人都会遇到的画面你人在外地电脑在办公室客户的邮件已经堆到“催办”状态。你需要的不是看文件而是让电脑上某个程序跑一遍、把某个目录里的文件重新归档、或者用一个已经写好的脚本生成一份报表。这种事听起来不难但真要远程操作第一步就卡住了——手机上没有办公电脑的环境远程桌面连上去又慢又卡光是在手机上敲键盘就够让人崩溃。我当时的需求更朴素我希望有一条“不占用我注意力”的通道把任务丢给电脑然后该干嘛干嘛去。就像你给同事发了一条工作消息同事做完之后回你一声。只不过这个“同事”不是人是运行在电脑上的 AI 助手。邮件恰好是这种异步通道的完美载体它可以排队、可以审计、可以带附件、可以在任何网络环境下收发而且微信本身就有邮件提醒你在聊天界面里就能收到“新邮件已到达”的推送点开就能转发或回复入口极其顺手。于是 WorkBuddy 的雏形就定为电脑上常驻一个服务通过 IMAP 协议定时检查邮箱发现符合约定的新邮件就交给大模型解析任务解析出明确的执行方案之后在白名单脚本范围内执行最后用 SMTP 把结果回信给你。整个链路里微信负责“人机交互”的第一公里邮件负责“传输与确认”AI 负责“从自然语言到可执行步骤”的翻译脚本负责“真正把活干了”。1.2 对比主流远程方案为什么只有这套组合最合适远程控制这件事市面上可选的方案非常多但每种的局限都很明显。远程桌面类工具比如向日葵、ToDesk、系统自带的 RDP胜在“所见即所得”但代价是操作链路长你得先在手机上打开客户端、等对方电脑响应、再在缩小的屏幕上找按钮。适合应急不适合高频的“让电脑自己干活”。SSH 类方案则更“极客”终端敲命令确实高效但手机上的终端体验一言难尽而且安全门槛不低——密钥管理、端口暴露、访问控制每一样都要花时间。更重要的是SSH 给到你的是一条命令通道而不是一个“能理解意图”的助手你依然要自己判断该跑哪条命令。还有一类是微信本身的生态功能比如文件传输助手、微信客服消息、以及各种 IoT 设备的微信控制。这些方案的问题是无法执行任意脚本只能触发预设的固定动作。如果我想“让电脑把本周的销售数据按新口径汇总并生成图表”预设按钮根本没法覆盖这种变化需求。而“微信 邮件 AI Agent”的组合刚好绕开了所有痛点。微信负责“提醒 快速编辑”你不用专门打开邮件 App邮件是标准、开放、可审计的协议收信和发信都有日志不会像私有协议那样被平台限制AI Agent 负责把模糊的自然语言指令翻译成可执行的脚本调用它是在电脑本地跑的管控权完全在自己手里。这套组合天然适合“异步、无人值守、需要一定智能判断”的远程任务。1.3 WorkBuddy 到底是个什么东西你可以把 WorkBuddy 理解成一个“收件即干活”的机器人管家。它不是一个需要另外安装的庞大平台本质上就是一个长期运行在电脑上的 Python 服务加上一套清晰的配置文件和几组脚本。它可以做到定时收取指定邮箱的未读邮件校验发件人是否在可信名单里把邮件标题和正文交给大模型让它提取任务意图根据意图从预先配置好的白名单脚本中选择一个或组合来执行把执行结果、日志、生成的文件通过邮件回复给发件人所有操作都留下日志方便事后回溯。名字里的“Work”强调它干的是具体活而不是像聊天机器人那样只给建议。它跟常见的代码结对助手也不一样代码助手比如各类 CodeBuddy偏向在 IDE 里帮你写代码、改代码而 WorkBuddy 更偏向操作系统层面的任务执行比如跑脚本、处理文件、调接口、生成报表。你可以把它理解成“能动手的 AI Agent”而不是“能聊天的 AI”。2. 整体架构与 AI 决策链路设计2.1 四层结构入口、解析、执行、反馈整套系统我习惯分成四层来看这样每一块的职责都很清晰出了问题也能快速定位。第一层是指令入口层。它解决的是“用户怎么把任务送进来”。我的选择是邮件配合微信的邮件提醒作为触点。邮件的好处前面说过这里再补一个关键细节邮件本身是纯文本的天然适合让 AI 解析。你不需要跟任何私有协议打交道也不需要担心平台接口变化只要邮箱服务商还支持 IMAP这套系统就能一直跑。第二层是解析决策层。这也是 WorkBuddy 的核心大脑。它拿到邮件后先做规则校验发件人是否在白名单、主题是否带约定的前缀标记。校验通过后把邮件正文发送给大模型接口让模型输出结构化的“行动计划”比如“执行哪个脚本、传什么参数、期望得到什么结果”。为了防止模型乱来我要求它只能输出 JSON而且“脚本名”必须从白名单里选模型没有权利发明一条系统命令。第三层是执行层。它干活的方式非常“笨”用 subprocess 去调用白名单里预先写好的脚本并且严格控制超时时间、工作目录、环境变量。这一层不接 AI只接明确的结构化指令。这样做是为了安全AI 可以有想象力但真正落在操作系统上的动作必须是可预期、可拦截的。第四层是反馈层。执行完成后把标准输出、标准错误、生成文件的附件通过 SMTP 发回给发件人。反馈内容我做了截断处理避免脚本输出几万行日志直接把邮件撑爆。如果有附件也会一并附上。这四层之间用队列和日志解耦。即使某一步失败前面的邮件已经处理过了不会重复消费后面的报错也会通过日志和邮件告诉你。2.2 AI 在这里承担什么角色从自然语言到操作计划AI 在 WorkBuddy 里不是执行器而是“翻译官”。它把一段口语化的中文比如“把桌面上的销售数据按区域汇总生成一个柱状图发给我”翻译成一份结构化的行动计划。为了让它翻译得准我在提示词里做了三件事一是限定输出格式。我让模型严格输出 JSON字段包括任务类型、选择的脚本名、脚本参数、执行优先级、备注。只要模型返回的不是合法 JSONWorkBuddy 就直接判定“解析失败”不会继续往下走。二是给模型一份“能力清单”。白名单里有哪些脚本、每个脚本是干什么的、支持哪些参数我都会通过系统提示词告诉它。这样模型是在“已知选项”里做选择而不是凭空造命令。我强烈建议这一步不要偷懒能力清单写得越细模型理解偏差就越小。三是要求模型先思考再输出。我在提示词末尾加了一句“请先基于邮件内容判断任务是否在你的能力范围内如果不在请把 action 字段置为 unsupported”。这样可以避免模型硬生生把一个复杂的任务映射到一个无关脚本上。实测下来加上这一句之后误执行率明显下降。模型的接入我采用 OpenAI 兼容接口的方式这样不管是商用大模型 API还是本地部署的模型服务只要能提供 HTTP 接口WorkBuddy 都能无缝对接。对延时要求高的场景我觉得本地模型更好对理解能力要求高的场景商用大模型接口更稳。两种都试过的感受是任务解析这种场景模型的理解能力和稳定性比响应速度更重要。2.3 任务协议设计让 AI 和人都能看懂所谓“任务协议”就是你和 WorkBuddy 之间约定的邮件格式。没有这个约定AI 解析就会像大海捞针一样没有抓手。我用的协议非常简单只有三条规则邮件主题必须以[WB]开头这样收信程序可以快速过滤无关邮件邮件正文第一行写任务目标后面可以随意补充背景资料、文件路径、特殊要求如果任务需要文件输入直接作为附件发送WorkBuddy 会把附件下载到工作目录后交给脚本处理。这套协议的好处在于它对人类来说非常自然你不需要学习复杂的命令语法对 AI 来说非常友好因为所有关键信息都集中在正文里对程序来说非常可靠主题前缀和发件人白名单两道过滤足以挡住 99% 的垃圾邮件和误触发。我还定义了一个“人工确认”扩展规则如果邮件正文里出现[confirm]标记WorkBuddy 执行前会先回一封确认邮件等你回复“确认执行”后才真正动手。这个规则在删除文件、批量重命名这类高风险操作上非常有用。刚开始你可以全部带[confirm]跑熟了再慢慢放开。3. 核心模块拆解与关键参数选择3.1 邮件接收模块IMAP 授权码与轮询策略邮件接收模块是整个系统最容易出问题的地方也是最需要小心配置的地方。我使用的是 IMAP 协议而不是 POP3原因是 IMAP 能保留服务器上的邮件状态程序把邮件标记为“已读”后你自己用手机还能看到邮件而 POP3 默认收信后服务器上就删了很容易造成邮件丢失。配置上有一个关键点账号密码不要直接用邮箱登录密码而是用邮箱服务商提供的“授权码”。比如常见的 QQ 邮箱、163 邮箱、企业邮在安全设置里都会有一个“开启 IMAP/SMTP 服务”的开关开启后会生成一串授权码专门给第三方客户端使用。这样做的好处是即使授权码泄露你随时可以在网页端撤销不影响邮箱登录密码安全。轮询策略我选的是“每 60 秒检查一次未读邮件”。这个频率在实用性和服务器压力之间比较平衡。如果你想做到“邮件发出几秒内就触发”可以研究一下 IMAP IDLE 扩展它能保持长连接实时推送新邮件到达事件但代价是连接稳定性要求更高断线重连逻辑写起来会复杂一些。我自己的经验是远程干活的场景通常不差那几十秒轮询 60 秒足够用了省心最重要。另外IMAP 连接是长连接还是短连接也需要根据你服务器的稳定性来定。我采用的是“每次任务循环新建连接、用完后关闭”的方式虽然多了一点连接开销但避免了邮箱服务器因为长时间空闲把连接踢掉这种常见故障。实测下来每 60 秒连接一次一天也就 1440 次连接对邮箱服务器来说几乎没什么压力。3.2 任务解析模块白名单与 Prompt 模板任务解析模块是 AI 发挥作用的地方。但请注意AI 的作用是“理解”和“规划”不是“授权”。我的做法是给模型一个写死的 Prompt 模板模板里包含当前可用的脚本清单、每个脚本的用途说明、参数约束、输出格式要求。模型只能在这个框架内输出结果不能自己发明脚本。Prompt 模板我大概长这样下面是一个简化版在系统提示词里写上“你是 WorkBuddy 的任务规划助手。用户会给你一封邮件的主题和正文请判断用户想做什么并从 available_scripts 列表中选出最合适的脚本。如果列表中没有合适的脚本请返回 actionunsupported。请严格输出 JSON不要输出任何解释”。然后 available_scripts 由程序从配置文件动态拼接到模板里确保模型看到的清单和实际可执行的脚本完全一致。这里有一个很容易踩的坑不要把模型返回的“脚本参数”直接拼进 shell 里用eval执行特别是不要让模型有机会传入;、|、这类 shell 元字符。我采用的解决方案是所有参数都通过列表形式传给 subprocess不经过 shell 解析并且在执行前用正则对参数做一次校验只允许字母、数字、下划线、短横线、点、斜杠和少量中文其他字符一律拒绝。温度参数我设置得比较低temperature0.2左右。任务解析这种场景我们希望模型输出尽量稳定、保守不需要它发挥创造力。温度调太高同一个任务每次解析出的脚本名和参数可能都不一样这对自动化系统来说是大忌。3.3 执行模块命令白名单、超时与结果回收执行模块是 WorkBuddy 的“手”。但我不想让 AI 直接操作这只手而是让 AI 只能挑选预先定义好的脚本。这些脚本都放在/home/wb/scripts/目录下并且是可执行的 shell 或者 Python 文件。WorkBuddy 在启动时会读取这个目录下的所有文件生成一份白名单。AI 输出里的脚本名必须能在这个名单里精确匹配到否则直接拒绝执行。超时控制也在这里做。每个脚本我默认给 120 秒的超时时间到期还没跑完就杀掉进程并记录超时日志。这个参数不是随便定的太短耗时的数据任务会被误杀太长一个卡住的脚本会一直占着资源。120 秒是我用了一年多以后觉得比较稳妥的值你完全可以根据自己的任务类型调整。我建议在配置里允许给单个脚本单独指定超时时间比如“生成月度报表”这种任务可能就需要 10 分钟。结果回收同样重要。Python 的subprocess.run会把脚本的标准输出和标准错误都捕获下来但我会对输出长度做截断比如标准输出最多取最后 2000 字符标准错误最多取 1000 字符。这样做的原因是脚本如果出现死循环打印邮件会被大量垃圾文本淹没反而看不到关键的错误信息。截断后配合一条“请查看服务器日志”的提示既保护了可读性也没有丢失问题线索。3.4 结果反馈模块SMTP 回信与附件任务干完了必须给人一个交代。反馈模块用 SMTP 发信把执行摘要、运行日志、生成的附件回传给发件人。这里的核心原则是反馈信息必须“一眼能看到结果”。我不会把日志原文直接放在邮件正文里而是先给一个结论成功、部分成功、还是失败然后再列关键信息最后附上日志。附件是一个容易被忽略但实际很刚需的能力。很多任务的结果就是一份文件比如 Excel 报表、PDF、图片、压缩包。WorkBuddy 会把工作目录下符合“产出文件”约定的文件自动作为附件添加。我的约定是脚本执行成功后如果在工作目录下发现output/文件夹有新的文件就自动打包或逐个附上。另外我会限制附件总大小不超过 20MB超过的话只回传文件的下载链接前提是你自己有一个文件服务或者干脆在邮件里提示“文件太大请到机器上查看”。邮件正文我还会加上“本任务由 WorkBuddy 自动执行”这样的标识避免日后翻邮件时产生困惑。这一点很实用特别是当你一个月会收到几十封这种自动回信时标识能帮你快速区分哪些是人在回、哪些是机器在回。4. 实操从零搭一个最小可用的 WorkBuddy4.1 环境准备与配置文件我以 Ubuntu 24.04 为例其他 Linux 发行版和 macOS 基本一样Windows 略有差异但不影响主体逻辑。准备三样东西Python 3.10 以上环境、一个支持 IMAP/SMTP 的邮箱、以及一台能长期开机的电脑。Python 依赖只需要PyYAML和requests装好就行。然后建立一个工作目录比如/opt/workbuddy里面放main.py、config.yaml、scripts/和logs/。一个最小可用的配置文件如下email: imap_server: imap.example.com imap_port: 993 account: workbuddyexample.com password: your_imap_auth_code check_interval: 60 allowed_senders: - meexample.com subject_prefix: [WB] ai: api_base: https://api.example.com/v1 api_key: sk-xxxx model: your-model-name temperature: 0.2 executor: scripts_dir: /opt/workbuddy/scripts workdir: /opt/workbuddy/workspace timeout: 120 max_output_chars: 2000 notify: smtp_server: smtp.example.com smtp_port: 465 account: workbuddyexample.com password: your_smtp_auth_code max_attachment_mb: 20注意几个容易踩的坑IMAP 服务器和 SMTP 服务器可能不是一个域名腾讯系、阿里系邮箱都区分得很清楚授权码可能是一段很长的字母数字粘贴的时候不要带空格SMTP 端口 465 是 SSL 加密587 是 STARTTLS我建议用 465代码更简单。allowed_senders一定要配置成你真正会在外面使用的邮箱否则你自己的其他邮箱发来的指令也会被无视。4.2 IMAP 收信与邮件解析代码收信模块是我的代码里最稳定的部分核心逻辑就是连接、搜索未读、遍历、标记已读。下面是一个可以直接使用的骨架import imaplib import email import time import yaml from email.header import decode_header from email.utils import parsedate_to_datetime def decode_mime_header(value): if value is None: return parts decode_header(value) return .join( part.decode(encoding or utf-8) if isinstance(part, bytes) else part for part, encoding in parts ) def fetch_unseen_tasks(cfg): imap imaplib.IMAP4_SSL(cfg[email][imap_server], cfg[email][imap_port]) imap.login(cfg[email][account], cfg[email][password]) imap.select(INBOX) status, data imap.search(None, UNSEEN) tasks [] for num in data[0].split(): status, msg_data imap.fetch(num, (RFC822)) raw msg_data[0][1] msg email.message_from_bytes(raw) sender decode_mime_header(msg.get(From)) subject decode_mime_header(msg.get(Subject)) # 只处理白名单发件人 if not any(addr in sender for addr in cfg[email][allowed_senders]): continue # 只处理带前缀标记的主题 if not subject.startswith(cfg[email][subject_prefix]): continue # 提取正文 body if msg.is_multipart(): for part in msg.walk(): if part.get_content_type() text/plain: body part.get_payload(decodeTrue).decode(utf-8, errorsignore) break else: body msg.get_payload(decodeTrue).decode(utf-8, errorsignore) tasks.append({subject: subject, body: body, raw: msg}) # 标记为已读避免下次重复处理 imap.store(num, FLAGS, \\Seen) imap.logout() return tasks这段代码有几个细节值得说明decode_email_header处理了中文主题乱码问题不处理的话中文邮件主题会显示成?utf-8?B?...?这种编码串msg.walk()只取text/plain部分是为了避开 HTML 邮件里夹杂的噪音store(num, FLAGS, \\Seen)是幂等设计的关键确保同一封邮件只被消费一次。如果你希望邮件处理失败后还能重新消费就不要在这里标记已读改成在成功完成后再标记。4.3 AI 任务解析与执行器AI 解析函数的关键是“把模型输出锁死在 JSON 结构里”。我用的是 OpenAI 兼容的 Chat Completions 接口即使你不方便用特定厂商的 SDK也可以用 requests 直接调。import json import requests def build_system_prompt(cfg): scripts list_scripts(cfg[executor][scripts_dir]) desc_lines [f- {name}: {get_script_desc(name)} for name in scripts] return ( 你是 WorkBuddy 的任务规划助手。用户会提供一封邮件的主题和正文 请判断用户想做什么并从下方可用脚本中选择最合适的脚本。 如果没有任何脚本可以完成用户需求请返回 actionunsupported。 请严格输出 JSON字段包括 action、params、reason。 可用脚本列表\n \n.join(desc_lines) ) def plan_task(cfg, subject, body): prompt build_system_prompt(cfg) payload { model: cfg[ai][model], temperature: cfg[ai][temperature], messages: [ {role: system, content: prompt}, {role: user, content: f邮件主题{subject}\n邮件正文{body}}, ], } resp requests.post( f{cfg[ai][api_base]}/chat/completions, headers{Authorization: fBearer {cfg[ai][api_key]}}, jsonpayload, timeout60, ) resp.raise_for_status() content resp.json()[choices][0][message][content] # 提取第一个 JSON 对象 start content.find({) end content.rfind(}) 1 return json.loads(content[start:end])执行器这边为了安全我强烈建议不要用shellTrue。把 AI 给的参数做成列表直接传给脚本程序import subprocess import re SAFE_PARAM re.compile(r^[A-Za-z0-9_\-./\u4e00-\u9fff]$) def execute_script(cfg, script_name, params): scripts_dir cfg[executor][scripts_dir] script_path pathlib.Path(scripts_dir) / script_name if not script_path.exists() or not script_path.is_file(): return ERROR: script not allowed for p in params: if not SAFE_PARAM.match(p): return fERROR: unsafe param: {p} try: result subprocess.run( [str(script_path), *params], capture_outputTrue, textTrue, timeoutcfg[executor][timeout], cwdcfg[executor][workdir], ) out result.stdout[-cfg[executor][max_output_chars]:] err result.stderr[-1000:] return fexit{result.returncode}\nstdout:\n{out}\nstderr:\n{err} except subprocess.TimeoutExpired: return ERROR: timeout这里面的正则校验是最后一道防线哪怕模型输出了一段带着 shell 元字符的注入攻击也会在正则这关被拦下。注意我没有让 subprocess 走 shell所以;、|、在参数里只会被当成普通字符不会被解释成命令拼接。4.4 回信通知与驻留服务执行完后的回信用 smtplib 发送即可。这里的逻辑就三步组装主题、拼正文、发附件。附件通过email.mime.application添加我把output/目录下的新文件全部带上。为了让 WorkBuddy 开机自启、崩溃自动拉起我把它注册成 systemd 服务。在/etc/systemd/system/workbuddy.service里写入如下内容[Unit] DescriptionWorkBuddy Agent Afternetwork-online.target [Service] ExecStart/usr/bin/python3 /opt/workbuddy/main.py WorkingDirectory/opt/workbuddy Restartalways RestartSec10 Userwb EnvironmentPYTHONUNBUFFERED1 [Install] WantedBymulti-user.target然后执行sudo systemctl daemon-reload sudo systemctl enable --now workbuddy就能跑起来。日志输出到 journald 里也可以用journalctl -u workbuddy -f实时查看。这个配置的关键是Restartalways和RestartSec10即使程序因为临时网络故障崩了也会在 10 秒后自动拉起对无人值守场景特别重要。主循环非常简单本质上就是“收信-解析-执行-回信”的无限循环。为了避免单个邮件耗时阻塞后续邮件我建议把任务放到一个线程池里做异步处理主循环只负责投递任务。这一步不是必须的但邮件多的时候能明显提升健壮性。4.5 部署后先做三轮自测刚部署完不要急着发复杂任务我建议按下面三轮来测。第一轮发一封主题为[WB] ping、正文为空的测试邮件。WorkBuddy 里对应一个ping.sh脚本只输出当前时间和主机名。这轮验证收信、解析、执行、回信是不是通了。收到回信说明链路已经活了。第二轮发一个带参数的中文任务比如“你好请帮我列出工作目录下的所有文件”。看 AI 是否选择了list_files.sh并正确传了参数。这轮验证 AI 理解能力和参数传递是否正常。注意看回信里脚本是否真的执行了而不是模型在“假装”执行。第三轮发一个明显超出能力范围的任务比如“帮我把电脑格式化”。正常情况是 AI 返回actionunsupported然后 WorkBuddy 回信说“能力范围外”。如果这时候 AI 真去执行了格式化那你的白名单机制一定出了问题需要立刻检查。这三轮全过就可以正常使用了。请记住任何自动化工具上线前都要先做“危险动作演练”你不是在测试正常流程而是在测试“AI 犯傻时系统怎么兜底”。5. 常见问题排查与避坑实录5.1 邮件迟迟不触发先看日志再看邮箱WorkBuddy 没反应是最高频的问题。我的排查顺序永远是先看服务进程还在不在再看日志有没有报错最后看邮箱里那封邮件是不是躺在“垃圾邮件”或者“已读”里。很多时候问题出在授权码过期或邮箱服务商的“安全提醒”上。部分邮箱服务商长时间未登录网页端会暂停第三方 IMAP 访问你需要去网页邮箱里重新确认一下“允许使用 IMAP 服务”。这是个容易忽略的坑。日志级别我也做得比较细每收到一封邮件、每解析完一个任务、每执行完一个脚本都会输出一条带时间戳的记录。排查的时候直接用journalctl -u workbuddy --since 10 minutes ago看最后几条基本能定位问题。5.2 AI 把任务理解偏了怎么办模型理解偏了最典型的场景是你明明想让它“重命名文件”它却跑去“复制文件”。原因多半是 prompt 里的脚本描述不够清晰或者是能力列表太宽泛模型在“貌似相关”的选项里做了错误选择。我的解决思路有两个。第一是脚本描述写得“带例子”比如在清单里写“rename_files: 批量重命名指定目录下的文件参数是目录路径和命名规则典型场景是清理下载文件夹”比只写“rename_files: 重命名文件”要有效得多。第二是当模型多次选错某个脚本时直接在 prompt 里加一条排除说明比如“除非邮件明确提到‘重命名’否则不要选择 rename_files”。另外如果邮件正文本身信息不足比如只写了“处理一下数据”没写处理方式AI 猜测的命中率会大幅下降。这时候 WorkBuddy 会回一封信问询而不是硬着头皮猜。这种“不确定性处理”对真实使用体验很重要宁可多问一句也不要自作主张。5.3 执行脚本报错但邮件里看不到具体原因脚本执行报错但是邮件里只有一句“exit1”这种情况也很常见。问题通常出在脚本的运行环境上WorkBuddy 作为 systemd 服务运行时环境变量跟你在终端里手动跑是完全不一样的比如 PATH 里没包含/usr/local/bin导致脚本调不到某个命令。解决办法是在脚本开头显式声明环境变量或者用绝对路径调用命令。再一个常见问题是工作目录不对脚本里所有相对路径都是相对于cwd的如果你没有把cwd设置成脚本所在目录很容易出现“找不到文件”。我建议在脚本里尽量用绝对路径或者先cd到固定目录再干活。如果邮件里被截断的内容不够定位问题可以直接登录服务器看/opt/workbuddy/workspace/下的脚本日志。我的每个封装脚本都会把自己的日志写到独立文件里避免和 WorkBuddy 的主日志混在一起。5.4 常见问题速查表现象可能原因排查与解决邮件发出后 WorkBuddy 无反应授权码失效、服务未运行、邮件进垃圾箱先看journalctl -u workbuddy再查邮箱“已读/垃圾”回信正文是乱码邮件编码处理逻辑有缺陷检查decode_mime_header是否处理了未知编码AI 选择了错误的脚本prompt 描述不清、参数缺失优化脚本描述增加“典型场景”说明脚本执行超时数据量大或脚本卡死单独给该脚本配置更长的超时时间回信没有附件产出文件路径不符合约定检查脚本是否把文件写到output/目录服务半夜崩溃网络或邮箱服务不稳定开启Restartalways和断线重试逻辑同一封邮件被反复处理未标记已读或任务执行失败检查标记逻辑改成任务成功后再标记已读5.5 安全相关的三条红线既然是做“远程操控”安全就必须当成第一优先级。我给自己定了几条红线分享出来给大家参考。第一条发件人白名单必须强制校验最好是校验完整的邮箱地址而不是简单包含匹配。比如xxxexample.com和xxxyyyexample.com都包含“xxx”简单字符串匹配会误放行。我用的是正则精确匹配整个邮箱域名和用户名。第二条永远不要让 AI 直接执行自由 shell 命令。WorkBuddy 的核心安全边界是“AI 只能选脚本不能发明命令”。一旦放开这个口子你等于把一个能读懂自然语言的攻击者放进了你的系统里。哪怕任务再简单也要先封装成脚本再让 AI 调用。第三条高风险操作默认要求二次确认。删除文件、批量重命名、覆盖数据库这类操作我都会在脚本里主动检查“是否带--force参数”如果没带就只输出预览计划而不实际执行。邮件里加上[confirm]标记则可以让整个流程多一道人工闸门。这套系统一定是“人在回路”的AI 可以做自动化但不能做最终决策。6. 写在最后我的几点真实体会这套 WorkBuddy 我用了一年多从最开始只会跑一个ping脚本到现在能帮我处理汇总表格、生成报告、定时清理目录中间确实踩了不少坑。最大的体会是自动化系统的价值不在于它有多智能而在于它多可靠。AI 负责把“人话”翻译成“机器话”这部分即使偶尔犯傻靠 prompt 优化和结果检查也能兜住真正让整个系统值得信赖的是白名单、权限控制、日志审计这些看起来不起眼的“笨功夫”。另外一个小技巧送给准备动手搭的人把你最高频的 5 个任务先做成独立的 shell 脚本脚本路径和参数都设计得尽量简单然后再去调 AI 解析。我最初犯的错误是反着来的先让 AI 解析各种句子结果发现模型太容易发挥后来老老实实把任务脚本先定义清楚再回来调 prompt一切就顺了。这个顺序很重要任务边界清楚了AI 再聪明也不会跑偏太多。最后提醒一句任何远程自动化的前提都是这些任务本身你已经手动跑过很多次、非常确定它的输入输出。WorkBuddy 不是帮你“发明”新流程而是帮你“重复”已经可靠的流程。从这个角度理解它你会少很多折腾。
上周出差客户临时要改汇总口径我在地铁上掏出手机打开微信里的邮件提醒把需求写进邮件正文发到工作邮箱。三分钟后办公室那台电脑上的 WorkBuddy 已经把数据重新跑完、表格改好把结果回信给我了。整个过程中我没开远程桌面没喊同事帮忙甚至没碰电脑。这套东西做出来之后我用了一年多也算踩了不少坑今天干脆把完整的思路、架构和实现细节都摊开来讲清楚。这套方案的核心就一句话把“远程操控电脑”从“人肉远程”变成“AI 代劳”。你在微信里顺手写一封邮件邮件就是指令电脑上常驻的 WorkBuddy 负责收信、理解任务、调用 AI 规划步骤、执行脚本、回传结果。它适合所有需要在外面让家里或办公室电脑干活的场景改表格、跑脚本、批量整理文件、生成报告、定时备份数据等等。不需要你有很深的编程功底但如果你会一点 Python下面这套东西基本可以照着抄。1. 为什么要做“邮件遥控电脑”这件事1.1 一个真实的远程救火场景先说一个很多人都会遇到的画面你人在外地电脑在办公室客户的邮件已经堆到“催办”状态。你需要的不是看文件而是让电脑上某个程序跑一遍、把某个目录里的文件重新归档、或者用一个已经写好的脚本生成一份报表。这种事听起来不难但真要远程操作第一步就卡住了——手机上没有办公电脑的环境远程桌面连上去又慢又卡光是在手机上敲键盘就够让人崩溃。我当时的需求更朴素我希望有一条“不占用我注意力”的通道把任务丢给电脑然后该干嘛干嘛去。就像你给同事发了一条工作消息同事做完之后回你一声。只不过这个“同事”不是人是运行在电脑上的 AI 助手。邮件恰好是这种异步通道的完美载体它可以排队、可以审计、可以带附件、可以在任何网络环境下收发而且微信本身就有邮件提醒你在聊天界面里就能收到“新邮件已到达”的推送点开就能转发或回复入口极其顺手。于是 WorkBuddy 的雏形就定为电脑上常驻一个服务通过 IMAP 协议定时检查邮箱发现符合约定的新邮件就交给大模型解析任务解析出明确的执行方案之后在白名单脚本范围内执行最后用 SMTP 把结果回信给你。整个链路里微信负责“人机交互”的第一公里邮件负责“传输与确认”AI 负责“从自然语言到可执行步骤”的翻译脚本负责“真正把活干了”。1.2 对比主流远程方案为什么只有这套组合最合适远程控制这件事市面上可选的方案非常多但每种的局限都很明显。远程桌面类工具比如向日葵、ToDesk、系统自带的 RDP胜在“所见即所得”但代价是操作链路长你得先在手机上打开客户端、等对方电脑响应、再在缩小的屏幕上找按钮。适合应急不适合高频的“让电脑自己干活”。SSH 类方案则更“极客”终端敲命令确实高效但手机上的终端体验一言难尽而且安全门槛不低——密钥管理、端口暴露、访问控制每一样都要花时间。更重要的是SSH 给到你的是一条命令通道而不是一个“能理解意图”的助手你依然要自己判断该跑哪条命令。还有一类是微信本身的生态功能比如文件传输助手、微信客服消息、以及各种 IoT 设备的微信控制。这些方案的问题是无法执行任意脚本只能触发预设的固定动作。如果我想“让电脑把本周的销售数据按新口径汇总并生成图表”预设按钮根本没法覆盖这种变化需求。而“微信 邮件 AI Agent”的组合刚好绕开了所有痛点。微信负责“提醒 快速编辑”你不用专门打开邮件 App邮件是标准、开放、可审计的协议收信和发信都有日志不会像私有协议那样被平台限制AI Agent 负责把模糊的自然语言指令翻译成可执行的脚本调用它是在电脑本地跑的管控权完全在自己手里。这套组合天然适合“异步、无人值守、需要一定智能判断”的远程任务。1.3 WorkBuddy 到底是个什么东西你可以把 WorkBuddy 理解成一个“收件即干活”的机器人管家。它不是一个需要另外安装的庞大平台本质上就是一个长期运行在电脑上的 Python 服务加上一套清晰的配置文件和几组脚本。它可以做到定时收取指定邮箱的未读邮件校验发件人是否在可信名单里把邮件标题和正文交给大模型让它提取任务意图根据意图从预先配置好的白名单脚本中选择一个或组合来执行把执行结果、日志、生成的文件通过邮件回复给发件人所有操作都留下日志方便事后回溯。名字里的“Work”强调它干的是具体活而不是像聊天机器人那样只给建议。它跟常见的代码结对助手也不一样代码助手比如各类 CodeBuddy偏向在 IDE 里帮你写代码、改代码而 WorkBuddy 更偏向操作系统层面的任务执行比如跑脚本、处理文件、调接口、生成报表。你可以把它理解成“能动手的 AI Agent”而不是“能聊天的 AI”。2. 整体架构与 AI 决策链路设计2.1 四层结构入口、解析、执行、反馈整套系统我习惯分成四层来看这样每一块的职责都很清晰出了问题也能快速定位。第一层是指令入口层。它解决的是“用户怎么把任务送进来”。我的选择是邮件配合微信的邮件提醒作为触点。邮件的好处前面说过这里再补一个关键细节邮件本身是纯文本的天然适合让 AI 解析。你不需要跟任何私有协议打交道也不需要担心平台接口变化只要邮箱服务商还支持 IMAP这套系统就能一直跑。第二层是解析决策层。这也是 WorkBuddy 的核心大脑。它拿到邮件后先做规则校验发件人是否在白名单、主题是否带约定的前缀标记。校验通过后把邮件正文发送给大模型接口让模型输出结构化的“行动计划”比如“执行哪个脚本、传什么参数、期望得到什么结果”。为了防止模型乱来我要求它只能输出 JSON而且“脚本名”必须从白名单里选模型没有权利发明一条系统命令。第三层是执行层。它干活的方式非常“笨”用 subprocess 去调用白名单里预先写好的脚本并且严格控制超时时间、工作目录、环境变量。这一层不接 AI只接明确的结构化指令。这样做是为了安全AI 可以有想象力但真正落在操作系统上的动作必须是可预期、可拦截的。第四层是反馈层。执行完成后把标准输出、标准错误、生成文件的附件通过 SMTP 发回给发件人。反馈内容我做了截断处理避免脚本输出几万行日志直接把邮件撑爆。如果有附件也会一并附上。这四层之间用队列和日志解耦。即使某一步失败前面的邮件已经处理过了不会重复消费后面的报错也会通过日志和邮件告诉你。2.2 AI 在这里承担什么角色从自然语言到操作计划AI 在 WorkBuddy 里不是执行器而是“翻译官”。它把一段口语化的中文比如“把桌面上的销售数据按区域汇总生成一个柱状图发给我”翻译成一份结构化的行动计划。为了让它翻译得准我在提示词里做了三件事一是限定输出格式。我让模型严格输出 JSON字段包括任务类型、选择的脚本名、脚本参数、执行优先级、备注。只要模型返回的不是合法 JSONWorkBuddy 就直接判定“解析失败”不会继续往下走。二是给模型一份“能力清单”。白名单里有哪些脚本、每个脚本是干什么的、支持哪些参数我都会通过系统提示词告诉它。这样模型是在“已知选项”里做选择而不是凭空造命令。我强烈建议这一步不要偷懒能力清单写得越细模型理解偏差就越小。三是要求模型先思考再输出。我在提示词末尾加了一句“请先基于邮件内容判断任务是否在你的能力范围内如果不在请把 action 字段置为 unsupported”。这样可以避免模型硬生生把一个复杂的任务映射到一个无关脚本上。实测下来加上这一句之后误执行率明显下降。模型的接入我采用 OpenAI 兼容接口的方式这样不管是商用大模型 API还是本地部署的模型服务只要能提供 HTTP 接口WorkBuddy 都能无缝对接。对延时要求高的场景我觉得本地模型更好对理解能力要求高的场景商用大模型接口更稳。两种都试过的感受是任务解析这种场景模型的理解能力和稳定性比响应速度更重要。2.3 任务协议设计让 AI 和人都能看懂所谓“任务协议”就是你和 WorkBuddy 之间约定的邮件格式。没有这个约定AI 解析就会像大海捞针一样没有抓手。我用的协议非常简单只有三条规则邮件主题必须以[WB]开头这样收信程序可以快速过滤无关邮件邮件正文第一行写任务目标后面可以随意补充背景资料、文件路径、特殊要求如果任务需要文件输入直接作为附件发送WorkBuddy 会把附件下载到工作目录后交给脚本处理。这套协议的好处在于它对人类来说非常自然你不需要学习复杂的命令语法对 AI 来说非常友好因为所有关键信息都集中在正文里对程序来说非常可靠主题前缀和发件人白名单两道过滤足以挡住 99% 的垃圾邮件和误触发。我还定义了一个“人工确认”扩展规则如果邮件正文里出现[confirm]标记WorkBuddy 执行前会先回一封确认邮件等你回复“确认执行”后才真正动手。这个规则在删除文件、批量重命名这类高风险操作上非常有用。刚开始你可以全部带[confirm]跑熟了再慢慢放开。3. 核心模块拆解与关键参数选择3.1 邮件接收模块IMAP 授权码与轮询策略邮件接收模块是整个系统最容易出问题的地方也是最需要小心配置的地方。我使用的是 IMAP 协议而不是 POP3原因是 IMAP 能保留服务器上的邮件状态程序把邮件标记为“已读”后你自己用手机还能看到邮件而 POP3 默认收信后服务器上就删了很容易造成邮件丢失。配置上有一个关键点账号密码不要直接用邮箱登录密码而是用邮箱服务商提供的“授权码”。比如常见的 QQ 邮箱、163 邮箱、企业邮在安全设置里都会有一个“开启 IMAP/SMTP 服务”的开关开启后会生成一串授权码专门给第三方客户端使用。这样做的好处是即使授权码泄露你随时可以在网页端撤销不影响邮箱登录密码安全。轮询策略我选的是“每 60 秒检查一次未读邮件”。这个频率在实用性和服务器压力之间比较平衡。如果你想做到“邮件发出几秒内就触发”可以研究一下 IMAP IDLE 扩展它能保持长连接实时推送新邮件到达事件但代价是连接稳定性要求更高断线重连逻辑写起来会复杂一些。我自己的经验是远程干活的场景通常不差那几十秒轮询 60 秒足够用了省心最重要。另外IMAP 连接是长连接还是短连接也需要根据你服务器的稳定性来定。我采用的是“每次任务循环新建连接、用完后关闭”的方式虽然多了一点连接开销但避免了邮箱服务器因为长时间空闲把连接踢掉这种常见故障。实测下来每 60 秒连接一次一天也就 1440 次连接对邮箱服务器来说几乎没什么压力。3.2 任务解析模块白名单与 Prompt 模板任务解析模块是 AI 发挥作用的地方。但请注意AI 的作用是“理解”和“规划”不是“授权”。我的做法是给模型一个写死的 Prompt 模板模板里包含当前可用的脚本清单、每个脚本的用途说明、参数约束、输出格式要求。模型只能在这个框架内输出结果不能自己发明脚本。Prompt 模板我大概长这样下面是一个简化版在系统提示词里写上“你是 WorkBuddy 的任务规划助手。用户会给你一封邮件的主题和正文请判断用户想做什么并从 available_scripts 列表中选出最合适的脚本。如果列表中没有合适的脚本请返回 actionunsupported。请严格输出 JSON不要输出任何解释”。然后 available_scripts 由程序从配置文件动态拼接到模板里确保模型看到的清单和实际可执行的脚本完全一致。这里有一个很容易踩的坑不要把模型返回的“脚本参数”直接拼进 shell 里用eval执行特别是不要让模型有机会传入;、|、这类 shell 元字符。我采用的解决方案是所有参数都通过列表形式传给 subprocess不经过 shell 解析并且在执行前用正则对参数做一次校验只允许字母、数字、下划线、短横线、点、斜杠和少量中文其他字符一律拒绝。温度参数我设置得比较低temperature0.2左右。任务解析这种场景我们希望模型输出尽量稳定、保守不需要它发挥创造力。温度调太高同一个任务每次解析出的脚本名和参数可能都不一样这对自动化系统来说是大忌。3.3 执行模块命令白名单、超时与结果回收执行模块是 WorkBuddy 的“手”。但我不想让 AI 直接操作这只手而是让 AI 只能挑选预先定义好的脚本。这些脚本都放在/home/wb/scripts/目录下并且是可执行的 shell 或者 Python 文件。WorkBuddy 在启动时会读取这个目录下的所有文件生成一份白名单。AI 输出里的脚本名必须能在这个名单里精确匹配到否则直接拒绝执行。超时控制也在这里做。每个脚本我默认给 120 秒的超时时间到期还没跑完就杀掉进程并记录超时日志。这个参数不是随便定的太短耗时的数据任务会被误杀太长一个卡住的脚本会一直占着资源。120 秒是我用了一年多以后觉得比较稳妥的值你完全可以根据自己的任务类型调整。我建议在配置里允许给单个脚本单独指定超时时间比如“生成月度报表”这种任务可能就需要 10 分钟。结果回收同样重要。Python 的subprocess.run会把脚本的标准输出和标准错误都捕获下来但我会对输出长度做截断比如标准输出最多取最后 2000 字符标准错误最多取 1000 字符。这样做的原因是脚本如果出现死循环打印邮件会被大量垃圾文本淹没反而看不到关键的错误信息。截断后配合一条“请查看服务器日志”的提示既保护了可读性也没有丢失问题线索。3.4 结果反馈模块SMTP 回信与附件任务干完了必须给人一个交代。反馈模块用 SMTP 发信把执行摘要、运行日志、生成的附件回传给发件人。这里的核心原则是反馈信息必须“一眼能看到结果”。我不会把日志原文直接放在邮件正文里而是先给一个结论成功、部分成功、还是失败然后再列关键信息最后附上日志。附件是一个容易被忽略但实际很刚需的能力。很多任务的结果就是一份文件比如 Excel 报表、PDF、图片、压缩包。WorkBuddy 会把工作目录下符合“产出文件”约定的文件自动作为附件添加。我的约定是脚本执行成功后如果在工作目录下发现output/文件夹有新的文件就自动打包或逐个附上。另外我会限制附件总大小不超过 20MB超过的话只回传文件的下载链接前提是你自己有一个文件服务或者干脆在邮件里提示“文件太大请到机器上查看”。邮件正文我还会加上“本任务由 WorkBuddy 自动执行”这样的标识避免日后翻邮件时产生困惑。这一点很实用特别是当你一个月会收到几十封这种自动回信时标识能帮你快速区分哪些是人在回、哪些是机器在回。4. 实操从零搭一个最小可用的 WorkBuddy4.1 环境准备与配置文件我以 Ubuntu 24.04 为例其他 Linux 发行版和 macOS 基本一样Windows 略有差异但不影响主体逻辑。准备三样东西Python 3.10 以上环境、一个支持 IMAP/SMTP 的邮箱、以及一台能长期开机的电脑。Python 依赖只需要PyYAML和requests装好就行。然后建立一个工作目录比如/opt/workbuddy里面放main.py、config.yaml、scripts/和logs/。一个最小可用的配置文件如下email: imap_server: imap.example.com imap_port: 993 account: workbuddyexample.com password: your_imap_auth_code check_interval: 60 allowed_senders: - meexample.com subject_prefix: [WB] ai: api_base: https://api.example.com/v1 api_key: sk-xxxx model: your-model-name temperature: 0.2 executor: scripts_dir: /opt/workbuddy/scripts workdir: /opt/workbuddy/workspace timeout: 120 max_output_chars: 2000 notify: smtp_server: smtp.example.com smtp_port: 465 account: workbuddyexample.com password: your_smtp_auth_code max_attachment_mb: 20注意几个容易踩的坑IMAP 服务器和 SMTP 服务器可能不是一个域名腾讯系、阿里系邮箱都区分得很清楚授权码可能是一段很长的字母数字粘贴的时候不要带空格SMTP 端口 465 是 SSL 加密587 是 STARTTLS我建议用 465代码更简单。allowed_senders一定要配置成你真正会在外面使用的邮箱否则你自己的其他邮箱发来的指令也会被无视。4.2 IMAP 收信与邮件解析代码收信模块是我的代码里最稳定的部分核心逻辑就是连接、搜索未读、遍历、标记已读。下面是一个可以直接使用的骨架import imaplib import email import time import yaml from email.header import decode_header from email.utils import parsedate_to_datetime def decode_mime_header(value): if value is None: return parts decode_header(value) return .join( part.decode(encoding or utf-8) if isinstance(part, bytes) else part for part, encoding in parts ) def fetch_unseen_tasks(cfg): imap imaplib.IMAP4_SSL(cfg[email][imap_server], cfg[email][imap_port]) imap.login(cfg[email][account], cfg[email][password]) imap.select(INBOX) status, data imap.search(None, UNSEEN) tasks [] for num in data[0].split(): status, msg_data imap.fetch(num, (RFC822)) raw msg_data[0][1] msg email.message_from_bytes(raw) sender decode_mime_header(msg.get(From)) subject decode_mime_header(msg.get(Subject)) # 只处理白名单发件人 if not any(addr in sender for addr in cfg[email][allowed_senders]): continue # 只处理带前缀标记的主题 if not subject.startswith(cfg[email][subject_prefix]): continue # 提取正文 body if msg.is_multipart(): for part in msg.walk(): if part.get_content_type() text/plain: body part.get_payload(decodeTrue).decode(utf-8, errorsignore) break else: body msg.get_payload(decodeTrue).decode(utf-8, errorsignore) tasks.append({subject: subject, body: body, raw: msg}) # 标记为已读避免下次重复处理 imap.store(num, FLAGS, \\Seen) imap.logout() return tasks这段代码有几个细节值得说明decode_email_header处理了中文主题乱码问题不处理的话中文邮件主题会显示成?utf-8?B?...?这种编码串msg.walk()只取text/plain部分是为了避开 HTML 邮件里夹杂的噪音store(num, FLAGS, \\Seen)是幂等设计的关键确保同一封邮件只被消费一次。如果你希望邮件处理失败后还能重新消费就不要在这里标记已读改成在成功完成后再标记。4.3 AI 任务解析与执行器AI 解析函数的关键是“把模型输出锁死在 JSON 结构里”。我用的是 OpenAI 兼容的 Chat Completions 接口即使你不方便用特定厂商的 SDK也可以用 requests 直接调。import json import requests def build_system_prompt(cfg): scripts list_scripts(cfg[executor][scripts_dir]) desc_lines [f- {name}: {get_script_desc(name)} for name in scripts] return ( 你是 WorkBuddy 的任务规划助手。用户会提供一封邮件的主题和正文 请判断用户想做什么并从下方可用脚本中选择最合适的脚本。 如果没有任何脚本可以完成用户需求请返回 actionunsupported。 请严格输出 JSON字段包括 action、params、reason。 可用脚本列表\n \n.join(desc_lines) ) def plan_task(cfg, subject, body): prompt build_system_prompt(cfg) payload { model: cfg[ai][model], temperature: cfg[ai][temperature], messages: [ {role: system, content: prompt}, {role: user, content: f邮件主题{subject}\n邮件正文{body}}, ], } resp requests.post( f{cfg[ai][api_base]}/chat/completions, headers{Authorization: fBearer {cfg[ai][api_key]}}, jsonpayload, timeout60, ) resp.raise_for_status() content resp.json()[choices][0][message][content] # 提取第一个 JSON 对象 start content.find({) end content.rfind(}) 1 return json.loads(content[start:end])执行器这边为了安全我强烈建议不要用shellTrue。把 AI 给的参数做成列表直接传给脚本程序import subprocess import re SAFE_PARAM re.compile(r^[A-Za-z0-9_\-./\u4e00-\u9fff]$) def execute_script(cfg, script_name, params): scripts_dir cfg[executor][scripts_dir] script_path pathlib.Path(scripts_dir) / script_name if not script_path.exists() or not script_path.is_file(): return ERROR: script not allowed for p in params: if not SAFE_PARAM.match(p): return fERROR: unsafe param: {p} try: result subprocess.run( [str(script_path), *params], capture_outputTrue, textTrue, timeoutcfg[executor][timeout], cwdcfg[executor][workdir], ) out result.stdout[-cfg[executor][max_output_chars]:] err result.stderr[-1000:] return fexit{result.returncode}\nstdout:\n{out}\nstderr:\n{err} except subprocess.TimeoutExpired: return ERROR: timeout这里面的正则校验是最后一道防线哪怕模型输出了一段带着 shell 元字符的注入攻击也会在正则这关被拦下。注意我没有让 subprocess 走 shell所以;、|、在参数里只会被当成普通字符不会被解释成命令拼接。4.4 回信通知与驻留服务执行完后的回信用 smtplib 发送即可。这里的逻辑就三步组装主题、拼正文、发附件。附件通过email.mime.application添加我把output/目录下的新文件全部带上。为了让 WorkBuddy 开机自启、崩溃自动拉起我把它注册成 systemd 服务。在/etc/systemd/system/workbuddy.service里写入如下内容[Unit] DescriptionWorkBuddy Agent Afternetwork-online.target [Service] ExecStart/usr/bin/python3 /opt/workbuddy/main.py WorkingDirectory/opt/workbuddy Restartalways RestartSec10 Userwb EnvironmentPYTHONUNBUFFERED1 [Install] WantedBymulti-user.target然后执行sudo systemctl daemon-reload sudo systemctl enable --now workbuddy就能跑起来。日志输出到 journald 里也可以用journalctl -u workbuddy -f实时查看。这个配置的关键是Restartalways和RestartSec10即使程序因为临时网络故障崩了也会在 10 秒后自动拉起对无人值守场景特别重要。主循环非常简单本质上就是“收信-解析-执行-回信”的无限循环。为了避免单个邮件耗时阻塞后续邮件我建议把任务放到一个线程池里做异步处理主循环只负责投递任务。这一步不是必须的但邮件多的时候能明显提升健壮性。4.5 部署后先做三轮自测刚部署完不要急着发复杂任务我建议按下面三轮来测。第一轮发一封主题为[WB] ping、正文为空的测试邮件。WorkBuddy 里对应一个ping.sh脚本只输出当前时间和主机名。这轮验证收信、解析、执行、回信是不是通了。收到回信说明链路已经活了。第二轮发一个带参数的中文任务比如“你好请帮我列出工作目录下的所有文件”。看 AI 是否选择了list_files.sh并正确传了参数。这轮验证 AI 理解能力和参数传递是否正常。注意看回信里脚本是否真的执行了而不是模型在“假装”执行。第三轮发一个明显超出能力范围的任务比如“帮我把电脑格式化”。正常情况是 AI 返回actionunsupported然后 WorkBuddy 回信说“能力范围外”。如果这时候 AI 真去执行了格式化那你的白名单机制一定出了问题需要立刻检查。这三轮全过就可以正常使用了。请记住任何自动化工具上线前都要先做“危险动作演练”你不是在测试正常流程而是在测试“AI 犯傻时系统怎么兜底”。5. 常见问题排查与避坑实录5.1 邮件迟迟不触发先看日志再看邮箱WorkBuddy 没反应是最高频的问题。我的排查顺序永远是先看服务进程还在不在再看日志有没有报错最后看邮箱里那封邮件是不是躺在“垃圾邮件”或者“已读”里。很多时候问题出在授权码过期或邮箱服务商的“安全提醒”上。部分邮箱服务商长时间未登录网页端会暂停第三方 IMAP 访问你需要去网页邮箱里重新确认一下“允许使用 IMAP 服务”。这是个容易忽略的坑。日志级别我也做得比较细每收到一封邮件、每解析完一个任务、每执行完一个脚本都会输出一条带时间戳的记录。排查的时候直接用journalctl -u workbuddy --since 10 minutes ago看最后几条基本能定位问题。5.2 AI 把任务理解偏了怎么办模型理解偏了最典型的场景是你明明想让它“重命名文件”它却跑去“复制文件”。原因多半是 prompt 里的脚本描述不够清晰或者是能力列表太宽泛模型在“貌似相关”的选项里做了错误选择。我的解决思路有两个。第一是脚本描述写得“带例子”比如在清单里写“rename_files: 批量重命名指定目录下的文件参数是目录路径和命名规则典型场景是清理下载文件夹”比只写“rename_files: 重命名文件”要有效得多。第二是当模型多次选错某个脚本时直接在 prompt 里加一条排除说明比如“除非邮件明确提到‘重命名’否则不要选择 rename_files”。另外如果邮件正文本身信息不足比如只写了“处理一下数据”没写处理方式AI 猜测的命中率会大幅下降。这时候 WorkBuddy 会回一封信问询而不是硬着头皮猜。这种“不确定性处理”对真实使用体验很重要宁可多问一句也不要自作主张。5.3 执行脚本报错但邮件里看不到具体原因脚本执行报错但是邮件里只有一句“exit1”这种情况也很常见。问题通常出在脚本的运行环境上WorkBuddy 作为 systemd 服务运行时环境变量跟你在终端里手动跑是完全不一样的比如 PATH 里没包含/usr/local/bin导致脚本调不到某个命令。解决办法是在脚本开头显式声明环境变量或者用绝对路径调用命令。再一个常见问题是工作目录不对脚本里所有相对路径都是相对于cwd的如果你没有把cwd设置成脚本所在目录很容易出现“找不到文件”。我建议在脚本里尽量用绝对路径或者先cd到固定目录再干活。如果邮件里被截断的内容不够定位问题可以直接登录服务器看/opt/workbuddy/workspace/下的脚本日志。我的每个封装脚本都会把自己的日志写到独立文件里避免和 WorkBuddy 的主日志混在一起。5.4 常见问题速查表现象可能原因排查与解决邮件发出后 WorkBuddy 无反应授权码失效、服务未运行、邮件进垃圾箱先看journalctl -u workbuddy再查邮箱“已读/垃圾”回信正文是乱码邮件编码处理逻辑有缺陷检查decode_mime_header是否处理了未知编码AI 选择了错误的脚本prompt 描述不清、参数缺失优化脚本描述增加“典型场景”说明脚本执行超时数据量大或脚本卡死单独给该脚本配置更长的超时时间回信没有附件产出文件路径不符合约定检查脚本是否把文件写到output/目录服务半夜崩溃网络或邮箱服务不稳定开启Restartalways和断线重试逻辑同一封邮件被反复处理未标记已读或任务执行失败检查标记逻辑改成任务成功后再标记已读5.5 安全相关的三条红线既然是做“远程操控”安全就必须当成第一优先级。我给自己定了几条红线分享出来给大家参考。第一条发件人白名单必须强制校验最好是校验完整的邮箱地址而不是简单包含匹配。比如xxxexample.com和xxxyyyexample.com都包含“xxx”简单字符串匹配会误放行。我用的是正则精确匹配整个邮箱域名和用户名。第二条永远不要让 AI 直接执行自由 shell 命令。WorkBuddy 的核心安全边界是“AI 只能选脚本不能发明命令”。一旦放开这个口子你等于把一个能读懂自然语言的攻击者放进了你的系统里。哪怕任务再简单也要先封装成脚本再让 AI 调用。第三条高风险操作默认要求二次确认。删除文件、批量重命名、覆盖数据库这类操作我都会在脚本里主动检查“是否带--force参数”如果没带就只输出预览计划而不实际执行。邮件里加上[confirm]标记则可以让整个流程多一道人工闸门。这套系统一定是“人在回路”的AI 可以做自动化但不能做最终决策。6. 写在最后我的几点真实体会这套 WorkBuddy 我用了一年多从最开始只会跑一个ping脚本到现在能帮我处理汇总表格、生成报告、定时清理目录中间确实踩了不少坑。最大的体会是自动化系统的价值不在于它有多智能而在于它多可靠。AI 负责把“人话”翻译成“机器话”这部分即使偶尔犯傻靠 prompt 优化和结果检查也能兜住真正让整个系统值得信赖的是白名单、权限控制、日志审计这些看起来不起眼的“笨功夫”。另外一个小技巧送给准备动手搭的人把你最高频的 5 个任务先做成独立的 shell 脚本脚本路径和参数都设计得尽量简单然后再去调 AI 解析。我最初犯的错误是反着来的先让 AI 解析各种句子结果发现模型太容易发挥后来老老实实把任务脚本先定义清楚再回来调 prompt一切就顺了。这个顺序很重要任务边界清楚了AI 再聪明也不会跑偏太多。最后提醒一句任何远程自动化的前提都是这些任务本身你已经手动跑过很多次、非常确定它的输入输出。WorkBuddy 不是帮你“发明”新流程而是帮你“重复”已经可靠的流程。从这个角度理解它你会少很多折腾。
