Lời nói đầu

Trong mấy năm gần đây, mình thấy một việc khá rõ: ai làm nội dung, bán hàng, chăm sóc khách hàng hay vận hành page Facebook thì đều bị cuốn vào rất nhiều việc lặp lại. Hôm nay viết bài, mai rep comment, ngày kia tổng hợp dữ liệu, rồi lại phải nhớ đăng đúng giờ, theo dõi khách nhắn gì, lưu lại kết quả ra sao. Nghe thì nhỏ nhỏ thôi, nhưng làm đều mỗi ngày thì nó ăn rất nhiều thời gian và năng lượng.

Trước đây những việc như vậy thường phải có một người trực page, một người viết nội dung, một người biết kỹ thuật để kéo dữ liệu hoặc gọi API. Nhưng khi AI agent bắt đầu thực dụng hơn, mình nghĩ có một hướng khá hay: thay vì chỉ hỏi AI cho vui, ta có thể biến nó thành một nhân viên phụ trợ thật sự. Nó biết nhận yêu cầu, biết gọi công cụ, biết tìm dữ liệu, biết viết nội dung, biết đăng bài hoặc lên lịch nếu được cấp quyền đúng cách.

Bài viết này mình viết để ghi lại cách nhìn tổng quan về một Facebook Agent như vậy. Nó không phải phép màu, cũng không phải kiểu bấm một nút là giàu ngay :> Nó chỉ là một hệ thống được chia nhỏ thành nhiều bước rõ ràng, có input, có xử lý, có công cụ, có kiểm tra kết quả. Khi hiểu được luồng đó thì việc tự làm, tự chỉnh, hoặc đánh giá một agent có dùng được trong công việc thật hay không sẽ dễ hơn rất nhiều.

Rồi, vào việc thôi.

Tổng quan bài toán của mình

Mình bắt đầu bài toán này từ một nhu cầu khá đời thường: vận hành một Facebook Page sao cho đều hơn, ít phụ thuộc vào việc ngày nào mình cũng phải ngồi trực từng thao tác nhỏ. Một page muốn chạy nghiêm túc thường không chỉ có chuyện đăng vài bài cho vui. Nó còn có comment, inbox, dữ liệu khách hỏi, lịch đăng, nội dung cần chuẩn bị, nguồn thông tin cần kiểm tra, rồi cả việc lưu lại kết quả để sau này còn biết cái gì đang hiệu quả.

Nếu làm thủ công, mọi thứ rất dễ bị rơi vào trạng thái rời rạc. Hôm nay mình thấy một chủ đề hay thì viết, mai bận thì quên đăng, khách hỏi nhiều câu giống nhau thì vẫn phải trả lời lại từ đầu, dữ liệu đã tìm hôm trước hôm sau lại phải mở tab tìm lại. Những việc này không quá khó, nhưng chúng lặp lại liên tục. Chính phần lặp lại đó mới là thứ làm mình mất năng lượng.

Facebook Agent trong bài này được hiểu như một trợ lý tự động chuyên hỗ trợ vận hành page. Nó không thay mình quyết định toàn bộ, cũng không nên được cấp quyền để muốn làm gì thì làm. Vai trò hợp lý hơn là nhận yêu cầu, hiểu mục tiêu, gọi đúng công cụ, tạo bản nháp, thao tác với Facebook khi được phép, lưu lại kết quả và báo cáo lại cho mình.

Nói cách khác, agent này giống một nhân viên phụ trợ biết làm việc theo quy trình. Mình vẫn là người đặt mục tiêu, duyệt những nội dung quan trọng và chịu trách nhiệm cuối cùng. Agent giúp gom những việc đều đều như tìm dữ liệu, viết nháp, trả lời câu hỏi thường gặp, lên lịch đăng, ghi log và tổng hợp kết quả vào một luồng rõ ràng hơn.

Ví dụ, thay vì tự làm từng bước khi muốn đăng một bài tổng hợp thông tin tuyển sinh, mình có thể giao cho agent: tìm thông tin mới nhất từ các nguồn đã chọn, tóm tắt thành nội dung dễ đọc, viết bản nháp theo giọng văn của page, đưa cho mình duyệt, sau đó đăng hoặc lên lịch đăng. Điểm quan trọng nằm ở chữ “quy trình”, vì nếu không có quy trình thì AI chỉ tạo ra vài đoạn văn rời rạc, chưa phải một agent dùng được trong công việc thật.

Các công cụ hỗ trợ

Để một agent làm được việc thật, chỉ có mô hình AI là chưa đủ. AI giống phần biết đọc hiểu và điều phối, còn những thao tác bên ngoài cần được nối với các công cụ cụ thể. Với bài toán Facebook Page, mình thường chia công cụ thành vài nhóm chính: công cụ giao tiếp với người dùng, công cụ AI, công cụ lấy dữ liệu, công cụ Facebook API, công cụ lưu trữ, công cụ hẹn giờ và công cụ theo dõi lỗi.

Phần giao tiếp với người dùng có thể rất đơn giản. Ban đầu chỉ cần một giao diện chat, một CLI, một dashboard nhỏ hoặc một bot Telegram là đủ. Mục tiêu của lớp này không phải làm cho đẹp ngay, mà là có một nơi để mình nhập yêu cầu theo cách ổn định. Khi đầu vào ổn định, agent sẽ dễ hiểu việc cần làm hơn.

Phần AI là nơi đọc yêu cầu, chia nhỏ nhiệm vụ và quyết định nên gọi công cụ nào. Ví dụ khi mình nói “viết bài và đăng sau 10 phút”, AI cần hiểu rằng đây không chỉ là một tác vụ viết nội dung. Nó còn liên quan đến kiểm tra dữ liệu, tạo bản nháp, xác nhận lịch đăng, gọi API đăng bài và trả lại kết quả. AI không nên tự làm mọi thứ trong đầu, mà nên đóng vai trò điều phối các skill nhỏ.

Phần lấy dữ liệu có thể là web search, web extract, API của website khác, file nội bộ hoặc database có sẵn. Với page bán hàng, dữ liệu có thể nằm trong Google Sheet, Notion, CRM, lịch sử inbox, danh sách sản phẩm hoặc các bài viết cũ. Agent càng có nguồn dữ liệu rõ thì nội dung tạo ra càng ít mơ hồ.

Phần Facebook API là lớp quan trọng nhất nếu muốn agent thao tác trực tiếp với page. Thông qua Graph API, agent có thể đọc một số thông tin của page, tạo bài đăng, lấy comment, phản hồi comment hoặc thực hiện các thao tác khác tùy quyền được cấp. Đây cũng là phần cần cẩn thận nhất, vì khi đã có token và quyền ghi, lỗi của agent không còn nằm trong bản nháp nữa mà có thể xuất hiện trực tiếp trên page thật.

Phần lưu trữ và log giúp agent có trí nhớ vận hành. Mỗi lần agent chạy, mình nên lưu lại yêu cầu ban đầu, dữ liệu đã lấy, nội dung đã tạo, công cụ đã gọi, trạng thái thành công hoặc thất bại và link kết quả nếu có. Lúc mới làm có thể chỉ cần file JSON, SQLite hoặc Google Sheet. Khi hệ thống lớn hơn mới cần database bài bản hơn.

Phần hẹn giờ giúp agent không chỉ phản hồi ngay, mà còn có thể chạy theo lịch. Ví dụ đăng bài lúc 8 giờ tối, tổng hợp comment mỗi sáng, gửi báo cáo mỗi tuần hoặc kiểm tra inbox định kỳ. Phần này có thể dùng cron, scheduler trong ứng dụng, n8n, Make, Zapier hoặc một queue riêng nếu hệ thống đã phức tạp.

Cuối cùng là phần theo dõi lỗi. Đây là phần nhiều người hay bỏ qua vì lúc demo thường mọi thứ chạy khá vui. Nhưng khi đưa vào page thật, mình cần biết lúc nào token hết hạn, API trả lỗi, nội dung không đạt điều kiện đăng, dữ liệu crawl bị thiếu hoặc lịch đăng không chạy. Không có log và cảnh báo thì agent rất dễ trở thành một hộp đen: nhìn bên ngoài tưởng đang chạy, nhưng bên trong hỏng từ lúc nào không biết.

Nếu vẽ tổng thể, luồng công cụ có thể hình dung như sau:

  flowchart LR
    U[Người dùng] --> UI[Giao diện chat / dashboard]
    UI --> A[AI Agent]
    A --> S[Skill xử lý nhiệm vụ]
    S --> W[Nguồn dữ liệu web / file / database]
    S --> FB[Facebook Graph API]
    S --> DB[Bộ nhớ / log]
    S --> SCH[Lịch hẹn]
    W --> A
    FB --> DB
    SCH --> S
    A --> R[Kết quả / bản nháp / link bài viết]

Cách thức thực hiện

Cách mình thích làm là bắt đầu từ một luồng nhỏ, chạy được, kiểm soát được, rồi mới mở rộng. Đừng bắt đầu bằng mục tiêu quá lớn như “tự động hóa toàn bộ page”. Nghe thì hay, nhưng rất dễ biến thành một hệ thống nhiều quyền, nhiều lỗi và không biết kiểm tra từ đâu. Một luồng đầu tiên hợp lý có thể là: nhận yêu cầu, viết bản nháp bài đăng, cho người dùng duyệt, đăng lên page test, lưu lại kết quả.

Bước đầu tiên là xác định rõ input và output. Input không nên chỉ là một câu mơ hồ kiểu “viết giúp bài hay hay”. Mình nên quy ước agent cần biết chủ đề, đối tượng đọc, giọng văn, độ dài, nguồn dữ liệu, có cần đăng luôn hay chỉ tạo bản nháp. Output cũng cần rõ: trả về nội dung nháp, link bài viết, ID bài đăng, trạng thái đăng thành công hay lỗi.

Sau đó mình tách agent thành các skill nhỏ. Một skill có thể hiểu là một khả năng cụ thể mà agent biết dùng khi cần. Ví dụ search_content để tìm dữ liệu, draft_post để viết bài, review_post để kiểm tra nội dung, publish_facebook_post để đăng bài, save_log để lưu lịch sử. Mỗi skill nên làm một việc đủ rõ. Khi có lỗi, mình biết lỗi nằm ở bước nào, chứ không phải lục trong một cục code dài.

Một cấu trúc thư mục đơn giản có thể đặt trong .agent, bên trong có thư mục skills, tools, memory và config. Phần skills chứa hướng dẫn hoặc code cho từng khả năng. Phần tools chứa các hàm gọi API, đọc file, ghi log, đặt lịch. Phần memory lưu lịch sử chạy thử hoặc dữ liệu mẫu. Phần config giữ những cấu hình không nhạy cảm như page id test, giọng văn, mẫu prompt, giới hạn độ dài bài viết. Token thật thì không nên đặt trong đây, mà nên để ở biến môi trường.

Với luồng đăng bài, agent có thể chạy theo trình tự khá rõ. Đầu tiên nó đọc yêu cầu của mình và phân loại nhiệm vụ. Nếu yêu cầu cần dữ liệu mới, nó gọi skill tìm dữ liệu. Nếu dữ liệu đã có sẵn, nó bỏ qua bước đó và chuyển sang viết nháp. Sau khi có bản nháp, agent kiểm tra lại vài điều cơ bản như nội dung có rỗng không, có quá dài không, có thiếu nguồn quan trọng không, có chứa thông tin nhạy cảm không. Nếu bài cần duyệt, nó dừng lại để mình xem. Nếu đã được phép đăng, nó gọi Facebook API, nhận lại ID hoặc link bài viết, rồi lưu toàn bộ kết quả vào log.

  sequenceDiagram
    participant User as Người dùng
    participant Agent as Agent
    participant Data as Dữ liệu / Web
    participant Review as Bước duyệt
    participant FB as Facebook Page
    participant Log as Log

    User->>Agent: Gửi yêu cầu
    Agent->>Data: Lấy dữ liệu nếu cần
    Data-->>Agent: Trả dữ liệu
    Agent->>Agent: Viết bản nháp và tự kiểm tra
    Agent->>Review: Gửi bản nháp để duyệt
    Review-->>Agent: Đồng ý đăng
    Agent->>FB: Đăng bài qua Graph API
    FB-->>Agent: Trả ID / link bài viết
    Agent->>Log: Lưu yêu cầu, nội dung, trạng thái
    Agent-->>User: Trả kết quả

Khi triển khai thật, mình không nhất thiết phải tự code mọi thứ từ đầu. Nếu muốn nhanh, có thể dùng n8n hoặc Make để nối các bước như nhận webhook, gọi AI, ghi Google Sheet và gọi Facebook API. Nếu muốn linh hoạt hơn, có thể viết một service nhỏ bằng Node.js hoặc Python, trong đó agent là lớp điều phối còn các tool là các hàm riêng. Cách nào cũng được, miễn là giữ được nguyên tắc: input rõ, skill rõ, quyền rõ, log rõ.

Một ví dụ thực tế là yêu cầu “tổng hợp các câu hỏi khách hay hỏi trong tuần và viết 3 bài Facebook trả lời”. Agent sẽ lấy dữ liệu comment hoặc inbox đã lưu, nhóm các câu hỏi giống nhau, chọn ra vài chủ đề nổi bật, viết thành 3 bản nháp khác nhau, rồi gửi lại cho mình duyệt. Ở bước này chưa cần cấp quyền đăng bài cũng đã có giá trị rồi. Sau khi luồng tạo nháp ổn định, mình mới thêm quyền đăng hoặc lên lịch.

Kinh nghiệm triển khai

Kinh nghiệm đầu tiên của mình là hãy bắt đầu bằng page test. Đừng thử trực tiếp trên page chính khi agent còn đang thay đổi liên tục. Page test giúp mình kiểm tra token, quyền, định dạng bài đăng, lỗi API và luồng log mà không ảnh hưởng tới người đọc thật. Khi mọi thứ chạy ổn nhiều lần, mình mới đưa từng phần sang page thật.

Kinh nghiệm thứ hai là đừng cấp quyền quá rộng ngay từ đầu. Nếu agent chỉ cần tạo bản nháp thì không cần quyền đăng. Nếu agent chỉ đọc comment để tổng hợp insight thì không cần quyền quản trị quá cao. Quyền càng rộng thì hậu quả khi lỗi càng lớn. Mình thích đi từ quyền đọc, sang quyền tạo bản nháp, rồi cuối cùng mới tới quyền đăng hoặc trả lời tự động.

Kinh nghiệm thứ ba là luôn có bước duyệt với nội dung ảnh hưởng tới thương hiệu. AI có thể viết nhanh, nhưng không phải lúc nào cũng hiểu hết ngữ cảnh kinh doanh, giọng văn cá nhân hoặc những điều nhạy cảm. Với bài quảng bá, bài có số liệu, bài liên quan tới chính sách, giá tiền, cam kết kết quả hoặc phản hồi khách hàng, mình nên để agent chuẩn bị bản nháp và con người duyệt lần cuối.

Kinh nghiệm thứ tư là log phải được làm từ sớm. Lúc demo, mình thường chỉ quan tâm “có chạy không”. Nhưng khi lỗi xuất hiện, câu hỏi quan trọng hơn là “nó đã chạy tới bước nào, dùng dữ liệu gì, gọi API nào, API trả gì”. Một dòng log tốt giúp tiết kiệm rất nhiều thời gian debug. Tối thiểu nên lưu thời gian chạy, yêu cầu ban đầu, skill đã gọi, nội dung cuối, trạng thái, lỗi nếu có và link kết quả.

Kinh nghiệm thứ năm là giới hạn phạm vi cho agent. Đừng để agent tự suy diễn quá nhiều khi yêu cầu chưa rõ. Nếu người dùng nói “đăng bài này lên page”, agent nên biết hỏi lại khi thiếu page id, thiếu nội dung, thiếu thời gian đăng hoặc thiếu xác nhận. Một agent tốt không chỉ là agent làm nhanh, mà còn biết dừng đúng lúc.

Kinh nghiệm thứ sáu là tách môi trường test và môi trường thật. Token test, page test, dữ liệu mẫu và log thử nghiệm nên tách khỏi token thật, page thật và dữ liệu khách thật. Việc này nghe hơi kỹ tính, nhưng càng về sau càng cứu mình khỏi những lỗi rất mệt, nhất là khi nhiều workflow cùng chạy.

Kinh nghiệm cuối cùng là đừng kỳ vọng agent hoàn hảo ngay. Lần đầu nên làm một workflow nhỏ thật chắc, ví dụ tạo bản nháp bài đăng từ một nguồn dữ liệu cố định. Khi workflow đó chạy ổn, mình thêm kiểm tra nội dung. Sau đó mới thêm đăng bài. Sau nữa mới thêm lịch hẹn, comment, inbox, báo cáo. Làm theo vòng nhỏ như vậy chậm hơn một chút ở đầu, nhưng đỡ vỡ hệ thống về sau.

Các kiến thức liên quan

Muốn tự làm một Facebook Agent, có vài mảng kiến thức nên nắm trước. Không cần thành chuyên gia hết, nhưng nên hiểu đủ để biết hệ thống đang làm gì và rủi ro nằm ở đâu.

Trước hết là kiến thức về Facebook Graph API. Đây là API chính để ứng dụng nói chuyện với Facebook. Mình cần hiểu các khái niệm như App, Page, Page ID, User Access Token, Page Access Token, permission, endpoint và response. Khi đăng bài lên page, agent không “bấm nút” như người dùng trên giao diện Facebook, mà gửi request tới API kèm token có quyền phù hợp.

Về token, cách làm thường bắt đầu từ Facebook Developer. Mình tạo một app, cấu hình quyền cần dùng, dùng Graph API Explorer hoặc luồng OAuth để lấy token, sau đó đổi sang Page Access Token nếu thao tác với page. Token này giống chìa khóa, nên tuyệt đối không đưa vào bài viết, không hard-code vào code public, không commit lên GitHub. Trong môi trường thật, token nên nằm trong biến môi trường, secret manager hoặc nơi lưu bí mật của nền tảng deploy.

Tiếp theo là kiến thức về permission. Không phải token nào cũng làm được mọi việc. Có quyền chỉ cho đọc thông tin, có quyền cho quản lý bài viết, có quyền liên quan tới tin nhắn hoặc comment. Một số quyền có thể cần app review nếu dùng ngoài phạm vi test. Vì vậy khi thiết kế agent, mình nên viết rõ skill nào cần quyền gì. Việc này giúp dễ xin quyền, dễ debug và dễ hạn chế rủi ro.

Một mảng khác là cách viết skill cho agent. Theo mình, một skill tốt nên có tên rõ, mô tả rõ khi nào dùng, input cần gì, output trả về gì và lỗi thường gặp là gì. Nếu skill là code, nó nên là một hàm hoặc module nhỏ, có thể test riêng. Nếu skill là hướng dẫn cho AI, nó nên nói rõ phạm vi và tiêu chuẩn đầu ra. Ví dụ skill đăng bài không nên kiêm luôn việc viết content, crawl dữ liệu và lưu log. Mỗi phần tách ra sẽ dễ thay đổi hơn.

Về prompt, mình nên viết theo hướng giao việc cụ thể thay vì mô tả chung chung. Một prompt tốt cho agent cần nói rõ vai trò, dữ liệu đầu vào, ràng buộc, định dạng đầu ra và khi nào phải hỏi lại. Ví dụ với bài Facebook, prompt nên có giọng văn, độ dài, đối tượng đọc, mục tiêu bài viết, những điều không được bịa và yêu cầu trả về bản nháp trước khi đăng.

Về dữ liệu, cần phân biệt dữ liệu công khai, dữ liệu nội bộ và dữ liệu khách hàng. Dữ liệu công khai như thông tin tuyển sinh có thể lấy từ web, nhưng vẫn cần kiểm tra nguồn. Dữ liệu nội bộ như bảng sản phẩm, giá, lịch đăng nên có nơi lưu ổn định. Dữ liệu khách hàng như inbox, số điện thoại, email thì cần xử lý cẩn thận hơn, chỉ lưu những gì cần thiết và hạn chế đưa vào các nơi không kiểm soát.

Cuối cùng là kiến thức về vận hành. Một agent dùng được không chỉ là một đoạn code gọi API thành công. Nó cần có log, cảnh báo lỗi, giới hạn quyền, quy trình duyệt, môi trường test, backup token, cách tắt khẩn cấp và người chịu trách nhiệm cuối cùng. Đây là phần nghe không hào nhoáng, nhưng lại quyết định agent có dùng được lâu dài hay chỉ là một demo vui.

Tổng thể

Tổng kết lại, Facebook Agent không phải một thứ quá bí ẩn. Nó là sự kết hợp giữa AI, skill, công cụ, Facebook API, bộ nhớ, lịch hẹn và cơ chế kiểm soát. Cái khó không nằm ở việc gọi AI viết vài dòng nội dung, mà nằm ở việc biến những thao tác rời rạc hằng ngày thành một quy trình có thể chạy đều, kiểm tra được và sửa được khi lỗi.

Nếu làm tốt, agent có thể giúp mình giảm rất nhiều việc lặp lại khi vận hành page: tìm dữ liệu, viết bản nháp, tổng hợp câu hỏi của khách, lên lịch đăng, ghi log và báo cáo kết quả. Nếu làm ẩu, nó cũng có thể tạo lỗi rất nhanh, nhất là khi được cấp quyền đăng bài hoặc trả lời khách. Vì vậy mình nghĩ cách đúng là bắt đầu nhỏ, chạy trên page test, giữ bước duyệt ở những chỗ quan trọng, rồi mở rộng dần.

Với mình, điểm đáng giá nhất của agent không phải là “AI thông minh cỡ nào”, mà là nó giúp biến một quy trình dễ quên, dễ sai và dễ mất sức thành một hệ thống có nhịp. Trong vận hành thật, có nhịp đôi khi quan trọng hơn rất nhiều so với vài lần chạy thật ấn tượng.