Absurd 5個月生產實測：一個SQL文件扛住所有

一個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人團隊的？當你選擇它們時，買的是能力，還是提前支付的規模稅？