Blog / Series AI Agents Thực Chiến

Workflow, memory, approval: ba lớp khiến AI agent sống được ngoài demo

Vấn đề gốc: vì sao agent đẹp trong demo nhưng vỡ trong production

Trong demo, một AI agent thường chỉ cần hoàn thành một đường đi ngắn: nhận yêu cầu, suy luận, trả câu trả lời, đôi khi gọi thêm một công cụ rồi kết thúc. Mọi thứ có vẻ mượt. Đó là lý do rất nhiều đội ngũ lầm tưởng rằng chỉ cần model đủ mạnh là có thể chuyển ngay sang môi trường thật.

Nhưng production không giống demo. Ở production, công việc hiếm khi là một lượt chat rồi xong. Nó là một chuỗi bước có trạng thái: lấy dữ liệu, so sánh điều kiện, chờ tín hiệu từ hệ thống khác, retry khi lỗi, ghi lại kết quả, tránh lặp hành động, và dừng đúng chỗ khi cần con người duyệt.

Nếu bài Từ chatbot → AI Agent giải thích vì sao muốn đi từ trả lời sang hành động phải có tool và boundary, còn bài agentic systems là gì cho thấy xu hướng thị trường đang chuyển từ “chat” sang “làm”, thì bài này đi thêm một bước thực dụng hơn: muốn agent sống được ngoài demo, hệ thống phải có ba lớp nền rất rõ.

Ba lớp đó là:

• workflow: hệ thống biết phải làm bước nào trước, bước nào sau, điều kiện chuyển trạng thái là gì;
• memory: hệ thống giữ được điều gì đã biết, điều gì đã quyết, điều gì tuyệt đối không được quên;
• approval: hệ thống biết bước nào agent được tự làm, bước nào phải xin duyệt.

Thiếu workflow, agent sẽ lang thang. Thiếu memory, agent sẽ lặp lại chính mình hoặc tự mâu thuẫn. Thiếu approval, agent sẽ sớm đi quá quyền.

Ba lớp nền: workflow, memory, approval thực ra giải quyết điều gì?

1. Workflow không chỉ là automation, mà là cách hệ thống giữ trật tự công việc

Nhiều người nghe chữ workflow rồi nghĩ ngay tới một sơ đồ nối API. Cách hiểu đó quá hẹp. Trong môi trường agent, workflow là nơi định nghĩa chuỗi quyết định hợp lệ: đầu vào nào cần đủ trước khi làm bước kế tiếp, kết quả nào phải được xác minh, lỗi nào được retry, lỗi nào phải dừng.

Một agent không có workflow rõ ràng thường rơi vào hai kiểu fail. Hoặc nó làm quá ít: trả về một câu trả lời nghe hợp lý nhưng không đụng được công việc thật. Hoặc nó làm quá nhiều: tiếp tục gọi tool, tiếp tục tìm kiếm, tiếp tục sinh thêm phương án dù mục tiêu đã đủ.

2. Memory không phải là lưu toàn bộ lịch sử chat

Khi nói về memory, nhiều hệ chỉ nhét thêm lịch sử hội thoại vào context. Điều đó chưa phải memory theo nghĩa vận hành. Memory hữu ích là memory giúp agent quyết định tốt hơn ở bước tiếp theo.

Ví dụ, hệ thống cần nhớ:

• mục tiêu dài hạn của run hiện tại là gì;
• người dùng đã chốt preference nào;
• bước nào đã hoàn tất, bước nào thất bại;
• cooldown hoặc quota nào đang còn hiệu lực;
• quy tắc nào đã được chấp thuận từ trước và quy tắc nào chỉ áp cho một lần.

Đó là lý do bài OpenClaw workflow: cron, skills, memory chạm đúng một điểm quan trọng: memory không phải để “kể chuyện dài hơn”, mà để hệ thống bớt quên những ràng buộc làm nên chất lượng vận hành.

3. Approval là cách biến agent từ rủi ro thành công cụ có trách nhiệm

Một agent càng hữu ích thì càng sớm đụng tới quyền hành động thật: gửi email, đăng bài, sửa dữ liệu, tạo đơn, bấm nút trong browser, hay tác động tới kênh social. Chính lúc này approval trở thành lớp không thể thiếu.

Approval không nhằm làm chậm mọi thứ. Approval tốt là approval đặt đúng chốt. Nó chỉ yêu cầu con người xuất hiện ở những điểm mà sai lầm có chi phí lớn: phát hành nội dung ra bên ngoài, gửi thông tin cho khách hàng, chi tiền, hoặc thực hiện hành vi có rủi ro chính sách.

Nếu bài Agent Security 2026 nói nhiều về least privilege và tool abuse, thì approval chính là hình thức tổ chức cụ thể của các nguyên tắc đó.

Một use case end-to-end: trợ lý vận hành nội dung và social cho một hệ blog AI

Hãy lấy một use case gần với thực tế mà nhiều đội đang gặp: xây một agent để hỗ trợ vận hành blog AI kèm social distribution. Mục tiêu nghe rất hấp dẫn: mỗi ngày chọn chủ đề, viết bài, chuẩn bị ảnh preview, xuất bản blog rồi mới đẩy sang social.

Nếu chỉ nhìn bề mặt, đây giống một bài toán content generation. Nhưng khi triển khai thật, nó nhanh chóng biến thành bài toán systems operations.

Bước 1: workflow tách rõ thứ tự công việc

Hệ thống phải biết thứ tự đúng:

1. xác định backlog và loại trừ chủ đề đã trùng;
2. chọn một góc bài mới có giá trị;
3. viết bản nháp long-form;
4. gắn ảnh riêng hoặc og:image riêng cho đúng bài;
5. publish blog;
6. chỉ sau khi publish thành công mới cho social autopost dùng URL đó.

Chỉ riêng việc giữ đúng thứ tự này đã là phần việc mà một chatbot thuần không làm được. Nó cần một workflow có điều kiện chuyển trạng thái rõ ràng. Nếu không, hệ thống dễ post social trước khi bài xuất hiện, dùng ảnh mặc định cho mọi bài, hoặc đẩy ra một chủ đề lặp với bài vừa viết hôm qua.

Bước 2: memory giữ các rule sống còn qua nhiều ngày vận hành

Agent cần nhớ những quyết định không nên phát minh lại mỗi ngày:

• ưu tiên blog trước social;
• tránh lặp chủ đề cũ, nếu trùng thì phải xoay góc hoặc tách thành series;
• mỗi bài cần ảnh minh họa đủ khác nhau để social preview không nhìn như spam;
• nếu execution bridge cho social/browser chưa được xác minh, chỉ chuẩn bị playbook và risk layer chứ không tự ý chạy hành vi rủi ro cao.

Nếu các ràng buộc này không được memory giữ lại ở tầng hệ thống, agent sẽ liên tục “mới với chính mình”. Hôm nay nó nhớ blog phải đi trước. Ngày mai nó quên. Hôm nay nó nhớ không được comment group tự động khi chưa có bridge. Ngày mai nó lại coi đó là một cơ hội tăng tương tác.

Bước 3: approval chặn các điểm rủi ro cao

Trong use case này, không phải bước nào cũng cần duyệt. Viết bản nháp có thể cho agent làm chủ động. Gợi ý ảnh cũng có thể tự động. Nhưng các bước như:

• đẩy một bình luận vào Facebook group bằng browser,
• vượt quá quota social an toàn,
• chạm vào tài khoản đang có tín hiệu checkpoint,
• hoặc đăng nội dung có khả năng bị xem là spam,

thì phải bị block hoặc yêu cầu phê duyệt. Nói cách khác, approval không cản agent làm việc. Approval bảo vệ hệ thống khỏi việc một chuỗi tự động nhỏ biến thành một sự cố thương hiệu hoặc một khóa tài khoản kéo dài.

Kiến trúc hệ thống: state machine, memory tiers và approval gates nên nằm ở đâu

Một sai lầm phổ biến là nhét cả workflow, memory và approval vào cùng một prompt dài. Cách đó có thể chạy demo, nhưng rất khó quan sát và càng khó mở rộng. Kiến trúc bền hơn thường tách ba lớp này ra rõ ràng.

1. Workflow layer: state machine hoặc orchestration layer

Lớp này định nghĩa run đang ở đâu: topic_selected, draft_written, image_ready, published, queued_for_distribution… Nó cũng định nghĩa điều kiện chuyển bước, timeout, retry và rollback. Khi có lỗi, hệ thống cần biết lỗi ở state nào thay vì chỉ biết “agent thất bại”.

2. Memory layer: tách ít nhất ba tầng

Một thiết kế thực dụng thường tách memory thành:

• working memory: trạng thái ngắn hạn của run hiện tại;
• session/project memory: các quyết định còn hiệu lực trong một workstream hoặc một chuỗi ngày;
• policy memory: các nguyên tắc gần như bất biến cho tới khi có người thay đổi rõ ràng.

Tách tầng như vậy giúp hệ thống biết điều gì có thể quên và điều gì tuyệt đối không được quên. Nếu không, mọi thứ trộn lẫn trong context rồi sớm muộn cũng drift.

3. Approval layer: nằm trước hành động, không chỉ log sau hành động

Approval hiệu quả phải đứng trước execution. Hệ thống nên chấm rủi ro trước khi bấm nút, không phải sau khi đã làm xong mới ghi log là “hơi nguy hiểm”. Với các hành động bên ngoài như social posting, browser automation, gửi email hoặc giao dịch, approval gate nên đọc được:

• loại hành động;
• đối tượng tác động;
• nội dung dự kiến gửi;
• quota gần đây;
• tín hiệu account health;
• và lịch sử các hành động tương tự.

Đây cũng là nơi một agentic browser runtime phải gắn với policy engine, thay vì chỉ coi browser là một bàn tay robot biết click.

4. Observability: lớp thứ tư thường bị quên nhưng rất đáng tiền

Dù bài này tập trung vào ba lớp chính, thực tế production gần như luôn cần thêm observability. Nếu không replay được một run, không biết agent đã nhớ gì, đã xin duyệt ở đâu, đã bị gate chặn vì rule nào, thì đội ngũ rất khó sửa hệ thống một cách có phương pháp.

Trade-off và failure modes: khi ba lớp này bị làm hời hợt

1. Workflow quá cứng làm agent mất giá trị

Nếu workflow bị biến thành một đường ray cứng tuyệt đối, agent chỉ còn là giao diện đẹp cho một automation cũ. Khi đó hệ thống an toàn hơn nhưng không linh hoạt trước ngoại lệ. Điểm cân bằng tốt là workflow đủ rõ để chặn hỗn loạn, nhưng đủ mở để agent xử lý biến thể hợp lý.

2. Memory quá nhiều tạo ra nhiễu, memory quá ít tạo ra lặp lỗi

Cho agent nhớ mọi thứ thường dẫn tới context phình to và ưu tiên tín hiệu sai. Nhưng cho agent nhớ quá ít thì nó quên constraint quan trọng, lặp hành động cũ hoặc đề xuất trái với quyết định đã chốt. Bài toán không phải “nhớ nhiều hay ít”, mà là nhớ có cấu trúc.

3. Approval đặt sai chỗ làm hệ thống vừa chậm vừa nguy hiểm

Nếu approval xuất hiện ở mọi bước nhỏ, con người sẽ mệt mỏi và cuối cùng bấm duyệt như máy. Nhưng nếu approval chỉ xuất hiện ở cuối, agent có thể đã đi quá xa trước khi bị dừng. Approval tốt là approval xuất hiện đúng nơi giá trị và rủi ro cắt nhau.

4. Failure modes phổ biến

• Orphaned workflow: hệ thống không biết một run dừng ở đâu và vì sao.
• Memory drift: cùng một rule nhưng được ghi khác nhau ở nhiều nơi, dẫn tới hành vi mâu thuẫn.
• Approval bypass: agent gọi một tool khác để đạt cùng kết quả mà không đi qua gate chính.
• Post-facto governance: chỉ ghi log sau khi hành động đã gây hậu quả.
• Hidden retries: agent lặp lại một hành động rủi ro nhiều lần vì không nhớ lần trước đã thất bại.

Checklist triển khai thực dụng cho đội sản phẩm và platform

Giai đoạn 1: chọn workflow có biên giới rõ

• Bắt đầu từ công việc nhiều bước nhưng không quá mơ hồ.
• Viết rõ đầu vào, đầu ra và các state chính.
• Xác định bước nào có thể thất bại mà vẫn retry an toàn.

Giai đoạn 2: thiết kế memory theo tầng, không theo cảm tính

• Tách working memory, project memory và policy memory.
• Định nghĩa TTL hoặc quy tắc cập nhật cho từng tầng.
• Không để một quy tắc quan trọng chỉ sống trong prompt tạm thời.

Giai đoạn 3: đặt approval vào đúng chốt rủi ro

• Liệt kê các hành động chạm ra ngoài hệ thống: gửi, đăng, mua, xóa, sửa.
• Xác định ngưỡng nào agent được tự thực hiện, ngưỡng nào cần review.
• Với các hành vi social hoặc browser-based, mặc định bảo thủ cho tới khi execution bridge được xác minh.

Giai đoạn 4: log để có thể replay

• Run ID cho từng workflow.
• Log decision trace, tool call, gate result và state transitions.
• Giữ bằng chứng đủ để postmortem sau một lỗi thật.

Giai đoạn 5: rollout theo mức quyền tăng dần

• Khởi đầu ở chế độ đề xuất.
• Chuyển sang human-in-the-loop execution.
• Chỉ cho auto-execution ở các nhánh đã đo đủ ổn định và rollback rõ.

Insight cuối cùng: sức mạnh của agent không nằm ở câu trả lời hay nhất, mà ở khả năng giữ trật tự khi làm việc thật

Trong vài năm đầu của làn sóng LLM, rất nhiều đội tối ưu cho khoảnh khắc demo: câu trả lời mượt, reasoning nghe thông minh, tool call trông ấn tượng. Nhưng production không chấm điểm theo khoảnh khắc đó. Production chấm điểm theo việc hệ thống có hoàn thành công việc lặp đi lặp lại mà không làm hỏng ranh giới vận hành hay không.

Vì vậy, nếu phải tóm gọn bài học cốt lõi: workflow giữ agent không đi lạc, memory giữ agent không quên, approval giữ agent không vượt quyền. Ba lớp này không phải phần phụ. Chúng là phần phân biệt giữa một AI agent thú vị và một AI agent có thể giao việc thật.

Ai tiếp tục xem agent như một hộp chat có thêm vài tool sẽ sớm đụng trần. Ai xây agent như một hệ thống có trạng thái, có trí nhớ và có cơ chế phê duyệt sẽ bắt đầu đi được xa hơn — không phải vì model nói hay hơn, mà vì hệ thống giữ được kỷ luật khi làm việc thật.