跳转到内容
类型解锁
阶段生产环境
难度高级
工作自动化任务
用于AI 构建者
服务Cron
服务智能体
服务SQLite
为何选 HoodyAI 原生
为何选 HoodyHTTP 原生
类型解锁
阶段生产环境
难度高级
工作自动化任务
用于AI 构建者
服务Cron
服务智能体
服务SQLite
为何选 HoodyAI 原生
为何选 HoodyHTTP 原生
类型解锁
阶段生产环境
难度高级
工作自动化任务
用于AI 构建者
服务Cron
服务智能体
服务SQLite
为何选 HoodyAI 原生
为何选 HoodyHTTP 原生
类型解锁
阶段生产环境
难度高级
工作自动化任务
用于AI 构建者
服务Cron
服务智能体
服务SQLite
为何选 HoodyAI 原生
为何选 HoodyHTTP 原生
CRON · AGENT · SQLITE

一个给昨天的智能体打分的智能体

你的产品每天跑数百场智能体会话。每一场都把对话写进一个 SQLite URL。早上 6 点,一条 cron 条目 POST 到一个主管智能体,带上一句提示词:读昨天的对话、打分、标出最差的三个。等你坐到办公桌前,成绩单已经打开了。

阅读 agent 文档

一行 cron、一句提示词、一个裁决

一个 5 字段的 cron 条目带着提示词 POST 到 agent 服务。主管容器醒来,读昨天的 SQLite 轨迹,把分数写回同一个数据库,然后退出。没有编排器、没有 rubric 服务、没有 eval 流水线。

POST /users/me/entries
POST · 调度器
# POST /api/v1/cron/users/me/entries
{
  "schedule": "0 6 * * *",
  "command": "curl -X POST $AGENT/api/v1/agent/tasks \
     -d @grade.json",
  "comment": "nightly-supervisor"
}
grade.json · 主管提示词
POST · 主管
# grade.json — the supervisor's instructions
{
  "description": "从 /sqlite/sessions 读昨天的对话,WHERE day = '2026-05-03'。抽 50 条。按事实性、工具调用正确性、语气漂移分别打分。把发现写进 report 表。把最差的三个标记给人审。",
  "mode": "code"
}

cron 行决定何时。提示词决定做什么。主管容器在夜里大约 20 分钟内完成工作,然后消失。等任何人坐到桌前时,评过分的样本已经在磁盘上了。

主管智能体能做、仪表盘做不到的三件事

AgentOps 的屏幕给你看日志。LangSmith 的 rubric 给你算分。一个会评分的主管把回路闭上——它读对话、判定哪里不好、把裁决写下来。

READS

它真的在读对话

不只是看指标。主管打开每一场会话,读工具调用,核对真值,衡量语气。表格化的 rubric 在数;一个智能体主管在判。

DECIDES

它挑出三个你应该看的

400 次运行里,397 次没问题。主管的工作就是把那不对劲的三次浮上来——按名字、配一行说明。你不用滚动仪表盘,只读四行。

WRITES

它把发现写回 SQLite

每一个分数、每一条备注都落进 worker 智能体使用的同一个 SQLite URL。明天的主管会做对比。漂移变成一次查询,而不是一种感觉。

从对话到裁决,二十分钟

上午 6:00 到 6:21 之间发生三件事。它们都不需要你。

/cron/0 6 * * * → agent/tasks → /grades/2026-05-03在你睡觉时运行
READ

打开昨天的对话

主管智能体查询 worker 们写入的同一个 SQLite URL。SELECT * FROM sessions WHERE day = yesterday。随机抽 50 条。

SCORE

按 rubric 打分

每场会话:事实性、工具调用正确性、语气漂移、幻觉次数。一个等级 + 一行理由。代价:一次智能体任务。

FLAG

写下发现 · 标记最差三个

INSERT 进 report 表。把最差的三个标给人审。/grades/[date] 那一页就是对那张表的 SELECT。

到 6:21,磁盘上已经有评过分的样本,以及三条排队等审的对话。打分者不盯着智能体——它按节奏运行并评判它们,就像老师在夜里读作业。

节奏给你买到的东西

数字来自 cron + agent + SQLite 的接口本身。不是编出来的基准。

  1. 一行 CRON0 6 * * *

    五个字段决定主管何时醒来。改 schedule,就改了节奏——每小时、每天、按需。这一行就是整个调度器。

  2. 评分窗口~20 min

    一次抽 50 场会话、读完每一场、写下裁决的主管任务通常 20 分钟内完成。任务结束,容器随之退出。

  3. 编排守护进程0

    没有 Airflow,没有 eval 服务,没有 DAG 调度器。cron 条目是 /etc/crontab 里的一行。裁决是 SQLite 里的一行。没有第三样东西。

标准的 5 字段 cron 表达式,依据 Hoody Cron API。主管会话长度取决于抽样大小和 rubric 复杂度。SQLite 就是 worker 智能体本来在写的同一个 hoody-sqlite URL——没有第二个存储。

cron 任务就是主管;主管也是一个智能体。

昨天 · 盲跑今天 · 6:21 已评分
旧的循环长这样工程师读日志 · 周会 · 事后在表格里写 rubric一周后才发现漂移 · 只审了 0.5% 的运行
现在它长这样
阅读 cron + agent 规范

它替代了什么

标准的智能体质量栈:只读仪表盘、人肉日志审阅、只评分不行动的 rubric 工具。主管 cron 在二十分钟里把这三件事一起做了。

  • 纯人工的智能体审阅工程师手动读日志 · 抽样 0.5% · 一周后才发现漂移
  • 周会上的智能体复盘等你讨论时,漂移已经存在了一周
  • 手动看日志grep、滚动、祈祷 · 没有 rubric、没有分数、没有记录
  • AgentOps 质量仪表盘(只读)你得自己去打开图表 · 裁决从未被写下来
  • 不行动的 LangSmith 评分 rubric分数被算出来 · 没人被呼叫 · 没人被告知
  • 事后用电子表格当 rubric周五填一份 Google 表格 · 周一就过期了

别再晚上 11 点读日志。安排一个智能体去夜里读,你早上端着咖啡看它的成绩单。

阅读 agent 文档

阅读其他内容