Bài viết

Khi thấy một cái tên như Hermes Agent hay OpenClaw, phản xạ phổ biến là hỏi: nó có tự động làm được việc gì? Viết mail? Đọc tài liệu? Gọi API? Mở trình duyệt? Lập kế hoạch?
Câu hỏi đó không sai, nhưng thường dẫn đội triển khai đi vào ngõ cụt. Vì một AI Agent có thể làm nhiều thứ không đồng nghĩa nó nên được giao làm tất cả. Agent càng được cấp nhiều quyền, càng cần ranh giới rõ: dữ liệu nào được đọc, hành động nào được phép thực hiện, kết quả nào cần người duyệt, lỗi nào phải dừng ngay.
Tôi nhìn Hermes Agent/OpenClaw theo một mental model đơn giản hơn: đây là một lớp thực thi giữa ý định của con người và các hệ thống đang có. Người dùng đưa mục tiêu. Agent tách việc, gọi tool, đọc dữ liệu, tạo bản nháp hoặc kích hoạt Workflow. Giá trị không nằm ở chuyện nó “thông minh như người”. Giá trị nằm ở việc nó giảm số lần con người phải chuyển qua lại giữa email, tài liệu, CRM, spreadsheet, ticket, dashboard và API.
Nghe rất hấp dẫn. Nhưng nếu đem Agent vào một quy trình đang rối, bạn chỉ có một cỗ máy chạy nhanh hơn trong mê cung. Hãy chọn những công việc có đầu vào tương đối rõ, có đầu ra kiểm tra được và có chi phí sai lầm chấp nhận được. Đó là chỗ Hermes Agent/OpenClaw có cơ hội tạo ra lợi ích thật thay vì thành một bản demo đẹp.
Agent tốt không phải Agent tự làm nhiều nhất. Agent tốt là Agent biết mình được phép làm đến đâu, biết lúc nào phải hỏi lại, và để lại dấu vết để người khác kiểm tra.
Đây là cách áp dụng thực tế nhất để bắt đầu. Một ngày làm việc của nhiều người bị cắt vụn bởi email, Slack, Telegram, chat nội bộ và các cuộc gọi. Vấn đề không phải thiếu thông tin. Vấn đề là thông tin đến lộn xộn, lẫn giữa việc cần phản hồi, việc cần giao, việc chỉ để biết và việc có thể bỏ qua.
Bạn có thể giao Hermes Agent/OpenClaw đọc một hộp thư hoặc một kênh chat đã giới hạn quyền truy cập, sau đó tạo bản tổng hợp theo cấu trúc cố định:
Đầu ra nên là một bản nháp ở Notion, Google Docs, task manager hoặc một spreadsheet. Đừng cho Agent tự gửi email trả lời ngay ở vòng đầu. Email là nơi một câu diễn đạt sai có thể làm hỏng quan hệ với khách hàng, đối tác hoặc đồng nghiệp.
Tôi sẽ đặt một rule rất khô: Agent được phép phân loại, trích xuất và soạn nháp; chưa được phép cam kết giá, deadline, chính sách hay quyết định nhân sự. Chỉ riêng rule này đã loại được một đống rủi ro ngớ ngẩn.
Nhiều cuộc họp dài vì người tham gia không có cùng dữ liệu nền. Có người đọc tài liệu trước, có người chưa. Có người biết lịch sử trao đổi với khách hàng, có người không. Mười phút đầu dành để kể lại bối cảnh, rồi đến phút thứ bốn mươi vẫn chưa ai quyết được gì.
Hermes Agent/OpenClaw có thể chuẩn bị meeting brief từ các nguồn đã được chỉ định: email liên quan, CRM, ticket hỗ trợ, tài liệu dự án, ghi chú cuộc họp cũ và lịch làm việc. Mục tiêu là tạo một trang ngắn trước giờ họp, không phải nhồi tất cả dữ liệu vào một bản tóm tắt.
Một brief hữu ích nên trả lời năm câu:
Phần cuối cùng rất quan trọng. Nếu Agent chỉ tóm tắt mà không làm rõ quyết định cần chốt, nó mới là một công cụ ghi chép. Khi nó giúp ép cuộc họp về một agenda có câu hỏi cụ thể, nó mới giúp tiết kiệm thời gian.
Điểm cần cảnh giác là nguồn dữ liệu. Một brief tạo từ thông tin cũ hoặc thiếu sẽ khiến cả nhóm tin nhầm rằng mình đang nắm toàn cảnh. Hãy buộc Agent ghi rõ nguồn tham chiếu, thời điểm lấy dữ liệu và những phần nó không tìm thấy. Tôi thà nhận một brief nói “chưa có dữ liệu” còn hơn một brief tự tin nhưng sai.
Research là loại việc Agent làm khá hợp, miễn là bạn không nhầm “tìm được nhiều trang” với “phân tích tốt”. Khi giao một AI Agent research, thứ bạn cần thiết kế đầu tiên là khung đánh giá. Nếu không, Agent sẽ trả về một bài tổng hợp mượt mà nhưng lẫn lộn giữa sự kiện, suy luận và quảng cáo.
Ví dụ, thay vì bảo “nghiên cứu đối thủ X”, hãy yêu cầu một template gồm: sản phẩm họ đang bán, nhóm khách hàng họ nhắm đến, thông điệp chính, dấu hiệu về mô hình giá, kênh phân phối, câu hỏi chưa có bằng chứng và nguồn của từng nhận định.
Hermes Agent/OpenClaw phù hợp để làm vòng thu thập đầu tiên: tìm nguồn, gom URL, trích đoạn, đưa dữ liệu về cấu trúc chung, so sánh theo bảng. Con người vẫn cần đọc phần quan trọng trước khi biến nó thành quyết định về sản phẩm hoặc chiến lược.
Tôi không tin vào kiểu report đối thủ dài mười trang nhưng không nói được: “Tuần này chúng ta nên làm gì khác đi?” Một research tốt phải tạo ra lựa chọn. Chẳng hạn: thay đổi thông điệp bán hàng, ưu tiên một nhóm khách hàng, bổ sung một tính năng, hoặc quyết định chưa nên làm gì vì bằng chứng chưa đủ.
Nếu đội bạn đang dùng dữ liệu nội bộ cùng tài liệu bên ngoài, hãy đọc thêm bài về RAG từ Zero đến Production. Agent muốn trả lời dựa trên tài liệu đáng tin cần retrieval, quyền truy cập và cách đánh giá rõ ràng; prompt hay không cứu được dữ liệu lộn xộn.
Content là khu vực nhiều người mang Agent vào sớm nhất, cũng là khu vực dễ sinh rác nhất. Lý do rất dễ hiểu: câu lệnh “viết bài về chủ đề này” thiếu gần như mọi thứ quan trọng. Thiếu độc giả, thiếu góc nhìn, thiếu ví dụ, thiếu tài liệu nguồn, thiếu quan điểm biên tập.
Cách dùng Hermes Agent/OpenClaw đáng tiền hơn là biến nó thành trợ lý biên tập có quy trình. Bạn đưa vào: brief, chân dung người đọc, tài liệu tham khảo được duyệt, cấu trúc bài, các luận điểm bắt buộc và những điều không được khẳng định. Agent có thể đề xuất outline, tìm chỗ thiếu dữ liệu, viết bản nháp đầu, tạo các phiên bản tiêu đề hoặc chuyển một bài dài thành nhiều format.
Với blog cá nhân hay đội marketing nhỏ, phần tiết kiệm nhất thường không phải đoạn văn đầu tiên. Nó là các thao tác vụn: gom note, tra lại nguồn, tách quote, rà phần trùng ý, tạo checklist xuất bản và chuẩn bị metadata.
Nhưng hãy giữ giọng nói của con người. Tôi sẽ không để Agent tự quyết định “quan điểm của tác giả”. Agent có thể giúp tìm phản biện, chỉ ra chỗ lập luận hổng hoặc đề xuất cách diễn đạt. Còn nhận định cuối cùng phải do người chịu trách nhiệm ký tên. Độc giả không quay lại vì câu chữ mượt. Họ quay lại vì bạn có một góc nhìn đáng nghe.
Support là nơi Agent có thể giúp rõ rệt vì nhiều ticket lặp lại, nhưng đây cũng là nơi sai một câu là mất khách. Hãy chia việc thành ba tầng thay vì ném toàn bộ inbox cho Agent.
Ở giai đoạn đầu, Agent không nên tự đóng ticket, hoàn tiền, thay đổi quyền truy cập hay hứa hẹn thời gian xử lý. Các hành động đó liên quan đến tiền, bảo mật và uy tín. Bạn có thể mở rộng quyền sau khi đã theo dõi đủ các trường hợp và biết loại ticket nào an toàn để tự động hóa.
Một tiêu chí hay để chọn ticket cho Agent là: câu trả lời có nằm trong knowledge base đã được phê duyệt không? Nếu có, Agent có thể trích đúng đoạn hướng dẫn và tạo câu trả lời theo tone quy định. Nếu không, Agent phải chuyển cho người thật thay vì tự bịa ra cách xử lý.
Đây là chỗ đội vận hành cần phân biệt observability với evaluation. Log cho bạn biết Agent đã gọi tool gì, đọc tài liệu nào, trả lời ra sao. Evaluation cho biết câu trả lời đó có đúng, hữu ích, an toàn và đúng policy không. Tôi đã viết kỹ hơn về hai lớp này trong bài AI App Chạy Được Nhưng Chưa Đáng Tin.
CRM của nhiều công ty nhìn thì có vẻ đầy dữ liệu, nhưng khi cần trả lời “khách nào đang có nguy cơ rời đi?” hoặc “deal nào bị đứng lâu?” thì không ai dám tin. Lý do là ghi chú nằm trong email, cuộc gọi, chat và đầu người của sales; các trường dữ liệu trong CRM lại thiếu hoặc cập nhật chậm.
Hermes Agent/OpenClaw có thể đọc các ghi chú được cấp quyền, trích xuất trường dữ liệu và đề xuất cập nhật: nhu cầu khách hàng, người quyết định, trạng thái deal, bước tiếp theo, objection, thời điểm follow-up. Từ “đề xuất” là từ cần gạch chân. Agent có thể điền sai công ty, nhầm tên người hoặc suy ra một trạng thái không hề được nói tới.
Workflow tốt sẽ tạo hàng chờ review. Người phụ trách chỉ cần duyệt các cập nhật được Agent đề xuất thay vì nhập lại tất cả từ đầu. Sau một thời gian, bạn sẽ thấy field nào có thể tự động cập nhật với rủi ro thấp, field nào luôn cần người kiểm tra.
Đừng bắt đầu bằng việc cố làm sạch toàn bộ CRM lịch sử. Chọn một luồng đang sống, ví dụ lead mới hoặc deal đang active. Khi quy trình mới đã chạy ổn, dữ liệu mới sẽ sạch dần. Cố xử lý mọi dữ liệu cũ ngay từ đầu thường là dự án dài, mệt và khó chứng minh hiệu quả.
Project management có rất nhiều việc lặp lại: tổng hợp update, nhắc owner, phát hiện task chưa có deadline, gom blocker, cập nhật status page. Đây là vùng phù hợp cho Agent vì phần lớn thao tác có cấu trúc.
Một Agent có thể lấy dữ liệu từ ticketing tool, calendar và ghi chú họp để tạo daily update: việc đã xong, việc đang kẹt, việc có nguy cơ trễ và câu hỏi cần người quyết định. Nó cũng có thể dò những ticket không có owner, task quá hạn hoặc dependency chưa được ghi nhận.
Nhưng Agent không hiểu chính trị nội bộ, mức độ ưu tiên ngầm hay lý do một người chậm phản hồi. Đừng để nó tự đánh giá hiệu suất cá nhân hoặc tự đẩy deadline chỉ vì bảng dữ liệu nói vậy. Những hành động ấy chạm vào niềm tin của đội ngũ.
Tôi sẽ dùng Agent như một thư ký dự án khó tính: nhắc đúng, ghi đúng, không quên, không ngại hỏi thiếu dữ kiện. Còn quyết định đổi phạm vi, đổi ưu tiên hay điều chuyển người vẫn là việc của người quản lý.
Nếu bạn đang nghĩ đến nhiều Agent cùng làm research, viết, kiểm tra và triển khai, hãy cẩn thận với độ phức tạp. Bài AI Agents 2026: Khi nào cần Multi-Agent và cách điều phối đúng có một điểm tôi đồng ý: multi-agent chỉ đáng dùng khi bài toán thực sự cần tách vai trò và có cơ chế điều phối rõ.
Nhiều lỗi công việc không đến từ việc thiếu kiến thức. Nó đến từ việc quên kiểm tra một điều nhỏ trong tài liệu dài: hợp đồng thiếu phụ lục, proposal chưa nêu giả định, báo cáo thiếu nguồn, yêu cầu bảo mật chưa được xác nhận, tài liệu kỹ thuật không có bước rollback.
Hermes Agent/OpenClaw có thể làm lớp kiểm tra đầu tiên bằng một checklist cố định. Bạn đưa cho nó policy hoặc tiêu chuẩn nội bộ, rồi yêu cầu đánh dấu phần nào có, phần nào thiếu, phần nào mâu thuẫn và phần nào cần người có thẩm quyền xác nhận.
Khác biệt lớn nằm ở cách đặt yêu cầu. Đừng hỏi “tài liệu này có ổn không?”. Hãy hỏi: “Theo checklist gồm các mục A, B, C, hãy trích chính xác đoạn chứng minh từng mục; nếu không có, ghi là không tìm thấy.” Câu lệnh sau buộc Agent dựa vào bằng chứng thay vì ném ra nhận xét chung chung.
Đây là ứng dụng phù hợp cho legal ops, sales ops, security review và QA tài liệu kỹ thuật. Dù vậy, Agent không thay luật sư, security engineer hay người phê duyệt. Nó giảm khối lượng rà soát thủ công; nó không chuyển trách nhiệm pháp lý sang máy.
Không ít team đang làm báo cáo tuần bằng cách mở vài dashboard, copy số liệu vào slide, hỏi từng người về status rồi ghép lại. Công việc này tốn thời gian và dễ sai vì số liệu thay đổi, định nghĩa thay đổi hoặc người tổng hợp chọn nhầm kỳ báo cáo.
Agent có thể lấy dữ liệu từ các nguồn đã xác định, chuẩn hóa thành một format, đánh dấu chênh lệch và tạo narrative ban đầu. Ví dụ, báo cáo có thể gồm số liệu theo kỳ, các thay đổi đáng chú ý, nguyên nhân đã xác nhận, giả thuyết chưa xác nhận và hành động tiếp theo.
Điểm tôi không thích ở nhiều báo cáo do LLM tạo là nó viết quá nhiều câu giải thích nghe hợp lý. Một biểu đồ đi xuống không tự nói lên nguyên nhân. Nếu không có bằng chứng, Agent phải ghi là “chưa xác nhận”, không được tự nối vài dữ kiện lại thành câu chuyện hấp dẫn.
Hãy yêu cầu đầu ra tách ba phần: fact, interpretation và question. Fact là dữ liệu có nguồn. Interpretation là cách đọc có điều kiện. Question là điều cần điều tra thêm. Chỉ cần tách như vậy, chất lượng cuộc họp review đã khác hẳn.
Ứng dụng dài hạn nhất của Hermes Agent/OpenClaw là giúp nhân viên hỏi kiến thức nội bộ theo ngôn ngữ tự nhiên: quy trình onboarding, hướng dẫn triển khai, tài liệu sản phẩm, policy, runbook, FAQ, kiến thức bán hàng. Người dùng không cần nhớ chính xác file nằm ở đâu hay keyword nào mới tìm được.
Nhưng đây không phải bài toán “upload PDF rồi chat”. Kiến thức nội bộ có phiên bản, quyền truy cập, tài liệu hết hạn và nội dung mâu thuẫn. Một Agent trả lời rất tự tin từ tài liệu cũ nguy hiểm hơn một ô search không trả về kết quả, vì người dùng dễ tin nó.
Để làm đúng, bạn cần ít nhất bốn thứ: nguồn dữ liệu rõ chủ sở hữu, phân quyền theo người dùng, câu trả lời có trích dẫn, và cơ chế báo lỗi khi Agent không chắc. Nếu tool có thể thực hiện hành động sau câu trả lời, chẳng hạn tạo ticket hay sửa cấu hình, cần tách bước hỏi đáp với bước thực thi.
Tôi nghiêng về thiết kế “read first, act later”. Giai đoạn đầu Agent chỉ đọc, tìm, giải thích và soạn nháp. Khi dữ liệu log cho thấy nó hoạt động ổn với một nhóm tác vụ cụ thể, bạn mới cấp quyền ghi hoặc gọi API. Cách này chậm hơn bản demo toàn quyền, nhưng rẻ hơn nhiều so với việc dọn hậu quả.
Nếu bạn muốn thử ngay, đừng lập danh sách mười ý tưởng rồi làm cùng lúc. Chọn một công việc thỏa phần lớn các điều kiện sau:
Ví dụ, tạo meeting brief hoặc phân loại ticket thường là use case khởi đầu tốt hơn việc cho Agent tự thương lượng với khách hàng. Lý do không phải Agent kia “thông minh hơn”. Lý do là ranh giới của việc đầu tiên rõ hơn, hậu quả khi sai thấp hơn và con người kiểm tra được nhanh hơn.
Trước khi đưa vào production, hãy viết ra một bảng ngắn gồm: Agent được đọc gì, được gọi tool gì, được ghi vào đâu, ai phê duyệt, hành động nào bị cấm, log giữ ở đâu, và tiêu chí nào khiến Workflow bị dừng. Bảng này nghe hành chính, nhưng nó là thứ ngăn dự án Agent biến thành một hệ thống không ai dám chạm vào sau vài tháng.
Theo tôi, chưa nên ở giai đoạn đầu. Hãy để Agent tạo nháp và phân loại mức độ an toàn trước. Các email xác nhận thông tin đã có sẵn có thể là nhóm đầu tiên để thử tự động hóa sau khi bạn đã review đủ mẫu. Email có cam kết thương mại, pháp lý, nhân sự hoặc xử lý khiếu nại cần người duyệt.
Thường là các việc nhiều thao tác lặp lại nhưng đầu ra đơn giản: tóm tắt inbox, chuẩn bị brief họp, phân loại ticket, tạo báo cáo status hoặc kiểm tra checklist tài liệu. Đừng chọn use case chỉ vì nghe ấn tượng. Chọn việc đang làm đội bạn tốn thời gian mỗi tuần và có tiêu chuẩn đúng-sai tương đối rõ.
Hãy buộc Agent trích nguồn cho từng nhận định quan trọng và tách fact khỏi interpretation. Nếu một kết luận không chỉ được ra đoạn nguồn, nó phải được xem là giả thuyết, không phải dữ kiện. Với tác vụ quan trọng, cần có bộ mẫu kiểm tra thực tế thay vì chỉ đọc vài câu trả lời thấy có vẻ ổn.
Không mặc định cần. Một Agent với tool calling, quyền hạn hẹp và Workflow rõ thường dễ vận hành hơn nhiều Agent nói chuyện với nhau. Chỉ tách thành nhiều Agent khi các vai trò thật sự khác nhau, ví dụ một Agent thu thập dữ liệu, một Agent kiểm tra policy và một Agent tổng hợp kết quả; đồng thời bạn có cách kiểm soát handoff giữa chúng.
Đo cả hiệu quả lẫn chất lượng. Hiệu quả có thể là thời gian xử lý, số bước thủ công hoặc số việc được xử lý. Chất lượng cần nhìn vào tỷ lệ kết quả cần sửa, lỗi phân loại, câu trả lời thiếu nguồn, hành động bị từ chối và các trường hợp Agent phải chuyển cho người. Nếu chỉ đo số task Agent hoàn thành, bạn rất dễ tối ưu nhầm thứ.
Hermes Agent/OpenClaw đáng thử khi bạn xem chúng là một phần của hệ thống làm việc, không phải một nhân viên ảo biết tuốt. Bắt đầu nhỏ, khoanh quyền hẹp, buộc đầu ra có bằng chứng và ghi lại mọi lần sai. Làm được bốn việc này, Agent có thể giúp đội bạn bớt việc vụn để tập trung vào quyết định khó. Bỏ qua chúng, bạn chỉ có thêm một nguồn tạo nội dung và hành động mà không ai kiểm soát được.
Nguồn tham khảo: cuongnguyen.ai.vn
Bài viết là góc nhìn cá nhân của tác giả, mang tính tham khảo — không phải tin tức báo chí.
Đừng bỏ lỡ bài viết tiếp theo. Đăng ký để nhận trong inbox.

Tác giả
Tôi là Cường Nguyễn - Founder của AI Ops Solutions.
Tôi từng là Logistics Operations Manager và đồng sáng lập thương hiệu CATCA - #1 Shopee ngành Pet Care.