一个SQL文件+薄SDK，没有独立服务、没有编译器插件、没有完整运行时——这是Earendil团队去年11月放出的Absurd。当时很多人当它是玩具，直到他们真把它塞进生产环境跑了5个月。
2024年4月的数据：系统没崩，设计没塌，开发者甚至有点上瘾。
从"能跑"到"敢用"：生产环境逼出的7个补丁
作者Gavin在博客里说，过去5个月的更新"都是你会对真实依赖系统期待的东西"。翻译一下：用户真的来了，边骂边用，把边缘情况一个个喂给了他们。
认领机制（claim-based scheduling）被加固了。之前worker挂掉可能留下僵尸认领，现在看门狗会掐死失联进程。死锁预防、租约管理、事件竞态条件——这些词听着枯燥，但任何一个在生产环境炸过的人都知道，它们是区分"演示代码"和"能用的系统"的分水岭。
最狠的一课：用户比你更会用你的产品。
团队原本以为ctx.step()——传个函数、拿到持久化结果——就够用了。结果用户需要在提交结果前检查步骤状态，用来建模"故意失败"和条件逻辑。于是有了beginStep()/completeStep()这对API。
这让我想起Notion早期被用户逼出database功能的故事。你以为自己在造锤子，用户拿它造了艘船。
三个被低估的设计决策
任务结果（Task results）。最初是纯fire-and-forget，现在可以spawn一个任务、干别的、回来取结果。听起来像基础功能？但就是这个" hindsight obvious"的改动，让Absurd能支持父工作流等子任务完成——这对调试AI agent尤其有用。
absurdctl。从脚本集合进化成正经CLI：初始化schema、跑迁移、创建队列、spawn任务、emit事件、重试失败项。作者的原话是"proper CLI tool"，带着一种终于把草台班子收拾利索的释然。
多语言SDK。TypeScript、Python、实验性Go。注意顺序：不是从系统语言往下铺，而是从业务开发者最顺手的地方开始。这很产品经理思维——先让用的人爽，再考虑炫技。
Postgres作为唯一依赖：大胆还是懒惰？
Absurd的激进之处在于：所有状态、调度、事件、检查点，全塞进Postgres。没有Redis，没有Kafka，没有专门的持久化层。
反对者会说这是单点故障。支持者会算一笔账：你的团队已经在运维Postgres了，再多一个系统的认知负荷和故障面，真的值得吗？
Gavin没直接回应这个争论，但给了数据：5个月生产运行，设计hold住了。换句话说，对于Earendil的规模和使用场景，Postgres的可靠性边界还没摸到。
这让我想起SQLite的复兴。不是因为它比Postgres强，而是因为"少一个东西在夜里报警"本身就是一种架构优势。
谁在偷偷用？
博客没披露客户名单，但提到"other people seem to agree"——GitHub仓库有外部贡献，Discord有人讨论生产部署。最有趣的信号是：团队开始收PR了，而且是在" hardened claim handling"这种脏活领域。
愿意给你写死锁预防代码的人，通常是真在用、真被卡过的人。
一个细节：作者特意提到"before call"和"after call"类型的hook API。这是支付、Webhook、第三方集成的典型模式——暗示Absurd正在渗入钱流过的系统。
最后的问题：如果持久化执行（durable execution）可以压缩成一个SQL文件，Temporal、Cadence这些重运行时系统，有多少复杂度是为了覆盖1000人公司的场景，而非10人团队的？当你选择它们时，买的是能力，还是提前支付的规模税？
热门跟贴