Cline Hooks Thực Chiến: Chặn Tool, Chạy Kiểm Tra Và Ghi Log AI Agent

Một AI coding agent có thể đọc repository, sửa file và chạy lệnh nhanh hơn con người, nhưng chính tốc độ đó làm lộ ra một khoảng trống: phần lớn quy tắc vận hành chỉ tồn tại dưới dạng lời nhắc. Khi agent chuẩn bị chạy một lệnh nguy hiểm, khi một tool vừa thay đổi mã nguồn hoặc khi cuộc trò chuyện sắp bị rút gọn vì chạm giới hạn context, bạn cần một lớp kiểm soát có thể chạy tự động và trả về kết quả xác định. Cline Hooks được thiết kế cho đúng khoảng trống này.

Hooks là các script thực thi tại những điểm cụ thể trong vòng đời của Cline. Chúng nhận dữ liệu JSON qua standard input, có thể kiểm tra ngữ cảnh, ghi log, chạy validator hoặc chặn hành động, rồi trả JSON qua standard output. Khác với Cline Rules vốn hướng dẫn model nên hành xử thế nào, Hook là mã chạy thật. Điều đó biến một nguyên tắc như “không sửa file migration đã phát hành” thành một cổng kiểm tra có thể từ chối tool call trước khi thay đổi xảy ra.

Bài viết này tập trung vào cách dùng Cline Hooks cho workflow Vibe Coding có kiểm soát: xác định đúng điểm kích hoạt, tổ chức hook toàn cục và hook theo dự án, xây luồng kiểm tra trước và sau tool, giữ context, kết nối với CLI và notebook, đồng thời tránh biến automation thành một nguồn rủi ro mới.

Cline Hooks giải quyết vấn đề gì?

Agent coding thường có ba lớp hành vi. Lớp thứ nhất là prompt và Rules, nơi bạn mô tả tiêu chuẩn code, cấu trúc thư mục hoặc giới hạn phạm vi. Lớp thứ hai là tool, nơi agent đọc file, ghi file, chạy terminal, dùng browser hoặc gọi MCP. Lớp thứ ba là hệ thống kiểm tra bên ngoài như test, linter, CI và audit log. Nếu không có cầu nối, ba lớp này hoạt động rời nhau: Rules có thể bị hiểu sai, tool có thể chạy trước khi validator kịp phản hồi và CI chỉ phát hiện lỗi sau khi thay đổi đã được đẩy đi.

Hooks tạo cầu nối theo sự kiện. Một PreToolUse hook chạy trước tool và có thể chặn hành động. PostToolUse chạy sau tool để kiểm tra kết quả hoặc đưa thêm thông tin trở lại cuộc trò chuyện. TaskStart và TaskResume có thể nạp bối cảnh dự án. PreCompact có thể lưu lại trạng thái trước khi lịch sử hội thoại được rút gọn. Vì điểm chạy được xác định trước, cùng một policy có thể được áp dụng lặp lại mà không phụ thuộc model có “nhớ” hay không.

Điều này đặc biệt hữu ích với repository có nhiều người, nhiều agent hoặc nhiều môi trường. Một hook đặt trong dự án có thể được review như code và đi cùng repository. Một hook toàn cục có thể bảo vệ máy cá nhân trước các lỗi phổ biến, chẳng hạn từ chối lệnh chạm vào thư mục chứa credential. Tuy nhiên, hook không thay thế sandbox, phân quyền hệ điều hành hay branch protection. Nó là một lớp kiểm soát bổ sung ở bên trong quy trình Cline.

Tám điểm kích hoạt trong vòng đời agent

Tài liệu Cline hiện mô tả tám hook type. Bốn loại gắn với vòng đời tác vụ là TaskStart, TaskResume, TaskComplete và TaskCancel. Ba loại gắn trực tiếp với tương tác và tool là UserPromptSubmit, PreToolUse và PostToolUse. Loại còn lại, PreCompact, chạy trước khi Cline thu gọn lịch sử để giải phóng context.

Không phải dự án nào cũng cần đủ tám loại. Cách an toàn là bắt đầu từ một rủi ro có thể mô tả rõ và chọn hook gần hành động nhất. Nếu muốn ngăn một lệnh terminal, dùng PreToolUse. Nếu muốn chạy test sau khi file được sửa, dùng PostToolUse. Nếu muốn nạp ticket, conventions và trạng thái triển khai khi bắt đầu, dùng TaskStart. Nếu muốn lưu một bản tóm tắt trước khi context bị rút gọn, dùng PreCompact.

Một sai lầm phổ biến là dùng PostToolUse để “bảo vệ” hành động nguy hiểm. Hook này chạy sau khi tool hoàn tất, nên dù có trả cancel: true, nó không thể hoàn tác lệnh vừa chạy. Hãy dùng nó cho audit, validation và hướng dẫn phục hồi; còn chặn thay đổi phải xảy ra ở PreToolUse hoặc ở lớp phân quyền thấp hơn.

Chuẩn bị môi trường trước khi bật automation

Cline hiện có nhiều bề mặt sử dụng, gồm extension trong IDE và CLI. Repository chính thức là mã nguồn mở theo Apache License 2.0, nhưng “mã nguồn mở” không đồng nghĩa mọi cấu hình đều tự host hoàn toàn. Cline vẫn cần một model provider; dữ liệu đi đâu phụ thuộc provider, endpoint và model bạn chọn. Nếu tổ chức yêu cầu dữ liệu không rời mạng nội bộ, cần kết hợp Cline với model hoặc gateway đáp ứng yêu cầu đó, thay vì chỉ dựa vào license của client.

Trước khi viết hook, hãy xác định bốn biên: hook được phép đọc gì, được phép thực thi gì, kết quả được ghi ở đâu và ai có thể sửa script. Một hook chạy với quyền của tiến trình Cline. Nếu script gọi shell, đọc biến môi trường hoặc gửi request mạng, nó có thể tiếp cận nhiều dữ liệu hơn mức bạn dự định. Vì vậy không nên nhúng API key vào hook, không ghi toàn bộ prompt hoặc source code vào log mặc định và không chạy hook tải script từ URL không cố định.

Với team, nên xem hook như một thành phần của supply chain. Script phải nằm trong version control, có owner, review, test và cách tắt khẩn cấp. Hook toàn cục do từng developer kiểm soát cần được ghi trong tài liệu onboarding. Hook theo dự án cần có tên dễ hiểu, mô tả rõ lý do chặn và giới hạn thời gian chạy để không làm agent bị treo.

Hook toàn cục và hook theo dự án

Cline phân biệt hai nơi lưu. Hook toàn cục nằm trong thư mục ~/Documents/Cline/Hooks/, áp dụng cho các workspace trên máy. Hook theo dự án nằm ở .clinerules/hooks/ trong repository và có thể được commit để cả team dùng chung. Khi cùng một loại tồn tại ở cả hai nơi, tài liệu Cline cho biết hook toàn cục chạy trước, sau đó đến hook của workspace. Nếu một trong hai trả kết quả chặn, thao tác dừng lại.

Phân chia hợp lý là đặt guardrail cá nhân hoặc chính sách thiết bị ở lớp toàn cục, còn quy tắc phụ thuộc repository ở lớp dự án. Ví dụ, cấm mọi agent đọc file .env thật có thể là global hook. Kiểm tra rằng file migration không bị sửa sau khi release nên là project hook, vì nó phụ thuộc cấu trúc và quy ước cụ thể.

Không nên sao chép cùng một logic vào cả hai nơi. Việc trùng lặp làm thông báo lỗi khó hiểu và tăng thời gian xử lý. Thay vào đó, hãy để mỗi hook có một trách nhiệm, xuất thông báo ngắn gọn và có mã nhận diện để log dễ truy vết. Nếu hook toàn cục chặn một hành động, thông báo nên nói rõ đây là policy ở máy; nếu hook dự án chặn, thông báo nên chỉ ra file quy định hoặc bước sửa cần thực hiện.

Cấu trúc input và output của một Hook

Mỗi hook nhận một JSON object với các trường chung như task ID, tên hook, phiên bản Cline, timestamp, danh sách workspace root, user ID và thông tin model. Dữ liệu riêng của hook nằm trong trường tương ứng: preToolUse chứa tên tool và parameters; postToolUse có thêm result, trạng thái thành công và thời lượng; userPromptSubmit chứa prompt; preCompact chứa số lượt hội thoại và ước lượng token.

Hook trả JSON với ba trường quan trọng. cancel quyết định có dừng hành động hay không. contextModification cho phép thêm một đoạn thông tin vào ngữ cảnh để Cline cân nhắc. errorMessage giải thích lý do khi hành động bị chặn. Output cần ngắn, ổn định và luôn là JSON hợp lệ; một dòng debug vô tình in ra standard output có thể làm parser thất bại.

{
  "cancel": true,
  "contextModification": "",
  "errorMessage": "Không được sửa migration đã phát hành. Hãy tạo migration mới."
}

Hãy gửi log kỹ thuật sang standard error hoặc file log riêng thay vì trộn với JSON output. Đồng thời đặt timeout cho các thao tác tốn thời gian. Một hook chỉ để kiểm tra path không nên khởi động toàn bộ test suite. Ngược lại, một hook sau tool có thể xếp việc test vào hàng đợi hoặc chỉ chạy test liên quan đến file vừa thay đổi.

Tạo Hook đầu tiên từ giao diện Cline

Giao diện Hooks của Cline cho phép tạo hook mới bằng cách chọn một sự kiện vòng đời. Cách triển khai tốt nhất không phải chọn tất cả event cùng lúc, mà là tạo một hook quan sát trước. Ví dụ, bắt đầu với PostToolUse chỉ ghi tên tool, thời lượng và trạng thái thành công, không ghi parameters nhạy cảm. Sau vài ngày, dữ liệu này cho biết tool nào chạy nhiều, hook nào sẽ đem lại giá trị và mức timeout hợp lý.

Khi thêm một hook có khả năng chặn, hãy thử ở chế độ cảnh báo trước. Script vẫn kiểm tra vi phạm nhưng trả cancel: false và dùng contextModification để thông báo. Sau khi rà false positive, mới chuyển sang chặn thật. Đây là cách giảm khả năng policy mới làm gián đoạn cả team.

Cline cũng cung cấp các điều khiển để bật, sửa và xóa hook. Nút tắt hữu ích khi debug vì giữ lại script và cấu hình nhưng loại nó khỏi luồng chạy. Tuy nhiên, với project hook đã commit, việc một cá nhân tắt cục bộ không nên được xem là bằng chứng policy vẫn được thực thi. Những kiểm tra bắt buộc cần được lặp lại trong CI hoặc branch protection.

Workflow 1: chặn tool chạm vào secrets và file nhạy cảm

Use case rõ nhất của PreToolUse là kiểm tra tên tool và parameters trước khi agent đọc hoặc ghi file. Hook có thể chuẩn hóa path, so sánh với danh sách cấm và từ chối khi đường dẫn khớp .env, private key, file credential hoặc thư mục production secrets. Đừng chỉ tìm chuỗi tuyệt đối; cần xử lý đường dẫn tương đối, symlink và khác biệt chữ hoa chữ thường trên từng hệ điều hành.

Thông báo chặn nên đưa ra lựa chọn thay thế, chẳng hạn yêu cầu dùng .env.example, secret manager hoặc mock credential. Nếu chỉ trả “permission denied”, model có thể thử một đường khác và lặp lại lỗi. Một thông báo có cấu trúc giúp agent đổi kế hoạch mà không cần người dùng giải thích lại.

Guardrail này không thay thế việc loại secret khỏi repository và giới hạn quyền hệ điều hành. Nếu tiến trình Cline vốn có thể đọc credential, một script lỗi hoặc tool khác vẫn có thể truy cập. Hãy kết hợp hook với sandbox, secret scanning và nguyên tắc cấp quyền tối thiểu. Bài bảo mật browser agent và self-hosting trên NextGZ trình bày cùng nguyên tắc khi agent làm việc với profile, cookie và dữ liệu đăng nhập.

Workflow 2: kiểm tra thay đổi ngay sau tool

PostToolUse phù hợp để biến tiêu chuẩn “sửa xong phải kiểm tra” thành luồng mặc định. Khi tool ghi file thành công, hook có thể xác định package bị ảnh hưởng rồi chạy formatter, type check hoặc test hẹp. Kết quả được đưa vào contextModification, giúp Cline thấy lỗi và tiếp tục sửa trong cùng task.

Điểm quan trọng là giới hạn phạm vi. Chạy toàn bộ monorepo test sau mỗi file edit sẽ làm workflow chậm và tốn tài nguyên. Nên ánh xạ file sang package, chọn command theo loại file và dừng sớm khi lỗi nền tảng xuất hiện. Với thay đổi tài liệu, có thể chỉ kiểm tra link hoặc Markdown. Với schema, chạy validator và migration check. Với code ứng dụng, ưu tiên test liên quan rồi để CI chạy bộ đầy đủ.

Hook cũng có thể ghi audit tối giản gồm task ID, tool, thời lượng, exit code và commit hiện tại. Không nên ghi toàn bộ source hoặc output command nếu không cần thiết. Log càng giàu nội dung càng tăng rủi ro chứa secret, dữ liệu khách hàng hoặc đoạn mã độc quyền.

Workflow 3: giữ context trước khi conversation bị compact

Cline dùng cơ chế compact để tiếp tục task dài khi context tiến gần giới hạn. PreCompact chạy trước thời điểm đó và nhận thông tin về độ dài hội thoại cùng ước lượng token. Hook có thể lưu một snapshot nhỏ: mục tiêu task, file đã sửa, test đang lỗi, quyết định kiến trúc và bước tiếp theo. Snapshot nên là dữ liệu có cấu trúc thay vì transcript đầy đủ.

Không nên dùng hook để tự động lưu mọi prompt vào repository. Transcript có thể chứa nội dung nhạy cảm và nhanh chóng làm phình lịch sử Git. Tốt hơn là ghi vào một thư mục tạm bị ignore, hoặc cập nhật một file trạng thái đã được thiết kế để không chứa secret. Nếu dự án đã dùng Memory Bank hoặc task file, PreCompact có thể gọi validator để chắc rằng trạng thái hiện tại đã được cập nhật trước khi context đổi.

Checkpoints và PreCompact giải quyết hai vấn đề khác nhau. Checkpoint giúp quay lại trạng thái workspace; PreCompact giúp bảo toàn thông tin vận hành. Dùng cả hai sẽ an toàn hơn việc coi bản tóm tắt hội thoại là bản sao của code.

Workflow 4: nạp bối cảnh khi bắt đầu hoặc tiếp tục task

TaskStart có thể kiểm tra branch, trạng thái working tree, phiên bản runtime và file hướng dẫn trước khi agent bắt đầu. Nếu working tree có thay đổi chưa commit, hook có thể thêm cảnh báo để Cline không ghi đè công việc đang dở. Nếu branch đang là production, hook có thể yêu cầu chuyển sang feature branch trước khi dùng tool ghi file.

TaskResume hữu ích khi task bị gián đoạn. Hook có thể đọc file trạng thái do lần chạy trước để bổ sung danh sách việc còn lại, test đang đỏ và commit tham chiếu. Tuy nhiên, dữ liệu được nạp cần được coi là input không tin cậy. Nếu file trạng thái có thể bị sửa từ pull request bên ngoài, không nên cho nội dung đó trực tiếp mở rộng quyền hoặc bỏ qua approval.

Trong team, một hook khởi động tốt nên làm ba việc nhanh: xác nhận môi trường, đưa ra context có thể kiểm chứng và chỉ rõ điều kiện dừng. Không nên biến TaskStart thành script cài dependency hoặc tải binary vì hành vi đó khó dự đoán, chậm và mở rộng supply-chain risk.

Kết hợp Cline CLI với provider và policy

Cline CLI cho phép chọn provider và model từ terminal. Đây là điểm cần policy rõ vì cùng một task có thể được chạy bằng endpoint khác nhau, với mức lưu giữ dữ liệu và chi phí khác nhau. Hook input có thông tin provider và model, nên project có thể cảnh báo khi một workflow nhạy cảm đang dùng model không nằm trong allowlist.

Không nên hard-code một model ID duy nhất nếu team thường xuyên thay đổi provider. Hãy phân loại policy theo khả năng và mức dữ liệu: model nội bộ, model bên thứ ba đã được phê duyệt, hoặc endpoint thử nghiệm. Khi model không xác định, chọn mặc định an toàn là cảnh báo hoặc dừng task nhạy cảm. Cline tài liệu hóa fallback unknown khi thông tin model không sẵn có; hook phải xử lý trường hợp này thay vì giả định field luôn hợp lệ.

CLI cũng phù hợp với automation headless, nhưng chế độ không tương tác làm thay đổi mô hình phê duyệt. Nếu workflow dùng tùy chọn tự động duyệt tool, hook và quyền hệ thống trở nên quan trọng hơn. Đừng dùng auto-approve như cách sửa lỗi timeout hoặc giảm phiền toái. Hãy thu hẹp command, filesystem scope và credential trước.

Nếu cần nhìn rộng hơn về khác biệt giữa agent trong terminal, IDE và cloud, xem bài so sánh terminal agent, IDE agent và cloud agent. Hooks phù hợp nhất khi bạn cần một lớp policy chạy gần agent trên máy hoặc trong workspace, còn kiểm soát tổ chức vẫn cần CI, repository rules và hạ tầng quan sát.

Hooks trong workflow Jupyter Notebook

Cline hỗ trợ thao tác Jupyter ở cấp cell trong VS Code, gồm tạo cell, giải thích và cải thiện cell. Với notebook, validation sau tool cần khác code thông thường vì file .ipynb là JSON chứa source, metadata, execution count và output. Một formatter thiếu hiểu biết có thể làm diff nhiễu hoặc xóa metadata cần thiết.

PostToolUse hook cho notebook nên kiểm tra cấu trúc JSON, kích thước output, dữ liệu nhúng và dấu hiệu chứa credential. Nếu notebook được dùng cho phân tích dữ liệu, hook có thể cảnh báo khi cell ghi file ra ngoài thư mục cho phép hoặc khi output lớn vượt ngưỡng. Nếu notebook là tài liệu chia sẻ, có thể yêu cầu xóa output nhạy cảm trước commit.

Không nên tự động chạy lại toàn bộ notebook sau mỗi cell change. Notebook có thể chứa tác vụ tốn chi phí, truy vấn production hoặc code không idempotent. Hãy chỉ chạy validator cấu trúc ở hook, còn execution thật cần môi trường cô lập và bước xác nhận riêng. Hình thức này giữ được lợi ích của AI-assisted notebook mà không coi mọi cell là code an toàn để chạy tự động.

Thiết kế Hook không biến thành lỗ hổng mới

Một hook là executable code, vì vậy nó có cùng nhóm rủi ro với script build và Git hook: command injection, path traversal, secret leakage, dependency confusion và denial of service. Không được ghép trực tiếp tool parameters vào shell command. Hãy truyền argument dưới dạng mảng, validate allowlist và tránh eval. Nếu phải gọi chương trình ngoài, dùng đường dẫn hoặc version đã kiểm soát.

Project hook đến từ repository cũng là nội dung không tin cậy cho tới khi được review. Khi checkout pull request từ fork, script có thể bị thay đổi. Team nên quy định ai được sửa thư mục hooks, yêu cầu CODEOWNERS và coi thay đổi hook là security-sensitive. Nếu Cline tải workspace mới, người dùng cần biết hook nào sẽ chạy trước khi bật.

Hook không nên tự cấp quyền cho agent. Ví dụ, PreToolUse có thể từ chối một command nhưng không nên tự động sửa policy để cho phép command tiếp theo. Quyền phải được cấu hình ở một lớp rõ ràng, còn hook chỉ đọc và thực thi quyết định. Điều này giúp audit dễ hơn và tránh vòng lặp trong đó chính agent thay đổi guardrail đang giám sát nó.

Debug và quan sát Hooks

Khi hook không hoạt động, hãy tách bốn loại lỗi: hook không được kích hoạt, input không đúng giả định, script lỗi, hoặc output không phải JSON hợp lệ. Bắt đầu bằng một fixture nhỏ chứa input mẫu và chạy script độc lập khỏi Cline. Sau đó mới bật trong workspace thử nghiệm.

Mỗi log nên có timestamp, hook name, task ID rút gọn, kết quả allow hoặc deny, thời lượng và mã lý do. Không cần ghi prompt, parameters đầy đủ hoặc source. Với lỗi, lưu stderr và exit code. Nếu hook quá chậm, đo riêng thời gian khởi động runtime và thời gian gọi dependency; một script Node hoặc Python khởi động cho mỗi tool call có thể tạo độ trễ đáng kể.

Giao diện Cline cho phép nhìn danh sách hook và trạng thái bật tắt. Đây là nơi kiểm tra nhanh cấu hình, nhưng trạng thái UI không chứng minh script đã chạy thành công. Hãy có một test canary hoặc log xác nhận. Với hook bắt buộc, CI nên kiểm tra file tồn tại, executable bit và schema output.

Hooks khác gì Rules, MCP và GitHub Actions?

Cơ chế	Thời điểm phù hợp	Điểm mạnh	Giới hạn chính
Cline Rules	Trước và trong suy luận	Truyền conventions, kiến trúc và cách làm	Không phải enforcement deterministic
Cline Hooks	Tại event của task và tool	Kiểm tra, chặn, ghi log, bổ sung context	Chạy với quyền cục bộ; cần bảo vệ script
MCP	Khi agent cần tool hoặc dữ liệu mới	Mở rộng khả năng qua giao diện chuẩn	Tăng bề mặt quyền và supply chain
GitHub Actions	Sau push, pull request hoặc event repository	Kiểm tra tập trung, có lịch sử và branch gate	Phản hồi muộn hơn so với pre-tool guardrail

Kiến trúc thực tế thường dùng cả bốn. Rules giúp agent hiểu ý định, Hooks chặn và phản hồi sớm, MCP cung cấp tool cần thiết, GitHub Actions xác minh lại trong môi trường độc lập. Không nên chuyển toàn bộ policy vào hook vì máy developer có thể bị cấu hình khác nhau. Ngược lại, chỉ dựa vào CI khiến agent lặp lại lỗi nhiều lần trước khi nhận phản hồi.

Bài Cline thực chiến với Rules, Checkpoints và MCP trình bày lớp workflow tổng quan. Hooks nên được xem là lớp bổ sung khi một tiêu chuẩn cần gắn với event cụ thể và có kết quả máy có thể kiểm tra.

Chi phí ẩn và mức độ trưởng thành

Repository Cline đang được phát triển tích cực, nhưng hoạt động mạnh không đồng nghĩa mọi tính năng đều ổn định cho mọi tổ chức. Hooks đụng tới security policy, tool execution và context, nên cần kiểm thử theo phiên bản đang dùng. Khi nâng cấp Cline, hãy chạy bộ fixture để phát hiện thay đổi schema hoặc lifecycle trước khi rollout rộng.

Chi phí ẩn lớn nhất không phải token mà là bảo trì policy. Mỗi hook thêm một nơi có thể lỗi, gây chậm hoặc chặn nhầm. Team cần người sở hữu, quy trình cập nhật, test và rollback. Nếu một policy đã có trong CI và không cần phản hồi sớm, đừng sao chép nó vào hook. Nếu một kiểm tra mất vài phút, hãy dùng queue hoặc chạy bất đồng bộ thay vì khóa mọi tool call.

Đối với developer cá nhân, hai hook đơn giản thường đã tạo giá trị: chặn secret và chạy test hẹp. Với startup, thêm audit và kiểm tra branch. Với doanh nghiệp, hook chỉ nên là một phần của hệ thống gồm endpoint quản lý, policy phân quyền, logging tập trung và review thay đổi. Star trên GitHub là tín hiệu quan tâm, không phải bằng chứng một cấu hình đã production-ready.

Checklist triển khai Cline Hooks an toàn

• Chọn một rủi ro cụ thể, không bắt đầu bằng tám hook cùng lúc.
• Dùng PreToolUse cho hành động cần chặn trước khi xảy ra.
• Dùng PostToolUse cho validation, audit và phản hồi phục hồi.
• Tách global policy và project policy; không sao chép logic.
• Validate JSON input, path và argument; không ghép chuỗi shell tùy ý.
• Giữ stdout chỉ chứa JSON output; đưa debug sang stderr.
• Không ghi prompt, source hoặc credential đầy đủ vào log.
• Đặt timeout, đo latency và tránh chạy full test suite sau mọi edit.
• Review hook như security-sensitive code, có owner và test fixture.
• Lặp lại kiểm tra bắt buộc trong CI hoặc branch protection.
• Có cách tắt và rollback khi hook gây false positive.
• Kiểm thử lại sau mỗi lần nâng cấp Cline hoặc thay model provider.

Kết luận

Cline Hooks có giá trị nhất khi biến một nguyên tắc mơ hồ thành điểm kiểm soát nhỏ, có thể quan sát và lặp lại. Một hook tốt không cố điều khiển toàn bộ agent. Nó biết chính xác lúc nào chạy, dữ liệu nào được phép đọc, điều kiện nào phải chặn và thông báo nào giúp agent phục hồi.

Hãy bắt đầu bằng một hook quan sát, đo hành vi thật, sau đó mới bật enforcement. Kết hợp Rules để truyền ý định, Hooks để phản hồi sớm, quyền hệ thống để giới hạn thiệt hại và CI để xác minh độc lập. Khi bốn lớp này hỗ trợ lẫn nhau, Vibe Coding không chỉ nhanh hơn mà còn dễ kiểm soát, debug và mở rộng cho team.