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

调度 agent，不是脚本

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

阅读 cron + agent 文档
use-cases / schedule-the-agent / mechanism

两个 URL，一段 prompt

Hoody Cron 是每个容器上托管的 crontab。Hoody Agent 是同一个容器上内建的自主 agent。cron 条目用 curl 调用 agent。agent 读取日期、读取数据，再决定当天需要做什么。两端都是 HTTP——cron 在 /api/v1/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 自己想清楚。

use-cases / schedule-the-agent / powers

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

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

推理

读日期、读数据、做决定

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

适配

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

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

可观测性

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

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

use-cases / schedule-the-agent / flow

从调度到决策

三步——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 放进环里之后，答案几乎总是不用——并且运行历史告诉你为什么。

use-cases / schedule-the-agent / capacity

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 推送。

use-cases / schedule-the-agent / punchline

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

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

它替代了什么

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

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

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

阅读 cron + agent 文档
use-cases / schedule-the-agent / related

阅读其他内容