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.
Top comments (0)