Temporal: cách giữ tiến trình của agent khi hệ thống của khách sập giữa chừng

Thử hình dung một agent đối soát 200 đơn hàng cho khách hàng logistics. Với mỗi đơn, agent gọi LLM để đọc chứng từ rồi ghi kết quả vào ERP của khách. Đến đơn thứ 120 thì ERP treo, và worker chạy agent chết theo.

Nếu cả vòng lặp chỉ nằm trong bộ nhớ, bạn mất sạch 119 đơn đã xử lý. Chạy lại từ đầu thì tốn thêm 119 lần gọi LLM, tệ hơn là có thể ghi trùng vào ERP. Ở site khách, sự cố kiểu này đủ để buổi demo thứ hai không bao giờ diễn ra.

Đó chính là bài toán Temporal nhắm tới. Samar Abbas, CEO kiêm đồng sáng lập Temporal, cho rằng agentic AI không tạo ra vấn đề mới mà chủ yếu làm lộ ra những vấn đề cũ như quản lý state và xử lý lỗi. Với một FDE, câu đó nên đọc như một lời nhắc: phần khó của agent production thường không nằm ở prompt.

Temporal làm gì, nói ngắn gọn?

Temporal là nền tảng mã nguồn mở, giấy phép MIT, của Temporal Technologies. Bạn viết business logic bằng SDK của ngôn ngữ mình dùng, còn Temporal chạy code đó dưới dạng Durable Execution. Tài liệu chính thức viết rằng một khi đã bắt đầu, Workflow sẽ chạy đến khi xong, dù mất vài giây hay vài tháng.

Ý tưởng cốt lõi là chuyển việc xử lý lỗi từ code ứng dụng xuống nền tảng. Worker sập thì Temporal Service giao phần việc cho một worker khác. Bạn không phải tự viết checkpoint, tự lưu cờ “đã xong đến đâu” vào database, hay tự dựng hàng đợi retry.

Công ty cũng đang đặt cược rõ vào agent. Trang chủ có hẳn một use case cho agent, MCP và các AI pipeline vẫn chạy tiếp được khi gặp lỗi. Thông cáo gọi vốn tháng 2/2026 đặt agentic AI ngay trong tiêu đề.

Phục hồi bằng cách đọc lại lịch sử

Temporal không chụp snapshot bộ nhớ. Mọi thứ xảy ra trong một Workflow được ghi vào Event History, một log có thứ tự mà tài liệu coi là bản ghi gốc của mọi việc diễn ra trong Workflow. Khi worker mới nhận việc, nó replay lại log này để dựng lại trạng thái.

Áp vào ví dụ 200 đơn: mỗi lần gọi LLM và mỗi lần ghi ERP là một Activity. Kết quả của 119 đơn đầu đã nằm trong Event History. Worker mới replay, thấy 119 bước đã có kết quả nên không gọi lại, rồi chạy tiếp từ đơn 120.

Lời gọi ERP bị treo ở đơn 120 được retry tự động theo Retry Policy. Lời khuyên ở đây là đừng để policy chạy theo mặc định mà không xem lại: hãy kiểm tra và đặt rõ số lần thử tối đa cùng các mức timeout sao cho hợp với sức chịu của hệ thống bên khách.

Cơ chế replay đi kèm một kỷ luật mà người mới hay vấp phải.

Ranh giới giữa Workflow và Activity

Vì Workflow được replay nên code Workflow phải deterministic: với cùng một lịch sử, nó phải đưa ra cùng các quyết định. Một lời gọi LLM cho cùng prompt có thể trả về câu trả lời khác ở lần sau, nên nó không được nằm trực tiếp trong Workflow. Gọi LLM, gọi tool, gọi API của khách đều phải đặt trong Activity.

	Workflow	Activity
Chứa gì	Logic điều phối: thứ tự bước, rẽ nhánh, vòng lặp agent	Việc dễ lỗi: gọi LLM, tool, ERP, gửi email
Yêu cầu	Deterministic, vì sẽ được replay	Nên idempotent, vì sẽ được retry
Khi lỗi	Worker khác replay Event History rồi chạy tiếp	Retry tự động theo Retry Policy
Lỗi hay gặp	Gọi LLM hoặc lấy giờ hệ thống ngay trong Workflow	Ghi trùng bản ghi khi retry

Cột bên phải là nơi FDE phải tự làm phần việc của mình. Temporal khuyến nghị Activity nên idempotent, tức chạy hai lần không sinh ra hai tác dụng phụ.

Thử đi một trường hợp cụ thể. Activity ghi đơn thứ 120 vào ERP, ERP thực ra đã lưu xong nhưng phản hồi không kịp về, nên Activity bị coi là lỗi và được retry. Nếu Activity chỉ biết “tạo bản ghi mới”, ERP giờ có hai dòng cho cùng một đơn.

Cách chữa là ghi kèm một khóa duy nhất lấy từ mã đơn. Lần retry gửi lại đúng khóa đó, ERP nhận ra bản ghi đã tồn tại và chỉ cập nhật, nên sau bao nhiêu lần retry vẫn chỉ có một dòng. Temporal lo việc retry, còn việc retry có an toàn hay không thì vẫn là trách nhiệm của bạn.

Khi nào nên dùng, khi nào chưa cần?

Temporal đáng dùng khi agent chạy nhiều bước, chạy lâu, và đụng vào hệ thống mà bạn không kiểm soát. Đó gần như là mô tả công việc của một FDE: pipeline đọc chứng từ cả đêm, agent chờ người duyệt rồi mới chạy tiếp, vòng lặp tool calling gọi vào API nội bộ chập chờn của khách.

Với một chatbot trả lời một lượt rồi thôi, thêm Temporal là thêm một nền tảng phải vận hành mà gần như không được gì. Cái giá thật nằm ở kỷ luật deterministic. Một đội quen viết agent như một script dài sẽ phải tách lại code, và lỗi non-determinism thường chỉ lộ ra đúng lúc replay, tức là lúc đang có sự cố.

Ở những site khách chạy on-prem, phép tính càng phải cân kỹ. Nếu Temporal Service đặt trong hạ tầng của khách, ai đó bên họ phải trực và vận hành thêm một hệ thống nữa sau khi bạn rời đi. Với một pipeline vài bước chạy trong vài phút, một bảng trạng thái đơn giản cộng retry thủ công có thể là lựa chọn dễ bàn giao hơn.

Học gì trước để dùng được ở site khách?

Đừng bắt đầu bằng việc cài cluster. Hãy nắm bốn khái niệm theo thứ tự: Workflow, Activity, Event History, Retry Policy. Điểm khởi đầu tốt là AI Cookbook chính thức của Temporal.

Trong đó có một recipe dựng agent trên OpenAI Agents SDK, chạy được qua sự cố và tự chọn tool để trả lời câu hỏi của người dùng. Bên cạnh là một recipe khác cho agentic loop có tool calling.

Một bài tập đáng làm: lấy recipe đó, thêm một Activity ghi kết quả vào một bảng giả lập ERP, rồi tắt worker giữa chừng và bật lại. Sau đó đếm số dòng trong bảng. Nếu thấy dòng trùng, bạn vừa tự phát hiện vì sao khóa idempotency phải có từ ngày đầu.

Khi đọc JD của các vị trí FDE hoặc AI engineer, hãy để ý những cụm như “durable execution”, “long-running agents” hay tên Temporal. Trên CV, một dòng như “agent đối soát nhiều bước tự phục hồi khi worker sập, Activity idempotent theo mã đơn” có sức nặng hơn nhiều so với dòng ghi “có kinh nghiệm LLM”.

Ở site khách, câu hỏi đầu tiên không phải là model nào thông minh nhất. Câu hỏi đầu tiên là khi ERP của họ sập lúc 2 giờ sáng, agent của bạn sẽ làm gì.