Một vòng lặp ẩn giấu một quyết định bên trong một hộp đen: điều gì sẽ chạy tiếp theo.
Mỗi khi vòng lặp của một tác nhân quyết định có nên thử lại, leo thang hay tiếp tục, quyết định đó diễn ra bên trong suy luận của chính mô hình, vô hình với bạn, không thể kiểm toán sau khi thực tế, và không thể kiểm tra nếu không đọc lại đầu ra thô của mô hình và hy vọng nó đã giải thích một cách trung thực. Một đồ thị (graph) làm cho cùng một quyết định đó trở nên rõ ràng. Được viết ra. Có thể kiểm tra trước khi quá trình chạy thậm chí bắt đầu.
Đây không phải là một sự khác biệt nhỏ. Đó là lập luận thực tế đằng sau một bài báo arXiv thực sự được xuất bản vào tháng 4 năm 2026, đã định hình lại cách các hệ thống tác nhân nên được xây dựng, và đáng để nói thẳng về một điều trước khi khóa học này đi xa hơn. Bản thân tác giả của bài báo đã bao gồm một tuyên bố từ chối trách nhiệm công bằng, nói rõ rằng đây là một thiết kế chưa được triển khai, và liệu nó có mang lại những lợi ích đã hứa trong thực tế hay không vẫn là một câu hỏi thực nghiệm mở. Khóa học này giảng dạy khuôn khổ một cách trung thực, bao gồm cả lưu ý đó, bởi vì hiểu một đề xuất thực tế, được lập luận chặt chẽ nhưng chưa được chứng minh ở quy mô lớn, hữu ích hơn là giả vờ rằng đó là sự thật đã được xác lập.
Vào cuối khóa học này, bạn sẽ hiểu kỹ thuật đồ thị thực sự là gì, tại sao nó tồn tại như một lớp trên các vòng lặp, ba cam kết mà mọi đồ thị trong khuôn khổ này dựa trên, và cách xây dựng đồ thị đầu tiên của bạn, cùng với một báo cáo trung thực về nơi bằng chứng hiện đang đứng và không đứng.
Tại Sao Vòng Lặp Có Một Giới Hạn
Để hiểu tại sao đồ thị tồn tại, bạn cần hiểu chính xác nơi các vòng lặp không còn đủ nữa.
Một vòng lặp, theo nghĩa tác nhân có liên quan ở đây, là một chu trình nơi một tác nhân cố gắng thực hiện một nhiệm vụ, quan sát kết quả và quyết định làm gì tiếp theo, lặp lại cho đến khi một số điều kiện được đáp ứng. Điều này hoạt động rất tốt cho một loạt các nhiệm vụ. Tuy nhiên, về mặt cấu trúc, nó là một hộp đen tại chính xác thời điểm quan trọng nhất: quyết định về điều gì xảy ra tiếp theo.
Khi tác nhân của vòng lặp quyết định thử lại một bước thất bại, quyết định đó đến từ việc mô hình suy luận trên ngữ cảnh của chính nó và đưa ra một lựa chọn. Bạn không thể kiểm tra quyết định trước khi nó xảy ra. Bạn chỉ có thể quan sát kết quả sau đó. Nếu tác nhân thử lại cùng một cách tiếp cận thất bại năm lần liên tiếp, tốn chi phí mỗi lần, không có gì trong cấu trúc của vòng lặp ngăn chặn điều đó, bởi vì quyết định thử lại hoàn toàn nằm trong phán đoán của chính mô hình, không phải trong bất kỳ quy tắc bên ngoài nào có thể kiểm tra được.
Điều này ổn cho các nhiệm vụ rủi ro thấp, chi phí thấp, nơi một lần thử lại lãng phí thỉnh thoảng không tốn kém gì đáng kể. Nó trở thành một trách nhiệm thực sự cho các công việc dài hạn, đắt đỏ hoặc rủi ro cao, chính xác là loại nhiệm vụ mà các hệ thống tác nhân ngày càng được tin tưởng giao phó. Lập luận cốt lõi của bài báo là khi các hệ thống tác nhân đảm nhận nhiều công việc hệ trọng hơn, sự mờ đục của "cái gì chạy tiếp theo" không còn là một hộp đen có thể chấp nhận được nữa và bắt đầu trở thành điểm thất bại thực sự đáng để kỹ thuật hóa trực tiếp.
Đồ Thị Thực Sự Là Gì
Một đồ thị, trong khuôn khổ này, thay thế quyết định bước tiếp theo ngầm của mô hình bằng một cấu trúc rõ ràng được xác định trước khi quá trình chạy bắt đầu.
Thay vì một tác nhân suy luận theo cách của nó đến "tôi nên thử lại" hoặc "tôi nên leo thang" bên trong một cửa sổ ngữ cảnh mờ đục, đồ thị xác định, trước, chính xác trạng thái nào tồn tại, chuyển tiếp nào giữa các trạng thái là hợp lệ và điều kiện cụ thể nào kích hoạt mỗi chuyển tiếp. Tác nhân vẫn thực hiện công việc thực tế bên trong mỗi trạng thái. Nhưng nó không còn quyết định một cách vô hình về hình dạng tổng thể của quá trình khi nó tiến hành.
Cấu trúc năm bước mô tả bất kỳ lượt đơn nào thông qua một đồ thị như thế này: Lập kế hoạch, Thực thi, Phục hồi, Leo thang, Lặp lại. Lập kế hoạch là nơi nhiệm vụ được phân rã thành một chuỗi xác định. Thực thi là nơi tác nhân thực sự làm công việc cho bước hiện tại. Phục hồi là những gì xảy ra khi thực thi thất bại, theo một giao thức xác định thay vì một lần thử lại ngẫu hứng. Leo thang là điểm rõ ràng, được xác định nơi đồ thị giao quyền kiểm soát cho con người thay vì tiếp tục cố gắng phục hồi tự động. Lặp lại đóng chu kỳ, chuyển sang bước tiếp theo trong kế hoạch.
Hãy chú ý những gì đã thay đổi so với một vòng lặp. Mỗi một trong năm bước này bây giờ là một trạng thái được đặt tên, có thể kiểm tra trong một đồ thị, với các chuyển tiếp được xác định giữa chúng, thay vì một quyết định diễn ra âm thầm bên trong một lời gọi mô hình duy nhất.
Ba Cam Kết
Mọi đồ thị trong khuôn khổ này đều dựa trên ba cam kết cụ thể. Hiểu sâu sắc ba cam kết này là cốt lõi thực sự của kỹ thuật đồ thị như một môn học, hơn bất kỳ chi tiết triển khai cụ thể nào.
Cam kết Một: Kế hoạch Bất biến
Kế hoạch thực thi không thể thay đổi giữa chừng. Một khi một kế hoạch được tạo ra và khóa lại, nó tồn tại như một phiên bản cố định trong suốt thời gian chạy đó. Tác nhân không thể âm thầm sửa đổi kế hoạch của chính nó giữa chừng dựa trên điều gì đó nó nhận thấy, như cách một tác nhân bên trong một vòng lặp thường làm mà không có bất kỳ ghi chép bên ngoài nào về việc sửa đổi đang diễn ra.
Điều này nghe có vẻ hạn chế, và nó có chủ đích như vậy. Sự hạn chế là toàn bộ ý nghĩa. Một tác nhân có thể tự do sửa đổi kế hoạch của chính nó giữa chừng chính xác là tác nhân mà hành vi của nó trở nên không thể kiểm toán sau khi thực tế, bởi vì kế hoạch bạn sẽ xem xét sau đó không phải là kế hoạch thực sự được tuân theo, nó là bất cứ thứ gì kế hoạch đã trôi dạt đến vào cuối cùng. Khóa kế hoạch đánh đổi sự linh hoạt thực sự để lấy khả năng kiểm tra thực sự. Sự đánh đổi đó không phải là miễn phí, và đáng để suy ngẫm một cách trung thực thay vì coi nó như một sự cải tiến nghiêm ngặt trong mọi trường hợp. Một tình huống thực sự mới lạ mà kế hoạch ban đầu không lường trước được sẽ được xử lý tệ hơn bởi một kế hoạch bất biến so với một vòng lặp có thể thích ứng tự do. Cam kết là một cược có chủ ý rằng, đối với loại nhiệm vụ mà khuôn khổ này nhắm đến, khả năng dự đoán và kiểm toán được đánh giá cao hơn khả năng thích ứng tối đa.
Cam kết Hai: Các Lớp Riêng Biệt
Lập kế hoạch, thực thi và phục hồi sống trong ba lớp độc lập thay vì một vòng lặp rối rắm nơi cả ba xảy ra bên trong cùng một quá trình suy luận liên tục.
Lớp lập kế hoạch tạo ra kế hoạch bất biến từ cam kết một và không làm gì khác, nó không thực thi các bước và không xử lý thất bại. Lớp thực thi chạy các bước đã xác định và báo cáo kết quả, nó không quyết định điều gì xảy ra khi thất bại, chỉ quyết định điều gì đã xảy ra. Lớp phục hồi nhận báo cáo thất bại và áp dụng một giao thức xác định, nó không trực tiếp thực thi công việc mới, chỉ quyết định cách phản ứng với những gì đã xảy ra.
Sự tách biệt này phản ánh, một cách có chủ ý, cùng một nguyên tắc đằng sau việc tách một Người xây dựng khỏi một Người đánh giá trong một vòng lặp xác minh, một vai trò tạo ra công việc không nên là cùng một vai trò đánh giá hoặc quyết định về công việc đó, bởi vì việc hợp nhất cả hai làm xói mòn tính độc lập làm cho việc kiểm tra có ý nghĩa ngay từ đầu. Ở đây, sự tách biệt là ba lần thay vì hai lần, nhưng lý luận cơ bản là giống hệt nhau: một hệ thống lập kế hoạch, thực thi và phục hồi tất cả bên trong một quá trình không phân biệt không thể kiểm toán một cách có ý nghĩa bất kỳ một trong các chức năng đó một cách độc lập, bởi vì chúng không bao giờ thực sự khác biệt trong dấu vết bạn sẽ xem xét sau đó.
Cam kết Ba: Leo thang Nghiêm ngặt
Phục hồi tuân theo một giao thức cố định thay vì thử lại vô thời hạn và hy vọng điều gì đó cuối cùng sẽ hoạt động.
Đây là cam kết giải quyết trực tiếp nhất chế độ thất bại token-blowout gây khó khăn cho các vòng lặp không có điều kiện dừng thực sự. Một giao thức leo thang nghiêm ngặt xác định, trước, chính xác bao nhiêu lần thử phục hồi được phép, chính xác điều gì được coi là một lần thử phục hồi thành công hoặc thất bại, và chính xác điều gì xảy ra ngay khi đạt đến giới hạn đã xác định, trao quyền kiểm soát cho con người, không phải cố gắng thêm một biến thể sáng tạo nào đó trên cùng một cách tiếp cận thất bại.
Phân tích của bài báo trên 70 hệ thống thực tế cho thấy một phần lớn các triển khai Vòng lặp Tác nhân không có giới hạn chính thức nào về các lần thử phục hồi, có nghĩa là hành vi thực tế khi có sự cố xảy ra được xác định bởi bất cứ điều gì mô hình tình cờ quyết định tại thời điểm đó, không phải bởi bất kỳ quy tắc nào mà con người thực sự đã xem xét và phê duyệt trước. Leo thang nghiêm ngặt đóng trực tiếp khoảng cách cụ thể đó.
Xây Dựng Đồ Thị Đầu Tiên Của Bạn
Đây là con đường thực tế để thực sự xây dựng một trong những thứ này, chuyển ba cam kết thành một thứ bạn có thể triển khai thay vì chỉ hiểu về mặt khái niệm.
Bắt đầu bằng cách xác định rõ ràng các trạng thái của bạn, trên giấy, trước khi viết bất kỳ mã hoặc lời nhắc nào. Đối với một nhiệm vụ điển hình, điều này thường trông giống như ít nhất: Lập kế hoạch, Thực thi Bước N, Phục hồi từ Thất bại, Đã leo thang, Hoàn thành. Viết ra, cho mỗi trạng thái, chính xác điều gì xảy ra khi hệ thống ở trong trạng thái đó và chính xác điều kiện nào gây ra chuyển tiếp ra khỏi nó.
Viết bước tạo kế hoạch sao cho đầu ra của nó là một tạo tác cố định, có phiên bản, không phải là một tài liệu sống mà phần còn lại của hệ thống có thể âm thầm chỉnh sửa. Một phiên bản đơn giản, thực tế của điều này là tạo kế hoạch như một danh sách đánh số các bước rời rạc, mỗi bước có một tiêu chí thành công rõ ràng và coi danh sách đó là chỉ đọc trong phần còn lại của quá trình chạy. Bất kỳ nhu cầu thực sự nào để đi chệch khỏi nó sẽ kích hoạt một sự leo thang rõ ràng cho con người, không phải là một sự sửa đổi nội bộ âm thầm.
Xây dựng lớp thực thi sao cho nó chỉ báo cáo kết quả, đạt, không đạt, với chi tiết cụ thể, không bao giờ tự đưa ra quyết định về điều gì xảy ra tiếp theo. Điều này phản ánh chính xác vai trò Người xây dựng từ một vòng lặp xác minh, tạo ra công việc và báo cáo trung thực về nó, mà không đồng thời là vai trò quyết định có nên thử lại hay không.
Xây dựng lớp phục hồi với một giao thức rõ ràng, được đánh số. Cố gắng một cách tiếp cận thay thế cụ thể. Nếu điều đó thất bại, hãy cố gắng một cách tiếp cận khác, cụ thể thứ hai. Nếu điều đó thất bại, hãy leo thang. Giao thức phải đủ cụ thể để một con người đọc nó trước có thể dự đoán chính xác hệ thống sẽ làm gì ở mỗi giai đoạn, thay vì một hướng dẫn mơ hồ như "cố gắng sửa nó một số lần hợp lý."
Kết nối trạng thái leo thang sao cho việc đạt đến nó là một sự kiện thực tế, có thể nhìn thấy, không phải là thứ gì đó được ghi lại một cách lặng lẽ và bị lãng quên. Một con người nên được thông báo, với toàn bộ lịch sử về những gì đã được thử và tại sao mỗi lần thử thất bại, cùng một kỷ luật được khuyến nghị cho các điều kiện dừng trong các vòng lặp xác minh nói chung.
Nơi Khuôn Khổ Này Thực Sự Giúp Ích Và Nơi Nó Không
Trung thực về các giới hạn của kỹ thuật đồ thị hữu ích hơn là coi nó như một bản nâng cấp phổ quát so với các vòng lặp trong mọi tình huống, và bản thân bài báo cũng ủng hộ cách đóng khung có chừng mực hơn này.
Đồ thị thực sự hữu ích cho các nhiệm vụ nơi không gian của những thứ có thể sai sót được hiểu khá rõ trước, nơi khả năng kiểm toán quan trọng hơn khả năng thích ứng tối đa và nơi chi phí của một chu kỳ thử lại vô hạn, không giới hạn sẽ thực sự đắt đỏ, về chi phí tính toán hoặc hậu quả của một kết quả xấu đến với người dùng thực tế hoặc hệ thống thực tế.
Đồ thị là một sự phù hợp tồi tệ hơn cho các nhiệm vụ khám phá, kết thúc mở thực sự, nơi bạn không thể dự đoán một cách có ý nghĩa hình dạng của thất bại trước và nơi giá trị của hệ thống đến từ khả năng ứng biến một phản ứng với điều gì đó không ai lường trước. Khóa một kế hoạch bất biến, cho một nhiệm vụ về cơ bản yêu cầu tái lập kế hoạch thích ứng khi thông tin mới xuất hiện, sẽ đánh đổi chính xác khả năng đã làm cho nhiệm vụ đó đáng để tự động hóa với một tác nhân ngay từ đầu.
Lập trường trung thực, có thể bảo vệ, và là lập trường mà chính tác giả của bài báo đưa ra, là đây là một sự đánh đổi thực sự đáng để hiểu sâu sắc, không phải là một sự thay thế vượt trội nghiêm ngặt cho các vòng lặp trong mọi trường hợp. Sử dụng một vòng lặp khi khả năng thích ứng quan trọng hơn khả năng kiểm toán. Sử dụng một đồ thị khi điều ngược lại là đúng. Hầu hết các hệ thống thực tế được hưởng lợi từ việc có cả hai mẫu có sẵn và lựa chọn có chủ ý giữa chúng theo từng nhiệm vụ, thay vì áp dụng một trong hai như một mặc định vĩnh viễn.
Một Ví Dụ Cụ Thể: Di Chuyển Mã Có Cấu Trúc Đồ Thị
Để làm cho cấu trúc năm bước và ba cam kết trở nên cụ thể, đây là cách chúng áp dụng cho một nhiệm vụ thực tế, phổ biến, di chuyển một mô-đun kế thừa sang phiên bản khuôn khổ mới trên toàn bộ cơ sở mã.
Trạng thái Lập kế hoạch chạy một lần, khi bắt đầu. Nó phân tích mô-đun, xác định mọi tệp cần thay đổi và tạo ra một danh sách cố định, được đánh số các bước di chuyển, mỗi bước có một tiêu chí thành công rõ ràng, ví dụ, bước 4 thành công khi tệp đã cập nhật biên dịch và bộ kiểm thử hiện có cho tệp đó vượt qua mà không sửa đổi. Kế hoạch này bị khóa. Đó là cam kết một, bất biến, trong thực tế.
Trạng thái Thực thi làm việc thông qua các bước của kế hoạch theo thứ tự. Đối với mỗi bước, nó áp dụng thay đổi cụ thể được xác định trong kế hoạch và báo cáo kết quả, đạt hoặc không đạt, với đầu ra trình biên dịch thực tế hoặc kết quả kiểm thử được đính kèm làm bằng chứng, không bao giờ là một tự đánh giá "có vẻ đúng." Đây là lớp thực thi từ cam kết hai, được tách biệt nghiêm ngặt khỏi quyết định về điều gì xảy ra nếu nó thất bại.
Khi một bước thất bại, đồ thị chuyển sang Phục hồi, tuân theo một giao thức xác định thay vì một lần thử lại ngẫu hứng. Lần thử một: áp dụng lại cùng một thay đổi với phạm vi hẹp hơn, cô lập chính xác phần nào của tệp gây ra lỗi biên dịch. Lần thử hai, nếu lần đầu thất bại: dựa vào một mẫu di chuyển thay thế đã được ghi lại cho loại thất bại cụ thể này, được rút ra từ một thư viện nhỏ các bản sửa lỗi đã biết thay vì được phát minh mới mỗi lần. Nếu cả hai lần thử xác định đều thất bại, đồ thị chuyển sang Đã leo thang, đây là cam kết ba, leo thang nghiêm ngặt, không phải là một lần thử ngẫu hứng thứ ba.
Trạng thái Đã leo thang thông báo trực tiếp cho con người, với toàn bộ lịch sử được đính kèm: bước nào thất bại, cả hai lần thử phục hồi đã thử những gì và đầu ra lỗi cụ thể từ mỗi lần. Một con người xem xét thất bại cụ thể này với bối cảnh đầy đủ, thay vì phát hiện ra nhiều ngày sau đó rằng một tác nhân đã âm thầm thử lại cùng một cách tiếp cận hỏng trong một vòng lặp suốt thời gian đó, tốn chi phí mà không có ghi chép về lý do.
Lặp lại đóng chu kỳ cho các bước thành công, chuyển đồ thị đến mục tiếp theo trong kế hoạch bị khóa cho đến khi danh sách cạn kiệt, tại thời điểm đó quá trình chạy đạt đến Hoàn thành.
Hãy chú ý những gì điều này mang lại cho bạn so với nhiệm vụ tương đương được chạy như một vòng lặp không cấu trúc. Mọi quyết định, có nên thử lại hay không, như thế nào và khi nào bỏ cuộc, đều hiển thị trong cấu trúc xác định của đồ thị trước khi quá trình chạy thậm chí bắt đầu, không chỉ có thể khám phá bằng cách đọc qua một bản ghi sau đó và suy luận mô hình chắc hẳn đã nghĩ gì. Một người đánh giá mã, hoặc một kiểm toán viên tuân thủ, có thể nhìn vào định nghĩa của đồ thị một mình và biết chính xác hệ thống có khả năng làm gì trong mọi kịch bản thất bại, mà không bao giờ phải xem nó chạy.
Kỹ Thuật Đồ Thị So Với Kỹ Thuật Vòng Lặp: Khi Nào Nên Sử Dụng Cái Nào
Với cả hai mẫu đều thực tế, được ghi chép và mỗi mẫu có điểm mạnh thực sự, đây là một khuôn khổ quyết định thực tế để lựa chọn giữa chúng cho một nhiệm vụ cụ thể, thay vì coi một trong hai như một mặc định vĩnh viễn.
Sử dụng một vòng lặp khi nhiệm vụ thực sự mang tính khám phá, khi bạn không thể dự đoán trước hình dạng của những gì có thể sai và khi khả năng của mô hình để ứng biến một phản ứng với điều gì đó không lường trước chính xác là khả năng bạn đang dựa vào. Các nhiệm vụ nghiên cứu, gỡ lỗi mở nơi nguyên nhân gốc rễ thực sự không xác định khi bắt đầu và công việc sáng tạo nơi cấu trúc cứng nhắc sẽ tích cực làm hỏng đầu ra, tất cả đều ủng hộ khả năng thích ứng của vòng lặp hơn khả năng kiểm toán của đồ thị.
Sử dụng một đồ thị khi nhiệm vụ được hiểu đủ tốt trước để bạn thực sự có thể liệt kê các chế độ thất bại có khả năng xảy ra, khi chi phí của một chu kỳ thử lại vô hạn, không được kiểm toán sẽ thực sự đắt đỏ và khi một người đánh giá, cho dù đó là nhóm tuân thủ, kiểm toán viên bảo mật, hay đơn giản là tương lai của chính bạn gỡ lỗi một sự cố sản xuất, sẽ cần kiểm tra chính xác những gì hệ thống có khả năng làm mà không cần đọc lại một bản ghi thực thi đầy đủ. Di chuyển, giao dịch tài chính, bất cứ thứ gì liên quan đến dữ liệu được quản lý và công việc tác nhân không giám sát chạy dài nơi một thất bại âm thầm có thể kết hợp trong nhiều giờ trước khi có ai nhận thấy, tất cả đều ủng hộ cấu trúc của đồ thị hơn sự linh hoạt của vòng lặp.
Hai mẫu này không loại trừ lẫn nhau trong một hệ thống lớn hơn duy nhất. Một thiết kế thực tế, phổ biến sử dụng một đồ thị ở cấp độ bên ngoài, cho cấu trúc nhiệm vụ tổng thể và các điều kiện dừng của nó, trong khi cho phép một vòng lặp chạy bên trong một trạng thái Thực thi duy nhất cho nhiệm vụ phụ thực sự mang tính khám phá là tìm ra cách triển khai một bước cụ thể. Điều này mang lại cho bạn khả năng kiểm toán của một đồ thị ở cấp độ nơi nó quan trọng nhất, hình dạng tổng thể của những gì hệ thống có thể làm, trong khi vẫn bảo toàn khả năng thích ứng của vòng lặp ở cấp độ nơi sự ứng biến thực sự thực sự có giá trị, các chi tiết của một phần công việc có giới hạn.
Kiểm Tra Đồ Thị Trước Khi Bạn Tin Tưởng Nó
Trước khi dựa vào một hệ thống có cấu trúc đồ thị cho bất cứ điều gì thực tế, hãy chạy nó qua các bài kiểm tra căng thẳng được thiết kế đặc biệt xung quanh ba cam kết, vì mỗi cam kết có cách riêng để thất bại âm thầm nếu được triển khai cẩu thả.
Để kiểm tra cam kết kế hoạch bất biến, cố tình xây dựng một kịch bản giữa chừng quá trình chạy nơi bước tiếp theo "rõ ràng đúng", nếu hệ thống đang suy luận tự do, sẽ đi chệch khỏi kế hoạch bị khóa. Xác nhận hệ thống thực sự leo thang cho con người thay vì âm thầm thích ứng kế hoạch một mình. Nếu nó thích ứng âm thầm, kế hoạch không bao giờ thực sự bất biến trong thực tế, bất kể mã được cấu trúc như thế nào.
Để kiểm tra cam kết các lớp riêng biệt, kiểm tra xem các báo cáo thất bại của lớp thực thi có chứa bất kỳ dấu vết nào của quyết định về điều gì nên xảy ra tiếp theo không, các cụm từ như "điều này có lẽ cần một cách tiếp cận khác" được nhúng trong những gì nên là một báo cáo đạt hoặc không đạt trung lập. Nếu lớp thực thi đã hình thành ý kiến về việc phục hồi, thì sự tách biệt khỏi lớp phục hồi không phải là thực tế, nó chỉ được đổi nhãn.
Để kiểm tra leo thang nghiêm ngặt, cố tình cung cấp cho hệ thống một thất bại mà không có nỗ lực phục hồi xác định nào có thể sửa chữa và xác nhận nó leo thang sạch sẽ ở giới hạn xác định thay vì cố gắng một cách tiếp cận thứ ba không xác định. Đây là tương đương của kỹ thuật đồ thị của việc kiểm tra điều kiện dừng của vòng lặp chống lại một nhiệm vụ thực sự không thể giải quyết và nó bắt cùng một loại thất bại âm thầm đắt đỏ.
Ngoài ba bài kiểm tra mục tiêu này, hãy theo dõi một số liệu cụ thể trong quá trình sử dụng thực tế mà các lựa chọn thay thế dựa trên vòng lặp thường không thể cung cấp cho bạn một cách sạch sẽ: tỷ lệ các lần chạy đạt đến trạng thái Đã leo thang, được chia nhỏ theo nỗ lực phục hồi cụ thể nào thất bại mỗi lần. Một đồ thị leo thang liên tục tại cùng một bước phục hồi cụ thể đang cho bạn biết giao thức xác định của bước đó đã được hiệu chỉnh sai, không phải rằng nhiệm vụ cơ bản là khó đồng đều, cùng một giá trị chẩn đoán mà việc theo dõi các kích hoạt điều kiện dừng cung cấp cho các vòng lặp, chỉ có sẵn ở đây với chi tiết hơn vì điểm thất bại là một trạng thái được đặt tên, có thể kiểm tra thay vì một khoảnh khắc suy luận bên trong một bản ghi mờ đục.
Các Lỗi Thường Gặp Khi Lần Đầu Xây Dựng Đồ Thị
Một số lỗi cụ thể xuất hiện lặp đi lặp lại đối với những người xây dựng hệ thống có cấu trúc đồ thị đầu tiên của họ và biết trước chúng tiết kiệm thời gian gỡ lỗi thực sự sau này.
Coi kế hoạch là bất biến chỉ trên danh nghĩa. Khóa kế hoạch trên giấy trong khi vẫn cho phép lớp thực thi âm thầm đi chệch khỏi nó trong thực tế tạo ra điều tồi tệ nhất của cả hai thế giới, không có khả năng thích ứng thực sự và cũng không có khả năng kiểm toán thực sự, vì dấu vết không còn khớp với kế hoạch bị khóa mà bạn sẽ xem xét.
Sụp đổ ba lớp trở lại một vì cảm thấy xây dựng nhanh hơn. Sự cám dỗ để cho lớp thực thi cũng quyết định về việc phục hồi, bỏ qua sự tách biệt từ cam kết hai, đánh bại mục đích thực tế của khuôn khổ. Nếu lập kế hoạch, thực thi và phục hồi không thực sự độc lập, bạn đã xây dựng một vòng lặp mặc từ vựng của đồ thị, không phải là một đồ thị thực tế.
Viết một giao thức phục hồi đủ mơ hồ để nó không thực sự là một giao thức. "Cố gắng một số cách tiếp cận thay thế hợp lý" không phải là một giao thức leo thang nghiêm ngặt, nó là một hướng dẫn mềm với cùng một chế độ thất bại như một vòng lặp không giới hạn, chỉ được mô tả bằng ngôn ngữ kỹ thuật đồ thị. Một giao thức thực sự đặt tên cho số lần thử cụ thể và các điều kiện cụ thể cho mỗi lần.
Bỏ qua đánh giá trung thực về sự phù hợp. Xây dựng một đồ thị cho một nhiệm vụ thực sự mang tính khám phá, kết thúc mở vì kỹ thuật đồ thị là khuôn khổ mới hơn, nghe có vẻ chặt chẽ hơn, chứ không phải vì nhiệm vụ thực sự được hưởng lợi từ sự đánh đổi, tạo ra một hệ thống khó xây dựng hơn một vòng lặp và tệ hơn ở công việc thực tế so với một vòng lặp.
Tình Trạng Trung Thực Của Bằng Chứng
Kết thúc với lưu ý mà khóa học này đã mở đầu, bởi vì nó quan trọng hơn ở đây so với hầu hết các bài viết kỹ thuật. Ba cam kết được mô tả ở trên là một đề xuất thực tế, được lý luận cẩn thận, được phân tích dựa trên 70 hệ thống thực tế để xác định chính xác nơi các vòng lặp thất bại âm thầm. Chúng chưa được xác nhận là mang lại lợi ích đã hứa ở quy mô lớn trong sản xuất, theo tuyên bố rõ ràng của chính tác giả.
Điều này không làm cho khuôn khổ trở nên vô giá trị. Nó làm cho nó trở thành một thiết kế thực sự hứa hẹn đáng để hiểu và thử nghiệm một cách có chủ ý, theo dõi kết quả của riêng bạn một cách trung thực thay vì cho rằng lập luận lý thuyết tự động chuyển thành thực tế. Nếu bạn xây dựng một hệ thống có cấu trúc đồ thị bằng cách sử dụng khóa học này, điều duy nhất có giá trị nhất bạn có thể làm là đo lường xem nó có thực sự giảm các chế độ thất bại cụ thể mà nó nhắm đến, các lần thử lại vô hạn, sự trôi dạt kế hoạch không bị phát hiện giữa chừng, các quyết định phục hồi không được kiểm toán, so với mức sử dụng thực tế của riêng bạn, thay vì cho rằng sự cải thiện vì lập luận cho nó có sức thuyết phục trên giấy tờ.
Kỷ luật đó, coi một khuôn khổ được lý luận tốt như một giả thuyết để kiểm tra chứ không phải một sự thật đã được xác lập để chấp nhận một cách không phê phán, bản thân nó là kỹ năng siêu việt thực tế bên dưới mọi thứ trong khóa học này. Kỹ thuật đồ thị, kỹ thuật vòng lặp, bất kỳ thực hành có tên nào trong lĩnh vực chuyển động nhanh này, đều đáng để học đúng cách và đáng để kiểm tra trung thực dựa trên kết quả của riêng bạn, thay vì được áp dụng chỉ vì nó có một cái tên và một bài báo đằng sau nó.
Theo dõi @cyrilXBT để cập nhật về khuôn khổ này khi các triển khai thực tế và kết quả thực sự bắt đầu xuất hiện.
