工作进来,就有东西把它领走。
推一个任务、定时创建一个,或者让事件来创建。每个任务都是持久的——中途挂掉的运行会被重新领走,而不是丢掉。
- 优先级、重试与死信处理
- 按计划重复执行的工作
- 背压,而不是静默丢弃
cken 给每个智能体三件东西:一个可以领任务的队列、一个它跨不过去的花费上限,以及最后一位审核人。于是你可以把 AI 放到真实工作上,同时还讲得清它做了什么。
无需信用卡。失败的运行从不计费。
第一个问题——模型能不能干这件事——早就有答案了。卡住团队的是第二个:出错时谁负责?花了多少钱?它到底做了什么?谁说了可以发出去?聊天窗口回答不了这里的任何一个,所以这些工作要么永远停在演示阶段,要么上线之后没人讲得清。
它跑过了,但没人说得清它做了什么。 结果在某个 Slack 消息里,提示词后来又改过两次,当时运行它的人已经离职了。
钱是真花掉了,之后才有人发现。 没有设上限,于是账单就是上限。
演示效果更好了,实际工作反而更差了。 改一次提示词修好了有人投诉的那个例子,同时悄悄弄坏了四个没人盯着的。
一个任务会依次经过这四种状态,一个都跳不过去。
把 cken 指向一个队列、一个定时任务,或者一个入站 webhook。任务是一行带状态的数据,不是一段需要你全程盯着的对话。一万个任务和一个任务的行为是一样的。
每次运行开始前就定好花费上限、超时和重试策略。碰到上限它就停下并说明原因。不存在「从账单上才知道」的这种情况。
完成的工作进入审核队列——批准、修改或退回,键盘优先,按规则路由给负责这类工作的人。只有批准才会放行结果。
审核人批准过的例子会变成测试集。改提示词或换模型时,cken 会先拿它们给这次改动打分,再决定是否进入生产环境——于是「变好了」是量出来的,不是盼出来的。
下面每个标题都是从运维者这一侧写的:你从此可以保证什么。
推一个任务、定时创建一个,或者让事件来创建。每个任务都是持久的——中途挂掉的运行会被重新领走,而不是丢掉。
按单次运行、按工作区、按月设置上限。会超出上限的运行在花钱之前就停下,并告诉排它进队列的人为什么。
结果排队等人处理:批准、修改或退回——修改会被保留下来,因为一个被人改过的结果,是你手上最有价值的训练信号。
你批准和退回的结果会变成一个可打分的测试集。每次改提示词或换模型都先跑一遍,分数附在这次改动上。
审核人做过的修正会留下来。同一类工作的第十次运行,是从你的团队在前九次里定下的结论开始的。
输入、输出、调用过的工具、成本、耗时、批准人、时间戳。几个月之后,你依然可以把当时到底发生了什么摆给别人看。
不是在 cken 和某个竞品之间选,而是在 cken 和你手上已经有的三样东西之间选。
| Capability | 聊天窗口 | 流程编排工具 | 团队自己写的脚本 | cken |
|---|---|---|---|---|
| 谁在干活 | 一个人,在写提示词 | 你画出来的步骤 | 代码,直到它坏掉 | 一个智能体,从队列里领 |
| 谁负责 | 谁粘贴的谁负责 | 没人 | 作者,但找不到人 | 一位署名的批准人 |
| 出错的时候 | 你也许会发现 | 它照样跑完 | 它无限重试 | 在发出去之前被退回 |
| 花了多少钱 | 不知道 | 按任务算,不按模型调用算 | 不知道 | 按单次运行,事前与事后都有 |
| 拿什么给审计看 | 一段 Slack 消息 | 一份运行日志 | 应用日志 | 那次运行本身,可回放 |
| 到一万个任务时 | 到不了 | 按任务计费开始咬人 | 有人得开始值班 | 还是同一件事,排队进行 |
流程编排工具是好东西。如果你的任务是确定性的,就用它们——更便宜,而且每次都对。这里的区别在于审核人和记录,不在能力。
同一个任务的重试不会算两次。还没产出任何东西就失败的运行不计费。整个计量就这么简单。
没跑完的运行,我们不收钱。
如果一次运行在产出结果之前就失败了,它对你就是零成本——不用申请退款,也不用开工单。
智能体领走并完成的一个任务,无论成功还是失败。同一个任务的重试仍然算一次运行。还没产出结果就失败的运行完全不计费。
可以——当某一类工作的评测分数足以支撑时,你可以让它自动批准,同时对其余工作保留审核。默认是开启审核,因为这是人们最容易后悔关掉的那个开关。
审核人退回或修改它,结果不会离开 cken。这次修改会作为样例保留下来,于是下次有人改提示词时,同样的错误会被评测集拦住。
那些工具执行的是你画出来的步骤。cken 执行的是你没有完全指定的工作,在预算之内,并且在结果前面放了一个人。如果你的任务是确定性的,就用流程工具——更便宜,而且每次都对。
无需信用卡。失败的运行从不计费。