Cursor Automations: Hướng dẫn thực hành về các tác nhân mã hóa luôn hoạt động

Nút thắt thực sự trong phát triển phần mềm ngày nay không còn là viết mã nữa, vì hầu như mọi lập trình viên trong một đội ở bất kỳ quy mô nào giờ đây đều có ít nhất một tác nhân hỗ trợ họ triển khai. Các tác nhân mã hóa đã được nhúng vào quy trình làm việc hằng ngày, và khâu triển khai không còn là phần chậm nhất của hệ thống.

Cursor Automations được xây dựng để thu hẹp khoảng cách đó. Thay vì lặp đi lặp lại việc nhắc lệnh cho tác nhân, bạn xác định khi nào nó cần hành động. Một trigger kích hoạt, các hướng dẫn định hướng việc cần làm, và nó tự chạy. Một pull request được mở, và sẽ có người xem xét. Một báo cáo lỗi xuất hiện trên Slack, và sẽ được xử lý. Một lịch chạy, và một báo cáo được tạo.

Trong hướng dẫn này, tôi sẽ chỉ cho bạn cách thiết lập tự động hóa Cursor từ đầu đến cuối. Bạn sẽ xây dựng hai quy trình tự động: một quy trình review PR và một bộ theo dõi độ bao phủ kiểm thử theo lịch. Trong quá trình này, tôi sẽ phân tích cách cấu trúc hướng dẫn và kết nối công cụ cùng MCP để các tác vụ tự động hoạt động đúng như kỳ vọng.

Một lưu ý trước khi bạn bắt đầu. Automations vẫn đang được phát triển, và bảng điều khiển tại cursor.com/automations đang thay đổi. Nếu nhãn menu hoặc nút bấm có khác đi khi bạn đọc bài này, thì logic cốt lõi vẫn sẽ phù hợp.

Cursor Automations là gì?

Cursor automations là hệ thống để chạy các cloud agent của Cursor một cách tự động, được kích hoạt bởi các sự kiện trong công cụ phát triển của bạn hoặc bởi lịch trình do bạn định nghĩa.

Trong Chế độ Agent của Cursor, như đã đề cập trong khóa Software Development with Cursor, bạn bắt đầu mỗi phiên bằng cách mở cuộc trò chuyện và nhập prompt, và tác nhân chạy trên máy cục bộ của bạn miễn là bạn theo dõi.

Trong Automations, tín hiệu bắt đầu đến từ một nơi khác trong stack của bạn, và tác nhân làm việc trong môi trường sandbox trên đám mây mà không cần bạn giám sát liên tục.

Automations bao gồm các sự kiện kích hoạt mà tôi đã tóm tắt trong bảng dưới đây, nhưng bạn cũng có thể thiết lập trigger tùy chỉnh bằng webhook. Một automation có thể có nhiều trigger và sẽ chạy bất cứ khi nào bất kỳ trigger nào kích hoạt.

Mỗi loại trigger trên thay thế một khoảnh khắc trong ngày khi lẽ ra bạn phải tự nhận ra điều gì đó, chuyển ngữ cảnh sang Chế độ Agent của Cursor và yêu cầu trợ giúp. 

Trigger pull request là thứ bạn có khả năng xây dựng đầu tiên. Đây là vòng đời của một PR trước và sau khi bạn thêm một automation để theo dõi repository của mình.

Điều thay đổi trong cột thứ hai không phải là tốc độ của từng bước riêng lẻ, mà là việc sự chú ý của bạn không còn là yếu tố giới hạn tốc độ của toàn bộ quy trình.

Cách Cursor Automations hoạt động ở tầng kỹ thuật

Mọi automation đều tuân theo cùng một pipeline ở tầng kỹ thuật. Khi trigger bạn định nghĩa kích hoạt, Cursor khởi tạo một cloud sandbox mới, nhân bản repository của bạn vào đó, và khởi chạy một agent tuân theo hướng dẫn của bạn cùng các công cụ, kết nối MCP, và model đã cấu hình. Repository đó không nhất thiết phải ở GitHub: các repository được lưu trên Cursor Origin, forge Git riêng của Cursor, cũng hoạt động với cloud agent và automations.

Agent xác minh đầu ra trước khi kết thúc, sau đó đăng kết quả đến nơi bạn đã cấu hình, có thể là bình luận PR, tin nhắn Slack, ticket Linear, hoặc mở một pull request mới.

Hai đặc tính định hình mọi automation bạn xây dựng:

• Sandbox chạy hoàn toàn trên đám mây của Cursor, không phải laptop của bạn. Nó tiếp tục chạy ngay cả khi máy của bạn tắt.
• Mỗi lần chạy được thực thi trong môi trường tách biệt. Nhiều automation có thể chạy song song mà không can thiệp lẫn nhau. Cursor cũng cho biết họ chạy hàng trăm automation mỗi giờ nội bộ.

Cũng có một công cụ bộ nhớ (memory), như hình xem trước dưới đây, cho phép automation của bạn lưu trạng thái giữa các lần chạy, điều này sẽ quan trọng ở phần sau khi chúng ta xây dựng bộ theo dõi độ bao phủ theo lịch.

Tôi sẽ quay lại phần này khi bạn xây dựng bộ theo dõi bao phủ theo lịch.

Cursor Automations so với Chế độ Agent

Nếu bạn đã dùng Cursor thường xuyên, câu hỏi then chốt là khi nào nên dùng automations thay vì Chế độ Agent. Tôi sẽ không dùng Automations cho các tác vụ một lần. Chúng được xây dựng cho công việc lặp lại hoặc phụ thuộc vào các sự kiện bên ngoài.

Tôi thấy việc so sánh sự khác nhau của chúng hữu ích khi lựa chọn không rõ ràng:

Tôi nghĩ như sau. Nếu một tác vụ bắt đầu bằng “bất cứ khi nào” hoặc “mỗi lần”, nó thuộc về Automations.

Ví dụ: “Mỗi khi mở PR, hoặc bất cứ khi nào có báo cáo lỗi vào #support, hãy tạo ticket Linear.” Trigger là lặp lại và có thể dự đoán.

Nếu bắt đầu bằng “ngay bây giờ tôi cần tái cấu trúc mô-đun này”, thì thuộc về Chế độ Agent. Bạn quyết định khi nào là “ngay bây giờ”.

Nếu bạn muốn khám phá Cursor trước khi đi sâu vào automations, hướng dẫn đầy đủ Cursor 2.0 của chúng tôi sẽ giới thiệu giao diện Agents, Composer, và quy trình đa tác nhân với một dự án Python hoàn chỉnh.

Truy cập Bảng điều khiển Automations

Bảng điều khiển automations của Cursor ở cursor.com/automations. Đăng nhập bằng tài khoản Cursor của bạn, và bạn sẽ vào trang chính như hình dưới:

Hãy cùng phân tích những gì hiển thị trên bảng điều khiển.

Các ô tóm tắt hoặc chỉ báo trạng thái ở phía trên

Các ô này cung cấp ảnh chụp nhanh về tình trạng mọi thứ bạn đã chạy. Chúng bao gồm:

• Tổng số automations (bạn đã cấu hình bao nhiêu) 
• Thành công (số lần chạy hoàn tất, cùng tỷ lệ thành công)
• Thất bại (những lần chạy gặp lỗi)
• Lịch sử chạy (khi nhấp sẽ hiển thị lưu lượng chạy theo thời gian)

Ô nhập prompt

Trường nhập là cách nhanh nhất để tạo automation mới mà không cần mở biểu mẫu cài đặt đầy đủ. Chúng ta mô tả tác vụ, và Cursor sẽ tạo cấu trúc automation.

Nếu bạn mới bắt đầu, tôi khuyên bạn nên bắt đầu từ đây. Xác định điều bạn muốn tự động hóa, rồi viết bộ hướng dẫn có cấu trúc để agent tuân theo mỗi khi trigger kích hoạt. 

Khi bạn bấm nút mũi tên, Cursor dùng những hướng dẫn đó để tạo automation cho bạn, điền sẵn tên, trigger và các công cụ cần thiết.

Tôi sẽ không coi những hướng dẫn này như một prompt thông thường, mà là một bản đặc tả mà agent sẽ chạy mỗi lần. Tôi sẽ quay lại điểm này khi hướng dẫn bạn xây dựng automation đầu tiên ở phần sau.

Nút chuyển mine / team và nút + new automation

Nút chuyển giúp lọc giữa automations của bạn và của đội. 

Nút + New mở trang cấu hình để thiết lập một automation mới:

Nút + New Automation là lựa chọn điền biểu mẫu đầy đủ thay thế cho ô prompt nội tuyến nếu bạn muốn tự cấu hình trigger, hướng dẫn, và kết nối công cụ từ đầu.

Danh sách các automation hiện có của bạn

Bảng hiển thị tất cả các automation chúng ta đã tạo, bao gồm công cụ đã dùng và lịch sử chạy.

Nhấp vào bất kỳ mục nào sẽ mở trang cài đặt và lịch sử chạy của nó:

Phần mẫu gợi ý

Bên dưới danh sách automation trước đó là một lưới thẻ mẫu. Các mẫu cung cấp automation dựng sẵn mà bạn có thể chỉnh sửa thay vì bắt đầu từ con số 0.

Các mẫu automation của Cursor là cách nhanh nhất để khởi tạo một automation trong ngày đầu tiên. Nếu bạn đang xây dựng automation đầu tiên, tôi gợi ý kiểm tra xem có mẫu nào khớp với tác vụ bạn muốn tự động hóa không và bắt đầu từ đó.

Các mẫu có thể cho bạn quan điểm về thế nào là hướng dẫn tốt, cũng như những kết nối công cụ hoặc MCP bạn cần.

Tài khoản và chi phí

Cursor automations chạy trên hạ tầng đám mây của Cursor, yêu cầu quyền truy cập cloud agent, được bao gồm trong các gói trả phí. Mỗi lần chạy tiêu thụ tín dụng dựa trên mô hình sử dụng và thời gian thực thi.

Automations hỗ trợ ba cấp độ hiển thị theo mô hình phân quyền:

• Private: Chỉ mình bạn nhìn thấy, tính phí vào tài khoản của bạn.
• Team Visible: Người khác có thể xem automation và lịch sử chạy của bạn, nhưng vẫn tính phí vào bạn.
• Team Owned. Automation tính phí vào pool dùng chung của đội và do quản trị viên đội quản lý.

Chọn đúng cấp độ rất quan trọng vì nó quyết định tín dụng của ai sẽ bị sử dụng mỗi lần automation chạy. Giữ các thử nghiệm ở chế độ private cho đến khi bạn tin tưởng đầu ra. Khi automation trở thành một phần quy trình làm việc của đội, bạn có thể chuyển nó sang cấp độ thuộc sở hữu đội.

Lỗi phổ biến nhất là để một automation chạy quá rộng quá sớm. Nếu nó kích hoạt trên mọi lần push trong một repo bận rộn, chi phí có thể tăng nhanh mà bạn không để ý. Bắt đầu hẹp, để nó chạy vài ngày, xem tần suất kích hoạt, rồi quyết định mở rộng hoặc điều chỉnh quy mô.

Xây dựng Automation đầu tiên: Review mã PR tự động

Review mã PR là automation khởi đầu hợp lý vì vòng phản hồi ngắn và hệ quả của một lần chạy kém là thấp. Nếu agent đăng bình luận hữu ích, chúng ta nhìn thấy ngay trên PR. Nếu nó đăng điều gì đó không phù hợp, chúng ta bỏ qua, và không có gì được triển khai.

Tôi sẽ hướng dẫn bạn xây dựng automation đầu tiên qua năm bước:

1. Kết nối repository GitHub của bạn
2. Thiết lập các trigger GitHub
3. Viết hướng dẫn cho agent (với cấu trúc rõ ràng và những điều cần tránh)
4. Thêm công cụ đăng bình luận Pull Request của GitHub
5. Triển khai automation

Bước 1: Kết nối repository GitHub của bạn

Trước khi agent có thể review một pull request, nó cần quyền truy cập vào repository. Cursor truy cập repository của bạn thông qua tích hợp ứng dụng GitHub App gốc. Không có kết nối đó, agent của automation không thể xem mã của bạn, đọc diff PR, hay phản hồi với góp ý, vì vậy sẽ không hoạt động được.

Nếu bạn chưa làm điều này:

1. Cài đặt Cursor GitHub App trên tài khoản hoặc tổ chức GitHub của bạn và cấp quyền truy cập vào các repository bạn muốn automations theo dõi.
2. Kết nối tài khoản GitHub của bạn trong bảng điều khiển trong thẻ Integrations. 

Khi kết nối đã hoạt động, các repository của bạn sẽ khả dụng khi bạn cấu hình trigger cho automation.

Bước 2: Thiết lập trigger

Từ bảng điều khiển automations:

1. Nhấp + New Automation để bắt đầu tạo automation.
2. Đặt tên automation. Bạn có thể đặt là PR Code Review – Open & Push – Comment Only
3. Trong phần trigger, nhấp Add trigger và chọn GitHub. Chọn cả PR opened và PR pushed làm sự kiện kích hoạt.
4. Chọn repository đích.

Nếu bạn bỏ qua bước 1 hoặc đây là lần đầu bạn kết nối GitHub với Cursor automations, bạn sẽ được nhắc xác thực. 

Trong hình xem trước dưới đây, tôi minh họa cách cấu hình và chọn repository đích sau khi ủy quyền xong:

Lưu ý: Chúng ta có thể gộp nhiều sự kiện trigger vào một automation khi hướng dẫn không thay đổi tùy theo sự kiện nào kích hoạt. Nhưng nếu độ sâu hoặc mục đích của review thay đổi tùy theo sự kiện, hãy tách thành các automation riêng.

Giờ đây automation đã biết khi nào cần chạy. Bước tiếp theo là nói cho nó biết cần làm gì.

Bước 3: Viết hướng dẫn automation hiệu quả

Hướng dẫn là yếu tố tác động lớn nhất đến việc automation của chúng ta có tạo ra đầu ra hữu ích hay không. Agent dùng chúng để học thế nào là “tốt”. Hướng dẫn mơ hồ dẫn đến kết quả thiếu nhất quán.

Trước khi viết hướng dẫn, chúng ta cần hiểu mình đang định nghĩa điều gì. Chúng ta không đưa ra một prompt dùng một lần. Chúng ta đang đặt ra một hành vi mà agent sẽ tuân theo mỗi khi trigger kích hoạt. Chất lượng của automation phụ thuộc vào việc chúng ta đặc tả hành vi đó rõ ràng đến đâu.

Đây là cấu trúc tôi khuyên dùng:

• Định nghĩa vai trò: Thiết lập góc nhìn và giọng điệu. Ví dụ: “Bạn là người review bảo mật cho pull request.”
• Định nghĩa mục tiêu: Rõ ràng về tiêu chí thành công. Ví dụ: “Phát hiện và giải thích rõ ràng các lỗ hổng thực sự.”
• Định nghĩa phạm vi: Làm rõ điều agent cần tập trung. Ví dụ: “Chỉ review mã được thêm hoặc chỉnh sửa, và chỉ dùng ngữ cảnh xung quanh khi cần để xác nhận tác động.”
• Phác thảo quy trình: Đưa ra cách tiếp cận rõ ràng. Ví dụ: “Kiểm tra thay đổi, lần theo input, và xác minh cơ chế bảo vệ.”
• Đặt ngoại lệ: Nói rõ điều cần bỏ qua để giảm nhiễu.
• Định nghĩa hành vi và đầu ra. Cách hành động và hình thức kết quả.
• Thiết lập ranh giới: Những điều tuyệt đối không được làm.

Hãy viết hướng dẫn automation giống như viết runbook: cụ thể, có thứ tự, với tiêu chí chấp nhận rõ ràng và ranh giới tường minh.

Ví dụ về hướng dẫn tốt

Đây là hướng dẫn tôi dùng cho automation review PR này. Bạn có thể sao chép vào ô nhập hướng dẫn, nhưng hãy chỉnh sửa cho phù hợp với trường hợp của bạn:

You are a code reviewer for pull requests triggered on PR open and push. Focus on identifying real issues that could introduce bugs, security vulnerabilities, or maintainability problems if merged. Review only added or modified code, and use surrounding context only when required to validate impact.

Check for:
- Logic errors such as incorrect conditions, edge cases, null handling, or wrong return values
- Security issues including injection, XSS, auth flaws, unsafe deserialization, or hardcoded secrets
- Contract changes such as modified APIs, response shapes, or schemas without corresponding updates
- Missing error handling or tests introduced by the change

Ignore style, formatting, naming preferences, and any pre-existing issues not introduced by this PR. Report only concrete findings with evidence from the diff, and post inline comments directly on changed lines. If no issues are found, respond: “Automated review complete: no issues found in this diff.” Do not approve, merge, push, or open PRs.

Đây là hướng dẫn trong ô nhập hướng dẫn:

Prompt này đã được giản lược, nhưng vẫn tuân theo cấu trúc rõ ràng và cụ thể. 

Ví dụ về hướng dẫn kém

Tránh các hướng dẫn mơ hồ như:

Review this PR and give feedback on any issues you notice.

Không có cấu trúc, ràng buộc, và mức độ ưu tiên, agent sẽ phải đoán “vấn đề” là gì, dẫn đến phản hồi chung chung, bề mặt thay vì đầu ra đáng tin cậy.

Bước 4: Thêm công cụ

Mở bảng công cụ bên trong trình chỉnh sửa automation. Với automation này, chúng ta sẽ vào phần GitHub và chọn công cụ Comment on Pull Request. Đảm bảo tắt phê duyệt PR, như trong hình xem trước dưới đây, để automation chỉ có thể bình luận, không phê duyệt thay đổi.

Comment on Pull Request cho phép agent đăng phát hiện trở lại PR. Nó không yêu cầu kết nối riêng vì dùng chung Cursor GitHub App bạn đã ủy quyền ở Bước 1.

Nếu muốn gửi đầu ra đến dịch vụ khác (như đăng lên Slack), chúng ta sẽ chọn công cụ tương ứng hoặc thêm kết nối MCP. Với automation này, công cụ bình luận là đủ.

Bước 5: Triển khai và theo dõi lần chạy đầu tiên

Khi đã thiết lập trigger, hướng dẫn, và công cụ, chúng ta nhấp Create để lưu automation, thao tác này mở trang cài đặt của automation như bạn thấy dưới đây:

Vì chúng ta đã triển khai automation, cần kích hoạt một lần chạy và quan sát agent tạo ra gì.

Mở một pull request dạng draft trong repository đã kết nối. Điều này kích hoạt trigger PR opened, và một mục mới sẽ xuất hiện trong Lịch sử chạy sau vài giây, như bạn thấy dưới đây:

Mở lần chạy đó và kiểm tra ba điều:

• Thời gian thực thi: Lần chạy mất bao lâu. Thay đổi tùy kích thước diff, mô hình, và độ phức tạp hướng dẫn.
• Lượt gọi công cụ: Tệp và công cụ nào đã dùng? Nếu agent đọc các tệp không liên quan, hãy xem lại hướng dẫn của bạn.
• Đầu ra: Những gì được đăng lại lên GitHub. So sánh với hướng dẫn của bạn.

Dưới đây là tổng quan lần chạy automation của tôi. Bạn có thể thấy nó chạy sáu phút, thực hiện một số hành động, và đăng review PR bằng công cụ PostReviewCommentOnPr:

Dưới đây là ví dụ bình luận agent đã đăng trên PR của tôi:

Đôi khi đầu ra có thể lệch, và khi điều đó xảy ra, vấn đề thường nằm ở hướng dẫn. Chúng ta điều chỉnh phần hướng dẫn kiểm soát hành vi muốn thay đổi, đẩy một commit mới để kích hoạt lượt chạy khác, và xem kết quả.

Với những lượt chạy đầu, hãy bắt đầu đơn giản để giảm rủi ro. Ở đây, chúng ta giới hạn automation chỉ bình luận, cho phép xác nhận hành vi một cách an toàn. Khi đầu ra ổn định, đưa vào sử dụng thực tế và sau đó kết nối thêm công cụ ngoài GitHub để mở rộng khả năng.

Kết nối thêm công cụ với MCP

Automation review PR mà chúng ta vừa xây dựng chạy trên GitHub. Nó đọc diff và đăng bình luận lên pull request bằng công cụ GitHub Comment on Pull Request. Nhưng nếu muốn agent làm nhiều hơn việc review mã, chúng ta cần kết nối công cụ khác. Đó là vai trò của Model Context Protocol (MCP).

MCP là giao diện tiêu chuẩn cho phép agent dùng các công cụ bên ngoài mà không cần tích hợp tùy chỉnh. Nếu không có nó, mỗi công cụ sẽ đòi hỏi thiết lập và bảo trì riêng. 

Với MCP, khi kết nối công cụ được hỗ trợ trong bảng công cụ của automation, agent có thể dùng nó qua cùng một giao diện.

MCP cho phép cùng một automation làm được nhiều hơn và hành động trong các công cụ khác. Automation review PR của bạn đã có thể bình luận trên GitHub. Thêm Slack, nó có thể đăng cập nhật lên kênh. Thêm Linear, nó có thể tạo ticket. Thêm Datadog, nó có thể lấy log. Mỗi kết nối mở rộng những gì automation có thể làm mà không cần đổi logic cốt lõi.

Cursor automations bao gồm bộ tích hợp MCP dựng sẵn như Slack, Linear, ClickUp, Datadog, Notion, và nhiều hơn nữa. Vì MCP là tiêu chuẩn mở, chúng ta có thể kết nối bất kỳ công cụ tương thích nào theo cùng cách.

Bạn sẽ tìm thấy MCP trong Tools -> MCP server trên trang cài đặt automation. Nhấp nút + New Connection để duyệt, rồi cài đặt và kết nối công cụ bạn cần.

Dưới đây là hình xem trước cách thêm chúng:

Ở phần tiếp theo, tôi sẽ hướng dẫn bạn cách thêm kết nối Slack MCP vào automation review mã PR.

Thêm kết nối Slack MCP

GitHub giúp automation đọc và bình luận mã của chúng ta. Slack giúp nó trò chuyện với đội.

Từ bảng Tools, nhấp Add Tool or MCP, chọn MCP Server, rồi chọn +New Connection. Trong bảng mở ra, tìm Slack và chọn Slack MCP server. 

Slack thường đã được cài sẵn, nếu chưa, hãy cài và làm theo luồng OAuth để cấp quyền cho workspace của bạn. Khi kết nối, nó sẽ xuất hiện trong bảng công cụ, như tôi minh họa trong hình tổng quan dưới đây:

Chúng ta không chọn kênh đích trong lúc thiết lập kết nối. MCP cấp cho agent phạm vi workspace ở các kênh công khai. Chúng ta kiểm soát chính xác nơi đăng bằng cách nêu tên kênh trong hướng dẫn, ví dụ, "Gửi tin nhắn Slack đến #pr-alerts nếu phát hiện vấn đề nghiêm trọng."

Lưu ý: Slack MCP chỉ hoạt động với các kênh công khai, và kênh đích phải mời bot Cursor trước khi automation có thể đăng. Sau luồng OAuth, một bot Cursor sẽ xuất hiện trong workspace Slack của bạn. Vào kênh và chạy /invite @Cursor để thêm bot.

Nếu bạn không thấy @Cursor bot, có thể ủy quyền thất bại. Vào dashboard ->  integrations, nhấp Manage cạnh Slack, và chạy lại OAuth.

Nếu bạn muốn tìm hiểu sâu hơn về chính MCP, hướng dẫn FastMCP 2.0 của chúng tôi sẽ hướng dẫn xây dựng một MCP server tùy chỉnh từ đầu và tích hợp vào Cursor.

Kết hợp trigger và công cụ

Khi đã kết nối Slack MCP, chúng ta có thể mở rộng automation review PR. Chúng ta sẽ giữ nguyên các trigger PR của GitHub và công cụ bình luận trên PR của GitHub. Nhưng giờ agent cũng có thể đăng phát hiện nghiêm trọng lên #pr-alerts qua Slack MCP.

Thêm khối này vào cuối phần hướng dẫn chúng ta đã viết ở bước 3 khi xây dựng automation đầu tiên:

Additionally:  
If you find any issue at severity high or critical, send a Slack message to #pr-alerts containing: the PR title, the author, a one-sentence description of the most severe finding, the severity label, and a link to the PR. If no high or critical issues are found, do not post to Slack at all.

Dòng cuối cùng quan trọng hơn vẻ ngoài của nó. Không có dòng đó, #pr-alerts có thể nhanh chóng đầy các thông báo “an toàn” và mất giá trị. Với tôi, nói cho agent biết khi nào không nên hành động cũng quan trọng như nói khi nào nên hành động.

Dưới đây là các đầu ra từ một lượt chạy PR thử nghiệm trên repository của tôi.

Một bình luận mà agent đã đăng khi PR mở trong GitHub của tôi (qua công cụ bình luận PR của GitHub):

Một thông báo Slack mà agent đã gửi trong kênh #pr-alerts cho cùng lượt chạy thông qua kết nối Slack MCP:

Tại thời điểm này, bạn đã có một automation hoạt động, review mọi PR, đăng bình luận trên GitHub, và nâng mức cảnh báo cho vấn đề nghiêm trọng lên Slack. Đó là mẫu cốt lõi. 

Trong phần tiếp theo, chúng ta sẽ xây dựng automation thứ hai theo cùng luồng: một trigger, hướng dẫn, và các công cụ agent cần để tạo đầu ra.

Xây dựng Automation thứ hai: Bộ theo dõi độ bao phủ kiểm thử theo lịch

Automation review PR chúng ta đã xây dựng phản ứng với sự kiện GitHub. Automation theo lịch hoạt động khác. Chúng ta định nghĩa khi nào agent cần chạy, và nó sẽ thực thi vào thời điểm đó bất kể repository có thay đổi gì hay không.

Automation chúng ta xây dựng ở đây sẽ chạy mỗi ngày lúc 9 giờ sáng, rà soát mã đã hợp nhất vào nhánh main trong 24 giờ qua, xác định khu vực có độ bao phủ kiểm thử chưa đủ, và đăng bản tóm tắt lên #repo-coverage trên Slack.

Thiết lập trigger cron và công cụ

Từ bảng điều khiển automations:

• Nhấp + New để tạo automation mới.
• Đặt tên là Daily Coverage Check – Main Branch.

Cấu hình trigger

• Trong Triggers, chọn Scheduled.
• Chọn Every... > Day và đặt giờ 9:00 AM.
• Nếu bạn cần định dạng khác, như chỉ ngày trong tuần, hãy dùng Custom (cron)
• Vì trigger theo lịch không suy ra repository, hãy chọn repository và nhánh đích (main).

Thêm công cụ Send to Slack

Ở đây, tôi sẽ giới thiệu công cụ Send to Slack có sẵn trong cài đặt automations. Công cụ này khác với Slack MCP đã dùng trước đó. Chúng ta dùng nó để gửi tin nhắn tới một kênh cụ thể, trong khi Slack MCP cấp quyền ở mức workspace và cho phép agent đăng vào bất kỳ kênh nào được nêu trong hướng dẫn.

Để thêm công cụ Send to Slack, chọn nó trong phần công cụ và chỉ định kênh đích cho đầu ra của automation. Hình dưới đây cho thấy cách hiển thị:

Viết hướng dẫn cho tác vụ theo lịch

Trong automation review PR, agent phản ứng với một pull request và đăng phản hồi. Với automation theo lịch, không có đầu vào đến. Agent tự khởi động tác vụ, nên chúng ta cần nói rõ điểm bắt đầu, cần kiểm tra gì, và đăng gì.

Công cụ bộ nhớ rất quan trọng ở đây. So sánh độ bao phủ chỉ hoạt động nếu agent biết số liệu của hôm qua. Chúng ta phải nói rõ key nào cần đọc, so sánh gì, và lưu gì ở cuối. Nếu để mơ hồ, kết quả có thể khác nhau giữa các lần chạy.

Đây là bộ hướng dẫn tôi đã dùng:

You are a daily test coverage monitor for this repository. Run every day at 9 AM on the main branch.
Identify PRs merged to main in the last 24 hours.For modified files, check if changed code paths have test coverage.Run tests with coverage:  pytest --cov=src --cov-report=json.Parse the report and record the overall coverage and per-file coverage for modified files.Read yesterday's coverage from memory (daily_coverage_latest: If none exists, post a green status and skip comparison.Compare coverage: If it drops by >1%, post a warning to #repo-coverage Slack Channel with today's value, yesterday's value, delta, and affected files. Otherwise, post a green status with today’s value and delta.Save today’s coverage to memory (daily_coverage_latest).

Dưới đây là đầu ra từ automation theo lịch của tôi lúc 9 giờ sáng.

Đây là tổng quan automation. Trường hợp của tôi, độ bao phủ vẫn trên ngưỡng, nên chỉ đăng trạng thái xanh trong kênh Slack:

Đây là tin nhắn Slack. Đây là lần chạy kiểm tra bao phủ đầu tiên, nên tôi không kỳ vọng nhiều. Bạn cũng có thể thấy lần chạy đã được lưu vào bộ nhớ làm đường cơ sở cho lần so sánh tiếp theo:

Quan sát lần chạy trên, hai phần trong hướng dẫn nổi bật. 

Thứ nhất, nó định nghĩa cả nhánh cảnh báo và nhánh xanh. Nhánh xanh là bắt buộc. Nếu chỉ định nghĩa khi có vấn đề, automation sẽ im lặng khi mọi thứ ổn. Trong kênh giám sát, sự im lặng đó trông như thất bại. Trạng thái xanh xác nhận lượt chạy đã hoàn tất.

Thứ hai, việc đọc và lưu bộ nhớ là tường minh. Agent có công cụ bộ nhớ, nhưng nó sẽ không sử dụng đáng tin cậy cho so sánh nếu không được chỉ dẫn. Nếu để ngầm định, kết quả có thể khác giữa các lần chạy. Chúng ta phải chỉ rõ key nào để đọc, so sánh gì, và lưu gì.

Trong hình dưới đây, bạn có thể thấy agent đã lưu automation của tôi:

Ở phần tiếp theo, tôi sẽ đề cập đến các lỗi thường gặp và thực tiễn tốt giúp bạn khai thác automations hiệu quả hơn.

Cursor Automations: Lỗi thường gặp và thực tiễn tốt

Hầu hết vấn đề với automations đến từ một nhóm lỗi có thể dự đoán. Chúng dễ tránh khi bạn biết, nhưng tốn kém để gỡ lỗi khi bạn không biết.

Lỗi thường gặp cần tránh

• Hướng dẫn mơ hồ: Đây là dạng thất bại phổ biến. Những câu như “review mã”, “kiểm tra lỗi”, hay “tóm tắt thay đổi” buộc agent phải đoán ý bạn, dẫn đến đầu ra thiếu nhất quán. Nếu câu có động từ mà không có đối tượng hoặc điều kiện rõ, hãy viết lại trước khi triển khai.
• Phạm vi quá rộng:. Đừng gom kiểm tra bảo mật, phong cách, hiệu năng, và độ bao phủ vào một automation. Điều này khiến lỗi khó gỡ. Automation hẹp dễ suy luận hơn. 
• Bỏ qua giai đoạn hiệu chỉnh: Không bật các cài đặt như tự động phê duyệt hay tự động hợp nhất sớm. Hãy để các lượt chạy đầu chỉ bình luận. Giai đoạn này phơi bày các trường hợp biên trong codebase của bạn. Xem đây là bước xác thực trước sản xuất.
• Cấu hình kênh Slack: Trigger Slack chỉ hoạt động trên kênh công khai, nên nếu automation Slack có vẻ không làm gì, hãy kiểm tra tính công khai của kênh và đảm bảo @Cursor bot đã được mời vào kênh đó.

Thực tiễn tốt để automation ổn định

• Mỗi automation một việc: Mỗi automation nên làm một việc được định nghĩa rõ ràng. Điều này giúp cô lập lỗi dễ hơn và sửa nhanh hơn.
• Bắt đầu từ trạng thái sạch: Commit cây làm việc trước khi để agent thay đổi để bạn luôn có diff rõ ràng để so sánh.
• Xem các lượt chạy đầu là hiệu chỉnh: Kỳ vọng có nhiễu lúc đầu, xem đầu ra, chỉnh hướng dẫn, và chạy lại cho đến khi hành vi ổn định.
• Dùng tên rõ ràng, mô tả: Các tên như PR Code Review – Open & Push – Comment Only hữu ích hơn nhãn chung chung khi bạn xem lại sau này.
• Xem lịch sử chạy sớm và thường xuyên: Trong vài tuần đầu, điều này giúp bạn hình thành trực giác về hành vi bình thường, từ đó dễ phát hiện vấn đề sau này.

Lời kết

Cursor Automations đưa mã hóa theo tác nhân từ quy trình tương tác sang hệ thống vận hành theo sự kiện. Trong Chế độ Agent của Cursor, chúng ta mở trò chuyện và nhắc agent review mã, tái cấu trúc hàm, hoặc điều tra vấn đề. Trong automations, chúng ta không khởi động công việc trực tiếp. Các trigger như pull request, tin nhắn Slack, hoặc lịch trình sẽ tự động khởi động agent, và nó tự hoàn thành tác vụ. Sự chuyển dịch chính là công việc thường nhật được đưa khỏi hàng đợi thủ công sang một hệ thống chạy nền.

Trong bài viết này, tôi đã hướng dẫn bạn xây dựng hai automation: review mã PR và bộ theo dõi độ bao phủ theo lịch. Chúng được cố ý giữ đơn giản, nhưng mang lại điểm khởi đầu tốt vì cho thấy hệ thống vận hành thế nào mà không thêm độ phức tạp. Khi đã quen, bạn có thể triển khai các quy trình nâng cao.

Ý tưởng cốt lõi là bắt đầu với một automation hẹp, viết hướng dẫn như runbook, chạy ở chế độ rủi ro thấp, và chỉ mở rộng khi nó vận hành ổn định. Giá trị đến từ tính ổn định của từng automation nhiều hơn là số lượng bạn xây dựng.

Để tiếp tục phát triển dựa trên những gì đã trình bày, dưới đây là các bước tiếp theo được khuyến nghị:

• Đào sâu hiểu biết về Chế độ Agent và quy trình làm việc rộng hơn của Cursor với khóa Software Development with Cursor của chúng tôi.
• Tìm hiểu điều mới trong Cursor 3.0.