Hermes Agent 学习笔记 08：用 Cron 定时任务让 Agent 从被动回复走向主动执行，TaoToken 统一 Key 配置实战

1. 为什么 Agent 需要 Cron从「你问我答」到「到点自己干」Hermes Agent 的 CLI 用久了会发现一个尴尬它很聪明但很被动。你敲一句它动一下你不敲它就安静地待着。前面几期把 CLI/TUI、Tools、Memory、Skills、Messaging Gateway 都过了一遍能力是攒齐了可这些能力有个共同前提——得有人先开口。现实里的活儿不全是临时冒出来的。每天早上想看一眼 AI Agent 圈的新动态、每周五要汇总项目进展、每小时想确认服务器还活着、每晚想备份某个目录、定期扫日志找异常——这些是周期性发生的靠人肉记着去敲命令迟早会漏。Cron 定时任务解决的就是这件事配置一次让时间而不是你来触发 Agent。普通对话是「用户触发 Agent」Cron 是「时间触发 Agent」。这一步跨过去Hermes 才从「响应式助手」变成「长期自动化助手」。这篇笔记就聚焦 Hermes Agent CLI 场景下 Cron 的落地给你一份可复制的config.toml骨架、TaoToken 统一 Key 的接入步骤再附一条定时任务从注册到触发的完整验证动作让你今天就能把主动执行链路跑通。2. TaoToken 前置一个 Key 管住所有模型调用Cron 任务跑起来之后最容易被忽略的成本是「无人值守时的模型调用」。任务在后台自己触发、自己调模型如果 Key 分散在好几个地方出问题你都不知道是哪次调用烧的。所以先把模型入口统一掉再谈定时。TaoToken 在这里的角色是统一模型接入层一个 Key、一个兼容 OpenAI 风格的接口把对话、编码等不同模型的调用收敛到一处。对 Cron 场景来说好处很直接——定时任务里所有 Agent 会话都走同一个入口配额、日志、切换模型都在一个地方看不用在多个 Key 之间来回倒腾。你需要提前准备两样东西一个 TaoToken API Key在控制台的 API Keys 页面创建确认要用的模型名比如对话类或编码类按你 Cron 任务的实际需求选。官网入口在这里https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后在控制台生成 Key。API 基址是https://taotoken.net/api这个地址不加 UTM 参数直接填进配置即可。提醒一句Key 只存在本地配置文件或环境变量里别写进会提交到 Git 的脚本。Cron 任务经常和项目目录绑在一起一不小心就跟着仓库上传了。3. 可复制配置config.toml 骨架 环境变量Hermes Agent 的模型接入写在config.toml里。下面这份骨架可以直接抄把api_key换成你自己的model换成你要用的模型名# ~/.hermes/config.toml [provider] name taotoken base_url https://taotoken.net/api api_key sk-你的TaoToken密钥 model 你的模型名 [agent] # Cron 任务在新会话中运行这里控制单次任务的超时秒 timeout 300 # 单次任务允许的最大工具调用轮数防止无人值守时无限循环 max_tool_rounds 20 [cron] # 调度器检查周期Gateway 每隔多久 tick 一次 tick_interval 60s # 任务输出目录 output_dir ~/.hermes/cron/output # 任务定义文件 jobs_file ~/.hermes/cron/jobs.json更稳妥的做法是把 Key 放进环境变量配置文件里只引用变量名这样配置文件本身可以安全地放进版本管理# ~/.bashrc 或 ~/.zshrc export TAOTOKEN_API_KEYsk-你的TaoToken密钥[provider] name taotoken base_url https://taotoken.net/api api_key ${TAOTOKEN_API_KEY} model 你的模型名改完配置后验证一下能不能正常调通再往下做 Cronhermes config check hermes chat 用一句话确认模型接入正常如果第二条命令能正常返回内容说明 TaoToken 这一层通了。这一步别跳过——Cron 出问题时先排除模型接入能省掉一大半排查时间。4. 注册第一条定时任务并验证触发配置通了来跑一条最小可用的定时任务。目标定得简单点每 2 分钟检查一次磁盘占用超过阈值才提醒正常就保持安静。用短周期是为了让你几分钟内就能看到结果验证完再改成真实周期。4.1 用 CLI 注册任务hermes cron create every 2m \ 检查当前机器的磁盘占用情况。如果根分区使用率超过 80%用中文输出分区名、使用率、占用最大的三个目录并给出清理建议。如果没有超过 80%只回复 [SILENT]。 \ --name disk-watch \ --deliver local几个参数说明一下every 2m是间隔时间表达表示每 2 分钟执行一次--name给任务起个名字方便管理--deliver local表示结果只存本地文件不往消息平台推。第一次验证用local最省事不用先配 Telegram 或 Slack。4.2 确认任务已注册hermes cron list输出里应该能看到disk-watch状态是active并且有一个next_run_at时间。如果状态是paused或没看到任务说明注册没成功回头检查命令有没有拼错。4.3 确认 Gateway 在跑这是最容易踩的坑Cron 不会自己触发得靠 Gateway 后台调度。Gateway 每隔一个 tick 检查有没有到期任务有就开一个新会话执行。Gateway 没运行任务就只是写在文件里的计划。hermes gateway status如果显示没运行前台起一个先验证hermes gateway想让它长期在后台跑用hermes gateway start装成服务。4.4 手动触发一次先验证任务本身能跑不想等 2 分钟可以直接手动跑hermes cron run disk-watch或者手动 tick 一次调度器hermes cron tick手动触发能跑通说明 prompt 和模型接入都没问题剩下的就交给时间。4.5 看结果等一个周期后去输出目录看ls -lt ~/.hermes/cron/output/ cat ~/.hermes/cron/output/disk-watch-*.log如果磁盘没超阈值日志里应该只有[SILENT]不会产生打扰。想验证「有异常才提醒」的逻辑可以临时把 prompt 里的阈值改成1%这样必然触发能看到完整的报告输出验证完再改回80%。5. 本篇常见坑任务不触发、重复跑、结果收不到跑通过程中大概率会撞上这几个问题按顺序排查基本都能定位。任务到点没动静。九成是 Gateway 没运行。先hermes gateway status没跑就起起来。其次是时间规则写错——30m是一次性任务跑完就结束不会重复想要周期得写every 30m。这两个特别容易混。同一个任务被触发两次。通常是多个 tick 撞在一起。Hermes 内部有锁机制防止重复执行但如果你手动hermes cron tick的同时 Gateway 也在 tick就可能出现重叠。调试时手动 tick最好先把 Gateway 停掉。任务跑了但收不到结果。检查--deliver目标。用local就去输出目录找文件用telegram之类就要确认对应平台的 token、权限、home channel 都配好了。投递是调度器负责的不是任务自己发消息所以投递配置错了任务执行成功你也看不到。绑定的 skill 没生效。先hermes skills list确认 skill 装了再确认名字大小写和目录名完全一致。Cron 任务在新会话里跑skill 必须在执行前能加载到。prompt 太模糊导致结果飘。Cron 任务看不到你之前的聊天上下文prompt 必须自包含。别写「做我的常规简报」要写清楚搜什么、时间范围、筛几条、输出格式、发到哪、没异常怎么办。任务越重要prompt 越不能省。无人值守时工具调用失控。在config.toml里设max_tool_rounds和timeout给任务一个硬边界。涉及删文件、改代码、提交 Git、调付费接口这类动作别一上来就全自动先只读、先生成报告、先要人工确认跑稳了再逐步放开。6. 把主动执行链路接进你的日常到这一步你已经有一条能跑的链路了TaoToken 统一模型入口 →config.toml配好 provider → Gateway 后台调度 → Cron 按时间触发 → 结果投递到本地或消息平台。接下来就是把它用起来。想继续深挖模型接入和 Key 管理可以看接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。想先在网页里试不同模型对同一段 Cron prompt 的理解差异用模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。如果你打算把定时任务和长期编码工作流绑在一起比如每天自动汇总仓库状态、定期生成代码审查报告Coding Plan 更合适https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。Key 的创建和管理都在控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API Keys 页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。我自己的习惯是新任务先跑一周--deliver local确认输出稳定、没有误报再改成推送到消息平台。监控类任务一律加[SILENT]规则只在真有变化时出声。自动化越强边界越要收着点——先提醒再只读报告再监控告警最后才考虑自动执行有副作用的动作。