1. 项目概述为什么在原版 Windows 上部署 Hermes-Agent 和 Hermes-Studio 是一件“值得较真”的事你有没有过这种体验花半小时装好一个号称“开箱即用”的 AI Agent结果一运行就报错——不是缺 Python 环境就是 Git 找不到再不然是 ffmpeg 路径没配对最后发现它偷偷依赖了 WSL2而你电脑上压根没开 Linux 子系统更尴尬的是你刚在公司内网重装完一台干净的 Windows 原版系统无预装软件、无管理员权限、无企业策略干扰想快速验证一个本地 AI 工作流结果所有教程都默认你已装好 Docker、Node.js 18、Python 3.12、Git for Windows、PowerShell 7……而你连winget都没权限启用这就是我们今天要解决的真实场景在一台出厂状态的 Windows 11/10 原版系统上零依赖、免 WSL、不碰注册表、不改系统策略原生部署 Hermes-Agent CLI Hermes-Studio Web UI并确保它能稳定调用本地大模型如 Qwen2.5、Phi-3.5、Llama-3.2完成真实任务。这不是一个“玩具级”安装。Hermes-Agent 的核心价值在于它的“自进化闭环”——它能从你每一次对话中提取技能、压缩记忆、优化工具调用链、甚至自动修复自身配置错误。但这个闭环的前提是它必须跑在你真正日常使用的环境里而不是某个隔离的 Docker 容器或 WSL2 虚拟层中。一旦它和你的文件系统、剪贴板、终端、浏览器、甚至 Outlook 日历脱节那个“越用越聪明”的承诺就成了一句空话。所以我们不走“Linux 兼容层”路线不依赖“WSL2 模拟器”不推荐“Docker Desktop 这种重量级依赖”。我们要的是PowerShell 原生命令一行敲下5 分钟内完成全栈部署所有二进制、Python 包、Node 模块、FFmpeg、MinGit 全部静默解压到%LOCALAPPDATA%\hermes下完全与系统环境隔离卸载时删掉这个文件夹即可不留任何痕迹。这正是 Nous Research 官方强调的“Native Windows support”的真实含义——不是“能跑”而是“像 Windows 原生应用一样呼吸”。你可能会问既然官方提供了iex (irm https://hermes-agent.nousresearch.com/install.ps1)一键脚本为什么还要深挖因为那只是“安装入口”不是“使用手册”。脚本背后藏着大量 Windows 特有的陷阱PowerShell 执行策略ExecutionPolicy默认为 Restricted会直接拦停脚本Windows Defender SmartScreen 会误报install.ps1为“未知发布者”并阻止下载某些企业域策略会禁用irmInvoke-RestMethod命令uvPython 包管理器在 Windows 上首次初始化时若遇到杀毒软件实时扫描会卡死在uv venv步骤长达数分钟而最隐蔽的坑是Hermes-Studio 的 Web UI 默认绑定localhost:8000但 Windows 10/11 的 Hyper-V 或 WSL2 有时会抢占该端口导致你打开浏览器只看到“连接被拒绝”。这些都不是文档里会写的“注意事项”而是我在给 7 家不同行业客户部署时亲手踩过、记在笔记本第 3 页的血泪清单。接下来的内容就是把这份清单摊开告诉你每一步为什么这么走、不这么走会怎样、以及如何一眼识别问题根源。2. 核心设计思路为什么放弃 WSL2/Docker坚持纯原生 PowerShell 部署2.1 “原生 Windows 支持”不是营销话术而是架构级取舍先破除一个常见误解很多人看到“Native Windows”就以为是“编译成 .exe”其实 Hermes-Agent 本质仍是 Python TypeScript 构建的跨平台项目。它的“原生性”体现在三个关键层面第一进程模型的原生适配。Hermes-Agent 的 CLI 终端TUI重度依赖 ANSI 转义序列控制光标、颜色、清屏。在 WSL2 中这些序列由 Linux 内核的 tty 驱动解析而在 Windows 原生 PowerShell 中它们由 Windows Console Hostconhost.exe或 Windows Terminal 的Windows.Terminal渲染引擎处理。官方选择不封装成 .exe而是让 Python 解释器直接调用rich库的Console对象是因为rich已深度适配 Windows 控制台 API如SetConsoleMode、GetStdHandle。实测对比同一段rich.progress进度条在 WSL2 的 Ubuntu 终端里偶尔会因字符宽度计算偏差出现乱码而在 Windows Terminal 中始终精准对齐。这说明其底层渲染逻辑已绕过 POSIX 兼容层直通 Windows API。第二文件系统路径的零转换。Hermes-Agent 的skills目录、memories文件、context files全部采用pathlib.Path构建路径。在 Windows 上Path(C:/Users/John/Documents) / project会自动生成C:\Users\John\Documents\project反斜杠且Path.resolve()能正确处理 NTFS 符号链接Junction Points和 OneDrive 的“按需文件”。而 WSL2 的/mnt/c/是通过 DrvFs 驱动挂载的它对 Windows 符号链接的支持是有限的——比如你用mklink /J创建的目录链接在 WSL2 中可能显示为空。这意味着如果你把 Hermes 的skills目录软链接到 OneDrive 同步区原生 Windows 部署能无缝工作WSL2 则大概率失败。这是架构设计上对 Windows 生态的主动拥抱而非被动兼容。第三工具链的静默捆绑策略。官方安装脚本install.ps1会检测系统是否已存在 Git、FFmpeg、ripgrep。若不存在则下载 MinGit约 45MB、FFmpeg 自包含版约 120MB、rg.exe约 5MB全部解压到%LOCALAPPDATA%\hermes\tools\下并将该路径注入 Hermes 的PATH环境变量仅对 Hermes 进程生效。这个设计精妙之处在于它规避了 Windows 用户最头疼的“全局环境变量污染”。你不需要把C:\Program Files\Git\bin加入系统 PATH也不用担心新装的 Git for Windows 和旧版冲突。Hermes 自己的git命令永远调用它私有的 MinGit版本锁定、路径固定、无副作用。相比之下Docker 部署需要你先装 Docker Desktop2GB再拉取hermes-agent镜像1.2GB最后还得配置 volume 映射来持久化skills和memories——这已经不是“部署 Agent”而是“部署一套容器编排平台”。提示当你看到hermes tools list输出中git的路径是C:\Users\YourName\AppData\Local\hermes\tools\git\cmd\git.exe就说明你已成功进入“原生模式”。这是判断部署是否合规的第一道门槛。2.2 为什么坚决不碰 WSL2四个无法回避的现实瓶颈尽管 WSL2 在技术上可行但在真实办公场景中它会引入四个不可控变量1. 网络策略的双重防火墙。WSL2 使用虚拟交换机vSwitch连接宿主机其网络地址是172.x.x.x段与 Windows 主机的192.168.x.x不同网段。当 Hermes-Agent 需要调用本地运行的 Ollama监听127.0.0.1:11434时WSL2 内部的curl http://host.docker.internal:11434并不能直通——因为host.docker.internal是 Docker Desktop 的 DNS 别名对 WSL2 无效。你必须手动在 WSL2 的/etc/hosts中添加172.16.0.1 host.docker.internal而172.16.0.1是 WSL2 的网关 IP它每次重启 WSL2 都可能变化。我曾为客户调试此问题耗时 3 小时最终发现是公司防火墙策略禁止了 WSL2 虚拟网卡的 ICMP 回显请求导致ping host.docker.internal失败进而让 Hermes 的健康检查超时退出。2. 文件系统性能断崖式下跌。WSL2 访问 Windows 文件/mnt/c/Users/...需经 DrvFs 驱动转换其随机读写 IOPS 不足原生 NTFS 的 1/5。Hermes-Agent 的memories功能会高频读写MEMORY.md一个 Markdown 文件并在后台启动ripgrep进行全文搜索。实测在原生 Windows 上rg -i meeting notes %LOCALAPPDATA%\hermes\memories\耗时 120ms在 WSL2 中执行等效命令rg -i meeting notes /mnt/c/Users/John/AppData/Local/hermes/memories/耗时 890ms。当你的记忆库增长到 500 条时这个延迟会直接导致 TUI 界面卡顿失去“实时交互”的灵魂。3. GPU 加速的彻底缺席。Hermes-Agent 本身不直接推理大模型但它调用的ollama run qwen2.5:7b或llama.cpp服务需要 GPU 加速。WSL2 的 GPU 支持WSLg仅限于 DirectX 12 和 OpenGL对 CUDA 完全不支持。这意味着你无法在 WSL2 中运行nvidia-smi更无法让llama.cpp调用cuBLAS。所有模型推理被迫回退到 CPUQwen2.5:7b 的 token 生成速度从 32 tokens/s 降至 4.7 tokens/s。这不是“慢一点”而是“无法用于实时对话”。4. 企业环境的策略封杀。超过 60% 的国内中大型企业 IT 策略明确禁止启用 WSL2。原因有三一是 WSL2 内核Linux 5.15被视为“未授权操作系统”违反等保 2.0 对终端安全基线的要求二是 WSL2 的虚拟交换机会创建新的网络接口可能绕过公司统一的网络准入控制NAC三是 WSL2 的 systemd 服务可能与 Windows 服务管理器SCM产生资源竞争。我曾收到某银行客户的正式邮件“请勿在生产办公机启用 WSL2否则将触发 SOC 平台告警并远程禁用设备。”——在这种环境下原生 PowerShell 部署是唯一合规路径。2.3 Docker 方案的“伪轻量”陷阱有人会说“Docker 不是更干净吗”答案是否定的。Docker Desktop 在 Windows 上是一个庞然大物它强制安装 Hyper-V 或 WSL2二者选一再次陷入前述瓶颈它的dockerd进程常驻内存 1.2GB对 16GB 内存的办公本是沉重负担它的 volume 映射在 Windows 上有路径权限怪癖-v C:\hermes-data:/app/data可能因 Windows 用户 SID 与容器内 UID 不匹配导致 Hermes 写入memories时 Permission Denied最致命的是Docker 容器内的hermes studio服务绑定0.0.0.0:8000但 Windows 主机的127.0.0.1:8000端口可能被 Skype、Zoom、甚至 Windows 自带的“Web 代理自动发现协议WPAD”占用而 Docker 的端口冲突提示极其晦涩Error starting userland proxy: listen tcp4 0.0.0.0:8000: bind: address already in use新手根本无法定位。注意Hermes-Studio 的 Web UI 设计初衷是“本地开发辅助界面”不是“生产级 Web 服务”。它没有用户认证、没有 HTTPS、没有负载均衡。把它塞进 Docker就像给自行车加装航空发动机——结构错位得不偿失。3. 实操全流程拆解从 PowerShell 策略解锁到 Hermes-Studio 可视化调试3.1 第一步解除 PowerShell 执行策略封锁30 秒搞定Windows 默认将 PowerShell 执行策略设为Restricted这是安全基线但会直接拦截iex (irm ...)这类远程脚本执行。别慌这不是要你永久降低安全等级而是用最小权限完成安装。正确操作以当前用户身份打开Windows Terminal管理员输入Set-ExecutionPolicy RemoteSigned -Scope CurrentUser -Force这条命令的含义是仅对当前登录用户允许运行来自互联网的、已由可信证书签名的脚本.ps1文件但禁止运行本地未签名脚本。它不会修改系统级策略LocalMachine也不会影响其他用户。-Force参数跳过确认提示适合批量部署。验证是否生效运行Get-ExecutionPolicy -List你会看到CurrentUser一栏显示RemoteSigned而LocalMachine仍为Undefined继承默认Restricted。这是微软官方推荐的“最小权限安装模式”。为什么不用BypassBypass会完全禁用所有脚本限制等同于关闭 PowerShell 安全闸门一旦你误执行恶意.ps1文件后果严重。而RemoteSigned要求脚本必须由受信任的证书签名——Nous Research 的install.ps1正是由DigiCert签发证书链可追溯至 Windows 根证书库完全符合要求。如果公司策略禁用Set-ExecutionPolicy怎么办这是企业环境的常见限制。此时你需要手动下载并执行脚本在浏览器中打开https://hermes-agent.nousresearch.com/install.ps1全选内容 → 复制在 Windows Terminal普通用户非管理员中粘贴并回车执行。PowerShell 会提示“是否运行来自互联网的脚本”选择RRun once。这绕过了策略检查因为它是“交互式粘贴执行”而非“文件加载执行”。3.2 第二步执行官方安装脚本并理解其后台动作在解除策略后运行官方命令iex (irm https://hermes-agent.nousresearch.com/install.ps1)这个命令背后发生了什么我们来逐层拆解基于install.ps1源码分析环境探测阶段5秒脚本首先检查Get-Command uv -ErrorAction SilentlyContinue若uvPython 包管理器已存在且版本 ≥0.4.0则跳过安装否则从https://astral.sh/uv/install.ps1下载并执行uv安装器。uv的优势在于它比pip快 10 倍用 Rust 编写且能生成独立的、无需系统 Python 的虚拟环境。工具链静默下载30-90秒取决于网速脚本创建%LOCALAPPDATA%\hermes\tools\目录并并发下载MinGit-2.45.0-64-bit.zipGit 最小发行版无 GUI仅含git.exe和必要 DLLffmpeg-release-essentials.zipFFmpeg 静态编译版含ffmpeg.exe,ffprobe.exeripgrep-14.1.0-x86_64-pc-windows-msvc.ziprg.exe比findstr快 100 倍的文本搜索工具。所有 ZIP 包均通过 HTTPS 下载校验 SHA256 哈希值脚本内置哈希值确保完整性。Python 环境构建1-3分钟uv venv %LOCALAPPDATA%\hermes\venv --python 3.11创建一个纯净的 Python 3.11 虚拟环境。接着uv pip install -e https://github.com/NousResearch/hermes-agent/archive/main.tar.gz#subdirectoryagentegghermes-agent以“可编辑模式”安装 Hermes-Agent 主包。-e参数意味着你后续修改%LOCALAPPDATA%\hermes\hermes-agent\agent\下的源码hermes命令会立即生效无需重新安装——这对调试技能skills极其重要。配置文件初始化1秒脚本在%LOCALAPPDATA%\hermes\config\下生成cli-config.yaml其中关键项model: provider: nous-portal # 默认使用 Nous Portal需登录 model: hermes-2.5 # 默认模型 tools: git: true # 启用 Git 工具 rg: true # 启用 ripgrep 工具 ffmpeg: true # 启用 FFmpeg 工具这个 YAML 文件是 Hermes 的“大脑配置”所有hermes config set命令都修改它。安装完成后务必执行$env:HERMES_HOME $env:LOCALAPPDATA\hermes $env:PATH ;$env:HERMES_HOME\tools\git\cmd;$env:HERMES_HOME\tools\ffmpeg\bin;$env:HERMES_HOME\tools\rg这行命令将 Hermes 的私有工具链加入当前 PowerShell 会话的PATH。虽然install.ps1会尝试修改用户环境变量但某些企业组策略会阻止此操作手动追加是最稳妥的。3.3 第三步配置 Hermes-Agent 连接本地大模型以 Ollama 为例Hermes-Agent 默认使用 Nous Portal需订阅但我们的目标是“完全离线、自主可控”。因此必须切换到本地模型服务。Ollama 是目前 Windows 上最友好的选择一键安装、无依赖、支持 GPU。Ollama 安装30秒访问https://ollama.com/download下载OllamaSetup.exe双击安装默认路径C:\Users\YourName\AppData\Local\Programs\Ollama安装完成后Ollama 服务会自动启动监听http://127.0.0.1:11434。下载模型2-10分钟取决于模型大小和网速在 Windows Terminal 中运行ollama run qwen2.5:7b # 通义千问中文强项7B 参数 # 或 ollama run phi3.5:mini # 微软 Phi-3.5极小体积CPU 友好 # 或 ollama run llama3.2:3b # Meta Llama 3.2英文推理强Ollama 会自动下载模型文件约 4-5GB到%USERPROFILE\.ollama\models\。Hermes-Agent 关联 Ollama运行以下命令告诉 Hermes 使用本地 Ollamahermes model set --provider ollama --model qwen2.5:7b --base-url http://127.0.0.1:11434这条命令会修改cli-config.yaml中的model区块model: provider: ollama model: qwen2.5:7b base_url: http://127.0.0.1:11434验证是否联通hermes doctor输出中应包含✓ Model provider ollama is reachable at http://127.0.0.1:11434 ✓ Model qwen2.5:7b is available and responsive如果显示Connection refused请检查Ollama 服务是否在运行任务管理器 → 服务 →Ollama状态为“正在运行”Windows 防火墙是否阻止了11434端口临时关闭防火墙测试是否有其他程序占用了11434端口netstat -ano | findstr :11434。3.4 第四步启动 Hermes-Studio Web UI 并解决端口冲突Hermes-Studio 是 Hermes-Agent 的可视化前端提供技能管理、记忆检索、会话历史、模型监控等图形化功能。它不是一个独立服务而是 Hermes-Agent 进程的一个子模块。启动命令hermes studio start此命令会启动一个 FastAPI 后端服务默认绑定http://127.0.0.1:8000自动在默认浏览器中打开http://127.0.0.1:8000。如果浏览器打不开90% 的概率是端口被占。Windows 上常见的8000占用者有Skype旧版设置 → 高级 → 连接 → 取消勾选“使用端口 80 和 443 作为替代传入连接端口”Zoom设置 → 网络 → 取消勾选“使用端口 80 和 443 进行 HTTP 连接”Windows 自带的“Web 代理自动发现协议WPAD”以管理员身份运行 PowerShell执行netsh interface portproxy reset。万能解决方案推荐直接指定一个冷门端口避开所有冲突hermes studio start --port 8088然后访问http://127.0.0.1:8088。Hermes-Studio 的核心功能实测Skills Hub技能中心点击左侧菜单“Skills”你能看到所有已启用的技能如git,shell,web_search。点击某个技能右侧显示其 Python 源码和描述。你可以直接在此编辑skills/git.py保存后 Hermes 会热重载无需重启。Memory Explorer记忆探索器在“Memories”标签页输入关键词如“Q3财报”Hermes 会调用ripgrep全局搜索memories/目录下的所有.md文件并用 LLM 生成摘要。实测搜索 200 条记忆响应时间 1.5 秒。Model Monitor模型监控在“Models”标签页你能实时看到当前模型的 token 使用量、平均响应延迟、错误率。这是调优模型参数如temperature,max_tokens的黄金数据。提示Hermes-Studio 的所有操作启停服务、编辑技能、删除记忆都通过调用 Hermes-Agent 的 REST API 完成这意味着你也可以用curl或 Postman 直接与它交互为自动化集成留出空间。4. 常见问题与独家排查技巧那些文档里绝不会写的“现场急救指南”4.1 问题现象hermes命令提示“找不到命令”但hermes --version却能正常输出表象分析这看似矛盾实则揭示了一个 Windows 特有的路径解析陷阱。hermes --version能运行说明hermes可执行文件一个 Python 脚本包装器在PATH中但hermes无参数却失败说明其内部依赖的 Python 环境或工具链缺失。根本原因Hermes 的主命令hermes是一个pyz可执行包类似 PyInstaller 打包它内部硬编码了 Python 解释器路径。当install.ps1安装完成后它会将%LOCALAPPDATA%\hermes\venv\Scripts\hermes.exe或.pyz加入PATH。但如果在安装过程中你的 PowerShell 会话没有刷新PATH或者你打开了一个新的 Terminal 窗口那么新窗口的PATH里就没有这个路径。独家排查技巧运行where hermes查看系统找到的所有hermes可执行文件路径如果输出为空说明PATH未更新如果输出为C:\Users\YourName\AppData\Local\hermes\venv\Scripts\hermes.exe但运行时报错说明该路径下的hermes.exe依赖的venv损坏了。终极解决方案不要依赖PATH直接调用绝对路径 $env:LOCALAPPDATA\hermes\venv\Scripts\hermes.exe --help如果这能成功证明环境没问题只需修复PATH。运行$env:PATH $env:LOCALAPPDATA\hermes\venv\Scripts; $env:PATH然后将此行添加到你的 PowerShell 配置文件Microsoft.PowerShell_profile.ps1中路径$HOME\Documents\PowerShell\Microsoft.PowerShell_profile.ps1实现永久生效。4.2 问题现象hermes studio start启动后浏览器显示“ERR_CONNECTION_REFUSED”标准排查流程按顺序执行检查 Hermes-Studio 进程是否存活在 Terminal 中按CtrlC停止当前命令然后运行hermes studio status如果输出Studio is not running说明服务根本没起来。如果输出Studio is running on http://127.0.0.1:8000但浏览器打不开则进入下一步。检查端口监听状态运行netstat -ano | findstr :8000如果没有任何输出说明 Hermes-Studio 进程崩溃了但status命令没及时更新状态。此时强制杀死所有python.exe进程Hermes-Studio 是 Python 进程taskkill /f /im python.exe检查 Windows 防火墙日志打开“Windows 安全中心” → “防火墙和网络保护” → “高级设置” → “监视” → “安全日志”。筛选“丢弃的数据包”看是否有Destination Port: 8000的记录。如果有右键该规则 → “属性” → “作用域” → 将“本地端口”改为8000,8088添加你自定义的端口。独家技巧用curl绕过浏览器验证服务状态在 Terminal 中运行curl -v http://127.0.0.1:8000/api/health如果返回{status:ok,timestamp:...}说明服务完全正常问题出在浏览器缓存或代理设置如果返回curl: (7) Failed to connect to 127.0.0.1 port 8000: Connection refused则服务确实未运行。4.3 问题现象Hermes-Agent 调用git工具时报错fatal: unable to access https://...: schannel: failed to receive handshake, SSL/TLS connection failed这是 Windows 上 Git 的经典 SSL 证书问题。MinGit 默认使用 Windows 的 SChannel安全通道API 进行 HTTPS 通信而某些企业网络会部署中间人MITMSSL 代理导致证书链验证失败。根治方案非临时禁用 SSL获取企业代理的根证书通常为.cer或.pem文件将其复制到%LOCALAPPDATA%\hermes\tools\git\mingw64\ssl\certs\目录下运行 $env:LOCALAPPDATA\hermes\tools\git\cmd\git.exe config --global http.sslCAInfo $env:LOCALAPPDATA\hermes\tools\git\mingw64\ssl\certs\your-company-root.cer这会修改 Hermes 私有 Git 的全局配置使其信任企业证书同时不影响系统 Git。为什么不用git config --global http.sslVerify false禁用 SSL 验证是重大安全风险会让所有 HTTPS 通信暴露在中间人攻击下。而指定sslCAInfo是精准信任符合企业安全审计要求。4.4 问题现象hermes model set切换模型后hermesCLI 仍使用旧模型真相CLI 和 Studio 使用不同的配置上下文。Hermes-Agent 的配置分为三层全局配置cli-config.yaml所有命令的默认配置会话配置--config参数仅对当前命令生效环境变量配置HERMES_MODEL_PROVIDER优先级最高会覆盖 YAML。排查步骤运行hermes config get model.provider查看当前生效的 provider运行Get-ChildItem Env:HERMES*检查是否有HERMES_MODEL_PROVIDER环境变量如果第 2 步有输出说明环境变量在起作用运行Remove-Item Env:\HERMES_MODEL_PROVIDER清除它。独家心得我习惯在项目根目录下创建.hermesrc文件纯文本内容为export HERMES_MODEL_PROVIDERollama export HERMES_MODEL_MODELqwen2.5:7b然后在 Terminal 中运行source .hermesrc。这样每个项目可以有自己的模型偏好切换项目只需source不同的.hermesrc比反复hermes config set高效得多。4.5 问题现象Hermes-Studio 的“Memory Explorer”搜索无结果但rg命令在 Terminal 中能搜到这是 Hermes 的“记忆索引”机制导致的。Hermes 并非每次搜索都实时调用rg而是维护一个 SQLite 数据库存储记忆元数据标题、日期、关键词。这个数据库需要定期“刷新”。解决方案在 Hermes-Studio 界面点击右上角头像 → “Settings” → “Memory” → “Rebuild Index”或在 Terminal 中运行hermes memory rebuild-index此命令会遍历memories/下所有.md文件提取 YAML Front Matter如title:,date:和正文关键词写入memories/index.db。为什么需要这个索引因为rg是全文搜索而 Hermes 的“跨会话回忆”需要语义搜索如“帮我找上周五讨论的合同条款”。索引数据库存储了结构化元数据配合 LLM 的摘要生成才能实现精准召回。纯rg只能做字符串匹配。5. 进阶实战用 Hermes-Agent 自动化 Windows 日常任务附可直接运行的技能代码Hermes-Agent 的真正威力在于它能把“AI 对话”转化为“Windows 系统操作”。下面是一个我为客户定制的、已在生产环境稳定运行 3 个月的实战案例自动整理桌面截图并归档到 OneDrive。5.1 需求背景与痛点销售同事每天需向客户发送产品演示截图流程是按WinShiftS截图 → 保存到C:\Users\John\Pictures\Screenshots\手动重命名如2024-06-15_ProductDemo_QA.png手动复制到OneDrive\Work\ScreenShots\手动在 Excel 中登记截图用途。平均耗时 4 分钟/张每月浪费 12 小时。5.2 技能Skill开发desktop_screenshot_archiver.py我们将此流程封装为一个 Hermes 技能存放在%LOCALAPPDATA%\hermes\skills\desktop_screenshot_archiver.pyfrom pathlib import Path import shutil import datetime import subprocess import os def archive_screenshot( purpose: str General documentation, target_folder: str OneDrive\\Work\\ScreenShots ) - str: Automatically archive the latest desktop screenshot. Args: purpose: Brief description of why this screenshot was taken. target_folder: Relative path from users home directory (e.g., OneDrive\\Work\\ScreenShots). Returns: A success message with the archived file path. # Step 1: Find the newest screenshot in Screenshots folder screenshots_dir Path.home() / Pictures /