# Tự động hoá mà cứ vài tuần lại phải vá một lần: đừng nối cứng luồng, hãy để agent tự dựng lại nó
Mình có một con máy nhỏ, ngày nào cũng tự quét vài nguồn tin để tổng hợp ra thứ gì đó liên quan tới "tự động hoá để làm tiền". Ý tưởng ban đầu rất đẹp: đặt nó bên cạnh, để nó chạy, mình chỉ việc đọc kết quả rồi bấm nút.
Thực tế lại là một vòng lặp nghe rất quen:
- ▹Tuần này nó chạy ngon.
- ▹Tuần sau, một nguồn đổi cách trình bày — thêm cột, đổi tiêu đề, chuyển sang dạng mới. Con máy vẫn "đọc" được, nhưng lọc xô lệch, hoặc kéo nhầm thứ rác vào.
- ▹Mình lại phải mở ra, chỉnh một đoạn, thêm một quy tắc, thử lại. Rồi quên mất cho tới lần vỡ tiếp theo.
Mình không viết bài này để than. Vì đợi tới khi mình thực sự ngồi xuống vẽ lại cái luồng, mình nhận ra cái sai không nằm ở con model, cũng không nằm ở cái nguồn "xấu". Cái sai nằm ở chỗ mình nối cứng luồng. Và thứ đáng làm không phải là sửa cho chắc, mà là làm cái luồng đó biết tự dựng lại chính nó.
Cái luồng "nối cứng" cứu bạn nhanh, rồi giết bạn từ từ
Khi người ta dựng tự động hoá, thói quen phổ biến là vẽ một cái sơ đồ cố định: lấy dữ liệu → lọc → gọi model → ra kết quả → đăng. Nối xong là chạy. Nghe rất trực quan, đúng kiểu "kéo thả nút" mà mấy công cụ no-code vẫn quảng bá.
Vấn đề của loại sơ đồ này không phải là nó sai. Nó đúng trong một thế giới tĩnh — nơi các nguồn không đổi, format không thay đổi, đầu vào luôn như đã biết. Nhưng thế giới thực tế mà bạn đang tự động hoá là thế giới động: nguồn tin chết, nguồn mới mọc, api đổi cấu trúc, người ta đổi template giao diện, thậm chí chỉnh cách đặt từ khoá.
Mỗi lần thế giới thay đổi một chút, cái sơ đồ cố định lại "lệch". Và vì nó là sơ đồ bạn đã nối tay, nên mỗi lần lệch, bạn lại phải dùng tay nối lại. Đây chính là lý do nhiều pipeline tự động hoá đẹp trên giấy, nhưng hằng ngày nó ngốn thời gian của bạn không kém gì việc làm thủ công — chỉ là dời chỗ của sự phiền phức từ "làm bằng tay" sang "sửa cái máy".
Mình từng nghĩ cứ chọn model xịn hơn là hết. Hoá ra model bao nhiêu lần thay cũng chẳng cứu được một cái luồng vốn đã nối sai chỗ. Bởi vì con máy chỉ "lớn" lên trong cái khuôn mình đã đóng sẵn — cái khuôn thì cứng ngắt.
Đảo ngược câu hỏi: để agent sở hữu cái luồng, thay vì bị nhốt trong nó
Gần đây mình đọc được một hướng nghiên cứu khá thú vị về các agent. Ý chính rất gọn: thay vì đưa cho agent một dãy bước đã nối cứng, hãy cho nó cái "luồng" như một thứ nó thao tác được — một cấu trúc nó tự dựng, tự test, rồi tự viết lại khi môi trường đổi.
Dịch theo cách dễ hiểu: agent không còn là một gã thợ chạy theo cái bản vẽ của bạn. Nó trở thành người tự vẽ bản vẽ, thử rồi sửa bản vẽ đó mỗi khi phát hiện "à, môi trường đổi, cách cũ không còn ăn nữa".
Đây là một sự dịch chuyển cách nghĩ lớn:
- ▹Cách cũ: con người viết workflow, model chạy theo. Bạn là kiến trúc sư, model là công nhân.
- ▹Cách mới: workflow là dữ liệu, và agent là người duy trì nó. Model không chỉ chạy các bước, mà còn được phép kiểm tra cái cấu trúc đang chạy, phát hiện chỗ nào lệch, và đề xuất/sửa lại bản thân cái cấu trúc.
Nghe hơi viễn vông nếu dừng ở mức lý thuyết. Nhưng mình thấy đây chính là lời giải cho đúng cái đau của mình: cái luồng tổng hợp tin của mình không vỡ vì model dở, mà vỡ vì mình là kẻ duy nhất phát hiện ra nó đã lệch, và mình lại là người duy nhất được quyền sửa nó. Nếu con máy tự nhận ra "khoan, tuần này định dạng nguồn A đổi rồi" và chủ động đổi cách nó đọc, thì vòng lặp "vỡ-rồi-vá" của mình coi như xong.
Nhưng đừng nhảy thẳng — có một phiên bản thực tế hơn nhiều
Mình cũng phải tự thừa nhận: để con agent tự dựng toàn bộ cái luồng như bài báo mô tả là một chuyện khá nặng, không phải ai cũng cần, và không phải lúc nào cũng đáng. Nhưng hầu hết lợi ích thì mình nghĩ đạt được bằng một nửa chặng đường. Cái đó gói gọn trong ba việc:
1. Biến workflow thành một thứ nhìn thấy và sửa được, đừng để nó là cơ thể ngầm. Thay vì viết luồng thành nhiều bước lồng nhau khó dò, hãy viết nó như một "cấu trúc" có tên, có vai trò rõ ràng, có bước nào chắc chắn bước nào mơ hồ. Nhìn vào là thấy ngay "đây là phần mềm, đây là phần cứng". Khi con máy chạy sai, nó — và bạn — biết chính xác chỗ nào cần soi, thay vì phải dò cả chuỗi dài.
# pseudo-code minh hoạ — KHÔNG phải nguồn triển khai thật
workflow = [
{"role": "hard", "action": khử_nhiễu, # luật, không tốn token
{"role": "soft", "action": chọn_lọc}, # model đánh giá
{"role": "hard", "action": ghép_ngữ_cảnh}, # nối liên kết giữa các mục
{"role": "gate", "action": kiểm_chứng}, # checkpoint quyết định
]
# Mỗi bước là một "đối tượng" độc lập → có thể thay từng mắt xích.2. Cho agent đóng góp vào việc sửa cấu trúc, nhưng đặt cái "cổng kiểm soát" ở chỗ cần. Đây là điểm mấu chốt mà ít người làm. Không phải để agent tự do bay và đổi cả luồng theo ý nó — mà để nó báo cáo khi nhận thấy "bước này có dấu hiệu lệch", đề xuất một thay đổi, và bạn kiểm chứng trước khi cho phép nó áp dụng. Nói cách khác: cho nó quyền sửa, nhưng theo cấp độ — từ "chỉ được nêu vấn đề", tới "được đề xuất", tới "được tự đổi phần nhỏ", và chỉ "tự bay" khi đã đủ dày dạn. Càng tiến tới cấp cao, bạn càng cần dữ liệu cho thấy nó sửa đúng nhiều hơn đúng-sai lẫn lộn.
Cái này nghe hơi phức tạp về mặt quản trị, nhưng nó chính là thứ khiến một hệ thống tự động đáng tin. Một cái máy "tự hỏng rồi tự vá nhưng bạn không biết nó vá thế nào" thật ra còn đáng sợ hơn một cái máy chỉ báo: "tôi thấy chỗ này hơi lệ, mày muốn tao đổi thế nào?"
3. Chấp nhận rằng phần "cứng" vẫn nên ở đó. Nghe lạ, vì mình đang bảo đừng nối cứng luồng. Nhưng ý mình là: đừng nối cứng các bước, còn phần quy tắc cơ bản thì cứ cứng. Những bước như "loại bỏ cái chắc chắn là rác", "ghép ngữ cảnh cho liền mạch", "so chi tiết trước khi đăng" — những thứ đó không cần model, cũng không nên để model cảm hứng. Đó là phần xương sống. Cái phần nên "mềm" và tự dựng lại chính là thứ tự và cách các bước được nối với nhau — vì phần đó mới là thứ bị môi trường đổi format làm xô lệch.
Vì sao điều này đáng tiền
Bạn có thể hỏi: "ồ, nghe hay đấy, nhưng mình có nhất thiết phải làm không? Mình tự động hoá cho vui."
Câu trả lời là: chừng nào bạn mới dựng một luồng, chừng đó chi phí vá là thấp. Nhưng càng nhiều luồng, càng lâu, càng đắt. Vòng lặp "vỡ-rồi-vá" có một đặc điểm khó chịu: nó không giảm theo thời gian, mà còn tăng, vì mỗi cái máy mới lại là một cái sơ đồ cứng khác để bạn theo dõi. Nếu mục tiêu là "để máy làm phần lớn, mình chỉ bấm nút", thì mỗi giờ bạn bỏ ra vá một cái luồng cứng chính là một giờ bạn chưa đạt được mục tiêu — chỉ là dời việc.
Gọn lại, ba điều mình muốn anh em mang về:
- ▹Người xây hệ thống đừng coi workflow là thứ nối một lần rồi bỏ. Nó là thứ phải biến đổi, và nên được thiết kế để dễ biến đổi ngay từ đầu.
- ▹Đừng nhảy thẳng tới "agent tự dựng toàn bộ". Làm từ cấp thấp: biến workflow thành cấu trúc nhìn thấy được, cho agent quyền đề xuất, đặt cổng kiểm soát, rồi mới nới dần.
- ▹Giữ phần "cứng" ở đúng chỗ. Quy tắc cũng quan trọng như trí tuệ — nhất là khi bạn muốn một cái máy chạy bền, không nóng máy giữa chừng.
Kết
Con máy tổng hợp tin của mình giờ vẫn là một cái máy, và nó vẫn bị thị trường "đổi format" trêu chọc. Nhưng mình đã ngừng coi việc vá nó là việc phải làm lặp lại, và bắt đầu coi nó là một tín hiệu: cái luồng này đang cần được dựng lại theo cách mà nó có thể tự đổi được.
Chuyện này không phải là một mẹo lập trình hay một công cụ cụ thể. Nó là một cách đặt câu hỏi: khi con máy của bạn cứ vài tuần lại "chệch" một lần, bạn muốn sửa từng nước, hay bạn muốn nó tự học cách đối phó?
Tuần nào anh em cũng phải mở cái máy tự động của mình ra vá một lần? Kể mình nghe ở comment nhé — mình đoán chúng ta đang vá chung một loại luồng. Còn bản thân mình, mình đang thử đẩy một bước tiếp theo: cho cái luồng thêm quyền "tự viết lại", nhưng vẫn giữ một cái công tắc ở trong tay mình.
Một phần của chuỗi mổ xẻ kỹ thuật tại zeodavu.com/blog. Nếu thấy hữu ích, theo dõi [zeodavu.com](/blog) — mỗi bài là một thứ mình thật sự dùng, vấp, và sửa lại.