Vì sao tôi tự xây bộ điều phối AI Agent, không dùng framework

TL;DR: Một AI Agent chuyên biệt chỉ giỏi một việc. Khi công việc thật cần nhiều Agent phối hợp, tôi cần một lớp điều phối biết ai làm gì, ai quyết định gì. Tôi từng cân nhắc framework mã nguồn mở, nhưng cuối cùng chọn tự xây — vì bài toán của tôi cần kiểm soát ranh giới quyết định, không cần tốc độ dựng nhanh.

Có một giai đoạn tôi vận hành nhiều AI Agent cùng lúc — mỗi Agent đảm nhận một việc cụ thể: một cái xử lý nội dung, một cái xử lý dữ liệu, một cái xử lý phản hồi khách hàng. Từng Agent đều làm tốt việc của nó. Vấn đề chỉ xuất hiện khi ba việc đó cần chạy nối tiếp nhau, và tôi là người duy nhất biết thứ tự đúng.

Tôi nhận ra mình đang tự làm cái việc mà đáng lẽ hệ thống phải làm: giữ ngữ cảnh, quyết định ai nói tiếp, và ngăn hai Agent giẫm chân nhau. Đó là lúc tôi hiểu — vấn đề không còn nằm ở từng Agent nữa. Vấn đề nằm ở lớp điều phối.

Bài toán: khi một AI Agent không còn đủ, bạn cần ai "chỉ huy"?

Một AI Agent đơn lẻ là một cái đầu chuyên trách — bạn giao việc, nó xử lý, bạn nhận kết quả. Ngay khi có từ hai Agent trở lên cần phối hợp trong cùng một quy trình, mô hình đó vỡ. Không phải vì từng Agent kém đi, mà vì không ai trong số chúng có tầm nhìn toàn cục.

Tôi từng thử để các Agent tự gọi nhau — Agent A xong việc thì tự nhắn cho Agent B. Nghe hợp lý trên giấy, nhưng thực tế nó sinh ra một mớ phụ thuộc chéo mà chỉ tôi mới gỡ được khi có lỗi. Mỗi Agent chỉ biết việc của nó, không Agent nào chịu trách nhiệm về toàn bộ luồng. Khi một bước giữa chừng thất bại, không có ai đứng ra quyết định: dừng lại, thử lại, hay chuyển sang phương án dự phòng.

Đó chính là khoảng trống cần một vai trò riêng — không làm việc chuyên môn, chỉ làm một việc: quyết định thứ tự, phân phối ngữ cảnh, và giữ trạng thái của toàn bộ quy trình. Trong tư duy Director Mindset mà tôi theo đuổi từ triết lý Director Mindset khi làm việc với AI, đây chính là bước tiếp theo tự nhiên: khi bạn đã quen điều phối một AI Agent, câu hỏi kế tiếp là làm sao điều phối nhiều Agent cùng lúc mà không phải tự mình đứng giữa làm cầu nối thủ công.

Framework có sẵn giải quyết được gì, và bỏ sót gì cho bài toán của tôi?

Framework điều phối multi-agent mã nguồn mở giải quyết tốt phần hạ tầng: định nghĩa Agent, truyền message giữa các Agent, quản lý vòng lặp gọi công cụ. Với một hệ thống demo hoặc một quy trình tương đối chuẩn, chúng giúp bạn dựng nhanh — có thể chạy được trong vài giờ thay vì vài tuần.

Nhưng tôi phát hiện điểm bỏ sót ngay khi đưa bài toán thật vào: framework cho tôi cơ chế giao tiếp giữa các Agent, chứ không cho tôi nguyên tắc để quyết định ai được quyền quyết định gì. Đó là hai việc khác nhau. Cơ chế là kỹ thuật — ai gọi ai, dữ liệu truyền theo định dạng nào. Nguyên tắc là quản trị — khi hai Agent đưa ra hai đề xuất mâu thuẫn, ai có tiếng nói cuối? Khi một tác vụ chạm ngưỡng rủi ro nhất định, ai bắt buộc phải dừng lại chờ tôi duyệt tay?

Phần lớn framework để phần này mở, coi đó là "logic nghiệp vụ" người dùng tự viết. Điều đó hợp lý về mặt thiết kế phần mềm, nhưng nó đồng nghĩa cái khó nhất trong bài toán của tôi — ranh giới quyết định, mức độ tự chủ được phép của từng Agent — vẫn là thứ tôi phải tự nghĩ ra và tự viết, dù dùng framework hay không. Framework giúp tôi tiết kiệm thời gian ở phần hạ tầng, nhưng không giúp tôi ở phần khó nhất.

Nguyên tắc tôi đặt ra khi thiết kế lớp điều phối: rõ vai trò, rõ ranh giới quyết định

Trả lời trực tiếp: Tôi thiết kế lớp điều phối xoay quanh hai nguyên tắc cố định — mỗi Agent chỉ được giao đúng một vai trò rõ ràng, và mọi quyết định vượt ngưỡng rủi ro đã định trước đều phải quay lại con người, không có ngoại lệ tự động.

Hai nguyên tắc này nghe đơn giản, nhưng ép tôi phải trả lời những câu hỏi mà tôi từng lảng tránh khi còn dùng framework mặc định:

• Vai trò của từng Agent kết thúc ở đâu? Tôi buộc mình viết rõ ranh giới trách nhiệm cho từng Agent trước khi viết một dòng code điều phối nào — Agent này được phép đề xuất, Agent kia được phép thực thi, nhưng không Agent nào được vừa đề xuất vừa tự phê duyệt việc của chính mình.
• Quyết định nào cần con người, quyết định nào Agent được tự xử lý? Tôi phân loại hành động theo mức độ có thể đảo ngược. Việc dễ sửa nếu sai, tôi để Agent tự quyết. Việc khó đảo ngược — gửi thông tin ra ngoài, thay đổi dữ liệu khách hàng — bắt buộc có một điểm dừng chờ xác nhận, dù chậm hơn.
• Ai giữ ngữ cảnh chung của toàn bộ quy trình? Chỉ lớp điều phối được giữ bức tranh toàn cục. Từng Agent chuyên biệt chỉ nhận đúng phần ngữ cảnh nó cần cho việc của nó — không hơn. Điều này giúp lỗi ở một Agent không lan sang Agent khác một cách âm thầm.

Không nguyên tắc nào trong ba điều trên nằm sẵn trong bất kỳ framework nào tôi từng xem qua. Chúng phải xuất phát từ cách tôi hiểu bài toán của chính mình — vận hành một hệ thống cho doanh nghiệp thật, không phải một bản demo.

Cái giá phải trả khi tự xây — và vì sao tôi vẫn chọn con đường này

Tự xây chậm hơn. Đây là điều tôi không né tránh. Những phần mà một framework cho tôi ngay lập tức — vòng lặp gọi công cụ, cơ chế retry, logging chuẩn — tôi phải tự viết lại, tự kiểm thử, tự tìm ra lỗi qua thực chiến chứ không qua tài liệu có sẵn. Có những tuần tôi mất nhiều thời gian sửa một lỗi điều phối vụn vặt mà một framework trưởng thành có lẽ đã xử lý sẵn từ lâu.

Nhưng đổi lại, tôi hiểu chính xác điều gì xảy ra ở từng bước quyết định trong hệ thống của mình. Khi có sự cố, tôi biết ngay lớp nào đang chịu trách nhiệm, không phải dò qua tài liệu của một dự án mã nguồn mở mà tôi không kiểm soát vòng đời cập nhật. Khi cần siết chặt ranh giới tự chủ của một Agent vì phát hiện rủi ro mới, tôi sửa trực tiếp ở nguyên tắc, không phải tìm cách "lách" qua cấu hình mặc định của framework.

Đây là một sự đánh đổi có ý thức, không phải vì tôi tin tự xây luôn tốt hơn dùng có sẵn. Với một hệ thống mà tôi vận hành hằng ngày, nơi ranh giới quyết định phải khớp chính xác với cách tôi chịu trách nhiệm cho kết quả, tốc độ dựng nhanh không quan trọng bằng việc tôi hiểu rõ từng phần mình đang vận hành. Đó là lý do, ít nhất ở giai đoạn này, tôi vẫn chọn con đường chậm hơn nhưng do chính tôi kiểm soát.

Kết luận

Bài toán điều phối multi-agent không phải là bài toán kỹ thuật thuần túy — nó là bài toán về ranh giới quyết định. Framework có thể cho bạn hạ tầng, nhưng câu hỏi ai được quyền quyết định gì vẫn luôn là việc bạn phải tự trả lời, dù chọn con đường nào.

Nếu bạn đang cân nhắc thiết kế một hệ thống nhiều Agent cho quy trình của mình, góc nhìn kỹ thuật cụ thể hơn về cách phân vai các Agent trong một pipeline nội dung có thể hữu ích: kiến trúc multi-agent cho agency content.