Hermes Agent：分布式智能体调度中枢与MCP协议实践-尧图网络科技

1. Hermes Agent 不是“又一个定时工具”，而是分布式智能体的调度中枢

你可能在 SpringBoot 项目里写过@Scheduled(cron = "0 0 * * * ?")，也可能在 Linux 上配过crontab -e，甚至用过 XXL-JOB 或 Quartz 做集群任务分发——但这些方案有个共同盲区：它们只管“什么时候跑”，不管“谁来跑”“跑完之后该告诉谁”“上次跑的结果能不能变成下一次的输入”。Hermes Agent 的本质，不是把 cron 封装得更漂亮，而是把任务从静态指令升级为可感知、可记忆、可协同的智能体（Agent）。

我第一次在客户现场看到它解决真实问题，是在一个跨三地数据中心的金融风控系统里。他们原来用 XXL-JOB 调度模型推理任务，但每次新模型上线，都要手动改数据库里的 cron 表达式、重启调度中心、再等 2 分钟注册节点——而模型迭代周期已压缩到 4 小时以内。Hermes Agent 接入后，运维人员只需在 Web 控制台拖拽一个“模型热更新触发器”，绑定 GitLab Webhook 和本地模型仓库路径，Agent 自动监听代码变更、拉取新权重、校验 SHA256、触发推理压测，并把结果写入长期记忆库供后续审计。整个过程无需重启任何服务，也不依赖开发改一行 Java 代码。

这背后是三个关键设计差异：

MCP 协议原生支持：不是“适配”消息协议，而是以 MCP（Model Control Protocol）为通信底座，所有组件——无论是 Playwright 浏览器实例、Figma 插件、还是 Oracle 数据库连接池——都作为 MCP 客户端注册到 Hermes Gateway，统一接受指令、上报状态、订阅事件；
长期记忆（Long-term Memory）内建：每个任务执行产生的日志、输出、异常堆栈、甚至截图和网络请求快照，都会按时间戳+上下文哈希自动存入嵌入式 RocksDB，支持自然语言查询（如“查上周五所有失败的 OTB 直播任务”）；
多平台运行时抽象：Windows Server 上它是个 Windows Service，Linux 上是 systemd unit，macOS 上是 launchd job，Docker 环境里是轻量级容器，而桌面版（Hermes Agent Desktop）则直接调用系统通知 API 和剪贴板接口——同一套配置文件，在不同平台启动后自动适配底层能力。

所以标题里说“99% 的人没用全”，真不是营销话术。绝大多数用户只把它当“带 Web 界面的 crond”，却忽略了它的 Agent 层：它能记住你上周三下午 3:17 修改过某个定时任务的参数，能在你下次打开控制台时主动弹出提示：“检测到您常修改otb_sync_job的--timeout参数，是否保存为模板？”——这种基于行为记忆的交互，才是它区别于传统调度工具的核心。

提示：如果你现在还在用@Scheduled注解硬编码时间表达式，或靠人工改数据库字段来调整任务频率，请先停下手。Hermes Agent 的价值不在“替代 cron”，而在“让 cron 具备上下文意识”。接下来我会拆解它真正被低估的 10 个功能，每一个都对应一个真实踩坑场景。

2. 功能一：MCP Server 模式下的动态插件热加载，彻底告别重启

很多团队卡在“Hermes Agent 安装卡在 uv package manager”或“桌面版安装超时”，根本原因不是网络问题，而是误用了默认的 Standalone 模式。当你执行hermes-agent install时，它默认下载的是包含完整 Python 运行时、Playwright 浏览器、FFmpeg 编解码器的“全能包”，体积超 1.2GB，国内镜像源又不稳定——但这恰恰暴露了对 Hermes 架构的误解：Hermes Agent 的核心是 MCP Server，而非一堆预装二进制。

真正的生产级部署，应该采用 MCP Server 模式。它的原理很简单：Agent 启动后，只运行一个轻量级 TCP 服务（默认端口 8081），监听 MCP 协议的REGISTER、INVOKE、NOTIFY消息；所有具体能力（比如执行 Selenium 脚本、调用 Oracle 存储过程、生成 Figma 设计稿）都由独立的 MCP Client 实现。Client 可以是 Python 脚本、Java JAR、甚至 Shell 命令，只要它能向localhost:8081发送标准 MCP JSON 消息即可。

我们实测过三种 Client 部署方式的冷启动耗时：

Client 类型	首次启动耗时	内存占用	热更新方式	适用场景
内置 Playwright Client（Standalone 模式）	47s	1.8GB	必须重启 Agent	临时测试、单机演示
独立 Python Client（`pip install hermes-mcp-playwright`）	1.2s	86MB	`kill -SIGHUP $(pidof python3)`	中小规模自动化，需频繁调试脚本
Java Spring Boot Client（`@McpClient`注解）	3.8s	210MB	JRebel 热替换或 Spring DevTools	企业级系统集成，强类型校验

关键操作步骤（以 Python Client 为例）：

在目标机器上执行pip install hermes-mcp-core hermes-mcp-playwright，不安装hermes-agent主包；
编写playwright_client.py，核心逻辑是：

from hermes_mcp.core import McpServer from hermes_mcp.playwright import PlaywrightExecutor server = McpServer(host="localhost", port=8081) executor = PlaywrightExecutor(headless=True) server.register_executor("browser:launch", executor.launch) server.register_executor("browser:goto", executor.goto) server.serve() # 启动 MCP Server，监听 8081

启动 Hermes Agent 主进程（此时它只是个空壳 MCP Server）：hermes-agent start --mode server；
运行python playwright_client.py，它会自动向 Agent 注册browser:*一系列能力；
在 Web 控制台创建新任务，选择“执行浏览器操作”，填入 URL 和 JS 脚本，保存即生效。

为什么这能解决“安装超时”问题？因为pip install下载的是纯 Python 包（<5MB），Playwright 浏览器二进制由 Client 启动时按需下载（可配置国内镜像源PLAYWRIGHT_DOWNLOAD_HOST=https://npmmirror.com/mirrors/playwright），且下载过程不阻塞 Agent 启动。

注意：RuoYi、Jeecg 等低代码平台用户常问“定时任务可以不重启直接改库里的时间吗”，答案是肯定的——但前提是你的定时任务执行器必须是 MCP Client。Agent 主进程只负责调度编排，Client 才是干活的，改数据库只影响调度计划，不影响执行器本身。我们有个客户把 Oracle JOB 改造成 MCP Client 后，DBA 在 PL/SQL Developer 里直接 updateHERMES_TASK_CONFIG表，3 秒后新 cron 就生效，完全不用找开发。

3. 功能二：长期记忆驱动的“任务健康度画像”，比告警更早发现问题

传统监控只告诉你“任务失败了”，Hermes Agent 的长期记忆则能回答：“为什么这次失败，而上次成功？”——它把每次任务执行视为一次“记忆快照”，自动关联上下文：前一次成功的输出值、当前系统负载、网络延迟波动、甚至 Git 提交哈希。我们给某电商公司的 OTB（Online To Broadcast）直播同步任务做的健康度画像，就是典型应用。

他们的 OTB 任务每 5 分钟拉取一次抖音直播间商品数据，写入 MySQL。过去用 XXL-JOB 时，告警规则只能设“连续 3 次失败才发钉钉”，但实际业务中，第 1 次失败往往已埋下隐患：比如抖音 API 返回rate_limit_exceeded，但错误码被前端 JS 框架吞掉，只留下空响应；或者 MySQL 主从延迟突增至 8 秒，导致写入超时。这些信号在单次失败日志里微不足道，但在长期记忆的时序分析中，就是明确的衰减曲线。

Hermes Agent 的记忆引擎做了三件事：

自动打标（Auto-tagging）：每次任务结束，解析 stdout/stderr，提取关键词（如rate_limit、timeout、connection refused），并关联系统指标（CPU >90%、内存使用率突增）；
相似性聚类（Similarity Clustering）：用 MinHash 算法计算日志文本相似度，把“抖音限流”相关失败归为一类，“MySQL 锁表”归为另一类；
根因推测（Root Cause Inference）：当某类失败在 1 小时内出现 ≥5 次，且伴随网络延迟 P95 >200ms，则自动标记为“网络层问题”，而非“应用层异常”。

具体到 OTB 任务，我们配置了一个记忆查询规则：

{ "query": "SELECT COUNT(*) FROM memory WHERE task_id = 'otb_sync' AND tag = 'rate_limit' AND timestamp > NOW() - INTERVAL 1 HOUR", "threshold": 3, "action": "trigger_webhook('https://xxx/api/alert', {\"level\": \"warning\", \"reason\": \"抖音API限流频发，建议切换备用Token\"})" }

这个规则不是写在配置文件里，而是通过 Web 控制台的“记忆洞察”模块可视化创建：拖拽时间范围、选择标签、设置阈值、绑定动作。上线后第三天，就捕获到抖音官方 SDK 升级导致的隐式限流（HTTP 200 但 body 为空），比业务方自己发现早了 17 小时。

更实用的是“记忆回溯调试”：当某个任务失败时，点击日志面板右上角的“🔍 回溯相似失败”，系统会列出最近 7 天所有匹配的日志，按相似度排序，并高亮差异字段。比如两次失败都报Connection refused，但回溯发现：第一次是10.0.1.5:3306，第二次是10.0.1.6:3306——立刻定位到是 MySQL 读写分离中间件路由异常，而非数据库本身故障。

实操心得：不要把长期记忆当成“日志归档”。它的价值在于建立任务执行的“数字孪生”：每次运行都是对系统状态的一次采样。我们建议至少开启 3 类自动打标：network_error（TCP 连接超时、SSL 握手失败）、resource_shortage（OOMKilled、磁盘满）、data_inconsistency（校验和不匹配、JSON 解析失败）。这些标签会在记忆查询中成为精准过滤器。

4. 功能三：多平台同步直播（OTB）的原子化编排，解决“状态漂移”顽疾

“多平台同步直播 OTB”是 Hermes Agent 最被低估的实战场景。很多团队用 FFmpeg + Nginx-RTMP 搭建推流网关，但遇到一个致命问题：抖音、视频号、快手三端开播状态不同步。比如抖音端已开播，视频号因微信审核延迟 2 分钟才上线，此时观众在抖音看到“正在直播”，在视频号看到“未开播”，体验割裂。传统方案要么强行等待（牺牲抖音时效性），要么各自推流（内容不一致）。

Hermes Agent 的解法是：把“开播”这个动作，从平台 API 调用，升维为跨平台的状态机（State Machine）。它不直接调用抖音live/start接口，而是定义一个抽象的otb:launch事件，由 Agent 统一调度三个平台 Client 执行，并确保它们满足“全部成功才视为开播成功”的原子性。

实现的关键在于 MCP 协议的transaction扩展：

{ "type": "INVOKE", "id": "tx-20240521-001", "method": "otb:launch", "params": { "title": "618大促预告", "cover_url": "https://cdn.xxx/cover.jpg" }, "transaction": { "mode": "all_or_nothing", "timeout": 30000, "rollback": [ {"client": "douyin", "method": "live:stop", "params": {"id": "{{douyin_id}}"}}, {"client": "wechat", "method": "live:stop", "params": {"id": "{{wechat_id}}"}}, {"client": "kuaishou", "method": "live:stop", "params": {"id": "{{kuaishou_id}}"}} ] } }

当 Agent 发送此消息，它会：

并发调用抖音、视频号、快手 Client 的live:start方法；
记录每个 Client 返回的live_id（如抖音返回douyin_abc123）；
若任一 Client 超时或返回错误，则立即触发rollback数组中的反向操作；
若全部成功，则向记忆库写入一条otb:launched事件，包含三个平台的live_id和启动时间戳。

我们给某 MCN 机构部署时，发现视频号 Client 常因微信审核超时（最长 5 分钟）导致事务失败。于是我们优化了 rollback 逻辑：不是简单调用live:stop，而是先检查视频号是否真的已开播（调用live:status），再决定是否停止。这避免了“审核未通过，却误发停播指令”的二次事故。

更进一步，利用长期记忆，我们实现了“智能降级”：

当检测到视频号审核队列积压 >10 个，自动将本次 OTB 任务降级为“抖音+快手双平台”；
当抖音 API 限流，自动切换备用 Token，并把旧 Token 标记为degraded，后续任务避开它；
所有降级决策都记录在记忆库，支持事后审计：“为什么今天只有两个平台开播？”

踩坑提醒：多平台同步最易忽略的是“时间窗口一致性”。抖音开播后 30 秒内必须推第一帧流，否则断开；视频号要求开播后 5 秒内完成推流握手。Hermes Agent 的事务超时（timeout: 30000）必须覆盖最慢平台的全链路耗时。我们实测发现，把超时设为 45 秒比 30 秒更稳——多出的 15 秒用于处理网络抖动，而不是盲目缩短。

5. 功能四：Gateway 模式下的零信任安全网关，替代 Nginx 反向代理

很多人以为 Hermes Agent 的 Gateway 只是“把 Web 控制台端口映射出来”，其实它是一个深度集成的零信任安全网关（Zero-Trust Gateway）。当你访问https://hermes.example.com，流量并非直通 Agent 的内置 HTTP 服务，而是经过 Gateway 的四层校验：TLS 终止、JWT 验证、MCP 消息签名、内存沙箱执行。这解决了企业最头疼的“定时任务越权调用”问题。

典型风险场景：某 RuoYi 系统的定时任务需要调用内部 Oracle 数据库，开发为图省事，在任务脚本里硬编码了 DBA 账号密码。一旦脚本被导出或泄露，整个数据库权限就拱手让人。Hermes Agent Gateway 的解法是：把数据库连接抽象为 MCP 服务，所有 SQL 执行必须经 Gateway 签名授权。

具体实现分三步：

服务注册：Oracle Client 启动时，向 Gateway 注册oracle:execute能力，并声明其最小权限集：

{ "service": "oracle:execute", "permissions": [ {"schema": "sales", "table": "orders", "actions": ["SELECT", "INSERT"]}, {"schema": "log", "table": "task_history", "actions": ["INSERT"]} ], "max_rows": 10000 }

策略配置：在 Gateway 控制台创建策略，规定哪些任务 ID 可以调用该服务，以及 SQL 模板白名单：

Task ID: sales_daily_report Allowed SQL Pattern: SELECT COUNT(*) FROM sales.orders WHERE create_time >= ?

安全执行：当任务触发时，Agent 不直接执行 SQL，而是向 Gateway 发送带签名的 MCP 消息：

{ "type": "INVOKE", "method": "oracle:execute", "params": {"sql": "SELECT COUNT(*) FROM sales.orders WHERE create_time >= '2024-05-20'"}, "signature": "sha256-hex(密钥+任务ID+SQL+时间戳)" }

Gateway 验证签名有效、SQL 匹配白名单、且调用者权限足够后，才转发给 Oracle Client。

我们帮一家银行做合规改造时，发现他们原有 XXL-JOB 任务中有 17 个脚本硬编码了sysdba密码。迁移到 Hermes Gateway 后，这些脚本被重写为标准 MCP 调用，DBA 在 Gateway 后台一键禁用某个任务的oracle:execute权限，5 秒内生效，无需重启任何服务。更重要的是，所有 SQL 执行都被记录在长期记忆库，包含完整 SQL 文本、执行耗时、返回行数——满足等保三级“操作留痕”要求。

关键配置技巧：Gateway 的 JWT 密钥不要用默认值！安装时务必执行hermes-agent gateway init --secret "your-32-byte-secret"。我们见过客户因用默认密钥，导致攻击者伪造 JWT 绕过认证，直接调用shell:exec执行rm -rf /。另外，max_rows限制必须设，防止恶意 SQL 拖垮数据库。

6. 功能五：桌面版的“剪贴板智能体”，让定时任务活在工作流里

Hermes Agent 桌面版（Desktop Edition）常被当作“Web 控制台的离线版”，但它真正的杀手锏是深度操作系统集成：监听剪贴板、捕获窗口焦点、读取邮件客户端收件箱、甚至调用 macOS 的 Shortcuts 自动化。这使得“定时任务”不再局限于服务器后台，而是嵌入到你的日常办公流中。

举个真实案例：某设计团队每天要从蓝湖（Lanhu）导出 20+ 个 Figma 文件的 PNG 预览图，上传到飞书知识库。原来流程是：设计师手动点蓝湖“导出”按钮 → 等待下载完成 → 打开飞书 → 拖拽上传 → 输入标题。平均耗时 8 分钟/人/天。

用 Hermes Agent 桌面版重构后：

创建一个“蓝湖导出监听”任务，启用clipboard:watch能力，正则匹配https://lanhu\.app/.*?/spec/.*?/image/.*?\.png；
当设计师复制蓝湖图片链接时，Agent 自动触发：
1. 下载 PNG 到本地~/Downloads/lanhu_exports/；
2. 用figma:mcpClient 调用 Figma API 获取对应页面标题；
3. 调用feishu:uploadClient 上传文件，并自动填充标题；
4. 将上传成功链接复制回剪贴板。整个过程在 3 秒内完成，设计师只需复制链接，剩下的全自动。

桌面版的核心能力矩阵：

能力类别	Windows 实现	macOS 实现	Linux 实现	典型用途
剪贴板监听	`user32.dll`Hook	`NSPasteboard`API	`xclip`+ inotify	捕获链接、代码片段、错误信息
窗口焦点跟踪	`GetForegroundWindow`	`NSWorkspace.activeApplication()`	`xdotool getwindowfocus`	当切换到 Chrome 时自动执行网页检查
邮件收件箱	Outlook REST API	MailKit + IMAP	OfflineIMAP	监听客户投诉邮件，自动创建工单
系统通知	Windows Toast	`osascript -e 'display notification'`	`notify-send`	任务完成时弹窗提醒，非静默推送

特别注意 macOS 版的权限陷阱：首次运行时，系统会弹出“Hermes Agent 想控制此电脑”，必须勾选“辅助功能”和“全盘访问”，否则无法监听剪贴板。这是 Apple 的隐私保护机制，不是 Bug。

实用技巧：桌面版最适合做“触发器（Trigger）”，而非“执行器（Executor）”。比如用clipboard:watch捕获 Jira Issue ID（PROJ-123），然后调用jira:mcpClient 查询详情，再触发服务器端的hermes-agent server执行复杂测试。这样既保证敏感操作在服务端执行，又让触发入口贴近用户工作流。

7. 功能六：Spring Cloud 架构下的分布式定时任务协同，终结“脑裂”调度

在 Spring Cloud 微服务架构中，分布式定时任务最大的痛点不是“怎么跑”，而是“谁来跑”。当多个服务实例都部署了@Scheduled，就会出现“脑裂”：同一任务在 3 台机器上同时执行，导致数据重复写入、库存超卖。XXL-JOB 用“执行器注册+路由策略”缓解，但仍有缺陷：路由策略是静态的（如第一个注册的节点），无法感知节点健康状态。

Hermes Agent 的解法是：把任务调度权从应用层上收至基础设施层，用 MCP 协议实现动态领导者选举（Leader Election）。它不假设哪个节点是 Leader，而是让所有 Agent 实例通过 MCP Server 的HEARTBEAT消息实时竞争。

技术细节如下：

每个 Agent 启动时，向 MCP Server（通常是集群模式的 Redis 或 Etcd）注册心跳，携带唯一instance_id和weight（权重，可设为 CPU 核心数）；
当创建新任务时，Agent 向 Server 发送SCHEDULE请求，Server 根据weight和当前负载（CPU、内存、网络延迟）选出最优节点；
选出的 Leader 节点执行任务，并在执行前向 Server 发送LOCK消息，锁定任务 ID；
若 Leader 失联（心跳超时），Server 自动将锁转移给下一个权重最高的节点，并触发RECOVER事件。

我们给某保险公司的理赔系统做迁移时，原架构有 8 个 Spring Boot 实例，每个都跑着@Scheduled(fixedDelay = 30000)的核保任务。切换到 Hermes 后：

所有实例卸载@Scheduled注解，改为监听 MCPclaim:process消息；
Hermes Agent 集群（3 节点）统一调度，根据实时负载，通常只有 1-2 个实例在执行；
当某台机器 CPU >95%，Server 自动将其weight降为 0，任务全部切到其他节点；
整个过程对业务无感，API 响应时间 P95 从 1200ms 降至 450ms。

关键配置项（hermes-agent.yml）：

scheduler: mode: cluster leader_election: backend: redis redis_url: redis://10.0.1.10:6379/2 lock_timeout: 30000 load_balancer: strategy: weighted_round_robin weights: - instance: "prod-app-01" cpu_cores: 8 memory_gb: 16 - instance: "prod-app-02" cpu_cores: 16 memory_gb: 32

注意事项：不要在同一个物理机上运行多个 Hermes Agent 实例！这会导致资源争抢。正确做法是：每台机器只运行一个 Agent，让它管理本机所有应用进程。我们曾见客户在 Docker Swarm 中为每个服务部署一个 Agent，结果因网络延迟导致 Leader 频繁切换，任务执行乱序。

8. 功能七：Playwright MCP Client 的“视觉回归测试”，超越传统断言

Playwright 是 Hermes Agent 最常用的 MCP Client，但多数人只用它做“点击-输入-断言”式的功能测试。Hermes 的 Playwright Client 真正强大之处，在于把浏览器渲染结果转化为可计算的视觉特征（Visual Features），实现像素级回归测试。

传统断言（如expect(page).toHaveTitle('首页')）只能验证文字，但无法发现：

新 CSS 样式导致按钮位置偏移 2px；
字体加载失败，文字渲染为方块；
图片 CDN 故障，显示占位符而非真实图。

Hermes Playwright Client 内置了visual:diff能力，原理是：

首次运行时，截取页面全屏（page.screenshot({fullPage: true})），用 OpenCV 计算图像指纹（Perceptual Hash）；
后续运行时，同样截图并计算指纹，与基线对比汉明距离（Hamming Distance）；
若距离 > 阈值（默认 15），则标记为“视觉差异”，并生成差异图（Highlight Diff Image）。

配置一个视觉回归任务：

{ "task_id": "home_page_vr", "schedule": "0 0 * * *", "executor": "playwright:visual-diff", "params": { "url": "https://example.com/", "baseline": "https://cdn.example.com/baselines/home_v1.png", "threshold": 12, "ignore_regions": ["#ad-banner", ".cookie-banner"] } }

其中ignore_regions是 CSS 选择器，用于排除广告、弹窗等动态区域，避免误报。

我们给某电商平台做大促前测试时，用此功能发现了两个严重问题：

首页轮播图组件在 Safari 17 下，因transform: scale(1.01)导致渲染模糊，视觉指纹差异达 28；
商品列表页的“加入购物车”按钮，在 iOS 16.4 下因touch-action: manipulation缺失，导致点击区域缩小，差异图清晰显示按钮边缘像素缺失。

实操要点：视觉回归必须配合“环境标准化”。我们在 Docker 中运行 Playwright Client，固定 Chromium 版本（mcr.microsoft.com/playwright:v1.42.0-chromium），并禁用字体抗锯齿（--disable-font-antialiasing），确保截图一致性。另外，基线图必须存放在 CDN，不能本地文件，否则每次构建都会生成新指纹。

9. 功能八：MCP 协议的“语义路由”，让任务自动找到最合适的执行器

MCP（Model Control Protocol）常被误解为“另一个 RPC 协议”，但它真正的创新是语义路由（Semantic Routing）：不是按方法名（user:create）硬编码路由，而是根据消息内容的语义特征，动态匹配最合适的执行器。这解决了“一个任务多种实现”的混乱问题。

典型场景：某公司有两套 OCR 服务——阿里云 OCR（高精度、慢）、Tesseract（本地、快）。传统方案是写 if-else 判断：

if (imageSize < 100KB) { useTesseract(); } else { useAliyunOCR(); }

但业务需求变化快，判断逻辑越来越复杂：还要考虑图片类型（证件照/截图/扫描件）、是否含表格、是否需返回坐标……代码迅速腐化。

Hermes Agent 的语义路由解法：

两个 OCR Client 向 Gateway 注册时，声明自己的能力标签：

// 阿里云 OCR Client { "service": "ocr:recognize", "tags": ["accuracy:high", "latency:slow", "type:id_card", "type:invoice"] } // Tesseract Client { "service": "ocr:recognize", "tags": ["accuracy:medium", "latency:fast", "type:screenshot", "language:zh"] }

任务发送 MCP 消息时，带上请求上下文标签：

{ "type": "INVOKE", "method": "ocr:recognize", "params": {"image_url": "https://cdn.xxx/idcard.jpg"}, "context": { "tags": ["type:id_card", "priority:high"], "constraints": ["latency < 5000ms"] } }

Gateway 根据context.tags和constraints，用加权匹配算法计算得分：

阿里云 OCR：匹配type:id_card（+10分），满足priority:high（+5分），但latency:slow违反约束（-20分）→ 总分 -5；
Tesseract：不匹配type:id_card（0分），但latency:fast满足约束（+15分）→ 总分 +15。

最终路由到 Tesseract，因为它更符合“低延迟”硬约束。

我们给政务系统做 OCR 选型时，还加入了“成本”维度：阿里云 OCR 按次计费，Tesseract 免费。Gateway 的路由策略可配置为cost_aware:true，当 Tesseract 得分 > 阿里云 80% 时，优先选免费方案。

关键经验：语义标签要遵循“名词+冒号+值”规范（如type:invoice），避免isInvoice:true这种布尔值，因为布尔值无法参与加权计算。另外，constraints必须是可量化的（latency < 5000ms），不能是模糊描述（fast）。

10. 功能九：Linux 定时任务的“无缝接管”，不改一行 crontab

很多遗留系统重度依赖crontab，贸然迁移到新调度平台风险极高。Hermes Agent 提供了业界唯一的“crontab 无缝接管”模式：它不替换 crontab，而是作为 crontab 的增强层，让所有现有定时任务自动获得长期记忆、MCP 调用、多平台协同等能力。

原理是：Hermes Agent 启动一个crontab:watcher进程，它定期（默认 10 秒）执行crontab -l -u $USER，解析 crontab 内容，提取* * * * * /path/to/script.sh这样的行，然后：

为每个脚本生成一个虚拟任务 ID（如crontab-user1-001）；
监听该脚本的 stdout/stderr，自动捕获输出并写入长期记忆；
当脚本执行时，注入环境变量HERMES_TASK_ID=crontab-user1-001，供脚本内调用hermes-mcp-client。

例如，你有一个老 crontab：

# m h dom mon dow command 0 2 * * * /opt/scripts/backup_mysql.sh

只需在backup_mysql.sh开头添加：

#!/bin/bash # 注入 Hermes 环境 export HERMES_TASK_ID="mysql_backup" # 调用 MCP Client 记录开始 hermes-mcp invoke "log:info" --params '{"message":"MySQL backup started"}' # ... 原有备份逻辑 ... # 调用 MCP Client 记录结束 hermes-mcp invoke "log:info" --params '{"message":"MySQL backup finished", "size_mb": '"$(du -sm /backup/mysql | cut -f1)"'}'

Hermes Agent 会自动识别这个任务，把它纳入 Web 控制台管理，支持：