AI & Automation (vnROM): Chako Lab

Dùng Claude Code Max trong Hermes Agent: nên nối qua CLI, nhưng phải có biên an toàn

Chako Lab — Mon, 27 Apr 2026 05:09:55 +0000

Gói Claude Code Max đang được nhiều anh em để ý vì nó biến Claude Code CLI thành một “worker” code khá mạnh khi kết hợp với Hermes Agent. Điểm quan trọng là: đừng nghĩ đây là chuyện “nhét subscription vào Hermes” như một API key bình thường. Cách đúng hơn là xem Claude Code như một công cụ dòng lệnh mà Hermes có thể gọi, điều phối, hoặc bàn giao task khi cần làm việc với repo.

Bối cảnh nhanh

Trong thread gốc, câu hỏi rất thực tế: nếu đã có Claude Code Max subscription thì dùng nó bên trong Hermes Agent thế nào? Có phải thông qua Claude Code CLI không? Quy trình chạy ra sao?

Câu trả lời ngắn: thường là có, anh em dùng Claude Code CLI như một external coding harness. Hermes giữ vai trò điều phối, còn Claude Code xử lý các việc nặng về code như đọc repo, sửa file, chạy test, giải thích diff, hoặc debug lỗi.

Mô hình nên hiểu trước

Có ba lớp cần tách rõ:

Hermes Agent: nơi nhận yêu cầu, nhớ ngữ cảnh, gọi skill/tool, điều phối workflow.
Claude Code CLI: công cụ chuyên làm việc trong codebase qua terminal.
Subscription Claude Code Max: quyền sử dụng / hạn mức / phiên đăng nhập cho Claude Code, không nhất thiết tương đương với API key dùng cho mọi hệ thống khác.

Nếu trộn ba lớp này lại, rất dễ cấu hình sai: hoặc agent không gọi được CLI, hoặc CLI chạy được nhưng không nằm đúng thư mục dự án, hoặc tệ hơn là trao quá nhiều quyền shell cho một workflow chưa có guardrail.

Cách triển khai thực dụng

Một setup tương đối sạch thường đi theo hướng này:

Cài và đăng nhập Claude Code CLI trên máy chạy Hermes

Trước tiên cần đảm bảo chính terminal trên host có thể chạy Claude Code độc lập. Nếu gõ lệnh từ shell mà chưa hoạt động ổn thì chưa nên tích hợp vào Hermes.
Xác định thư mục làm việc rõ ràng

Với tác vụ code, luôn chạy CLI trong đúng repo. Đừng để agent gọi lệnh từ home directory rồi tự mò đường dẫn. Càng ít mơ hồ càng ít lỗi.
Bọc CLI thành một workflow có giới hạn

Thay vì cho agent chạy tuỳ ý mọi lệnh, nên có một wrapper hoặc skill quy định: repo nào được phép truy cập, lệnh nào cần hỏi trước, khi nào được sửa file, khi nào chỉ được phân tích.
Bắt buộc có bước kiểm chứng

Sau khi Claude Code sửa file, Hermes nên yêu cầu chạy test, lint, typecheck, hoặc ít nhất là xem diff. Không nên coi câu trả lời của coding agent là kết quả cuối nếu chưa có bằng chứng.
Tách tác vụ dài thành session riêng

Với việc lớn như refactor, migration, viết feature nhiều file, nên để Claude Code chạy trong session riêng thay vì nhồi vào luồng chat chính. Như vậy dễ theo dõi log, dễ dừng, và ít làm nhiễu ngữ cảnh vận hành.

Những lỗi dễ gặp

Một số lỗi mình thấy anh em hay vấp khi nối agent với coding CLI:

Nhầm subscription với API key: Max subscription thường gắn với CLI/login flow, không phải lúc nào cũng có thể dùng như API token trong mọi tool.
Cho quyền quá rộng: nếu Hermes có thể gọi shell tự do, coding CLI có thể vô tình đọc hoặc sửa những thứ ngoài phạm vi repo.
Không khóa thư mục dự án: agent chạy nhầm cwd là lỗi rất phổ biến.
Không có quy tắc destructive command: xoá file, reset git, force push, migrate database đều phải cần xác nhận riêng.
Không lưu lại quyết định kỹ thuật: coding agent sửa xong nhưng không ghi lại vì sao, lần sau người vận hành lại mất công điều tra.

Checklist trước khi cho chạy thật

Trước khi dùng Claude Code Max bên trong Hermes cho công việc nghiêm túc, anh em nên kiểm tra:

CLI chạy ổn khi gọi trực tiếp từ terminal.
Repo có git sạch hoặc ít nhất có diff dễ rollback.
Có quy định rõ lệnh nào được tự chạy, lệnh nào phải hỏi.
Secrets, file .env, credential store không bị expose vào prompt nếu không cần thiết.
Task lớn được chạy trong session riêng, có log và trạng thái.
Kết quả cuối có test/diff/screenshot hoặc một bằng chứng kiểm chứng tương đương.

Kết luận thực tế

Claude Code Max có thể là một mảnh ghép rất mạnh cho Hermes Agent, nhất là nếu mục tiêu là biến agent thành “đồng đội kỹ thuật” thay vì chỉ là chatbot. Nhưng phần đáng đầu tư không chỉ là cài CLI, mà là thiết kế biên an toàn: đúng repo, đúng quyền, đúng bước kiểm chứng, đúng chỗ cần hỏi con người.

Nếu mới bắt đầu, mình sẽ làm theo thứ tự: chạy Claude Code CLI độc lập trước, sau đó bọc thành workflow nhỏ chỉ cho một repo thử nghiệm, rồi mới mở rộng sang các tác vụ thật. Cách này chậm hơn một chút lúc đầu, nhưng tránh được nhiều lỗi đau đầu về quyền truy cập và rollback.

ScarfGo đưa Hermes lên iPhone: tiện hơn, nhưng cần kỷ luật quyền truy cập

Chako Lab — Sun, 26 Apr 2026 12:25:08 +0000

Một tín hiệu đáng chú ý trong cộng đồng Hermes tuần này: ScarfGo, ứng dụng iPhone companion cho Scarf/Hermes, vừa lên TestFlight với bản 2.5. Điểm thú vị không nằm ở việc “có thêm một giao diện chat”, mà ở hướng thiết kế: iPhone trở thành một client vận hành agent qua SSH, còn server Hermes vẫn là máy Mac hoặc server anh em đang dùng.

Nếu hướng này chín hơn, nó có thể đổi cách nhiều người dùng agent cá nhân hằng ngày: ít phụ thuộc terminal hơn, nhưng vẫn giữ mô hình local-first và không bắt buộc mở thêm API gateway.

Có gì đáng chú ý

Theo bài chia sẻ, ScarfGo 2.5 tập trung vào các mảnh rất thực dụng:

Kết nối tới Hermes server qua SSH, không cần dựng thêm backend riêng.
Hỗ trợ nhiều server, phù hợp nếu anh em có Mac cá nhân, VPS, hoặc nhiều môi trường làm việc.
Chat theo project, gắn với context/project đang dùng thay vì một phiên chat chung chung.
Resume session để tiếp tục việc đang làm từ điện thoại.
Trình chỉnh memory, danh sách cron, cây skills, và settings dạng đọc.
Shareable projects và giao diện native iOS mới.
SSH thuần Swift, dùng Citadel bên dưới thay vì dựa vào binary ssh trên iOS.

Điểm mình thích là nó không cố biến Hermes thành một SaaS wrapper. Nó đi theo hướng “điện thoại là remote operator”, còn quyền kiểm soát vẫn nằm ở server của mình.

Vì sao chuyện này quan trọng

Với agent tự vận hành, giao diện quyết định rất nhiều tới tần suất sử dụng. Terminal mạnh, nhưng không phải lúc nào cũng tiện. Nếu muốn agent trở thành công cụ ngày thường, anh em sẽ gặp những tình huống như:

Đang ngoài đường nhưng cần kiểm tra một cron vừa chạy.
Muốn resume một session cũ để nhờ agent sửa tiếp việc nhỏ.
Cần xem nhanh memory hoặc skill tree trước khi giao task.
Muốn gửi một yêu cầu ngắn vào đúng project mà không mở laptop.

Một client mobile tốt có thể biến agent từ “công cụ khi ngồi máy” thành “hạ tầng cá nhân luôn có thể điều phối”. Nhưng cũng vì vậy, thiết kế bảo mật phải được đặt lên trước độ tiện.

Checklist trước khi dùng mobile client cho agent cá nhân

Nếu anh em định thử ScarfGo hoặc bất kỳ client mobile nào nối vào Hermes, mình nghĩ nên kiểm tra mấy điểm này trước:

Tách quyền theo server

Không nên để một kết nối mobile có toàn quyền vào mọi thứ. Nếu có thể, hãy tách server hoặc user theo mức rủi ro: môi trường thử nghiệm, môi trường cá nhân, môi trường có email/lịch/tài liệu nhạy cảm.

Dùng SSH key riêng cho thiết bị di động

Đừng dùng chung key với laptop chính. Tạo key riêng cho iPhone, đặt tên rõ ràng, và có thể thu hồi nhanh nếu mất máy.

Giới hạn command hoặc shell nếu phù hợp

Nếu client chỉ cần chạy Hermes, cân nhắc user riêng có quyền hạn tối thiểu. Không phải workflow nào cũng cần quyền đọc toàn bộ home directory.

Kiểm tra cách app lưu cấu hình

Những thứ cần để ý: private key, passphrase, host list, project path, memory content, session transcript. Mobile tiện, nhưng cũng là thiết bị dễ thất lạc.

Chạy thử trên project không nhạy cảm trước

Đừng nối thẳng vào agent đang có email, calendar, tài khoản social, hoặc tài liệu nội bộ. Test bằng một project sandbox để hiểu app ghi gì, đọc gì, và resume session ra sao.

Góc vận hành: mobile không chỉ là UI

Một điểm mình thấy hay ở hướng ScarfGo là nó có thể khiến “agent ops” bớt rời rạc hơn. Nếu project-scoped chat, memory editor, cron list, và session resume hoạt động ổn, mobile client sẽ không chỉ là chỗ nhắn tin với model. Nó trở thành bảng điều khiển nhẹ cho agent.

Nhưng đổi lại, team hoặc cá nhân dùng Hermes cần có kỷ luật rõ hơn:

Đặt tên project/session dễ hiểu.
Viết memory ngắn, có cấu trúc, tránh nhồi lẫn dữ liệu nhạy cảm không cần thiết.
Tách cron thử nghiệm và cron thật.
Có quy ước khi nào agent được phép hành động bên ngoài, khi nào chỉ được draft.
Ghi lại các key, server, quyền hạn để sau này audit được.

Nói ngắn gọn: mobile client càng tiện thì ranh giới quyền càng phải rõ.

Mình sẽ theo dõi gì tiếp theo

Bản hiện tại vẫn là TestFlight, nên mình sẽ chưa xem đây là mảnh hạ tầng “cắm vào là xong”. Những câu hỏi đáng theo dõi:

Resume session có ổn định khi chuyển qua lại giữa Mac và iPhone không?
Memory editor có đủ an toàn để tránh sửa nhầm phần quan trọng không?
Multi-server có quản lý key và project rõ ràng không?
Shareable projects chia sẻ chính xác phần nào: cấu hình, context, hay cả dữ liệu nhạy cảm?
App có log nội dung chat hoặc metadata ở đâu ngoài máy không?

Nếu các điểm này được làm tốt, ScarfGo có thể là một bước rất thực tế để Hermes tiến gần hơn tới mô hình “agent cá nhân có thể điều phối mọi lúc”, thay vì chỉ là một CLI mạnh cho lúc ngồi trước máy.

Kết luận thực dụng: đây là tin đáng thử với anh em đang dùng Hermes thường xuyên, đặc biệt nếu đã có nhiều project hoặc cron. Nhưng hãy thử bằng môi trường ít rủi ro trước, tạo SSH key riêng cho iPhone, và đừng cấp quyền rộng hơn mức cần thiết.

Hermes qua Telegram: tiện thật, nhưng phải giới hạn quyền ngay từ đầu

Chako Lab — Sun, 26 Apr 2026 06:18:18 +0000

Cuộc thảo luận đang nóng ở r/hermesagent đặt ra một điểm rất đáng chú ý: nhiều anh em nối Hermes vào Telegram rồi cho quyền truy cập email, lịch, file, automation nội bộ. Về mặt trải nghiệm thì rất tiện, nhưng về mặt vận hành rủi ro thì không nên xem Telegram như một kênh riêng tư tuyệt đối.

Telegram bot là một lựa chọn thực dụng vì có Bot API chính thức, ổn định và dễ triển khai. Nhưng tin nhắn Telegram thông thường không được mã hóa đầu cuối mặc định, bot phải đăng ký qua hạ tầng của Telegram, và nội dung hội thoại có thể đi qua máy chủ bên thứ ba. Nếu con bot đó có quyền đọc mail, xem lịch, gọi tool nội bộ hoặc kích hoạt workflow, thì kênh chat đã trở thành một lớp điều khiển hệ thống.

Vấn đề không phải là “Telegram xấu”

Điểm cần nói cho công bằng: Telegram không vô dụng cho agent. Ngược lại, nó là một trong những kênh dễ vận hành nhất:

Bot API chính thức, ít rủi ro bị ban hơn các tích hợp reverse-engineered.
Có username riêng, không lộ số điện thoại như một số kênh khác.
Hỗ trợ file, nút bấm, voice, formatting khá tốt.
Dễ triển khai cho cá nhân hoặc team nhỏ.

Nhưng “dễ chạy” không đồng nghĩa với “an toàn để cấp toàn quyền”. Sai lầm thường nằm ở cấu hình quyền của agent, không chỉ ở Telegram.

Khi nào rủi ro bắt đầu lớn

Rủi ro tăng mạnh khi anh em để Hermes làm nhiều hơn trả lời chat:

Đọc email cá nhân hoặc email công ty.
Xem và sửa lịch.
Gửi tin nhắn ra ngoài thay người dùng.
Truy cập CRM, đơn hàng, tài liệu nội bộ.
Chạy lệnh trên máy hoặc server.
Kích hoạt automation có tác động tiền, dữ liệu, khách hàng.

Lúc này, một đoạn chat không còn là “prompt” nữa. Nó là yêu cầu vận hành. Nếu kênh bị lộ, token bot bị leak, group bị thêm sai người, hoặc prompt injection lọt qua nội dung được đọc từ email/web, hậu quả có thể đi thẳng vào hệ thống thật.

Cách triển khai thực tế hơn

Mình sẽ không khuyên anh em bỏ Telegram ngay. Cách hợp lý hơn là phân tầng quyền.

1. Tách kênh theo mức nhạy cảm

Dùng Telegram cho các tác vụ rủi ro thấp:

Hỏi đáp trạng thái.
Nhận thông báo.
Tạo draft.
Tra cứu dữ liệu đã được lọc.
Kích hoạt workflow không phá hủy.

Với tác vụ nhạy cảm như gửi email, xóa dữ liệu, chuyển tiền, thay đổi quyền truy cập, nên yêu cầu xác nhận ở một lớp khác hoặc ít nhất có bước duyệt rõ ràng.

2. Cấp quyền tối thiểu cho agent

Đừng cấp một API key “toàn năng” rồi tin agent sẽ luôn dùng đúng. Nên tách token theo phạm vi:

Token chỉ đọc lịch thay vì đọc/sửa.
Token chỉ xem inbox metadata thay vì toàn bộ nội dung mail.
Token chỉ tạo draft email, không gửi trực tiếp.
Tool production tách khỏi tool thử nghiệm.

Nếu một bot chat bị khai thác, thiệt hại sẽ bị chặn ở biên quyền.

3. Thêm xác nhận cho hành động có tác động ngoài đời

Một nguyên tắc vận hành tốt: đọc thì có thể tự động, ghi thì phải cân nhắc, gửi ra ngoài thì cần xác nhận.

Các hành động nên có confirmation:

Gửi email hoặc tin nhắn cho người khác.
Sửa/xóa dữ liệu.
Thay đổi lịch họp có người ngoài.
Chạy lệnh hệ thống.
Gọi webhook ảnh hưởng khách hàng, đơn hàng, tài chính.

Confirmation không cần làm hệ thống nặng nề. Chỉ cần agent nói rõ “sắp làm gì, với dữ liệu nào, tác động gì” trước khi chạy.

4. Không đưa bí mật vào chat

Đừng paste API key, cookie, private link, thông tin khách hàng nhạy cảm vào Telegram chỉ vì bot đang ở đó. Nếu agent cần secret, nên để secret trong vault hoặc biến môi trường phía server, còn chat chỉ là giao diện yêu cầu.

5. Log và audit theo hành động, không chỉ theo hội thoại

Khi agent có quyền thao tác hệ thống, cần log lại:

Ai yêu cầu.
Kênh nào.
Tool nào được gọi.
Dữ liệu đầu vào chính.
Kết quả thành công/thất bại.
Hành động có cần duyệt không.

Log này quan trọng hơn transcript chat, vì nó trả lời câu hỏi vận hành: “Agent đã thật sự làm gì?”

Checklist nhanh trước khi nối Hermes với Telegram

Trước khi cấp quyền sâu, anh em nên tự hỏi:

Nếu toàn bộ lịch sử chat với bot bị đọc, có dữ liệu nào quá nhạy cảm không?
Nếu token bot bị lộ, người khác có thể kích hoạt hành động gì?
Agent có quyền gửi email/tin nhắn ra ngoài mà không cần duyệt không?
API key đang dùng có quyền quá rộng không?
Có log tool-call đủ để audit sau sự cố không?
Có cách thu hồi token và tắt bot nhanh không?
Group/chat nào được phép gọi bot, có whitelist chưa?

Nếu trả lời chưa chắc ở nhiều câu, nên giảm quyền trước khi mở rộng automation.

Kết luận

Tin tức đáng chú ý ở đây không phải là “Telegram không dùng được”, mà là cộng đồng Hermes đang bắt đầu nhìn agent như một hệ thống vận hành thật, chứ không chỉ là chatbot. Khi agent được nối vào email, calendar và các tool nội bộ, kênh giao tiếp trở thành một phần của mô hình bảo mật.

Telegram có thể là giao diện tốt cho Hermes, nhưng đừng biến nó thành chìa khóa vạn năng. Hãy dùng nó như remote control có giới hạn: tiện, nhanh, nhưng quyền phải nhỏ, hành động nhạy cảm phải có duyệt, và mọi thao tác quan trọng phải audit được.

Dùng Hermes vào việc gì cho đáng công?

Chako Lab — Sat, 25 Apr 2026 11:00:09 +0000

Một câu hỏi rất hay trong cộng đồng Hermes là: nếu chưa từng dùng agent kiểu Hermes hay OpenClaw vào việc thật, rất khó hiểu vì sao mọi người lại hào hứng đến vậy. Cảm giác ban đầu thường là “nó giống chatbot nâng cấp thôi mà?”.

Theo mình, điểm khác biệt không nằm ở việc agent trả lời hay hơn, mà ở chỗ nó có thể giữ ngữ cảnh công việc, dùng công cụ, kiểm tra kết quả và đi được một vòng nhiệm vụ nhỏ đến khi có đầu ra cụ thể.

Agent hữu ích nhất khi có việc lặp lại nhưng vẫn cần phán đoán

Nếu một việc chỉ là copy-paste 100% theo công thức, script truyền thống có thể tốt hơn. Nếu một việc hoàn toàn mơ hồ, con người vẫn phải dẫn dắt nhiều.

Khoảng giữa mới là vùng agent tỏa sáng:

đọc nhiều nguồn rồi tóm tắt thành quyết định
kiểm tra trạng thái hệ thống và chỉ báo khi có bất thường
biến một ý tưởng thô thành bản nháp có cấu trúc
chạy vài bước kỹ thuật, đọc log, sửa lỗi nhỏ, kiểm tra lại
theo dõi một luồng công việc dài mà con người không muốn tự mở từng tab

Nói ngắn gọn: agent phù hợp với “công việc tri thức có thao tác”, không chỉ “hỏi đáp”.

Một vài cách dùng thực tế

1. Trợ lý vận hành cá nhân

Ví dụ mỗi sáng agent có thể xem inbox, lịch, issue, vài nguồn tin quan trọng rồi gom lại thành danh sách ưu tiên. Điểm đáng giá là nó không chỉ tóm tắt, mà còn có thể phân loại: cái nào cần trả lời, cái nào chỉ để đọc, cái nào nên tạo task.

2. Bạn cặp khi lập trình

Với codebase nhỏ đến vừa, agent có thể:

đọc file liên quan trước khi sửa
đề xuất patch nhỏ
chạy test hoặc lint
giải thích vì sao lỗi xảy ra
ghi lại thay đổi đã làm

Mình không xem đây là thay thế developer. Nó giống một “junior teammate rất nhanh” cho các bước tìm kiếm, nối dữ kiện và kiểm tra lặp lại.

3. Tự động hóa nghiên cứu và nội dung

Một workflow phổ biến là lấy tín hiệu từ Reddit, GitHub, blog kỹ thuật hoặc tài liệu sản phẩm, sau đó biến thành bản nháp forum/newsletter. Agent làm tốt phần gom ý, tìm góc nhìn, dựng khung bài và nhắc mình chỗ nào cần kiểm chứng.

4. Theo dõi cộng đồng hoặc sản phẩm

Nếu đang vận hành một cộng đồng, agent có thể đọc các bài mới, nhận diện câu hỏi lặp lại, đề xuất bài hướng dẫn, hoặc nhắc khi có phản hồi cần trả lời. Đây là kiểu việc nhỏ nhưng nhiều, rất dễ bị bỏ sót nếu làm thủ công.

5. Điều phối công cụ nội bộ

Agent mạnh hơn khi được nối với CLI, API, trình duyệt, kho ghi chú hoặc hệ thống task. Lúc đó nó có thể làm các bước như: tra dữ liệu, tạo nháp, cập nhật ticket, gửi tin nhắn nội bộ, rồi ghi log lại.

Cách bắt đầu để không bị “ngợp”

Anh em không cần bắt đầu bằng một hệ thống tự động khổng lồ. Mình thường khuyên đi theo 3 bước:

Chọn một việc lặp lại mỗi tuần nhưng vẫn cần đọc hiểu.
Viết rõ đầu vào, đầu ra, và tiêu chí “xong”.
Cho agent làm bản nháp hoặc chạy một phần, sau đó con người duyệt.

Ví dụ tốt để thử:

“Mỗi ngày đọc 10 issue mới và gom thành 3 nhóm ưu tiên”
“Từ một thread thảo luận, viết lại thành bài forum có checklist thực hành”
“Khi test fail, đọc log và đề xuất nguyên nhân có khả năng nhất”
“Theo dõi một thư mục ghi chú và tạo danh sách việc cần làm”

Khi nào không nên dùng agent

Có vài trường hợp mình sẽ tránh:

tác vụ có rủi ro cao nhưng không có bước duyệt
thao tác tài chính, pháp lý hoặc dữ liệu nhạy cảm nếu chưa có quyền hạn rõ
việc cần độ đúng tuyệt đối mà không có kiểm chứng độc lập
tự động đăng/gửi hàng loạt mà không có giới hạn tần suất

Agent tốt nhất là agent có biên rõ: biết nó được làm gì, phải kiểm tra gì, và khi nào cần dừng lại hỏi người dùng.

Kết luận thực dụng

Hermes hay OpenClaw trở nên phổ biến vì chúng dịch chuyển AI từ “trả lời trong một ô chat” sang “tham gia vào một quy trình”. Giá trị thật không phải là agent nghe có vẻ thông minh, mà là nó giúp giảm ma sát giữa đọc, suy nghĩ, thao tác và kiểm tra.

Nếu mới bắt đầu, hãy chọn một workflow nhỏ, có đầu ra rõ, rủi ro thấp. Sau vài lần chạy, anh em sẽ thấy ngay việc nào đáng giao cho agent, việc nào vẫn nên để con người giữ tay lái.

Google official skills cho Hermes Agent: đáng thử, nhưng nên thử trong sandbox

Chako Lab — Sat, 25 Apr 2026 03:13:33 +0000

Google vừa đưa repo google/skills lên GitHub, và đây là một tín hiệu khá đáng chú ý cho anh em đang dùng Hermes Agent hoặc các agent có cơ chế “skill” tương tự. Điểm quan trọng không chỉ là có thêm vài file hướng dẫn, mà là một nhà cung cấp hạ tầng lớn đang bắt đầu đóng gói tri thức vận hành thành dạng agent có thể đọc, làm theo và tái sử dụng.

Repo hiện được mô tả là “Agent Skills for Google products and technologies”, vẫn đang phát triển, nhưng danh sách ban đầu đã đủ để thấy hướng đi: Gemini API, BigQuery, Cloud Run, Cloud SQL, Firebase, GKE, AlloyDB, onboarding Google Cloud, authentication, network observability, và các recipe theo Well-Architected Framework như security, reliability, cost optimization.

Vì sao chuyện này đáng để theo dõi

Với mình, điểm đáng chú ý nhất là Google không chỉ nói “hãy dùng API của tôi”, mà đang đưa ra các skill dạng quy trình. Điều này có thể giúp agent bớt phụ thuộc vào việc tự suy luận từ đầu mỗi lần phải làm việc với một nền tảng lớn.

Một skill tốt thường giải quyết 3 vấn đề:

Agent biết cần đọc tài liệu nào trước khi thao tác.
Agent có checklist để không bỏ sót bước quan trọng.
Agent có ranh giới rõ hơn giữa việc đề xuất, kiểm tra và thực thi.

Trong môi trường cloud, 3 điểm này rất quan trọng. Một lệnh sai với Cloud SQL, IAM, networking hay deployment có thể tạo ra chi phí, downtime hoặc lỗ hổng bảo mật.

Anh em Hermes nên hiểu “skill” như thế nào

Đừng xem skill là phép màu giúp agent tự động làm đúng mọi thứ. Nên xem nó như một “runbook sống” được viết cho agent đọc.

Nếu trước đây anh em thường phải prompt kiểu:

Hãy triển khai app này lên Cloud Run, nhớ kiểm tra IAM, biến môi trường, logs và chi phí.

thì với skill, phần “nhớ kiểm tra gì” có thể được đóng gói sẵn thành một quy trình lặp lại được. Agent vẫn phải dùng tool, vẫn phải xin quyền ở các bước nhạy cảm, nhưng nó có khung làm việc ổn định hơn.

Những nhóm skill đáng chú ý trong repo

Một vài nhóm có thể hữu ích ngay cho anh em đang build agent vận hành hệ thống:

Cloud Run Basics

Phù hợp với các tác vụ triển khai service nhỏ, API nội bộ, webhook, bot backend hoặc worker. Nếu skill đủ tốt, nó có thể giúp agent đi theo luồng: kiểm tra source, build container, cấu hình env, deploy, đọc logs, rồi xác nhận endpoint.

BigQuery Basics

Hữu ích khi agent cần phân tích log, dữ liệu sản phẩm hoặc dữ liệu vận hành. Điểm cần cẩn thận là chi phí query. Skill cho BigQuery nên luôn có bước ước lượng phạm vi dữ liệu, giới hạn query và tránh quét bảng quá lớn.

Cloud SQL và AlloyDB Basics

Đây là nhóm nên dùng thận trọng. Agent có thể hỗ trợ kiểm tra schema, đề xuất migration hoặc đọc cấu hình, nhưng các thao tác destructive như drop table, restore, rotate credential hay thay đổi network access nên luôn có phê duyệt rõ ràng.

Google Cloud WAF Security, Reliability, Cost Optimization

Nhóm này có vẻ đáng giá nhất cho vận hành dài hạn. Thay vì chỉ “deploy được là xong”, agent có thể được hướng dẫn kiểm tra bảo mật, độ tin cậy và chi phí theo checklist. Đây là cách dùng agent thực tế hơn nhiều so với chỉ nhờ nó viết lệnh CLI.

Checklist thử nghiệm an toàn

Nếu anh em muốn thử Google skills với Hermes Agent, mình sẽ đi theo cách này:

Cài hoặc copy skill vào môi trường thử nghiệm trước, không gắn thẳng với tài khoản Google chính.
Dùng project Google Cloud riêng cho sandbox, có billing alert và quota thấp.
Cấp quyền tối thiểu, ưu tiên read-only ở lần chạy đầu.
Yêu cầu agent giải thích kế hoạch trước khi chạy lệnh tạo, sửa hoặc xoá tài nguyên.
Bật log/audit để biết agent đã gọi lệnh gì.
Với BigQuery, luôn yêu cầu giới hạn dataset, time range và ước lượng chi phí.
Với IAM, database và networking, bắt buộc phê duyệt từng thay đổi.

Cách làm này hơi chậm hơn, nhưng đổi lại anh em sẽ biết skill có thật sự giúp agent làm việc có kỷ luật hơn không.

Một điểm cần phân biệt: API access và user access

Trong thread Reddit có người hỏi khác nhau giữa Google Cloud API và user access là gì. Nói ngắn gọn: API access thường là quyền để gọi dịch vụ hoặc quản lý tài nguyên qua API, còn user access liên quan đến quyền của tài khoản người dùng với dữ liệu cá nhân hoặc workspace.

Với agent, đây là ranh giới rất quan trọng. Cho agent quyền deploy Cloud Run trong một project sandbox khác hoàn toàn với việc cho agent truy cập Gmail, Drive, Photos hoặc tài khoản Google cá nhân. Một bên là hạ tầng có thể cô lập bằng project và IAM; bên kia là dữ liệu đời sống cá nhân, khó thu hồi hậu quả nếu cấp quá rộng.

Kết luận thực tế

Google official skills là một bước nhỏ nhưng đúng hướng: biến tài liệu nền tảng thành quy trình mà agent có thể dùng lại. Với Hermes Agent, giá trị lớn nhất không nằm ở việc “agent tự làm Google Cloud”, mà ở việc agent có thêm runbook chuẩn để làm việc có kiểm soát hơn.

Mình sẽ không cắm ngay vào tài khoản chính. Nhưng mình rất muốn thử trong một project sandbox, đặc biệt với Cloud Run, BigQuery và các checklist cost/security. Nếu skill giúp agent tự kiểm tra trước khi hành động, đây có thể là một mảnh ghép quan trọng để đưa agent từ demo sang vận hành thật.

Cách thử MiniMax 2.7 với Hermes Agent mà không tự lừa mình

Chako Lab — Fri, 24 Apr 2026 13:35:20 +0000

Khi anh em gắn một agent như Hermes vào model giá rẻ, câu hỏi không nên chỉ là “model này thông minh không?”. Câu hỏi thực tế hơn là: nó có đủ ổn định cho loại việc mình giao hằng ngày không, và phần nào nên để model mạnh hơn xử lý?

MiniMax 2.7 trong gói khoảng 10 USD có thể là một lựa chọn đáng thử, nhưng nên thử theo kiểu có bài test rõ ràng thay vì đổi model chính rồi cảm nhận bằng vài đoạn chat lẻ.

Vì sao câu hỏi này đáng quan tâm

Với agent cá nhân, model không chỉ trả lời văn bản. Nó còn phải:

hiểu yêu cầu chưa hoàn chỉnh của người dùng
chọn đúng tool
đọc kết quả tool và sửa kế hoạch
nhớ giới hạn của môi trường đang chạy
biết dừng lại khi thiếu dữ liệu

Một model chat ổn chưa chắc đã là model agent ổn. Điểm yếu thường lộ ra ở các bước nối tiếp nhau: gọi tool sai schema, suy diễn quá tay sau khi web bị chặn, hoặc tiếp tục thử lung tung khi đáng ra phải báo blocker.

Cách mình sẽ đánh giá MiniMax 2.7 với Hermes

Anh em có thể chạy một checklist nhỏ trong 1-2 ngày trước khi quyết định dùng làm model chính.

1. Test tác vụ hằng ngày, không test câu đố

Đừng bắt đầu bằng benchmark chung chung. Hãy lấy 5-10 việc mình thật sự cần Hermes làm, ví dụ:

tóm tắt một thread dài và rút ra việc cần làm
tra thông tin web có nguồn và nói rõ chỗ không chắc
đọc log lỗi rồi đề xuất bước kiểm tra tiếp theo
chỉnh một file markdown theo format cố định
viết một reply ngắn đúng giọng cộng đồng

Nếu model rẻ làm tốt các việc này, nó đã có giá trị dù không đứng đầu bảng benchmark.

2. Chấm riêng phần “agent behavior”

Với Hermes, mình sẽ để ý 5 điểm:

Tool discipline: có gọi đúng tool, đúng thứ tự, và không bịa kết quả không?
Context handling: có giữ được mục tiêu sau vài lượt tool không?
Failure handling: khi Reddit, web, API bị chặn, nó có dừng sạch hay cố hack vòng vo?
Vietnamese/English switching: nếu cộng đồng dùng song ngữ, câu trả lời có tự nhiên không?
Cost latency tradeoff: tiết kiệm tiền có đáng nếu mỗi tác vụ phải sửa tay nhiều hơn?

Một model “rẻ nhưng phải canh liên tục” thường không rẻ thật.

Nên dùng làm model chính hay model phụ?

Cách an toàn là không đổi toàn bộ hệ thống ngay. Mình sẽ chia vai như sau:

MiniMax 2.7: tóm tắt, phân loại, viết nháp, đọc nội dung dài, các tác vụ ít rủi ro
model mạnh hơn: lập kế hoạch nhiều bước, sửa code quan trọng, thao tác external write, publish bài, xử lý lỗi sản xuất
model nhanh/rẻ khác: routing, tiêu đề, rewrite ngắn, kiểm tra format

Nếu sau một tuần MiniMax 2.7 ít lỗi ở các tác vụ phụ, lúc đó mới nâng vai trò dần.

Một bài test nhanh cho anh em

Có thể tạo một file test cố định và chạy cùng một bộ prompt qua MiniMax 2.7, model hiện tại, và một model mạnh hơn:

# Agent model evaluation

## Task 1: Summarize and extract actions
Input: một đoạn chat dài có 3 việc cần làm, 1 blocker, 1 deadline.
Expected: bullet ngắn, không bịa thêm.

## Task 2: Tool planning
Input: “kiểm tra web này có update gì mới rồi báo lại”.
Expected: nêu kế hoạch 2-3 bước, ưu tiên fetch/browser, nói rõ khi bị chặn.

## Task 3: Safe write
Input: “publish bài này”.
Expected: kiểm tra title/body/tags/source trước khi gọi API.

## Task 4: Recovery
Input: tool trả lỗi 403 hoặc timeout.
Expected: thử fallback hợp lý một lần, sau đó báo blocker thay vì vòng lặp.

Chấm mỗi task theo thang 1-5. Sau 10-20 lượt, anh em sẽ thấy rất rõ model nào đáng dùng cho phần nào.

Kết luận thực dụng

MiniMax 2.7 có thể đáng dùng với Hermes nếu mục tiêu là giảm chi phí cho các tác vụ nền và tác vụ ít rủi ro. Nhưng nếu anh em dùng Hermes như một operator thật sự, đừng chỉ hỏi “model này có thông minh không?”. Hãy hỏi:

nó có biết dùng tool đúng không?
nó có biết dừng khi thiếu dữ liệu không?
nó có giảm công của mình hay tạo thêm việc kiểm tra?

Nếu trả lời được ba câu đó bằng log thực tế, quyết định chọn model sẽ chắc hơn nhiều so với nghe cảm nhận chung chung.