Mọi đội kỹ thuật đều mang trên mình một lớp công việc lặp đi lặp lại mà không ai lên kế hoạch, nhưng tất cả đều phải trả giá. Có người tổng hợp bản tóm tắt standup. Có người đọc từng báo cáo bug gửi đến rồi chuyển đến đúng chỗ. Có người ngồi gom báo cáo trạng thái thứ Sáu từ sáu tab dữ liệu rải rác. Không việc nào khó cả. Nhưng tất cả đều là những việc vặt nhàm chán: có thể đoán trước, lặp đi lặp lại và âm thầm tốn kém, bởi nó rơi vào tay người phát hiện ra nó đầu tiên.
Đây chính là kiểu công việc mà một AI Agent xử lý rất tốt, miễn là có thứ gì đó khởi động Agent vào đúng thời điểm mà không cần người gõ prompt. Cơ chế khởi động đó chính là thứ mà Automations mang lại trong Sharkly. Automation là một định nghĩa thuộc sở hữu của Space dành cho công việc lặp lại của Agent hoặc Crew: hướng dẫn bằng văn bản, assignee thực thi, một hoặc nhiều trigger, và lịch sử chạy mà bạn có thể xem lại.
Mục tiêu không phải là tự động hóa việc phán đoán. Cách Sharkly định vị vấn đề rất thẳng thắn: tự động hóa dừng lại ở nơi cần đến phán đoán của đội ngũ. Automation có thể soạn bản tóm tắt standup, đọc sơ bộ một bug, và tổng hợp báo cáo hàng tuần. Nhưng con người vẫn là người quyết định đội ngũ sẽ xử lý những việc đó thế nào. Nếu bạn mới biết đến Sharkly, hãy bắt đầu với Sharkly là gì rồi quay lại đây.
TL;DR
Automation trong Sharkly là một quy tắc thuộc sở hữu của Space, khởi động một Agent hoặc Crew với một bộ hướng dẫn cố định mỗi khi trigger được kích hoạt. Có bốn loại trigger: theo lịch (cron năm trường kèm múi giờ), thay đổi trạng thái task, bình luận chứa cụm từ đã cấu hình, và URL webhook bí mật cho các dịch vụ bên ngoài; ngoài ra còn có nút Run now để kiểm thử thủ công. Mỗi lượt chạy đều được ghi lại trong lịch sử chạy kèm nguồn kích hoạt, kết quả và lý do thất bại, và bạn có thể tạm dừng rồi tiếp tục một Automation trong lúc chỉnh sửa nó. Hãy dùng Automations cho những công việc lặp lại đã được định nghĩa rõ ràng: tóm tắt standup, triage bug vòng đầu, báo cáo định kỳ. Agent đảm nhiệm việc đọc và soạn thảo; con người xem lại kết quả và đưa ra quyết định.
Automation là gì và không phải là gì
Một Automation lưu trữ định nghĩa nhỏ gọn nhưng đầy đủ cho một công việc lặp lại: tên và hướng dẫn mô tả mục tiêu, các bước, ràng buộc và kết quả mong đợi; Space sở hữu nó; assignee, tức Agent hoặc Crew thực hiện công việc; độ ưu tiên; trạng thái Active hoặc Paused; một hoặc nhiều trigger; và lịch sử chạy ghi lại nguồn, kết quả, lượt chạy của Agent và lý do thất bại của mỗi lần chạy.
Có hai ranh giới có thể sẽ khiến bạn bất ngờ.
Thứ nhất, Automation không tạo Task cho mỗi lần chạy. Nó khởi động trực tiếp một lượt chạy của Agent hoặc Crew. Lượt chạy, kết quả đầu ra và mọi lỗi đều nằm trong lịch sử chạy của Automation chứ không phải trong danh sách task của bạn, nhờ đó bảng công việc của bạn không bị lấp đầy bởi các Task do máy tạo ra vào 9 giờ sáng mỗi ngày.
Thứ hai, Automations không phải là canvas workflow của Sharkly. Một Space có hai bề mặt tự động hóa: Automations — quy tắc đơn lẻ được mô tả ở đây — và Automation workflows, một canvas gồm các node trigger và action có thể gọi connector của bên thứ ba. Hãy dùng Automation khi một Agent hoặc Crew cần chạy một bộ hướng dẫn để phản hồi một sự kiện có thể đoán trước. Hãy dùng workflow khi bạn cần các hành động nhiều bước hoặc liên ứng dụng trước khi Agent tham gia.
Vì assignee là một Agent đầy đủ của Sharkly, mọi thứ bạn đã cấu hình trên Agent đó đều được áp dụng: hướng dẫn, Runtime, Skills, repository và các thiết lập khi chạy. Nếu bạn chưa tạo Agent nào, bài Agents trong Sharkly giải thích cách một cấu hình đang hoạt động được lưu lại trở thành thứ mà cả đội có thể tái sử dụng. Nói cách khác, Automation thực chất là một cuộc hẹn thường xuyên với Agent đó.
Bốn loại trigger
Một Automation có thể có nhiều trigger, mỗi trigger được bật hoặc tắt độc lập. Một định nghĩa có thể phục vụ nhiều điểm vào: cùng một bộ hướng dẫn triage có thể kích hoạt khi trạng thái thay đổi và khi có slash command, mà không cần lặp lại bất cứ thứ gì.
| Trigger | Kích hoạt khi | Phù hợp nhất cho | Cần lưu ý |
|---|---|---|---|
| Theo lịch | Biểu thức cron khớp, theo múi giờ đã chọn | Kiểm tra định kỳ, tóm tắt, nhắc nhở, bảo trì | Việc chọn múi giờ; lượt chạy vẫn diễn ra dù có thay đổi gì hay không |
| Thay đổi trạng thái Task | Một task chuyển sang một trạng thái Organization đã chọn | Hàng đợi tiếp nhận, theo dõi review, triage | Việc khớp diễn ra trên toàn Organization, không lọc theo Space |
| Cụm từ trong bình luận | Bình luận của task chứa cụm từ đã cấu hình, không phân biệt chữ hoa chữ thường | Các lệnh theo yêu cầu như /triage ngay trong cuộc thảo luận | Cũng lắng nghe trên toàn Organization; hãy chọn cụm từ thật đặc trưng |
| Webhook | Một dịch vụ bên ngoài gửi POST đến URL bí mật | Kết quả CI, sự kiện GitHub, cảnh báo từ các hệ thống khác | URL chính là một bearer secret; hãy lưu trữ và xoay vòng cẩn thận |
Theo lịch dùng biểu thức cron năm trường tiêu chuẩn kèm múi giờ, với các preset phổ biến theo giờ, theo ngày, theo ngày trong tuần và theo tuần. Đây là trigger dành cho công việc cần diễn ra vì hôm nay là thứ Ba, chứ không phải vì có gì đó thay đổi.
Thay đổi trạng thái Task khởi động Automation khi một task chuyển sang một trạng thái Organization đã chọn. Có một chi tiết đáng lưu ý: trạng thái là những định nghĩa Organization có thể tái sử dụng, và việc khớp sự kiện hiện tại diễn ra trên toàn Organization. Nếu nhiều Space dùng cùng một trạng thái “Needs Triage”, một chuyển đổi khớp ở bất kỳ Space nào trong số đó cũng có thể khởi động Automation của bạn. Hãy viết hướng dẫn sao cho Agent xác minh task đã kích hoạt trước khi hành động.
Cụm từ trong bình luận khởi động một lượt chạy khi bình luận của task chứa cụm từ đã cấu hình. Việc khớp không phân biệt chữ hoa chữ thường, kiểm tra ở bất kỳ vị trí nào trong bình luận, và cũng lắng nghe trên toàn Organization. Tài liệu khuyên: nên dùng một slash command đặc trưng như /triage-bug thay vì “check”, và để hướng dẫn tự xác thực task đã kích hoạt.
Webhook tạo một URL bí mật tiếp nhận POST từ dịch vụ bên ngoài. URL đầy đủ chỉ hiển thị khi trigger được tạo hoặc tạo lại và không thể xem lại sau đó, bởi mặc định chính URL đóng vai trò bearer secret. Nếu bạn cấu hình signing secret, các request còn phải vượt qua bước xác minh chữ ký, đúng theo cách GitHub áp dụng cho webhook của chính mình. Hãy giữ những secret này ngoài source control, và tạo lại nếu chúng bị lộ. Để lập trình Sharkly ngoài phạm vi webhook, xem Sharkly CLI và API.
Còn một cách nữa để khởi động lượt chạy mà không phải là trigger: Run now khởi động Automation trực tiếp — cách để kiểm tra hướng dẫn và mức sẵn sàng của assignee trước khi giao việc cho bốn loại trigger.
Automation thực sự chạy những gì
Khi trigger được kích hoạt, Sharkly khởi động Agent hoặc Crew được chỉ định với bộ hướng dẫn của Automation. Bộ hướng dẫn đó chính là toàn bộ bản giao kèo, nên tài liệu nói rất cụ thể về những gì cần nêu: kết quả cần tạo ra, những dữ liệu đầu vào cần kiểm tra, các bước cần thực hiện, nơi ghi lại kết quả, những thay đổi được phép, và thời điểm con người bắt buộc phải xem xét hoặc quyết định.
Điểm cuối cùng xứng đáng được nhấn mạnh. Một Automation được viết tốt sẽ tự nêu rõ điểm dừng của mình. Câu “Soạn bản tóm tắt và ghi lại; không thay đổi trạng thái task” là hướng dẫn tốt hơn một hướng dẫn dài dòng nhưng để quyền hạn mơ hồ. Hướng dẫn triển khai của tài liệu cũng rõ ràng không kém: hãy bắt đầu với công việc có thể quan sát và đảo ngược, rồi xem lại vài lượt chạy trước khi mở rộng phạm vi.
Ba việc vặt nên tự động hóa đầu tiên
Mỗi việc dưới đây đều nằm trong mức độ mà sản phẩm hỗ trợ: Agent đọc, soạn thảo và ghi lại; con người vẫn giữ quyền quyết định.
Tóm tắt standup hằng ngày. Trigger: theo lịch, preset ngày trong tuần, theo múi giờ của đội. Assignee: một Agent báo cáo có quyền đọc những ngữ cảnh liên quan. Hướng dẫn: kiểm tra các task trong Sprint hiện tại, ghi nhận việc gì đã tiến triển, việc gì đang bị chặn và việc gì đang chờ review, sau đó ghi lại một bản tóm tắt ngắn ở nơi đội ngũ đọc, mà không thay đổi bất kỳ task nào. Agent làm phần mà không ai thích trong buổi standup — ghép nối bức tranh tổng thể — và standup trở thành cuộc trò chuyện về hai hạng mục cần phán đoán. Nếu đội bạn vận hành nhịp làm việc qua Sharkly, Sprints cung cấp cấu trúc để Agent kiểm tra.
Triage bug vòng đầu. Trigger: trigger theo trạng thái task trên trạng thái tiếp nhận bug của bạn, hoặc trigger theo bình luận với một cụm từ đặc trưng như /triage, hoặc cả hai. Assignee: một Agent triage có repository bao phủ phần code bị ảnh hưởng. Hướng dẫn: xác minh task đã kích hoạt là một bug trong đúng Space dự kiến, đọc báo cáo, kiểm tra khu vực liên quan của codebase, rồi ghi lại bug có vẻ liên quan đến phần nào, báo cáo có đủ thông tin để xử lý hay không, và đề xuất mức ưu tiên kèm lý do. Đề xuất; không quyết định. Bước xác minh không phải là chi tiết cho có: vì việc khớp trạng thái và bình luận diễn ra trên toàn Organization, nên hướng dẫn chính là bộ lọc phạm vi của bạn. Lợi ích thu được là mọi bug đều được đọc kỹ như nhau ngay trong vài phút sau khi xuất hiện. Cách phân chia công việc này vẫn đúng khi công việc đến từ bên ngoài Sharkly; xem cách một ticket Jira trở thành công việc của Agent.
Báo cáo định kỳ. Trigger: theo lịch, preset theo tuần. Assignee: cùng kiểu Agent báo cáo, với hướng dẫn giới hạn trong khoảng thời gian dài hơn: tóm tắt những gì đã hoàn thành, những gì bị trễ và những gì đang bị chặn. Điểm khác biệt so với trường hợp standup chỉ là phạm vi và đối tượng đọc — chính vì thế nó thuộc về một Automation. Một báo cáo có mặt đều đặn mỗi thứ Sáu với chất lượng ổn định vẫn hơn một báo cáo tốt hơn nhưng chỉ ra đời khi có ai đó rảnh.
Ở cả ba ví dụ, hãy để ý những từ không bao giờ xuất hiện trong hướng dẫn: accept, approve, ship, close, decide.
Lịch sử chạy, tình trạng, tạm dừng và tiếp tục
Một Automation mà bạn không thể kiểm tra là một Automation bạn không thể tin tưởng, nên mọi lượt chạy đều được ghi lại. Lịch sử chạy báo cáo mỗi lượt chạy ở trạng thái Running, Completed, Failed hoặc Skipped, và phần chi tiết lượt chạy cho phép bạn mở payload của trigger, lượt chạy của Agent, kết quả đầu ra và lý do thất bại đã ghi lại. Phía trên các lượt chạy riêng lẻ, một tín hiệu tình trạng tóm tắt trạng thái hữu ích mới nhất: never tested, running, healthy, skipped hoặc needs attention.
Có một điều phủ định về ranh giới mà bạn nên in đậm trong đầu: trạng thái Completed mô tả lượt chạy của Automation, chứ không phải lời hứa rằng mọi kết quả về sau đều đúng. Completed nghĩa là cỗ máy đã hoạt động. Còn bản tóm tắt có chính xác hay quyết định triage có hợp lý hay không thì vẫn phải do con người đánh giá.
Tạm dừng và tiếp tục tồn tại đúng cho những thời điểm mà bạn có thể hình dung. Hãy tạm dừng một Automation để chặn các lượt chạy mới do trigger trong lúc bạn chỉnh sửa hướng dẫn, trigger hoặc assignee, rồi tiếp tục khi cấu hình đã sẵn sàng; trong khoảng thời gian đó, định nghĩa và lịch sử của nó vẫn được giữ nguyên. Xóa là cách duy nhất để loại bỏ, nên hãy để dành nó cho những định nghĩa mà bạn không còn cần lịch sử chạy. Và trước khi lưu trữ một Agent, hãy kiểm tra xem còn Automation nào phụ thuộc vào nó không.
Trước khi tin dùng bất kỳ Automation nào, tài liệu gợi ý một danh sách kiểm tra ngắn: chạy thủ công bằng Run now, xác nhận Agent hoặc Crew có quyền truy cập cần thiết, kiểm tra lượt chạy và kết quả đầu ra, thử từng trigger riêng biệt, dùng một trạng thái hẹp hoặc một cụm từ bình luận đặc trưng, và giữ secret của webhook ngoài source control.
Tự động hóa dừng ở đâu
Rất dễ đi đến kết luận rằng mục tiêu là một pipeline không cần người trông coi. Không phải vậy, và chính thiết kế của sản phẩm cũng nói lên điều đó. Automations không tự chấp nhận kết quả của chính mình, và chúng ghi lại mọi lượt chạy để con người xem xét.
Vậy nên nguyên tắc quyết định trung thực là thế này. Hãy dùng Automation khi cùng một công việc đã được định nghĩa rõ ràng cần được khởi động lặp lại hoặc để phản hồi một sự kiện có thể đoán trước, và khi một bản nháp đầu tiên nhất quán vẫn tốt hơn một bản xuất sắc chỉ xuất hiện lác đác. Hãy giao Task trực tiếp cho một Agent khi công việc chỉ diễn ra một lần, và giữ công việc hoàn toàn cho con người khi bản thân công việc chính là việc phán đoán: quyết định ưu tiên dưới những áp lực xung đột, quyết định chấp nhận, hay bất cứ việc gì mà sai một cách nhất quán còn tệ hơn chậm một cách thỉnh thoảng.
Hãy bắt đầu nhỏ và nhàm chán. Thiết lập xong, tạo một Agent báo cáo, viết một Automation với lịch theo ngày trong tuần và hướng dẫn kết thúc bằng “không thay đổi bất kỳ task nào”, rồi chạy thủ công một lần. Đọc kết quả đầu ra. Nếu thấy hữu ích, hãy để lịch trình đảm nhiệm. Tài liệu trình bày chi tiết hơn về Automations và canvas workflow.
Câu hỏi thường gặp
Automations của Sharkly hỗ trợ những loại trigger nào?
Bốn loại: theo lịch, dùng biểu thức cron năm trường kèm múi giờ; trigger theo trạng thái task, kích hoạt khi một task chuyển sang trạng thái Organization đã chọn; trigger theo bình luận, kích hoạt khi gặp cụm từ đã cấu hình; và trigger webhook, tiếp nhận POST tại một URL bí mật. Một Automation có thể kết hợp nhiều trigger, mỗi trigger được bật hoặc tắt độc lập, và Run now khởi động thủ công một lượt chạy để kiểm thử.
Automation có tạo Task mỗi lần chạy không?
Không. Automations hiện tại khởi động trực tiếp các lượt chạy của Agent hoặc Crew và không tạo Task cho mỗi lượt chạy. Lượt chạy, kết quả đầu ra và lý do thất bại (nếu có) đều được ghi lại trong lịch sử chạy của Automation. Nếu bạn muốn kết quả xuất hiện ở nơi đội ngũ đọc, hãy nói rõ điều đó trong hướng dẫn.
Automations khác Automation workflows ở điểm nào?
Đây là hai bề mặt riêng biệt trong một Space. Automation là một quy tắc: khởi động khi nào, Agent hoặc Crew nào chạy, và nó tuân theo hướng dẫn nào. Automation workflows là một canvas gồm các node trigger và action, có thể gọi ứng dụng bên thứ ba thông qua connector. Hãy dùng quy tắc đơn lẻ cho các kiểm tra định kỳ và lệnh qua bình luận; dùng canvas cho các luồng nhiều bước, liên ứng dụng.
Automation có thể tự xử lý việc triage bug không?
Nó có thể đảm nhiệm vòng đầu: xác minh task đã kích hoạt, đọc báo cáo, kiểm tra phần code liên quan và ghi lại các phát hiện kèm mức ưu tiên đề xuất. Quyết định triage vẫn thuộc về con người, và hướng dẫn cần nói rõ điều đó. Tài liệu khuyên nên bắt đầu với công việc có thể quan sát và đảo ngược, rồi xem lại vài lượt chạy trước khi mở rộng phạm vi.
Điều gì xảy ra khi một lượt chạy Automation thất bại?
Lượt chạy được ghi là Failed trong lịch sử chạy kèm lý do thất bại nếu có, và tín hiệu tình trạng chuyển sang needs attention. Hãy mở chi tiết lượt chạy để kiểm tra payload của trigger, lượt chạy của Agent và kết quả đầu ra, sửa hướng dẫn, trigger hoặc assignee, rồi dùng Run now để xác minh bản sửa trước khi tin tưởng các trigger trở lại.
