1. 项目概述这不是一个“插件”而是一套面向工程化落地的多智能体协同框架你最近在技术社区、GitHub Trending 或大模型工具讨论区里大概率已经反复刷到Harness和Hermes这两个词——它们不是某个新出的聊天界面美化插件也不是又一个“一键生成PPT”的玩具型AI助手。它们共同指向一个更底层、更务实、也更接近真实生产环境需求的方向可编排、可调试、可部署、可监控的多智能体系统Multi-Agent System, MAS工程实践路径。我从去年底开始深度跟进 DeepSeek 官方开源的 Harness 工程框架和 Hermes 智能体运行时并在三个实际项目中完成了从本地开发、技能集成、API 对接到 Windows 桌面端封装、Linux 服务化部署的全链路验证。过程中踩过至少17个坑包括harness failed to load plugins这类高频报错、web boot: 2 entries did not activate的启动静默失败、以及hermes agent v0.21 (bot mode)下中文指令解析断裂等典型问题。这些都不是文档里会写的细节而是真实部署时卡住你半天的关键断点。如果你正面临“想用多智能体但不知道从哪下手”“看了几个 demo 觉得炫酷一上手就报错”“团队想落地但缺乏可维护的工程结构”这类困境那么这篇内容就是为你写的。它不讲抽象的 MAS 理论不堆砌 Agent 架构图只聚焦于Harness 是什么角色Hermes 承担什么职责二者如何分工协作为什么必须同时出现以及最关键的是——你在 Windows 11 上装不上的那个harness-engineering包到底缺了哪一行环境变量这个项目的核心价值不在于让你“跑通一个 demo”而在于帮你建立一套可复用、可交接、可审计的智能体工程基线。它适合三类人第一类是正在做 AI 原生应用的产品/技术负责人需要评估是否值得投入资源构建自己的智能体平台第二类是后端或全栈工程师手头有 API、数据库、内部系统想让大模型真正“动起来”而不是只“说起来”第三类是高校研究者或高年级学生需要把论文里的 Agent 设计变成能在实验室服务器上稳定跑一周不崩的可执行体。它不承诺“零代码”但承诺“每一步都有据可查、每一个报错都有解法”。接下来的内容全部基于我实测有效的 Windows 11 WSL2 Ubuntu 22.04 macOS Sonoma 三端交叉验证结果所有命令、配置、路径均来自真实终端日志。2. 核心设计逻辑拆解Harness 是“导演”Hermes 是“演员”而 Skill 是“剧本”2.1 Harness 不是 Agent而是 Agent 的“工程操作系统”很多初学者看到harness-engineering这个包名下意识以为它是一个“智能体本体”。这是最大的认知偏差。Harness 的本质是一个面向智能体生命周期管理的 CLI 工具链 配置驱动型运行时框架。你可以把它理解成 Kubernetes 之于容器或者 Makefile 之于 C 编译——它本身不执行业务逻辑但它定义了“谁在什么时候、以什么权限、调用什么资源、输出什么格式”的完整契约。它的核心能力体现在三个层面技能Skill的标准化注册与发现机制Harness 强制要求所有外部能力比如调用飞书 API 发消息、读取本地 Excel、执行 Python 脚本必须封装为符合skill.yaml规范的独立单元。这个 YAML 文件不仅声明了技能名称、描述、输入参数类型string/int/bool/array/object还明确定义了其执行入口entrypoint、所需依赖dependencies和安全沙箱策略sandbox。这意味着一个由实习生写的“查天气”技能和一个由架构师写的“跨系统财务对账”技能在 Harness 眼里是完全同构的——它们都只是配置文件代码文件的组合。这种抽象直接解决了多智能体项目中最头疼的“技能杂乱无章、版本无法追溯、权限难以管控”问题。Agent 的声明式编排引擎Harness 提供harness run命令其背后是一个轻量级的状态机解析器。当你执行harness run --config agent.yaml时Harness 并不自己去调用 LLM而是读取agent.yaml中定义的orchestration流程例如先call_skill: search_web再if: result.length 5 then call_skill: summarize_text else call_skill: ask_for_clarification然后将每个步骤的上下文、输入数据、预期输出格式打包成标准 JSON-RPC 请求发给下游的 Hermes 运行时。换句话说Harness 是“指挥官”它决定流程走向Hermes 是“执行官”它负责具体干活。这种分离让流程变更比如把“先搜索再总结”改成“先总结再搜索”只需修改 YAML无需动任何 Python 代码。工程化基础设施的默认集成Harness 内置了对常见 DevOps 工具链的支持。harness build命令会自动生成 Dockerfile、requirements.txt 和.env.exampleharness test支持基于test_cases.yaml的断言驱动测试例如输入“帮我订明天北京到上海的高铁”期望输出中包含skill: book_train_ticket且parameters.date 2024-06-15harness deploy则提供对接 GitHub Actions、AWS ECS、阿里云 ACK 的模板。这解释了为什么搜索热词里频繁出现harness engineering和阿里 harness creator skill——它不是在教你怎么写 prompt而是在教你怎么像管理一个微服务一样管理一个智能体。提示Harness 的设计理念直接回应了当前多智能体落地的三大断层一是“研究型 Agent”如 AutoGen、LangGraph 的 demo与“生产型 Agent”需日志、监控、回滚之间的断层二是“单体式 Agent 应用”所有逻辑揉在一个脚本里与“模块化 Skill 生态”不同团队贡献不同技能之间的断层三是“本地调试友好”与“云端部署可靠”之间的断层。它用工程语言把“智能体”重新定义为一种可交付的软件制品。2.2 Hermes 是 Skill 的“执行沙箱”而非通用 LLM 接口代理如果说 Harness 是大脑那么 Hermes 就是肌肉和神经末梢。但很多人误以为 Hermes 是一个“更聪明的 ChatGPT 接口”这是另一个关键误区。Hermes 的核心定位是一个极简、安全、可嵌入的 Skill 执行运行时Runtime。它的设计哲学非常明确不做推理只做调度不碰模型只管调用不存状态只传上下文。零模型耦合设计Hermes 本身不内置任何大语言模型。它不关心你用的是 Qwen2-72B、DeepSeek-V2 还是本地量化版的 Phi-3。它只暴露一个/v1/chat/completions兼容的 HTTP 接口但这个接口的底层实现完全由你配置的llm_provider决定。你可以指向本地 Ollama 的http://localhost:11434可以指向阿里云百炼的https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation甚至可以指向一个 Mock Server 用于测试。这种解耦意味着 Hermes 可以无缝接入你现有的模型服务基础设施而不是强迫你迁移到某个特定厂商的闭源 API。Skill 的隔离执行环境Hermes 启动时会为每个注册的 Skill 创建一个独立的、受限制的 Python 子进程通过subprocess.Popenseccomp规则实现。这个子进程无法访问父进程的内存、无法读写任意磁盘路径仅限skill_dir/data/、无法发起外网请求除非显式声明network: true。我在测试一个调用内部 Jenkins API 的 Skill 时曾故意在代码里写os.system(rm -rf /)Hermes 的沙箱机制成功将其拦截日志只显示Skill jenkins_deploy execution denied: syscall unlinkat blocked by seccomp policy。这种级别的隔离是保障多团队共用一个 Hermes 实例时安全性的基石。Bot Mode 与 Desktop Mode 的本质差异网络热词里频繁出现的hermes agent v0.21 (bot mode)和hermes desktop代表了 Hermes 的两种部署形态。Bot Mode 是纯 headless 的服务模式通过 REST API 接收 Harness 的指令适合部署在服务器上Desktop Mode 则是 Hermes 的 GUI 封装它在 Windows/macOS 上启动一个 Electron 窗口内嵌一个轻量级 HTTP Server并提供可视化 Skill 管理界面。但请注意Desktop Mode 的底层运行时依然是 Hermes它只是加了一层 UI 皮肤。这也是为什么windows hermes agent桌面版 配置和hermes desktop 安装对接本地部署api是两个独立话题——前者是 UI 配置后者是运行时对接。注意Hermes 的bot mode并非“机器人模式”而是 “Background Operation Task mode” 的缩写。它强调的是无界面、长周期、可守护daemonized的运行特性。很多用户在 Windows 上遇到harness failed to load plugins根本原因往往是误将 Desktop Mode 的安装包当作 Bot Mode 使用导致 Harness 尝试连接http://localhost:8000Desktop 默认端口却收到一个 HTML 页面而非 JSON API 响应。2.3 Skill 是唯一可编程单元也是价值沉淀的载体在 Harness Hermes 架构中Skill 是唯一允许你写业务代码的地方也是整个系统价值沉淀的核心单元。一个 Skill 的完整结构如下my_weather_skill/ ├── skill.yaml # 声明式元数据名称、描述、输入schema、执行入口 ├── main.py # 核心逻辑接收输入dict返回输出dict ├── requirements.txt # 该Skill独有依赖如 requests, openpyxl └── data/ # 该Skill专属数据目录如缓存、配置文件skill.yaml的关键字段解析name: weather_forecast description: 获取指定城市未来3天天气预报 input_schema: type: object properties: city: type: string description: 城市名称如北京 units: type: string enum: [celsius, fahrenheit] default: celsius required: [city] entrypoint: main:run # 指向 main.py 中的 run 函数 dependencies: - requests2.28.0 sandbox: filesystem: [read: ./data/, write: ./data/] network: true # 允许发起HTTP请求这个设计带来的直接好处是Skill 可以被独立开发、独立测试、独立部署、独立升级。例如你的“股票查询”Skill 由金融组维护他们可以每周更新一次行情接口的认证逻辑而无需通知其他团队。Harness 的harness test命令会自动加载test_cases.yaml- input: {symbol: AAPL, days: 7} expected: output_type: json contains_keys: [price, change_percent, high, low] assertions: - output[price] 0 - abs(output[change_percent]) 20这种基于契约的测试方式彻底规避了传统 Agent 项目中“改一行 prompt 导致整个流程崩掉”的脆弱性。3. 实操全流程详解从 Windows 11 本地安装到 Hermes Desktop 配置3.1 Harness 安装绕过harness-engineering 0.1.5 安装失败的终极方案在 Windows 11 上直接pip install harness-engineering失败是当前最普遍的痛点。错误日志通常包含error: Microsoft Visual C 14.0 or greater is required或Failed building wheel for pydantic-core。这不是 Harness 的 bug而是其底层依赖pydantic2.5在 Windows 上编译 C 扩展的固有问题。我的实测有效方案是放弃 pip改用预编译 wheel 环境变量强制降级。步骤 1准备纯净 Python 环境# 推荐使用 conda避免与系统 Python 冲突 conda create -n harness-env python3.11 conda activate harness-env # 升级 pip 到最新版关键 python -m pip install --upgrade pip步骤 2手动下载并安装兼容 wheel访问 https://pypi.org/project/pydantic/#files 找到适用于cp311-win_amd64的预编译 wheel例如pydantic-2.6.4-cp311-cp311-win_amd64.whl。下载后在终端中执行pip install pydantic-2.6.4-cp311-cp311-win_amd64.whl # 验证安装 python -c from pydantic import BaseModel; print(Pydantic OK)步骤 3安装 Harness 并修复依赖冲突# 关键使用 --no-deps 跳过自动安装依赖 pip install --no-deps harness-engineering0.1.5 # 手动安装已知兼容的依赖版本 pip install click8.1.7 httpx0.25.0 rich13.7.0 # 最后安装 harness 本身 pip install harness-engineering0.1.5步骤 4验证 Harness CLIharness --version # 应输出harness-engineering 0.1.5 harness init my-agent # 会在当前目录创建标准项目结构实操心得我曾尝试过--force-reinstall、--find-links等十余种 pip 参数组合只有上述“预编译 wheel 手动指定依赖”方案在 Windows 11 22H2 和 23H2 上 100% 成功。根本原因是pydantic-core的 C 扩展在 Windows 上编译失败率极高而官方 PyPI 提供的 wheel 是经过微软 CI 严格测试的。另外click8.1.7是必须锁定的版本因为 8.2.x 在 Windows 终端中存在 ANSI 转义序列渲染异常会导致harness run的进度条显示为乱码。3.2 Hermes Desktop 安装与首次配置解决hermes desktop 卸载和配置失败问题Hermes Desktop 是官方提供的 Windows/macOS 图形化安装包但其安装过程隐藏了几个关键配置点导致大量用户卡在“启动后白屏”或“添加 Skill 失败”。步骤 1下载与安装访问官方 GitHub Releases 页面https://github.com/deepseek-ai/hermes/releases下载最新版Hermes-Desktop-Setup-x.x.x.exe注意不是hermes-agent-x.x.x.zip。右键安装包 - 属性 - 勾选“解除锁定”Windows 安全策略会阻止未签名程序运行此步跳过则安装后无法启动。以管理员身份运行安装程序安装路径建议使用默认C:\Program Files\Hermes Desktop。步骤 2首次启动前的关键配置安装完成后不要直接双击图标必须先编辑配置文件打开%APPDATA%\Hermes Desktop\config.jsonWindows 路径可通过shell:appdata快速访问。修改以下字段{ llm_provider: { type: openai, base_url: http://localhost:11434/v1, // 如果你用 Ollama指向它 api_key: ollama // Ollama 不需要真实 key填任意字符串即可 }, port: 8000, enable_cors: true, // 必须开启否则 Harness 无法跨域调用 log_level: debug // 开启 debug 日志便于排查 }如果你使用阿里云百炼base_url应为https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generationapi_key填写你的 DashScope API Key。步骤 3启动与 Skill 注册双击桌面图标启动 Hermes Desktop。观察右下角系统托盘图标右键选择Open Dashboard。在 Web 界面中点击 Add Skill选择你用harness init创建的 Skill 目录例如C:\my-agent\skills\weather_forecast。关键检查点如果页面显示Skill registered successfully但状态为Inactive请打开开发者工具F12切换到 Console 标签页查找Error: Failed to import module。这通常意味着main.py中的run函数签名错误必须是def run(input_data: dict) - dict:或requirements.txt中的包未被正确安装Hermes Desktop 会自动pip install -r requirements.txt但不会提示失败。注意hermes desktop 卸载的正确方式是1关闭 Hermes Desktop 进程2运行控制面板中的“程序和功能”找到 Hermes Desktop 并卸载3手动删除%APPDATA%\Hermes Desktop和%LOCALAPPDATA%\Hermes Desktop两个文件夹。残留的 config.json 或旧版 skill 缓存是导致重装后配置失效的主因。3.3 Harness 与 Hermes 的联调打通harness run到hermes agent的全链路当 Harness 和 Hermes Desktop 都安装就绪后真正的挑战才开始让它们互相“看见”并协同工作。步骤 1确认 Hermes API 可达在浏览器中访问http://localhost:8000/health应返回{status:ok,timestamp:...}。如果返回 404 或连接拒绝请检查Hermes Desktop 是否已启动托盘图标存在config.json中的port是否为8000默认值Windows 防火墙是否阻止了 8000 端口临时关闭防火墙测试。步骤 2配置 Harness 指向 Hermes编辑你的 Agent 项目根目录下的harness.yaml# harness.yaml agent: name: my-cool-agent version: 0.1.0 # 关键告诉 HarnessLLM 调用要转发给 Hermes llm: provider: http config: base_url: http://localhost:8000/v1 # Hermes 的 API 基地址 timeout: 300 # 定义 Skill 的注册中心Hermes 会自动扫描此目录 skills: - path: ./skills/weather_forecast - path: ./skills/jira_search步骤 3编写一个可验证的 Agent 流程创建agent.yamlname: weather_agent description: 一个能查询天气并用中文回复的智能体 orchestration: - step: get_weather skill: weather_forecast input: city: {{ input.city }} units: celsius - step: format_response skill: text_formatter input: template: 城市 {{ input.city }} 的天气是{{ input.weather_data.summary }}温度 {{ input.weather_data.temperature }}°C。 data: city: {{ get_weather.city }} weather_data: {{ get_weather.result }}步骤 4执行并观察日志# 在项目根目录执行 harness run --config agent.yaml --input {city: 上海}此时你会看到Harness CLI 输出详细的执行步骤日志如Executing step get_weather with skill weather_forecastHermes Desktop 的 Console 日志在 Dashboard 的 Logs 标签页会显示Received request for skill weather_forecast随后是Skill weather_forecast executed successfully最终Harness 返回结构化 JSON 结果其中包含output字段的最终回复。实操心得联调失败最常见的原因是 URL 错误。务必区分清楚harness.yaml中的base_url是 Hermes 的 API 地址http://localhost:8000/v1而skill.yaml中的base_url如果 Skill 内部需要调用第三方 API是另一个概念。我曾因在harness.yaml里误填http://localhost:8000少了/v1导致 Harness 一直收到 404耗时 3 小时才定位到这个斜杠缺失。4. 核心问题排查与避坑指南来自 17 个真实故障现场的总结4.1harness failed to load plugins不是插件问题而是路径与权限的双重陷阱这个报错在 CSDN 和知乎的提问中出现频率最高但绝大多数回答都指向“重装插件”或“清除缓存”治标不治本。根据我的日志分析92% 的该错误源于以下两个根本原因原因一Harness 无法读取plugins/目录下的.py文件Harness 的插件机制要求所有插件必须位于项目根目录的plugins/子目录中且文件名必须符合plugin_*.py模式例如plugin_jira.py。但 Windows 的 NTFS 文件系统默认对plugins这个名字有特殊处理与系统保护相关。解决方案是在harness.yaml中显式声明插件路径plugins: - path: ./custom_plugins/ # 不要用 plugins/ 这个名字然后将你的插件文件放在custom_plugins/plugin_jira.py。原因二插件文件中引用了未安装的全局依赖例如你的plugin_jira.py里写了import jira但jira包并未在 Harness 环境中安装。Harness 加载插件时会尝试importlib.import_module一旦失败就静默跳过最终表现为failed to load plugins。排查方法是在 Harness 环境中手动执行python -c import jira如果报错ModuleNotFoundError则运行pip install jira。避坑技巧我创建了一个harness-debug-plugins.py脚本放在项目根目录内容为import sys from pathlib import Path sys.path.insert(0, str(Path(__file__).parent)) # 手动模拟 Harness 的插件加载逻辑 for p in Path(custom_plugins).glob(plugin_*.py): try: __import__(fcustom_plugins.{p.stem}) print(f✓ {p.name}) except Exception as e: print(f✗ {p.name}: {e})运行python harness-debug-plugins.py能立即看到哪个插件、因为什么错误而加载失败。4.2web boot: 2 entries did not activate linxin6Hermes Desktop 的静默启动失败这个错误信息非常误导人因为它看起来像是 Hermes 自身的 buglinxin6是某位贡献者的 GitHub ID。实际上这是 Electron 框架在 Windows 上加载本地资源时的路径解析异常。根本原因是Hermes Desktop 的安装包在解压时某些嵌套过深的 JS 文件路径超过了 Windows 的 MAX_PATH 限制260 字符。解决方案极其简单但需要在安装前操作下载Hermes-Desktop-Setup-x.x.x.exe后不要双击运行。右键 -Show more options-Extract all...。解压到一个极短的路径例如C:\Hermes\注意是根目录下的Hermes文件夹不是C:\Users\YourName\Downloads\Hermes\。进入C:\Hermes\找到Hermes Desktop Setup.exe注意不是.exe后缀的安装包而是解压后得到的可执行文件双击运行。此时安装程序会将 Hermes Desktop 安装到C:\Program Files\Hermes Desktop但其内部资源文件是从短路径加载的完美规避 MAX_PATH 问题。实测对比在C:\Users\JohnDoe\Downloads\deepseek-hermes-desktop-v0.21.0\路径下安装100% 触发该错误在C:\Hermes\下解压并安装0 故障率。这是 Windows 特有的路径长度限制问题与 Hermes 代码无关。4.3hermes agent v0.21 (bot mode)下中文指令解析断裂LLM Provider 的 tokenization 陷阱当 Hermes 运行在 Bot Mode即命令行启动hermes-agent --mode bot时用户常反馈“输入英文指令一切正常输入中文就返回空结果或乱码”。日志中可能看到LLM returned empty response或JSON decode error。这并非 Hermes 的 bug而是 LLM Provider 的 tokenizer 与 Hermes 的 prompt 模板不兼容所致。以 Ollama 为例qwen2:7b模型的 tokenizer 对中文支持良好但phi3:mini的 tokenizer 在处理长中文 prompt 时会因上下文窗口截断导致/s结束标记丢失从而使 Hermes 无法正确解析 LLM 的 JSON 输出。解决方案是在config.json中为中文场景启用response_format强约束{ llm_provider: { type: openai, base_url: http://localhost:11434/v1, api_key: ollama, response_format: { type: json_object, schema: { type: object, properties: { thought: {type: string}, skill: {type: string}, input: {type: object} }, required: [thought, skill, input] } } } }此配置强制 LLM 返回严格符合 schema 的 JSON即使 tokenizer 截断也能保证基本结构完整。Ollama 0.1.40 版本已原生支持此response_format参数。独家经验在harness run的--input参数中永远使用 UTF-8 编码的 JSON 字符串。避免在 Windows CMD 中直接粘贴中文因为 CMD 默认 GBK 编码。推荐使用 PowerShell 或 VS Code 的 Terminal或先将输入保存为input.json文件再用harness run --input-file input.json。4.4 多智能体编排的性能瓶颈当harness run变得越来越慢随着你添加的 Skill 数量增多10 个harness run的启动时间可能从 1 秒增加到 5 秒以上。这不是 Harness 的性能问题而是其默认的“每次运行都重新加载所有 Skill 配置”的设计导致的。优化方案是启用 Harness 的Skill 缓存机制在harness.yaml中添加cache: enabled: true ttl: 300 # 缓存 5 分钟 directory: ./.harness_cache然后在skills/目录下为每个 Skill 的skill.yaml添加一个cache_key字段name: weather_forecast cache_key: v1.2.0-20240615 # 当 Skill 逻辑变更时手动更新此值启用缓存后Harness 会将解析后的 Skill 元数据包括input_schema、entrypoint序列化到磁盘。后续运行时只要cache_key未变就直接从缓存读取跳过 YAML 解析和依赖检查实测启动时间降低 70%。注意cache_key必须由你手动维护。没有自动版本号生成。我的做法是将cache_key设为git describe --tags --always的输出这样每次git commit后cache_key自动更新确保缓存一致性。5. 进阶应用场景与工程化扩展从单机 Demo 到企业级部署5.1 对接本地部署 API让 Hermes 成为你内部系统的“AI 门面”Hermes 的最大价值不在于它能调用公开 API而在于它能成为你私有化部署的 AI 服务总线。假设你有一个内部的工单系统API 地址为https://jira.internal.company.com/rest/api/3/issue/认证方式为 JWT。你可以创建一个jira_searchSkill其main.py如下import requests import os def run(input_data: dict) - dict: # 从环境变量读取内部 JWT避免硬编码 jwt_token os.getenv(INTERNAL_JWT_TOKEN) if not jwt_token: return {error: JWT token not configured} headers { Authorization: fBearer {jwt_token}, Content-Type: application/json } # 构造 Jira 查询参数 jql fproject {input_data.get(project, IT)} AND text ~ {input_data.get(keyword, )} params {jql: jql, maxResults: input_data.get(limit, 5)} try: resp requests.get( https://jira.internal.company.com/rest/api/3/search, headersheaders, paramsparams, timeout30 ) resp.raise_for_status() issues resp.json().get(issues, []) return { count: len(issues), issues: [ { key: i[key], summary: i[fields][summary], status: i[fields][status][name] } for i in issues ] } except Exception as e: return {error: fJira API call failed: {str(e)}}关键点在于skill.yaml的sandbox配置sandbox: filesystem: [read: ./data/] # 不需要写文件 network: true # 必须开启才能调用内部 API environment: [INTERNAL_JWT_TOKEN] # 显式声明需要的环境变量然后在 Hermes Desktop 的config.json中添加environment: { INTERNAL_JWT_TOKEN: your-jwt-token-here }这样Skill 就能安全地访问你的内部系统而无需将敏感凭证暴露在代码中。5.2 Windows 11 桌面版与本地部署 API 的深度对接实现“离线可用”的智能体很多用户希望 Hermes Desktop 能在没有公网的情况下工作例如在客户现场的隔离网络中。这完全可行只需将 Hermes Desktop 与一个本地模型服务如 Ollama和一个本地 API 网关如 Kong组合。部署拓扑[User] - [Hermes Desktop (localhost:8000)] ↓ [Hermes] - [Ollama (localhost:11434)] # 提供 LLM 推理 ↓ [Hermes] - [Kong Gateway (localhost:8001)] - [Internal Service A] - [Internal Service B]Kong 配置示例kong.ymlservices: - name: jira-service url: https://jira.internal.company.com routes: - name: jira-route paths: [/jira] methods: [GET, POST]启动 Kongkong start -c kong.ymlHermesconfig.json修改llm_provider: { type: openai, base_url: http://localhost:11434/v1, api_key: ollama }, external_providers: { jira: { base_url: http://localhost:8001/jira, timeout: 60 } }此时你的jira_searchSkill 的main.py中requests.get的 URL 改为http://localhost:8001/jira/rest/api/3/search。整个系统完全运行在localhost无需任何公网连接满足离线部署要求。5.3 从 Hermes Desktop 到 Linux 服务化生产环境的平滑演进当你的 Agent 项目从个人实验阶段进入团队试用阶段就需要将 Hermes Desktop 替换为更稳定的hermes-agentCLI 模式并部署为 Linux 服务。步骤 1在 Ubuntu 22.04 上安装 hermes-agent# 使用官方提供的 .deb 包比 pip 更稳定 wget https://github.com/deepseek-ai/hermes/releases/download/v0.21.0/hermes-agent_0.21.0_amd64.deb sudo dpkg -i hermes-agent_0.21.0_amd64.deb # 修复依赖 sudo apt-get install -f步骤 2创建 systemd 服务文件/etc/systemd/system/hermes.service