跳转到内容
类型新原语
阶段生产环境
难度中等
工作自动化任务
用于AI 构建者
用于后端开发者
服务Cron
服务智能体
为何选 HoodyAI 原生
为何选 HoodyHTTP 原生
类型新原语
阶段生产环境
难度中等
工作自动化任务
用于AI 构建者
用于后端开发者
服务Cron
服务智能体
为何选 HoodyAI 原生
为何选 HoodyHTTP 原生
类型新原语
阶段生产环境
难度中等
工作自动化任务
用于AI 构建者
用于后端开发者
服务Cron
服务智能体
为何选 HoodyAI 原生
为何选 HoodyHTTP 原生
类型新原语
阶段生产环境
难度中等
工作自动化任务
用于AI 构建者
用于后端开发者
服务Cron
服务智能体
为何选 HoodyAI 原生
为何选 HoodyHTTP 原生
返回使用场景列表
CRON · AGENT · 0 7 * * *

调度 agent，不是脚本

传统 cron 行在凌晨 2 点跑 reconcile.sh。Hoody 的 cron 行把一段 prompt POST 给 hoody-agent。调度是固定的，工作不是。边界情况不再是你要维护的分支——它们变成 agent 推理时的上下文。

阅读 cron + agent 文档

两个 URL，一段 prompt

Hoody Cron 是每个容器上托管的 crontab。Hoody Agent 是同一个容器上内建的自主 agent。cron 条目用 curl 调用 agent。agent 读取日期、读取数据，再决定当天需要做什么。两端都是 HTTP——cron 在 /users/me/entries，agent 在 /api/v1/agent/tasks。中间没有任何胶水代码。

cron-1.containers.hoody.com · entry
POST · cron/users/me/entries
# POST /api/v1/cron/users/me/entries
{
  "schedule": "0 7 * * *",
  "command": "curl -X POST $AGENT/api/v1/agent/tasks \
     -d @prompt.json",
  "comment": "morning-reports"
}
agent-1.containers.hoody.com · task
POST · agent/tasks
# prompt.json — the body of the POST
{
  "description": "对账昨天的订单。如果 schema 漂移，重新映射。如果异常分数 > 3，停下并呼叫 on-call。如果今天是月末，对税务调整后的总账做月度结账。",
  "mode": "code"
}

两次 POST，搞定。这一行 crontab 永远不再改——你维护的唯一文件就是 prompt。新的边界情况？加一句话。新的异常规则？加一句话。调度照常触发；每次触发意味着什么由 agent 自己想清楚。

prompt 能做、脚本做不到的三件事

agent 收到的工作形态总是相同——一个日期、一个数据集、一个目标。变化的是 agent 决定怎么处理它们。

推理

读日期、读数据、做决定

cron 触发后 agent 启动。它检查日历——月末、节假日、财务结账。它采样数据集——schema、数据量、异常分数。它根据这些上下文挑选下一步动作，而不是依赖你六个月前写的静态 if 树。

适配

新增列？新增币种？同一段 prompt。

当昨天的导出新增 refund_reason 列时，脚本会崩溃并呼你。agent 读取 schema，将其映射到旧字段，并在运行摘要里记下变化。crontab 那一行从来不需要知道。

可观测性

每次运行是一段话，不是一个返回码

每次运行都把 agent 决定了什么、为什么决定，回写出来。历史就是大白话——「跳过：没有新数据」、「已适配：新增退款列」、「异常：退款飙升 +412%，已呼叫 on-call」——而不是 exit code 0 / exit code 1。cron 的日志变成了一本日记。

从调度到决策

三步——cron 触发，agent 推理，决策落地。中间那一步过去是你自己用 400 行 shell 加 17 个边界分支写出来的。现在它是一段 prompt。

三步每日循环一段 PROMPT · 无限边界情况
07:00

cron 触发

Hoody Cron 运行这条条目。crontab 那一行就是一次 curl：POST /api/v1/agent/tasks，请求体里是 prompt。重试不用你写、日志接线也不用你接——cron 服务把这条条目注入系统 crontab 并跟踪运行。

07:00 + ε

agent 推理

agent 收到描述，打开它的工具——terminal、files、sqlite、browser、exec——然后挑一份动作计划。它可能运行、跳过、适配或呼人。挑选每天都不同。指令始终一致。

07:00 — 07:04

决策落地

运行结束。agent POST 回一行摘要：报表已重新生成、因没有新数据跳过、因异常停下。你边吃早饭边在手机上读它。

调度没改。脚本没改。改变的是你这个人是否得起来去处理。把 agent 放进环里之后，答案几乎总是不用——并且运行历史告诉你为什么。

cron + agent 组合给你的能力

Hoody Cron 和 Hoody Agent 是同一个容器上的两个服务，都通过 HTTP 可达。数字来自有文档支撑的接口——不是凭空的基准。

  1. CRONTAB 大小1 行

    crontab 里一行 curl，用永远。prompt 是你唯一会重写的东西——而且是在一个 JSON 文件里改，不是 crontab -e。

  2. AGENT 端点100+

    hoody-agent 把整套接口——terminal exec、文件读写、sqlite 查询、浏览器自动化、守护进程控制——以普通 HTTP 调用的形式开放给 agent 任务。

  3. 胶水代码行数0

    cron 和 agent 之间没有 SDK。POST 一个 URL，读另一个。两个服务都跑在同一个容器上，所以调用是本地网络速度。

Hoody Cron 支持标准 5 字段表达式（* * * * *）和宏（@hourly、@daily、@weekly、@monthly、@yearly）。Hoody Agent 任务创建是一次 POST /api/v1/agent/tasks；实时更新通过 /api/v1/agent/ws 推送。

cron 条目不再运行任务——它请 agent 去想清楚任务。

之前 · 分支脚本之后 · 分支 prompt
过去 cron 条目指向什么0 2 * * * /usr/local/bin/reconcile.sh # 412 行 · 17 个边界每加一条月末规则都意味着改脚本，然后祈祷
现在它指向什么0 7 * * * curl POST agent/tasks -d @prompt.json一行，永远——你维护的唯一产物是 prompt
阅读 agent 任务规范

它替代了什么

你过去因为 cron 只会执行文件而塞进 reconcile.sh 的那一堆东西。每一项都是一个分支、一个开关、一份配置——没有一项是调度真正需要知道的。agent 读取这一天，自己决定。

  • 脆弱的脚本式 cron 任务输入列稍微挪一下就崩的 bash 分支
  • 为 schema 变更做的人工维护每次上游导出多一个字段就改 reconcile.sh
  • 手写的 ETL 脚本一整个 .sh 文件夹，团队里只有一个人能看懂
  • if X then Y else Z 的 cron 逻辑月末、节假日、异常——三个开关塞进同一段脚本
  • 轮询变更的脚本另一条 cron，任务就是盯着第一条 cron 的输出再做决定
  • 手写的 if-else 调度器200 行的分发器，唯一的工作是挑一段脚本运行

别再维护 cron 脚本。开始维护 prompt。调度照样触发；agent 自己想清楚。

阅读 cron + agent 文档

阅读其他内容