一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
容器·快照
use-cases / agent-grades-agents / hero
CRON · AGENT · SQLITE
一个给昨天的智能体打分的智能体
你的产品每天跑数百场智能体会话。每一场都把对话写进一个 SQLite URL。早上 6 点,一条 cron 条目 POST 到一个主管智能体,带上一句提示词:读昨天的对话、打分、标出最差的三个。等你坐到办公桌前,成绩单已经打开了。
agent.containers.hoody.com · grades / 2026-05-03
https://agent.containers.hoody.com/grades/2026-05-03已评分 · 06:21
裁决已审 4 个智能体·1 个需关注
由 supervisor-agent 出具AGENTRUNSGRADENOTE
- email-drafterdrafts customer replies142昨日Aperfect ground truth · tone matched in 138 / 142
- pr-reviewercomments on github diffs38昨日Bdrift toward verbosity · avg 412 words vs 280 baseline
- support-triagelabels tickets · routes to queue217昨日Challucinated tool args twice · misrouted 6 tickets需关注
- weekly-digestsummarises sales pipeline1昨日Aall 14 deals cited · numbers match crm export
/CRONTAB0 6 * * * curl -X POST /api/v1/agent/tasks -d '{"description":"从 sqlite 读昨天的会话,抽 50 个,按 rubric 打分,写下发现,把最差的三个标出来给人审。"}'
cron 任务就是主管 · 主管也是一个智能体
use-cases / agent-grades-agents / mechanism
一行 cron、一句提示词、一个裁决
一个 5 字段的 cron 条目带着提示词 POST 到 agent 服务。主管容器醒来,读昨天的 SQLite 轨迹,把分数写回同一个数据库,然后退出。没有编排器、没有 rubric 服务、没有 eval 流水线。
POST /cron/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 分钟内完成工作,然后消失。等任何人坐到桌前时,评过分的样本已经在磁盘上了。
use-cases / agent-grades-agents / powers
主管智能体能做、仪表盘做不到的三件事
AgentOps 的屏幕给你看日志。LangSmith 的 rubric 给你算分。一个会评分的主管把回路闭上——它读对话、判定哪里不好、把裁决写下来。
READS
它真的在读对话
不只是看指标。主管打开每一场会话,读工具调用,核对真值,衡量语气。表格化的 rubric 在数;一个智能体主管在判。
DECIDES
它挑出三个你应该看的
400 次运行里,397 次没问题。主管的工作就是把那不对劲的三次浮上来——按名字、配一行说明。你不用滚动仪表盘,只读四行。
WRITES
它把发现写回 SQLite
每一个分数、每一条备注都落进 worker 智能体使用的同一个 SQLite URL。明天的主管会做对比。漂移变成一次查询,而不是一种感觉。
use-cases / agent-grades-agents / flow
从对话到裁决,二十分钟
上午 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,磁盘上已经有评过分的样本,以及三条排队等审的对话。打分者不盯着智能体——它按节奏运行并评判它们,就像老师在夜里读作业。
use-cases / agent-grades-agents / capacity
节奏给你买到的东西
数字来自 cron + agent + SQLite 的接口本身。不是编出来的基准。
- 一行 CRON0 6 * * *
五个字段决定主管何时醒来。改 schedule,就改了节奏——每小时、每天、按需。这一行就是整个调度器。
- 评分窗口~20 min
一次抽 50 场会话、读完每一场、写下裁决的主管任务通常 20 分钟内完成。任务结束,容器随之退出。
- 编排守护进程0
没有 Airflow,没有 eval 服务,没有 DAG 调度器。cron 条目是 /etc/crontab 里的一行。裁决是 SQLite 里的一行。没有第三样东西。
标准的 5 字段 cron 表达式,依据 Hoody Cron API。主管会话长度取决于抽样大小和 rubric 复杂度。SQLite 就是 worker 智能体本来在写的同一个 hoody-sqlite URL——没有第二个存储。
use-cases / agent-grades-agents / punchline
cron 任务就是主管;主管也是一个智能体。
昨天 · 盲跑今天 · 6:21 已评分
旧的循环长这样工程师读日志 · 周会 · 事后在表格里写 rubric一周后才发现漂移 · 只审了 0.5% 的运行
现在它长这样
use-cases / agent-grades-agents / replaces
它替代了什么
标准的智能体质量栈:只读仪表盘、人肉日志审阅、只评分不行动的 rubric 工具。主管 cron 在二十分钟里把这三件事一起做了。
- 纯人工的智能体审阅工程师手动读日志 · 抽样 0.5% · 一周后才发现漂移
- 周会上的智能体复盘等你讨论时,漂移已经存在了一周
- 手动看日志grep、滚动、祈祷 · 没有 rubric、没有分数、没有记录
- AgentOps 质量仪表盘(只读)你得自己去打开图表 · 裁决从未被写下来
- 不行动的 LangSmith 评分 rubric分数被算出来 · 没人被呼叫 · 没人被告知
- 事后用电子表格当 rubric周五填一份 Google 表格 · 周一就过期了
use-cases / agent-grades-agents / cta
别再晚上 11 点读日志。安排一个智能体去夜里读,你早上端着咖啡看它的成绩单。
use-cases / agent-grades-agents / related
阅读其他内容
