週二小貼士：計算代理人的排隊天數時，要以天數而不是行數來計算（我的顯示是 5 天，但實際數字是 0）。

My watchdog agent ran at 23:35 last night and reported a perfect evening. Eighteen slots scheduled, seventeen dispatched, sixteen task runs exited clean. Zero failures. Nothing to retry.

Then it told me tomorrow was already broken.

Not failing — 破碎的. Nothing had gone wrong yet, nothing would trip an alarm, and one of my agents was still going to publish something false the next night unless I intervened. Here is the tip, and then the receipt.

The tip: measure your queue in days, not rows

Every autonomous system you build ends up with the same shape. Something fills a queue. Something else drains it. And almost everybody monitors the wrong number — the row count — because it is the number the dashboard hands you for free.

A row count tells you nothing on its own. Two numbers turn it into an answer:

• How many rows are actually usable — not how many exist.
• How fast the drain runs — usable rows divided by consumption per day gives you days of runway.

Five rows can be zero days. Zero rows can be perfectly healthy. I have both in my container right now.

Receipt one: the queue that says five and means zero

One of my agents posts a researched social topic every night at 20:07. I pulled its queue table this morning — 74 records, 69 already used, 5 still queued. Five days of cover. Fine.

Except all five are “On This Day” briefs, and each one is welded to a calendar date: 1958, 1967, 1982, 1991, 2008. The anniversaries are 12 September, 3 September, 19 September, 6 August and 10 September. The poster publishes to tomorrow. Every one of those dates has already gone past.

There is no day left on which any of those five records is true. Usable rows: 零. They were not saved for last — they were skipped, silently, night after night, because they could never be picked. The queue depth of five was made entirely of things that had quietly expired in place.

Receipt two: the arithmetic underneath it

That is the symptom. This is the disease, and it is embarrassingly simple.

The agent that fills that queue runs twice a week — Thursday and Saturday — and writes two topics each time. That is 4 records a week going in. The agent that drains it runs every day. That is 7 a week coming out.

Four in, seven out. A structural deficit of three records a week, hard-coded into my own schedule file. That queue was never going to survive; it was only ever a question of which Tuesday it ran dry. Nothing failed. Nobody made a mistake on the night. The outage was scheduled months ago, by me, in a config file, in two lines that nobody ever read next to each other.

And because both agents report 成功 — the filler filled, the drainer drained — not one monitoring rule I own would ever have caught it. You cannot alert your way out of arithmetic.

Receipt three: the same leak, slower

Once you see the pattern you start checking everything. My blog pipeline: the research agent queues 5 briefs every Monday. The writer publishes 7 a week. Minus two a week.

The queue currently holds 9 briefs. That is not four and a half weeks of content — it is four and a half weeks until the exact same morning happens again, on a bigger, more expensive pipeline. It is draining at walking pace, it looks healthy every single day, and it has a due date.

And the one that’s fine at zero

Here is the counter-example that proves the row count is the wrong instrument. My newsletter queue has 14 records and every one is already sent. Depth: zero. Empty.

It is the healthiest pipeline I own. The researcher writes the brief Thursday morning; the writer sends it Friday morning. One in, one out, refill landing about 22 hours before it is needed. Zero rows is not a problem when the refill reliably beats the drain. Five rows is fatal when none of them can be used.

Three lines to steal

1. Give every record a usability test, and count only what passes. One question: is this row still true on the day it gets consumed? Anything with a date, a price, a stock level or a deadline baked into it has a shelf life. Expired rows should not be quietly skipped — they should be marked dead, so your depth number stops lying to you.
2. Report queues in days of runway, not rows. Usable rows ÷ consumption per day. Have the agent print that one line every run, and alert under two days. “Five records” is trivia; “zero days” is an instruction.
3. Diff the two rates before you ship anything. Producer per week versus consumer per week. If the producer is slower, you have not built a pipeline, you have built a countdown — and no amount of monitoring, retrying or error handling will save it, because nothing is going to break. Fix it in the scheduler, or make the consumer skip loudly instead of inventing something to publish.

要點： a queue is not a bucket, it is a clock. The row count tells you how much is in there. Only the rate tells you how long you have — and the failures that hurt most in an autonomous system are the ones where nothing fails, everything reports success, and the calendar quietly runs out underneath you.

This is the intake version of the problem I wrote about yesterday, when my agent had produced 314 drafts and posted zero of them — same disease, opposite end of the pipe. It is also why your scheduler lies to you and why a clean exit code is not evidence of work: I covered the silent-failure checks that catch the rest. If your own piles have grown past reading, start by clearing the approval queue before it clears you.

Want the plumbing that makes this boring instead of exciting? That is most of the real work behind agents you can actually leave alone. 預約自動化策略會議 and we will count your queues in days.