Last updated on
Hermes AgentAI Agent优化自动化量化cron

Hermes Agent 优化迭代实录：一个AI Agent的持续进化之路

前言：当AI Agent成为你的量化队友

做量化交易的人都知道——80%的时间花在”不是交易”的事情上。

每天早上打开电脑，先跑一遍数据下载脚本；收盘后导出今日行情，跑一遍信号计算；周末整理持仓分析，看周报。这些事情本身不难，但它们反反复复吃掉你的精力，让你没有时间去思考真策略、真逻辑。

我一直在想，能不能找个”人”来帮我干这些活？

2026年5月，我遇到了 Hermes Agent——一个开源的AI Agent框架，由Nous Research开发。跟当时市面上的其他Agent框架相比，Hermes有一个让我眼前一亮的特点：它天然支持cron调度。这意味着Agent可以像Linux的定时任务一样，到点自动执行，不需要手动触发。

“就是它了。”

从那天起，我开始了长达数十天的Hermes Agent深度使用与迭代之旅。这篇文章就是这段旅程的完整记录——没有理论，全是实战。

第一阶段：基础搭建

WSL环境下的Hermes安装

我日常工作在Windows上，但量化工具链（DuckDB、pytdx、akshare这些）对Linux更友好。所以选择了WSL（Windows Subsystem for Linux）作为运行环境。

安装过程其实相当顺利。Hermes的文档很清晰，基本上就是：

git clone https://github.com/NousResearch/hermes-agent.git
cd hermes-agent
pip install -e .

两行命令就能跑起来。但真正开始用的时候，才意识到配置才是最花时间的部分。

网关配置：飞书 + 微信双平台接入

Hermes支持”网关”（Gateway）的概念，就是你可以在多个IM平台上跟Agent对话，它会把消息统一路由到背后的LLM处理。

我配了两个网关：

飞书（Feishu/Lark） 是主力平台。飞书的开放平台支持度很高——机器人API、消息卡片、富文本、图片、文件——几乎你想要的功能都有。配置过程需要：

  1. 在飞书开放平台创建应用
  2. 配置事件回调（Event Callback）和消息卡片
  3. 获取App ID和App Secret
  4. 在Hermes的gateway配置中填好对应参数

微信 作为备选。一开始想用企业微信做推送，但后来发现个人微信的限制太多——主动推送消息非常困难。最终选用了iLink Bot作为微信接入方案，但它有一个致命问题（后面会详说）。

模型提供商配置

Hermes支持多种LLM后端。我配置了三家：

  • GLM（智谱）：主力模型，处理日常对话和技能调用
  • DeepSeek：备用模型，写代码和做数据分析时表现很好
  • OpenAI兼容接口：用于测试和对比

配置方式是在Hermes的profile配置中指定provider和model name。我一开始主力用的是 GLM-5.2（智谱的第五代旗舰模型），后来因为限流问题不得不降级——这是后话了。

# provider配置示例（简化）
providers:
  - name: glm
    api_key: ${GLM_API_KEY}
    base_url: https://open.bigmodel.cn/api/paas/v4
  - name: deepseek
    api_key: ${DEEPSEEK_API_KEY}
    base_url: https://api.deepseek.com

第二阶段：技能系统

从0到20+技能的建设过程

Hermes最核心的概念是”技能”（Skills）。技能就是Agent可以调用的工具——Python脚本、命令行、API调用、数据分析函数——你把它包装成一个技能，Agent就能在对话中自动调用它。

最开始，我只写了3个技能：

  • 数据下载：每日从pytdx拉取行情数据
  • 信号计算：跑一下策略信号
  • 日报生成：产出每日市场概览

然后就发现：Agent的真正威力在于，你每加一个技能，它的能力边界就扩大一圈。

一个月下来，我写出了20多个技能。这二十几个技能大概分成这几类：

技能分类

量化策略类（核心）

  • 可转债低溢价轮动策略分析
  • 双低策略打分排序
  • ETF轮动信号计算
  • 布林带均值回归信号
  • Barra因子选股
  • 全市场估值监控

数据工程类

  • pytdx数据同步（日线 / 分钟线）
  • akshare实时行情获取
  • DuckDB查询接口（支持任意SQL）
  • 数据完整性校验
  • 增量更新与去重

AI工具类

  • 调用LLM生成分析报告
  • 舆情情绪分析（新闻情感打分）
  • 研报关键信息提取

DevOps类

  • 磁盘空间检查
  • 定时任务状态监控
  • 日志分析与告警
  • 文件清理

技能的持续迭代

每个技能都经历了 创建 → 使用 → 发现问题 → patch修复 的循环。

比如”数据下载”这个看似简单的技能，迭代了至少5次：

  1. 初版：直接调用pytdx，全量拉取所有股票
  2. 问题：太慢了，4500只股票要跑十几分钟
  3. 修复：改为增量模式，只拉取上次同步后新增的数据
  4. 新问题：偶尔有几只股票同步失败，没报错
  5. 修复：增加逐只股票的状态检查和重试机制
  6. 再迭代：加入进度条和预计完成时间

每次迭代，我都在技能的文档字符串（docstring）里更新使用说明和注意事项，这样Agent调用时能看到最新信息。

后来我养成了一个习惯：每次技能出问题，立刻修，不拖延。因为一个有bug的技能不仅耽误事，还可能污染Agent的判断——它会以为这个技能”不可靠”，转而用更复杂的方式解决问题。

第三阶段：cron调度系统

这是整个过程里最让我兴奋的部分。

Hermes Agent的cron机制，本质上是把技能跟定时触发器绑定。你可以写一个cron表达式，告诉Agent “每天早上6点执行这个任务”，然后就不用管了。

我最终搭建了这么一套调度系统：

每日06:00 — 早间检查

早上6点，Agent自动醒来，执行一系列检查：

  1. 磁盘空间是否充足（低于10%报警）
  2. 昨日数据同步是否正常完成
  3. 检查是否有技能执行失败需要重试
  4. 如果一切正常，推送一条”早安”消息到飞书，附上今日待办

这个模块很薄，但作用巨大——它取代了我每天早上第一件事”检查系统状态”的习惯。现在起床后看一眼飞书消息，就能知道一切是否正常。

每日18:00 — 数据同步

收盘后，Agent自动执行：

  1. 调用pytdx拉取当日最新行情
  2. 数据清洗和去重
  3. 写入DuckDB数据库
  4. 更新缓存数据

这大概需要5-15分钟，取决于当日数据量。Agent会在完成后推送一条简短的同步报告。

每周一 09:30 — 全市场估值周报

周一开盘前，Agent生成一份完整的周度报告：

  • 各大指数估值（PE、PB、百分位）
  • 行业轮动分析
  • 风格因子表现
  • 宏观数据更新

这份报告通过飞书消息卡片发送，包括文本摘要和图片附件。为了这个功能，我专门写了媒体文件上传的逻辑——因为飞书的消息卡片支持插入图片（通过 image_key），需要先上传图片文件到飞书服务器。

每周六 10:00 — 可转债推荐

周六上午，Agent跑一遍可转债策略：

  1. 拉取全市场可转债数据
  2. 用低溢价 + 双低策略打分排序
  3. 筛选出Top 10推荐
  4. 生成分析报告推送

这是我最满意的技能之一。以前我手动做这件事需要跑脚本、看数据、写笔记，前后至少半小时。现在Agent十分钟搞定，而且它还会在报告里附上每个转债的基本面概要说明。

每周日 20:00 — 记忆 + Wiki 更新

周末晚上，Agent做一次”自我维护”：

  1. 记忆优化：清理不重要的短期记忆，整理长期记忆
  2. Wiki更新：把本周踩坑的经验教训结构化存入Wiki
  3. 系统复盘：检查这周的cron执行记录，看有没有异常

这部分实际上是在维护Agent本身的知识库。一开始我没重视，后来发现如果不做定期整理，Agent的记忆会越来越”胖”，关键信息淹没在废话里。

自我进化系统

除了固定的cron任务，我还设置了一套”自我进化”机制：

  • 每日19:00：Agent搜索行业最新的量化研究和技术博客
  • 整理成摘要存入自己的Wiki
  • 如果发现有用的新技能或新工具，会自己评估是否值得接入

听起来很科幻对吧？实际上实现起来没那么复杂——就是一个搜索 + 摘要 + 存入Wiki的技能链。但它确实产生了实际价值：有一天Agent自己发现了一篇关于 “DuckDB全内存查询优化” 的文章，然后主动建议我把某些慢查询改成内存模式。

第四阶段：记忆与知识管理

记忆系统的容量管理

Hermes Agent有记忆系统（Memory），它会记住你和它的对话历史。但有一个现实约束：每个记忆条目最大约2200字符。

这意味着你不能把一大段对话塞进去，必须精炼。我摸索出的套路是：

  • 好的记忆：一句话说清楚事实，比如 “用户偏好使用双低策略做可转债筛选，阈值是价格<130且溢价率<30%”
  • 坏的记忆：冗长的对话片段，包含大量上下文和无关细节

我还写了一个”记忆压缩”技能，定期把多条相似记忆合并成一条精炼的。

经验教训的沉淀

Agent会踩坑，也会学会不踩同一个坑。

比如有一次，Agent在执行数据下载时没检查网络连接，导致脚本超时挂了。我在记忆里写了一条：

“执行数据下载前，先用 ping 检查pytdx服务器是否可达。如果不可达，等待60秒后重试，最多3次。”

之后Agent再执行数据下载，就会自动检查网络。这个”教训”一次都没再犯过。

Wiki 与第二大脑的联动

Hermes Agent的Wiki机制类似于一个结构化的知识库。我把Wiki分成了几个板块：

  • 量化配置：数据源配置、API密钥使用规范
  • 策略文档：每个策略的详细说明、参数、注意事项
  • 运维手册：cron任务说明、故障处理流程
  • 学习笔记：Agent从外部搜索中整理的新知识

Wiki的存在极大地缓解了记忆容量问题——记忆存”索引”，Wiki存”正文”。Agent先查记忆找到线索，再去Wiki获取详细信息。

踩坑与优化（重点）

这部分是全文最有价值的章节。每一个坑都是用时间换来的教训。

1. 模型限流：从GLM-5.2到deepseek-v4-flash的三级降级

这是最大的坑，没有之一。

第一周：我用 GLM-5.2 做主力模型，效果很好。回复质量高，技能调用准确。

第二周：cron任务跑起来之后，问题来了。每天18:00的数据同步需要反复调用Agent执行多个子任务，再加上飞书网关的实时对话消耗，API调用量暴增。智谱的API开始返回 429 Too Many Requests。

第一次降级：从 GLM-5.2 降到 GLM-5.1。限流问题缓解了一些，但每天高峰期还是会触发。GLM-5.1的回复质量略有下降，但技能调用准确率还能接受。

第二次降级：GLM-5.1 仍然扛不住cron密集调用的压力。我开始研究Hermes的模型降级机制——在配置里设置fallback provider，当主模型触发限流时自动切换到备用模型。

最终方案：GLM-5.2 → GLM-5.1 → deepseek-v4-flash 三级降级链。主模型GLM-5.2，触发限流降级到GLM-5.1，再限流就降到deepseek-v4-flash。DeepSeek的v4-flash模型虽然不如GLM-5.2智能，但胜在速度快、限流宽松，做数据同步和脚本调用足够用了。

这个三级降级方案稳定运行至今，再也没因为限流而中断过cron任务。

2. WSL的WARP代理导致的DNS问题

非常隐蔽的一个问题。

WSL的网络模式默认跟Windows共享网络栈。我的Windows上开着WARP（Cloudflare的VPN），它会接管DNS请求。

有一天，Agent突然无法访问任何外部API——飞书网关连不上，pytdx也连不上。排查了很久，发现是WSL的 /etc/resolv.conf 被WARP改成了 127.0.0.53 的本地DNS代理，而这个代理在WSL里工作不正常。

解决方案：在WSL里显式配置DNS：

echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf

然后锁住 /etc/resolv.conf 防止被覆盖：

sudo chattr +i /etc/resolv.conf

之后DNS问题再没出现过。

3. 飞书API token刷新机制

飞书的机器人API使用 tenant_access_token 进行鉴权，这个token的有效期是2小时。你需要定期刷新。

Hermes的gateway机制有自动token刷新，但有一个触发条件：只有在收到飞书消息的时候才会检查并刷新token。这意味着如果Agent在cron任务中主动向飞书推送消息，而token又恰好过期了，推送就会失败。

修复：在推送消息前增加一次显式token刷新检查，不管有没有消息事件，都主动调一次token刷新API。

我一开始想用微信做Agent的告警推送渠道，选用了iLink Bot方案。配置完成后发现一个问题：iLink Bot只能被动回复消息，不能主动向用户推送。

这就尴尬了。cron任务执行完毕后，Agent需要主动推送报告，但微信这条路走不通。

解决方案：放弃微信作为主动推送渠道，只保留飞书。微信作为”备选对话入口”保留——如果飞书挂了，还能从微信手动触发技能。主动推送全部走飞书。

5. cron no_agent脚本路径问题

Hermes在执行cron任务时，有一个 no_agent 模式：就是不经过LLM，直接执行一个预定义的脚本。这在某些场景下很高效——比如数据同步没必要让LLM参与，直接跑脚本就行。

但问题来了：no_agent 脚本的工作路径和标准技能的环境不一样。我的脚本开头有用相对路径引用的数据文件，用 no_agent 模式跑起来就找不到文件。

修复：把所有脚本里的相对路径改成绝对路径，或者在脚本开头强制 cd 到项目目录。

import os
os.chdir(os.path.dirname(os.path.abspath(__file__)))

这个很小的改动，节省了我不知道多少调试时间。

6. 文件变更冲突

当cron任务和手动对话同时在跑的时候，偶尔会出现两个进程同时修改同一个文件的情况。

最典型的场景是：Agent在cron里写DuckDB数据库，同时我通过飞书给Agent发了一条消息，它也触发了数据查询——两个进程同时读写DuckDB文件，导致写入冲突。

解决方案：

  1. DuckDB层面：所有写入操作改为”写入临时文件 + 原子重命名”的模式
  2. 调度层面：调整cron任务的执行时间，尽量避开我使用的高峰时段
  3. 互斥锁：为关键资源（DuckDB、配置文件）增加文件锁

7. 磁盘空间监控

这个教训来得比较”肉疼”。

WSL的虚拟硬盘（ext4.vhdx）默认是动态增长，但不会自动收缩。我每天下载行情数据、生成报告、保存日志，磁盘占用稳步上升。有一天发现WSL虚拟硬盘膨胀到了硬盘快要放不下的程度。

解决方案：

  1. 写了一个磁盘监控技能，每天检查 / 的使用率
  2. 设置告警阈值：使用率超过80%推送提醒
  3. 写日志清理脚本：删除7天前的日志
  4. 定期执行 WSL 磁盘压缩
# WSL磁盘压缩（需要在Windows的PowerShell中执行）
wsl --shutdown
# 然后在Windows上执行DiskPart或者使用Optimize-VHD

效果评估

到现在，这套系统已经稳定运行了相当长一段时间。来算一笔时间账：

每天自动化覆盖的工作量

任务原来耗时现在耗时节省
每日行情下载 + 清洗15分钟0（自动）15分钟
收盘后数据同步10分钟0（自动）10分钟
策略信号计算10分钟0（自动）10分钟
每日市场简报20分钟0（自动）20分钟
每周估值周报45分钟0（自动）45分钟
每周可转债推荐30分钟0（自动）30分钟
数据校验 + 查错不定时自动告警大量精力

每天保守估计节省 55分钟，每周 6小时+。而这些时间都用来做真正有价值的事：研究新策略、优化参数、测试新想法。

系统架构（文字描述）

整个系统可以抽象为四层架构：

┌─────────────────────────────────────────┐
│           交互层（飞书 / 微信）            │
│  消息卡片 · 文本对话 · 图片 · 文件         │
└────────────────┬────────────────────────┘
                 │
┌────────────────▼────────────────────────┐
│           网关层（Hermes Gateway）        │
│  消息路由 · token刷新 · 多平台适配        │
└────────────────┬────────────────────────┘
                 │
┌────────────────▼────────────────────────┐
│           Agent层（Hermes Core）          │
│  技能调度 · LLM推理 · 记忆管理 · Wiki     │
│  cron调度 · 模型降级 · 上下文管理          │
└────────────────┬────────────────────────┘
                 │
┌────────────────▼────────────────────────┐
│            执行层（技能 & 脚本）           │
│  DuckDB · pytdx · Python · Shell        │
│  数据同步 · 策略计算 · 报告生成            │
└─────────────────────────────────────────┘

Agent层是最核心的部分——它负责理解意图、拆解任务、调度技能、管理上下文。cron调度器跑在Agent层之上，定时触发任务链。

总结与心法

经过这段时间的持续迭代，我总结了几条心法：

  1. 先跑起来，再优化。不要试图一次性搭好完整系统。先搞一个最简单的cron任务，跑通，再慢慢加。

  2. 每个技能都要有”自我修复”能力。Agent不是人，它不会”感觉不对”。你必须把异常处理写进技能里——重试、降级、告警，一个都不能少。

  3. 记忆要精简。一条好的记忆就是一句话。长篇大论的记忆只会让Agent更困惑。

  4. 日志就是一切。cron跑在后台，你看不到它的执行过程。没有好的日志，出了问题只能盲猜。每个技能至少输出 [INFO]、[ERROR]、[WARN] 三档日志。

  5. 接受不完美。Agent偶尔会犯错——选错参数、调用错技能、推理逻辑出错。追求100%正确率会让你陷入无穷无尽的优化。我的经验是：AI不是取代你，而是放大你。90%的正确率，乘以每天的自动执行次数，带来的收益远大于手动做100%。

未来规划

系统的开发永远不会停。接下来的方向：

  1. 可视化仪表盘：在飞书上做一个行情看板，不用打开终端就能看到实时数据
  2. 更为智能的错误恢复：当技能执行失败时，Agent能自己分析错误日志并尝试修复
  3. 多Agent协作：不同Agent负责不同版块（策略A、策略B、数据运维），它们之间可以互相通信
  4. 实时行情接入：从pytdx的实时接口或WebSocket获取盘中数据，实现盘中信号推送
  5. 自动策略回测：当Agent发现一个新想法时，自动拉取历史数据做回测并给出报告

如果你也在用Hermes Agent做量化自动化，或者在搭建自己的AI Agent系统，欢迎交流。这条路还在继续，每一次迭代都让系统变得更强一点点。

而最强的那个版本——永远是下一个。

📚 相关文章推荐

💬 评论