hatchet

后台任务编排引擎 Hatchet：用 Postgres「重造」Temporal？

一个客服 AI 每天处理 10 万工单背后的故事

想象这样的场景：你运营着一个每天处理 10 万条用户消息的 AI 客服系统。每条消息进来，系统需要：先调用大模型判断意图，再查询知识库补充上下文，接着生成回复草稿，最后还要记录工单、触发后续的人工复核流程。这条链路中任何一环出错——大模型超时、知识库查不到、数据库写入失败——你都希望能重试而不是从头来过。更重要的是，你希望有一个 Dashboard 实时看到每个任务卡在哪一步。

Hatchet 正是为这类场景设计的。它是一个后台任务与 AI Agent 编排引擎，支持 Python、TypeScript、Go 和 Ruby 四种语言，既可用云服务（Hatchet Cloud）也支持完全私有化部署。

背景：为什么需要专门的任务编排工具？

传统的消息队列（如 RabbitMQ、Redis Queue）只负责「把任务送出去」，但不保留执行历史。任务一旦执行完毕从队列中消失，你就无法知道它过去发生了什么、失败了哪一步。更复杂的是，当你要构建一个由多个步骤组成的工作流——比如上面的「AI 客服处理链」——你需要自己管理每个步骤之间的状态、依赖关系和错误恢复逻辑。

Temporal（分布式持久化工作流引擎）解决了这个问题，但代价是运维复杂度较高，需要维护一套独立的持久化层。Hatchet 的核心思路是：直接复用 Postgres 作为持久化后端，把 Temporal 的能力用更轻量的方式实现，同时自带监控、告警和多租户。

核心功能：从简单任务到复杂工作流

后台任务是 Hatchet 最基础的用法。你只需定义一个普通函数，加上 @workflow 或 @task 装饰器，注册到 Hatchet 平台，平台自动帮你处理：

• 自动重试：指数退避、配置重试次数上限
• Cron 调度：支持定时任务和延迟任务
• 优先级队列：关键任务可以「插队」先执行
• 公平调度：基于动态 Key 的并发控制，防止单用户任务占满所有资源

** Durable Tasks（持久化任务）**是 Hatchet 与普通任务队列最大的区别。你可以把一个跨多天的业务流程写成「持久化工作流」——中间可以暂停（sleep）、等待外部事件（如用户点击确认按钮）、再从断点继续执行。整个执行历史都记录在 Postgres 中，宕机重启后自动从上次断点恢复，无需任何额外操作。

DAG 工作流用于构建数据流水线（如 ETL）。与 Durable Tasks 的区别在于：DAG 更适合「一次性执行、结果确定」的场景，而 Durable Tasks 更适合「长时间运行、需要人工介入」的业务流程。

技术架构：Go 后端 + React 前端 + Postgres 持久化

从代码仓库结构来看，Hatchet 的架构非常清晰：

• 后端引擎（Go）：主要业务逻辑在 cmd/hatchet-engine 中，API 服务在 cmd/hatchet-api，pkg 和 internal 目录包含核心模块
• 前端 Dashboard（React/TypeScript）：位于 frontend/app，基于 Vite 构建，使用 Radix UI 组件库，集成 Monaco Editor（代码编辑器）和 Cypress 端到端测试
• 多语言 SDK：sdks/ 下分别有 Python、TypeScript、Go、Ruby 四个 SDK，每个 SDK 有独立的 README 和示例代码
• 数据存储：PostgreSQL 15 作为唯一真相来源（durability 层），PgBouncer 做连接池，RabbitMQ 处理消息广播
• 可观测性：内置 OpenTelemetry 采集和 Prometheus metrics 导出，支持将数据发送到外部监控系统

上手体验

如果你只是想快速体验 Hatchet，最简单的方式是注册 Hatchet Cloud——官方提供了一个可直接使用的云端平台，适合在正式部署前了解完整功能。

本地开发则需要安装 Docker，通过一条命令即可启动完整服务栈：

curl -fsSL https://install.hatchet.run/install.sh | bash
hatchet server start

这条命令会拉取 docker-compose 配置，自动启动 PostgreSQL、PgBouncer、RabbitMQ 以及 Hatchet 后台引擎和前端 Dashboard。启动后访问本地地址即可看到任务监控界面。

不足与局限

Hatchet 的吞吐量不如纯内存队列。官方坦诚说明：在需要极致性能的场景（如每秒 10 万+ 任务），Hatchet 的 Postgres 持久化开销会成为瓶颈，此时更适合使用 Redis 或 RabbitMQ。对于大多数应用场景，Hatchet 宣称的 10k tasks/s 已足够。

此外，Hatchet 采用 MIT 许可证，但部分高级功能（如 SSO、细粒度 RBAC）仅在 Cloud 版提供，开源版本的功能集相对基础。

行业意义

Hatchet 代表了一种趋势：把分布式系统的复杂度从基础设施层下沉到应用层。过去需要运维 Temporal/CDK/Flink 才能实现的「任务持久化 + 精确重试 + 实时监控」，现在通过一个 docker-compose 配置文件就能跑起来。这降低了中小团队构建可靠后台系统的门槛，也让 AI Agent 的「可观测性」从概念变成工程实践。

如果你的产品涉及：AI 工作流编排、定时批处理系统、需要人工介入的业务审批流、跨服务的数据同步任务——Hatchet 是一个值得尝试的开源选择。

分析基于 GitHub 仓库 v0.50+ 版本，数据截至 2026-05。