82 个定时任务，44 个不调用模型

早上九点整，这台机器上的第 1000 个定时任务进程启动了。它在执行表里留下一行：谁叫醒的、几点开始、跑的是哪个任务，然后照着任务书去干活。往前数 51 个小时，这样的记录正好 1000 条，平均每小时 19.7 次唤醒。这 1000 次启动里，没有一次是我点的。

这台机器上跑着一支 82 个任务的定时舰队。每天早上八点和晚上八点各跑一批网站内容，每两小时看一次站点健康度，每四小时生成一轮社交文案，每天巡检一次数据源注册表。它们由固定的时刻叫醒，干完活写回一行记录，然后继续睡。公司只有一个人，所以这支舰队不是部门项目，是我的手和脚的延伸。

我把最近两天的账翻出来对了一遍。这套东西的成本，最后落在另外 44 个从头到尾不调用模型的任务上，而不是那 82 个里调用模型的任务。这件事跟常识相反。

一天的账：475 次唤醒，38 条消息

先摆口径，因为这一层的数最容易糊。执行表里一行对应一次唤醒，不管这次唤醒最后是写了五段分析还是一句话没发。10 月 26 日全天，475 行执行记录，覆盖 69 个不同任务，非零退出 0 次。同一天投递到人眼前的消息 38 条。两者相减，437 次唤醒什么也没说，占 92%。

再看舰队构成。配置了 101 个任务，启用 82 个。这 82 个里有 44 个是纯脚本任务：读文件、查数据库、算差值、写一行状态，全程不调用一次模型。它们做的是新鲜度检查、字段非空率统计、注册表一致性比对、去重指纹计算。剩下的 38 个才需要模型读材料、做判断、写文字。

这两个数字放在一起，说明了一件被普遍忽略的事。一支几十个任务的舰队，绝大多数唤醒是确定性的。答案在写任务书的时候就定了，跑一万次也还是那个答案。模型只出现在少数需要判断的岔口上。这意味着拿整支舰队的唤醒次数乘以一次模型调用的价格，估出来的账会比真实账高一个数量级。反过来也成立。拿那个价格去规划舰队，人会不敢加任务，而真正该加的那些恰恰不花钱。

唤醒的成本和这次干多少活无关

要理解为什么是那一半决定成本，得先拆开一次唤醒到底在干什么。进程起来之后，第一件事是重建上下文：读规则文件、读记忆、读任务书、装配工具清单、取上一次的状态。这一整段开销是准入门票。它跟这次要处理一百行还是一百万行没有关系，门票付完才开始干活。

模型这一层的账更陡。模型接口每次调用都要把整段对话历史重新计费，多步工具调用会让账单按步数平方增长。Augment Code 在 2026 年 6 月更新的成本指南里给了个具体倍数：一个 20 步的循环，实际消耗可能超过按每步单价估算的 10 倍。Anthropic 自己的工程团队公布的数字是，智能体消耗的 token 约是普通对话的 4 倍，多智能体系统约 15 倍。这两份材料各自成立。它们指向同一件事：账单的乘数是唤醒的量，不是单次处理量。

所以我们做了一次取舍，把能判定的工作全部压到脚本里。新鲜度够不够、字段填充率到没到阈值、两个注册表有没有漂移、这份材料是不是上周那份，这些问题的答案都不需要判断力，只需要算术和比较。脚本的产出是二值的：通过或者不通过，退出码 0 或者 1。模型的产出不是二值的，它需要被读、被判断，而判断本身又要花一次唤醒。

这句话可以反过来说，更能看清代价。把一件确定性的事交给模型，你付的钱不在那一次调用上。它落在从此以后每一次的核对上：总要有人，或者另一个模型，去看它这一次对不对。原因是核对成本通常高于执行成本，而且要一直付下去。

92% 不发言是规格，不是省事

公司原则里有一条：没有状态变化就说不了话。写的时候我以为这是省 token 的规矩，跑了一个月才明白它是这套东西能活下来的条件。设想另一条路：475 次唤醒每次都发一条消息。第三天我会把整支舰队关掉。这不是因为哪条消息错了，是因为人无法从 475 条里挑出那 3 条要紧的。

所以静默不是省略，是任务自己承担了筛选的职责。每个任务在写任务书的时候就必须回答一个问题：什么情况下我有资格说话。我们把它收成三种：结论变了、某个数越过了阈值、有一件事只有人能决定。三者之外一律闭嘴。这条规则如果写不进去，说明这个任务还不该被建出来。

静默还有个副产品。因为平时不说话，一个任务突然说话这件事本身就变成了信号。10 月 26 日那 38 条消息里，有几条是巡检发现数据源连续两天没更新，有几条是内容闸门拦下了不合格的稿子。这些消息的价值不在于它们写了什么，在于它们稀少。如果每天有 400 条消息，同样这几条会被淹没，而人是会习惯性忽略的。

把人的成本算进去，这个比例的意义更清楚。读一条需要判断的消息，平均三十秒。475 条就是近四个小时，一个人一天里没有四个小时连续的空档。38 条是十九分钟，可以塞进任何两个会议之间。所以差别不在机器那边，在人这边还剩多少余量去真正读懂那几条。这意味着静默率不是美观指标，它决定了这套系统还有没有人愿意用。

唯一那次失败，是检测器在说真话

51 小时 1001 次执行里，只有 1 次非零退出，故障率 0.1%。这个数字好看得可疑，所以我去读了那次的错误原文。进程的退出码是 1，输出是一串通过项和一条没过的检查：审计新鲜度通过、观察者连续性通过、检测路径覆盖率 100% 通过，某一条没过。也就是说，这次所谓的失败，是一个巡检脚本在如实报告一个真实存在的状态。它没有崩，它是在报警。

这个区别很要紧。把非零退出直接算成故障率，团队会得到一个漂亮指标。然后大家花力气去优化这个指标。真正的问题是，失败不在这里。真正的失败藏在 completed 里，至少三种形态。第一种是沉默地做错：格式合法、结论错误，退出码 0。第二种是重复劳动：同一份数据被两个任务各处理一遍，产出两份措辞不同、结论相同的报告。第三种是把旧结论当新结论：没有新证据，但因为到了时间，照样写一篇。

这三类都不会让任何监控变红。这意味着它们只能靠设计挡住。我们的做法是给每个任务一个指纹：把它的输入（数据文件的哈希、查询结果的摘要、上游产物的版本号）算成一个串。串没变就直接退出，退出码 0，不发消息。重复劳动从需要被发现的问题，变成了不会发生的事。第三种失败靠另一条规则挡住：没有新证据的任务，输出必须写成增量，不许重写全文。

第一种最难。它需要有人真的去读产出，而不是读状态。我们的做法是让内容闸门做机器能做的部分，语言风格、引用完整性、标题长度、组件渲染，全部自动化；剩下的判断留给一次主动阅读。这也解释了为什么 38 条消息里有相当一部分是「请你看一眼」，而不是「我已经处理好了」。

我们的判断

定时舰队的架构单位不是模型，也不是编排框架，是唤醒契约。一份契约要回答四个问题：什么条件下醒、醒来能看到什么、什么算干完、不满足条件时怎么闭嘴。四个都写死，底下的模型可以随便换，换便宜的还是换贵的只是价格问题；四个里有一个没写，换多贵的模型都补不上。

这也是我们不追多智能体框架的原因。一个任务的边界清楚、判据可写，它就不需要编排，一张执行表加一个幂等键就够了。边界不清楚的时候，编排不会让它变清楚，只会把不清楚复制成四份，token 也复制成四份。Anthropic 那组 4 倍和 15 倍的数，说的就是这个复制。

顺带说清一个我们不打算改的选择。这 44 个脚本任务是整支舰队里最不性感的部分，没有演示价值，也进不了任何发布会。但它们也是最稳定的部分，而且不受任何供应商调价的影响。一家小公司要把运营压到一个人身上，靠的正是这一半。

我们自己的内容流水线就是这么分的。闸门跑的是脚本：中文字数底线、引用链接数量、标题长度、组件有没有渲染、必须出现的字段齐不齐。每一条都能用一句断言写出来，答案每次都一样。模型只保留最后一件它真正擅长的事，把材料写成文章。这条分界线我后来总结成一句：如果一件事的正确答案每次都一样，它就不该由模型回答；只有答案每次可能不一样的，才轮到判断。

这句话有一个容易被忽略的推论。判断不免费，它要花一次唤醒，还要花一个人去核对。所以判断应该放在最少的岔口上，一个任务里最好只有一处。一旦任务里有三处需要判断，它实际上是三个任务被硬塞进同一个进程，成本也按三份收。

要建同类舰队，先做五个动作

第一，先分类再动手。把候选任务分成两类：判据能写成代码的，判据要人定的。第一类禁止使用模型，这一条没有例外，因为一旦开了口子，后面每个任务都会声称自己需要判断力。

第二，写唤醒条件，不写周期。能用「数据变了才醒」的，不要用「每 15 分钟醒一次」。周期是给无法观察输入的任务用的，观察得到输入的任务用周期，等于用固定成本买不确定性。

第三，每个任务一个指纹。指纹不变就退出，并且不许发消息。这一条同时解决重复劳动和噪音两个问题。

第四，把「什么算干完」写成一个可执行的判断，而不是一句描述。「写好了」不是判据，「文件存在、字数过线、校验通过」才是。

第五，给每个任务记四个数：醒来次数、说话次数、非零退出次数、需要人介入次数。四个数放一张表，一周看一次。说话次数除以醒来次数，如果接近 1，这个任务的设计有问题；如果一直是 0，它可能已经死了，只是还在按时醒来。

最后留一个问题给正在铺这条路的团队。你手上那些定时任务，有多少次唤醒是不需要模型也能得出同样结论的？这个比例决定了你的单位成本，也决定了明年供应商调价时你有多少谈判空间。它通常比你估计的高得多。原因很朴素：把一个任务交给模型，多数时候的理由是写脚本要花一个下午，跟判断力无关。

数据口径

本文的四个数来自本机定时任务执行库，统计区间为 2026 年 10 月 25 日 06:18 至 10 月 27 日 09:00，共 1001 行执行记录。唤醒次数按执行行计，同一任务同一时刻只记一次。投递次数来自投递库，按消息条数计，同一批多条消息分别计数。任务总数与是否调用模型，按任务配置里的脚本型标记统计。以上数字可以由同一台机器上的执行记录复算。口径写在这里，是为了让读者能用自己的库对一遍，不必相信一个孤立的百分比。

还有一处需要说明。执行库只保留最近约 1000 行，所以每天的唤醒次数是一天的全量，五天的投递次数是五天的全量，两者不能直接相除。文中 92% 这个比例用的是同一天的分母和分子：10 月 26 日 475 次唤醒、38 条投递。跨天的数放在一起比，会得到偏低的静默率，这个错误我第一遍就算错过。

参考来源

Anthropic 工程团队关于多智能体研究系统的实测 token 倍数：anthropic.com/engineering/built-multi-agent-research-system（厂商自报，一手）。

Augment Code 关于智能体循环中上下文累积导致成本按平方增长的估算：augmentcode.com/guides/ai-agent-loop-token-cost-context-constraints（厂商技术指南，页面标注 2026 年 6 月 18 日更新）。

本文的唤醒次数、投递次数、任务构成、那次非零退出的错误原文，均为本机执行记录，非转述。