Tác tử chạy bền vững: lưu bước, tiếp tục và chống làm hai lần

Đăng ngày 27/10/2026

Chạy tiếp phải biết việc nào đã thật sự xảy ra

Tác tử chạy bền vững cần giữ được trạng thái công việc khi tiến trình mất kết nối, máy chạy lại hoặc phải chờ người xử lý. Nhưng lưu cuộc hội thoại chưa đủ để biết một hồ sơ đã được tạo ở hệ thống khác hay chưa. Nếu lời gọi đã thành công mà phản hồi bị mất, tác tử có thể tưởng chưa làm và tạo thêm lần nữa. Câu hỏi thiết kế quan trọng là bằng chứng nào cho phép tiếp tục, thử lại, dừng hoặc bàn giao.

Tài liệu persistence của LangGraph phân biệt điểm lưu trạng thái theo luồng chạy với kho thông tin dùng qua nhiều luồng; nó cũng lưu ý bộ lưu trong bộ nhớ mất dữ liệu khi tiến trình khởi động lại [1]. Tên có chữ lưu không bảo đảm dữ liệu còn sau sự cố. Khi chọn một cơ chế, cần xác định phần nào được ghi bền, lúc nào ghi và cách kiểm lại sau khi mất tiến trình. Đừng lấy việc tiếp tục được trong cùng cửa sổ trình duyệt làm nghiệm thu khả năng khôi phục.

Bài đề xuất hai công cụ: sổ bước việc có bằng chứng và bảng quyết định cho kết quả chưa rõ. Ví dụ là tác tử thu thập hồ sơ từ nhiều hệ thống nội bộ của một đơn vị Việt Nam, hoàn toàn giả định. Tác tử chỉ gom tài liệu được phép và tạo một gói kiểm nội bộ. Những điểm lưu, phép thử và chỉ số được trình bày là thiết kế cần kiểm, chưa phải một hệ thống đã triển khai hay một cam kết không bao giờ mất việc.

Định danh công việc khác với định danh lần chạy

Một yêu cầu nghiệp vụ có thể trải qua nhiều lần chạy do mất mạng, đổi máy xử lý hoặc chờ bổ sung. Nếu mỗi lần khởi động tạo một mã công việc mới, hệ thống khó nhận ra nó đang tiếp tục cùng yêu cầu. Ngược lại, dùng một mã cho mọi việc của một người cũng làm các yêu cầu khác nhau nhập vào nhau. Nên phân biệt mã yêu cầu nghiệp vụ, mã bước có tác dụng và mã từng lần thử; mỗi loại trả lời một câu hỏi khác nhau.

Mã yêu cầu giúp tìm toàn bộ tiến triển của cùng việc. Mã bước gắn với một hành động cụ thể như tạo gói kiểm cho bộ tài liệu đã chốt. Mã lần thử phục vụ điều tra khi lời gọi được thực hiện lại. Trong sổ, nhiều lần thử có thể thuộc cùng một bước mà không trở thành nhiều hồ sơ mới. Các mã cần được tạo và giữ bởi ứng dụng đáng tin; không dựa vào việc mô hình nhớ lại một chuỗi từ hội thoại để tự quyết đâu là yêu cầu cũ.

Định danh còn cần gắn với đơn vị, người giao việc và phiên bản dữ liệu phù hợp. Hai phòng ban có thể dùng cùng tên hồ sơ nhưng không được nhìn tài liệu của nhau. Một yêu cầu bổ sung tài liệu thật sự có thể là bản mới của gói, không phải thử lại bản cũ. Đội nghiệp vụ và tích hợp phải chốt quy tắc phân biệt ấy. Đừng dùng tên tệp, tiêu đề hoặc thời điểm gần nhau làm dấu duy nhất để suy hai hành động có cùng ý định.

Tách ý định thực hiện khỏi bằng chứng hoàn thành

Tài liệu Activity Definition của Temporal nêu rõ hoạt động đã hoàn tất được ghi nhận sẽ không chạy lại trong việc phát lại luồng. Tuy nhiên, nếu máy xử lý đã làm xong mà chưa báo được kết quả tới dịch vụ, hoạt động có thể bị thử lại; tính chống tác dụng lặp vẫn cần được thiết kế tại dịch vụ được gọi [2]. Vì vậy, bộ máy điều phối biết bước đã được giao không đồng nghĩa nó biết chắc thay đổi bên ngoài đã hoàn thành.

Sổ bước việc cần phân biệt dự định gửi, đã gửi lời gọi, đã nhận bằng chứng kết quả và đã đối chiếu được tác dụng. Những trạng thái này không nhất thiết phải là nhiều nút cho người dùng, nhưng bên vận hành phải truy được. Nếu chỉ có đang chạy và đã xong, phần mơ hồ sau mất mạng dễ bị ép vào một kết luận sai. Câu trả lời đúng cho người dùng đôi khi là chưa xác minh được trạng thái, kèm bước kiểm hoặc người tiếp nhận tiếp theo.

Một biên nhận cũng có phạm vi. Nó có thể chứng minh dịch vụ đã nhận yêu cầu, đã xếp hàng hoặc đã tạo đối tượng; ba điều ấy khác nhau. Công cụ cần trả về nghĩa đủ rõ để tác tử không nói đã hoàn tất khi mới nhận mã chờ. Nếu cần kết quả cuối, phải có đường tra trạng thái thích hợp. Giữ liên kết giữa mã yêu cầu và biên nhận giúp người vận hành đối chiếu mà không phải đọc lại toàn bộ hội thoại và đoán từ lời kể của mô hình.

Thiết kế hành động chống tác dụng lặp

RFC 9110 phân biệt phương thức có tính idempotent theo tác dụng được yêu cầu với phương thức chỉ đọc; nó cũng nêu giới hạn thử lại tự động khi chưa biết ngữ nghĩa lời gọi có chống lặp hay chưa [3]. Trong tác tử, điều này nhắc rằng gọi cùng tên hàm hai lần không mặc nhiên an toàn. Một thao tác tạo hồ sơ có thể cần hợp đồng riêng để nhận ra cùng yêu cầu, còn một thao tác xóa dù lặp không đổi thêm vẫn có thể gây hậu quả lớn.

Bài kỹ thuật Making retries safe with idempotent APIs của Amazon mô tả cách dùng định danh do bên gọi cung cấp để thể hiện ý định. Nó bàn cả trường hợp cùng mã nhưng tham số khác và việc phải giữ kiến thức về yêu cầu cũ trong một khoảng phù hợp [4]. Đây là kinh nghiệm kỹ thuật của nhà cung cấp, không phải bảo đảm mọi API đều hỗ trợ. Trước khi dùng, cần đọc hợp đồng của dịch vụ cụ thể và kiểm cách nó xử lý mã trùng, nội dung khác hoặc yêu cầu đến muộn.

Với bước tạo gói kiểm, ứng dụng có thể giữ một mã thao tác ổn định cho cùng ý định đã chốt và truyền nó theo cơ chế dịch vụ dưới hỗ trợ. Thử lại sau lỗi giao tiếp vẫn dùng cùng mã, không tạo mã mới để né thông báo đã tồn tại. Nhưng nếu bộ tài liệu hoặc người nhận thay đổi có ý nghĩa, không được âm thầm coi đó là bản thử lại giống trước. Cần xử lý đổi phiên bản và quyết định cho phép theo quy tắc của công việc.

Chỉ ghi một mã vào nhật ký bên gọi chưa làm dịch vụ dưới chống trùng. Hai tiến trình cùng thấy chưa có kết quả rồi cùng tạo hồ sơ vẫn có thể vượt qua một phép kiểm rời rạc. Cần xác minh cơ chế chống lặp được thực thi ở đâu, liên kết với bước ghi thế nào và xử lý cạnh tranh ra sao. Nếu tích hợp không cung cấp khả năng cần thiết, giữ hành động ghi ở phạm vi nhỏ hoặc bàn giao người vận hành khi trạng thái chưa rõ, thay vì hứa có cơ chế làm đúng một lần.

Công cụ một: sổ bước việc có bằng chứng

Sổ được đề xuất có sáu phần: mã yêu cầu, mã bước, phiên bản đầu vào, trạng thái hiện biết, bằng chứng và người tiếp nhận ngoại lệ. Một dòng chỉ được coi hoàn thành khi đáp ứng tiêu chí kết quả của bước đó. Với bước đọc tài liệu, bằng chứng có thể là nguồn và phiên bản được đọc. Với bước tạo gói, cần mã đối tượng cùng trạng thái đã kiểm ở nơi giữ gói. Hai bước có loại chứng cứ khác nhau, không nên dùng chung một câu trả lời thành công mơ hồ.

Trong Life beyond Distributed Transactions, Pat Helland bàn về việc ứng dụng cần nhớ thông điệp đã xử lý để lặp lại không tạo thêm thay đổi nghiệp vụ. Đây là bài quan điểm tại CIDR 2007 với những giả định về quy mô và ranh giới giao dịch [5]. Nó giúp thấy vì sao trạng thái chống lặp có ý nghĩa riêng; không phải bằng chứng mọi hệ thống nên bỏ giao dịch phân tán. Sổ đề xuất ở đây vận dụng ý tưởng giữ quan hệ giữa thông điệp, đối tượng và tác dụng, không sao chép toàn bộ kiến trúc trong bài.

Sổ không cần chứa nguyên bản mọi tài liệu. Có thể giữ mã tham chiếu, phiên bản hoặc dấu kiểm đủ để mở lại nguồn theo quyền phù hợp. Nếu chép cả hồ sơ nhạy cảm vào lịch sử luồng chạy, nơi lưu trạng thái trở thành một kho dữ liệu mới cần quản lý quyền và vòng đời. Người thiết kế phải biết thông tin nào được giữ, ai có thể đọc và khi nào có thể xóa theo chính sách áp dụng. Khả năng khôi phục không phải lý do để lưu vô hạn mọi đầu vào.

Cũng cần tách sổ nghiệp vụ khỏi ghi chú suy luận của mô hình. Một đoạn tác tử tự tóm tắt rằng đã thu đủ hồ sơ không thay danh mục các tài liệu được kiểm. Khi phục hồi, ứng dụng lấy trạng thái đáng tin từ sổ và dịch vụ nguồn rồi mới đưa phần cần thiết vào ngữ cảnh. Mô hình có thể giúp chọn bước tiếp theo trong phạm vi, nhưng không nên được tự viết lại lịch sử hoàn thành để làm kế hoạch hiện tại có vẻ liền mạch.

Công cụ hai: bảng quyết định khi kết quả chưa rõ

Bảng đề xuất phân loại theo bằng chứng, không theo mức tự tin của tác tử. Nếu xác minh thao tác chưa được áp dụng và còn quyền, có thể thử theo hợp đồng. Nếu đã thấy kết quả đúng của cùng mã bước, ghi nhận và tiếp tục. Nếu có trạng thái đang xử lý, chờ hoặc tra theo chính sách đã chốt. Nếu không phân biệt được đã ghi hay chưa, giữ chưa rõ và chuyển đường đối chiếu hoặc người vận hành; không tự biến timeout thành thất bại chắc chắn.

Mỗi nhánh cần có giới hạn thời gian, số lần tra và người tiếp nhận do đội vận hành xác định. Tiếp tục hỏi trạng thái quá nhanh có thể làm dịch vụ đang lỗi chịu thêm tải; chờ mãi lại làm người dùng không biết việc của mình ở đâu. Giới hạn nên dựa trên hợp đồng dịch vụ và hậu quả của công việc, không phải một con số chung trong bài. Khi hết khả năng tự kiểm, bàn giao đủ mã và bằng chứng đã có, tránh khởi động một yêu cầu mới trùng ý định.

Mẫu transactional outbox trong hướng dẫn AWS xử lý vấn đề ghi cơ sở dữ liệu và gửi sự kiện như hai việc có thể lệch nhau. Tài liệu vẫn lưu ý thông điệp có thể lặp và bên nhận cần xử lý phù hợp [6]. Mẫu này có thể hỗ trợ đường gửi nội bộ khi kiến trúc đáp ứng điều kiện, nhưng không tự làm mọi tác dụng ở dịch vụ ngoài chỉ xảy ra một lần. Cần kiểm cả nơi phát, nơi nhận và trạng thái đối tượng cuối, thay vì chỉ thấy sự kiện đã rời hàng đợi.

Khôi phục phải kiểm dữ liệu và quyền hiện hành

Điểm lưu mô tả tiến triển đã biết ở một thời điểm, không giữ nguyên hiệu lực của mọi quyền và mọi dữ liệu. Trong lúc tác tử dừng, người giao có thể rời nhóm, tài liệu bị thay hoặc hồ sơ chuyển trạng thái. Trước hành động tiếp theo, cần kiểm điều kiện còn phù hợp với công việc được giao. Một bản lưu có chứa token hoặc quyền cũ không phải căn cứ cho phép bỏ qua kiểm quyền ở dịch vụ tài nguyên.

Cũng cần phân biệt phát lại để phục hồi lịch sử với chạy lại mô hình trên đầu vào mới. Nếu mô hình tạo một quyết định khác sau lần khởi động, ứng dụng phải biết đó là kế hoạch mới hay chỉ cách diễn đạt lại. Phần kết quả đã được ghi đáng tin không nên bị tính lại rồi ghi đè tùy tiện. Đội tích hợp cần chọn ranh giới bước rõ để dữ liệu không xác định, lời gọi mô hình và thao tác có tác dụng được quản lý đúng theo cơ chế lưu của khung đang dùng.

Khi đổi mã chương trình hoặc cấu trúc trạng thái, các công việc đang chờ vẫn cần đường xử lý. Có thể giữ bản xử lý tương thích, chuyển đổi có kiểm hoặc dừng bàn giao những việc chưa hỗ trợ; lựa chọn phụ thuộc kiến trúc và hậu quả. Không coi việc phiên bản mới chạy tốt với yêu cầu mới là bằng chứng nó khôi phục được bản cũ. Bộ thử phải có trạng thái lưu trước thay đổi và kiểm tiếp tới kết quả nghiệp vụ cần thiết.

Giữ khả năng dừng và bù trừ có kiểm soát

Tài liệu Activity Execution của Temporal phân biệt yêu cầu hủy với cách hoạt động nhận và xử lý hủy; nó nêu điều kiện heartbeat và khả năng ứng dụng chấp nhận hoặc bỏ qua yêu cầu ấy [7]. Điều này cho thấy một nút dừng trên giao diện chưa chứng minh mọi tiến trình ngoài đã ngừng. Cần biết yêu cầu đi tới đâu, bước nào có thể còn chạy và ai kiểm các tác dụng đã xảy ra. Cơ chế cụ thể phải được thử theo SDK và cấu hình đang sử dụng.

Bài Sagas của Garcia-Molina và Salem mô tả chuỗi giao dịch cùng giao dịch bù trừ cho phần đã thực hiện. Phần bàn về bù trừ cũng cho thấy xử lý hậu quả không luôn giống xóa sạch lịch sử: có hành động không thể đảo ngược nguyên trạng [8]. Trong tác tử, không nên coi khôi phục điểm lưu cũ là hoàn tác mọi thay đổi bên ngoài. Muốn hủy gói, gỡ một chia sẻ hoặc gửi thông báo sửa, cần một hành động nghiệp vụ được phép riêng và bằng chứng nó đã thực hiện.

Quy trình dừng cần chốt việc nào ngăn ngay, việc nào chờ kết quả để đối chiếu và việc nào cần người quyết phương án xử lý. Nếu chỉ dừng bộ điều phối trong khi lời gọi đang chạy ở dịch vụ khác, trạng thái có thể tiếp tục thay đổi. Sau dừng, giữ sổ và mã đối tượng để kiểm lại. Không dùng khóa đã bị thu hồi để tự bù trừ và không báo đã hoàn tác khi mới phát ra yêu cầu hủy chưa được nơi nhận xác nhận.

Tình huống giả định: gom một gói hồ sơ nội bộ

Giả sử một đơn vị dịch vụ tại Việt Nam cần gom tài liệu được phép từ hệ thống nhân sự, kho tài liệu và ứng dụng quản lý công việc để chuẩn bị một gói kiểm nội bộ. Tác tử không sửa hồ sơ nguồn và không gửi gói ra ngoài. Mỗi nguồn có thời điểm cập nhật khác nhau; một người phụ trách xác định danh mục cần đủ và nhóm được xem gói. Ví dụ không khẳng định một đơn vị thật đã dùng hệ thống hoặc việc gom tài liệu có căn cứ pháp lý cụ thể.

Lần chạy đầu đọc được hai nguồn, còn nguồn thứ ba chưa sẵn sàng. Sổ giữ phần đã đọc với phiên bản và ghi rõ phần thiếu, thay vì tạo gói có vẻ đầy đủ. Khi tiếp tục, tác tử kiểm các phiên bản còn dùng được và quyền đọc vẫn còn. Nếu nguồn đã thay tài liệu có ý nghĩa với gói, tạo lại phần tổng hợp cần thiết theo quy tắc. Không tự lấy một bản từ thư mục khác ngoài quyền chỉ vì tên tài liệu giống phần đang thiếu.

Sau khi đủ điều kiện, tác tử yêu cầu tạo gói ở hệ thống quản lý công việc. Hệ thống đã tạo nhưng phản hồi bị mất trước khi bộ điều phối ghi hoàn thành. Lần phục hồi phải tra theo mã thao tác hoặc cơ chế dịch vụ hỗ trợ, xác minh gói nào thuộc yêu cầu này rồi mới đi tiếp. Nếu chỉ tìm theo tiêu đề chung, có thể nhận nhầm gói của một yêu cầu khác. Nếu không có đường tra đủ chắc, bàn giao phần chưa rõ để người có quyền đối chiếu.

Trong nhánh dừng, người phụ trách rút yêu cầu khi gói đã tạo nhưng chưa chia sẻ. Tác tử ngừng bước chia sẻ và giữ bằng chứng trạng thái, còn quyết định xóa hay lưu gói theo quy trình đơn vị là việc riêng. Nếu thao tác chia sẻ đã được gửi đi, cần kiểm nơi nhận trước khi nói chưa ai có quyền xem. Sổ bước giúp thấy ranh giới ấy và tránh dùng từ dừng như thể mọi thay đổi trước đó đều chưa từng xảy ra.

Điều kiện vận hành và phép thử trước khi mở rộng

Đội nhỏ có thể giới hạn ở đọc nguồn và lưu nháp để giảm tác dụng cần khôi phục. Khi mở tạo đối tượng ở nhiều hệ thống, phải có người giữ tích hợp, cơ chế lưu bền và cách đối chiếu kết quả từng nơi. Đơn vị lớn cần thêm phân tách quyền, quản lý phiên bản trạng thái và trực xử lý việc chưa rõ. Không nên tăng số hệ thống chỉ vì tác tử đã thu thập trơn tru trong một lượt trình diễn không có lỗi.

Bộ thử đề xuất cắt tiến trình ở các ranh giới: trước gửi lời gọi, sau nơi nhận ghi nhưng trước phản hồi, và sau phản hồi nhưng trước lưu bước hoàn thành. Kiểm cùng một ý định sau phục hồi có tạo thêm đối tượng hay không. Thử hai tiến trình cùng tiếp tục một yêu cầu, thông điệp đến muộn, cùng mã nhưng tham số đổi và yêu cầu dừng khi bước ngoài vẫn chạy. Tất cả dùng môi trường cùng dữ liệu thử được phép; bài không khẳng định đã thực hiện các phép thử này.

Báo cáo cần tách tỷ lệ gói đúng và đủ theo bộ kiểm, số tác dụng trùng, số trường hợp chưa rõ, thời gian người vận hành đối chiếu và phần việc được khôi phục tới đích. Mẫu số phải nói gồm loại sự cố nào; thành công trên lỗi trước gửi không đại diện lỗi sau ghi. Dừng mở rộng khi có bản trùng chưa giải thích, tiến trình báo hoàn thành thiếu bằng chứng hoặc người vận hành không tìm được đối tượng thật từ mã yêu cầu.

Hỏi đáp về tác tử chạy bền vững

Có điểm lưu thì có bảo đảm không làm hai lần không? Không thể kết luận như vậy chỉ từ tên chức năng. Cần xem bước nào đã được lưu hoàn tất, thao tác ngoài có thể đã xảy ra trước khi mất tiến trình hay không, và dịch vụ nhận có hỗ trợ chống lặp không. Kiểm cả đường lỗi sau khi nơi nhận ghi thành công. Lưu trạng thái giúp phục hồi điều phối, còn tác dụng ngoài cần hợp đồng và bằng chứng tương ứng.

Tại sao không tạo mã mới mỗi lần thử lại cho đơn giản? Mã mới có thể khiến dịch vụ coi đó là một ý định mới và tạo thêm đối tượng. Với cùng thao tác được thử lại theo hợp đồng, cần giữ định danh phù hợp. Tuy nhiên, không dùng cùng mã cho nội dung đã đổi có ý nghĩa hoặc hai yêu cầu độc lập. Đơn vị phải xác định ranh giới ý định, phiên bản và cách xử lý tham số khác trước khi tự động hóa thử lại.

Có nên cho tác tử tự giải quyết mọi trạng thái chưa rõ không? Chỉ khi nó có đường tra đủ căn cứ và được phép thực hiện bước tiếp. Nếu không phân biệt được hồ sơ đã tạo hay chưa, thử thêm có thể làm hậu quả tăng. Giữ trạng thái chưa rõ, giới hạn tự kiểm và chuyển người vận hành cùng mã, thời điểm, kết quả đã có. Bàn giao tốt là một kết quả vận hành hợp lệ, không phải lý do để tác tử tự mở rộng quyền.

Khôi phục bản lưu trước có hủy việc đã gửi không? Không. Bản lưu thuộc bộ điều phối, còn tài liệu, đối tượng hoặc thông báo ở hệ thống khác có vòng đời riêng. Cần kiểm tác dụng đã xảy ra rồi xử lý bằng thao tác bù trừ hoặc quy trình được phép. Có việc chỉ sửa được bằng một thay đổi mới, không thể làm như chưa từng xảy ra. Vì vậy, kiểm dừng và xử lý hậu quả phải đi cùng kiểm tiếp tục.

Nguồn, phương pháp và giới hạn suy luận

Bài có hỗ trợ AI, dựa trên tám nguồn gốc đã đọc ngày 27/10/2026, gồm tiêu chuẩn HTTP, nghiên cứu hệ thống phân tán và tài liệu chính thức của khung điều phối cùng nhà cung cấp. Hồ sơ nguồn ghi phần đọc, bản tài liệu và giới hạn; nguồn thương mại chỉ hỗ trợ hiểu cơ chế. Sổ bước, bảng quyết định, ca gom hồ sơ và phép thử là tổng hợp biên tập giả định, chưa triển khai hoặc đo thực địa, không bảo đảm một kiến trúc cụ thể đạt khả năng khôi phục hay đáp ứng pháp lý.