Agent Autoloop cho SRE: chạy ticket và alert nền, chỉ dừng ở điểm duyệt
Agent Autoloop nhận event, giao việc cho CLI agent theo từng lượt rồi chỉ gửi thẻ xin quyết định khi cần. Với DevOps/SRE, dự án phù hợp để pilot triage và theo dõi CI/CD có approval gate, quyền tối thiểu và lịch sử truy vết.
Một alert xuất hiện khi bạn đang họp: log đã có dấu hiệu, thay đổi gần nhất nằm trong một PR, nhưng restart hay rollback vẫn cần người chịu trách nhiệm quyết định. Nếu agent chỉ biết “tự động xử lý”, nó có thể làm quá tay. Nếu hỏi từng bước, tự động hóa lại mất ý nghĩa.
Agent Autoloop chọn một nhịp khác: nhận event, giao việc cho CLI agent xử lý theo từng lượt, rồi chỉ gửi thẻ xin quyết định khi chạm điểm chưa chắc chắn. Khi có câu trả lời, hệ thống tiếp tục cuộc hội thoại trước đó để hoàn tất việc.
Với DevOps/SRE, đây không nên được xem là công cụ để giao toàn bộ production cho AI. Nó đáng thử như một lớp điều phối có trạng thái cho ticket, alert, kiểm tra định kỳ và theo dõi CI/CD — nếu quyền hạn, điểm duyệt và dấu vết quyết định được thiết kế trước.
Vòng lặp xử lý hoạt động thế nào?
Agent Autoloop là một “trung tâm tự động hóa” nhẹ chạy trên macOS hoặc Linux. README mô tả phần lõi không có runtime dependency; nguồn event, CLI agent, kênh thông báo và luồng giao hàng được tách thành plugin.
Một event có thể đến từ lịch chạy, GitHub Issue, webhook HTTP hoặc hệ thống bên ngoài mà bạn kết nối. Rule cục bộ quyết định agent nào nhận việc và chạy trong thư mục nào. Agent chạy một lượt, ghi kết quả ở phản hồi cuối rồi thoát.
Khi gặp việc cần quyết định — chẳng hạn xóa dữ liệu, restart dịch vụ, phát sinh chi phí hoặc gửi thông tin ra ngoài — agent có thể trả về một card để hỏi. Trong thời gian chờ, agent không giữ tiến trình chạy và không tiếp tục tiêu thụ token; hệ thống trung tâm vẫn lưu trạng thái chờ. Khi người trực trả lời, tác vụ có thể được nối lại từ cuộc hội thoại trước đó.
Điểm này hữu ích cho vận hành:
Alert không biến thành một cửa sổ terminal phải canh liên tục.
Agent có thể thu thập bằng chứng, đối chiếu code và tóm tắt phương án.
Hành động có tác động vẫn có thể dừng ở một approval gate.
Việc đang dở không nhất thiết mất trạng thái chỉ vì một lượt agent đã kết thúc.
README có recipe “ops alert”: nhận lỗi, đối chiếu code để tìm nguyên nhân và hỏi bằng card khi cần restart. Tuy vậy, dự án nêu rõ các script và hồi đáp mẫu chỉ được kiểm tra bằng HTTP cục bộ cùng CLI Feishu giả; chưa có xác nhận rằng toàn bộ quy trình nghiệp vụ đã chạy trên tài khoản thật. Hãy coi đây là khung để pilot, không phải bằng chứng sẵn sàng cho production.
Ba hàng rào cần có trước khi nối vào hạ tầng
Giá trị của mô hình này không chỉ nằm ở việc “agent tự làm”, mà ở cách giới hạn vòng lặp.
1. Approval gate phải là ranh giới thật
Hãy tách rõ hành động chỉ đọc và hành động làm thay đổi trạng thái.
Ví dụ, agent có thể đọc dashboard, log, manifest hoặc trạng thái CI. Còn restart, scale, merge, deploy, xóa resource hay gửi phản hồi ra ngoài nên dừng lại để người có trách nhiệm duyệt.
Agent có thể đặt một khối agent-autoloop ở cuối phản hồi để tạo câu hỏi với các lựa chọn. Nếu JSON trong khối đó lỗi, hệ thống được thiết kế để yêu cầu agent viết lại phần cuối thay vì chạy lại toàn bộ tác vụ. Điều này có ích khi tác vụ đã thu thập nhiều bằng chứng.
2. Quyền tối thiểu phải nằm ở rule cục bộ
Theo README, việc dùng agent nào, chạy ở thư mục nào và quyền nào được quyết định bởi rule trên máy cục bộ. Event bên ngoài mang các trường như cwd, agent hoặc access sẽ bị từ chối.
Cách tách này giảm nguy cơ tiêu đề Issue, nội dung ticket hoặc payload alert điều khiển nơi agent chạy hay quyền mà agent nhận được.
Với Kubernetes và IaC, đây nên là ranh giới kiến trúc bắt buộc:
Agent điều tra chỉ có quyền đọc và chạy trong workspace chứa bản sao cấu hình.
Agent chuẩn bị thay đổi chỉ tạo patch hoặc đề xuất.
Pipeline có quyền apply hoặc merge là một chặng khác, sau phê duyệt của người có trách nhiệm.
Đây là khuyến nghị triển khai, không phải tích hợp Kubernetes hay Terraform có sẵn trong Agent Autoloop.
3. Nhật ký quyết định phải truy vết được
README mô tả lõi dùng event sourcing: trạng thái được dựng từ log chỉ-ghi-thêm; log và index được ghi trong cùng transaction trước khi hệ thống phản hồi.
Lệnh sau dùng để xem diễn biến của một lượt xử lý:
bash
agent-autoloop why 1
Ví dụ trong README cho thấy lịch sử gồm phiên bản rule, event kích hoạt, bên nhận việc và kết quả kết thúc.
Đây là điểm hợp với postmortem. Thay vì chỉ giữ các đoạn chat rời rạc, đội vận hành có thể đối chiếu alert đã mở vòng xử lý nào, rule nào được áp dụng và kết luận cuối cùng là gì. Approval quan trọng vẫn nên được ghi thêm vào incident timeline hoặc change record của chính đội ngũ.
Pilot an toàn: bắt đầu từ ticket không có quyền ghi
Dự án yêu cầu Node 24, Git, curl và một CLI agent đã đăng nhập. Trên macOS hoặc Linux, README hướng dẫn cài đặt bằng:
bash
curl -fsSL https://raw.githubusercontent.com/KKKKhazix/agent-autoloop/main/install.sh | sh
Sau đó chạy luồng thử có sẵn:
bash
agent-autoloop try
Luồng này minh họa việc agent hỏi một câu chọn màu, chờ người dùng trả lời rồi tiếp tục. Trong terminal không tương tác, ví dụ README dùng:
bash
agent-autoloop answer 1 2
Kiểm tra tiến độ sau đó bằng:
bash
agent-autoloop status
Đây là walkthrough tốt để xác nhận cơ chế “dừng để duyệt rồi nối lại”. Nó không xác minh tích hợp với PagerDuty, Kubernetes, Terraform hay nền tảng observability của bạn.
Sau bước thử, hãy bắt đầu với GitHub Issue hoặc tác vụ tổng hợp trạng thái CI có phạm vi chỉ đọc. Rule mẫu trong README có cấu trúc như sau; trước đó cần đăng ký nguồn github theo hướng dẫn của dự án:
json
{
"name": "处理 issue",
"when": { "source": "github", "types": ["issues.opened"] },
"to": "codex",
"cwd": "~/code/app",
"skill": "handle-issue",
"parallel": 3
}
Sau khi sửa rule, chạy:
bash
agent-autoloop check
README cho biết nếu rule mới lỗi, bị xóa hoặc không đọc được, hệ thống sẽ tiếp tục dùng rule cũ và gửi card cảnh báo. Đây là hành vi hữu ích cho vận hành, nhưng không thay thế review cấu hình.
Mẫu prompt: điều tra alert, không tự can thiệp
Prompt hoặc Skill là nơi cần phân biệt rõ “thu thập bằng chứng” với “thay đổi hệ thống”. Bạn có thể dùng cấu trúc như sau trong Skill mà rule gọi tới:
text
Bạn là agent điều tra sự cố cho <service>.
Mục tiêu:
Tóm tắt tín hiệu từ <alertpayload>.
Đối chiếu với <repositoryorrunbook>.
Nêu giả thuyết, bằng chứng còn thiếu và bước kiểm tra chỉ đọc.
Giới hạn:
Không restart, deploy, rollback, scale, xóa dữ liệu hoặc gửi thông báo ra ngoài.
Không thay đổi file cấu hình production.
Không yêu cầu hay in secret, token, kubeconfig hoặc thông tin xác thực.
Nếu đề xuất hành động có tác động:
Chỉ rõ tác động, phương án thay thế và điều kiện rollback.
Tạo yêu cầu phê duyệt với các lựa chọn rõ ràng.
Chờ quyết định của người trực trước khi tiếp tục.
Kết quả cuối:
Tóm tắt cho incident timeline.
Danh sách bằng chứng đã dùng.
Trạng thái: <resolved|needsapproval|needshumaninvestigation>.
Kết quả tốt không phải là “đã restart để hết alert”. Nó cần trả về chẩn đoán, mức độ tin cậy, các bước đã kiểm tra và một yêu cầu phê duyệt cụ thể nếu cần can thiệp.
Người duyệt không nên nhận lựa chọn mơ hồ như “tiếp tục/không”. Card nên nêu rõ dịch vụ bị ảnh hưởng, hành động đề xuất, tác động dự kiến và phương án thay thế.
Kiểm tra đầu ra AI trước khi áp dụng
Dù agent viết YAML, Terraform hay đề xuất pipeline, nguyên tắc vẫn là: AI tạo bản nháp; hệ thống kiểm chứng; người có thẩm quyền quyết định.
Một quy trình thực dụng cho đội platform:
Dùng agent-autoloop check sau khi đổi rule.
Chạy linter, scanner, policy check và plan/dry-run hiện có trong repository trước khi apply.
So sánh diff với ticket, alert và runbook; không chỉ tin phần tóm tắt của agent.
Yêu cầu review người thứ hai với IAM, network, secret, production manifest và delivery rule.
Với luồng delivery của dự án, chỉ đọc cấu hình review và giao hàng từ main; README mô tả cơ chế này không checkout hoặc chạy code từ PR trên máy nhận việc.
Ghi approval cùng kết quả truy vết vào incident timeline hoặc change record.
README cho biết Agent Autoloop gọi các CLI đã cài và đăng nhập trên máy, không đọc hoặc chuyển lưu credential của các CLI đó. Tuy nhiên, agent và plugin vẫn chạy trong môi trường của bạn. Quyền file, biến môi trường, dữ liệu đầu vào và quyền gọi API vẫn phải được kiểm soát như mọi automation khác.
Không đưa token, secret, kubeconfig, payload nhạy cảm hoặc dữ liệu khách hàng vào prompt nếu chưa có biện pháp kiểm soát phù hợp.
Kết luận: tự động hóa điều tra trước, tự động hóa hành động sau
Agent Autoloop hấp dẫn ở chỗ biến trạng thái “đợi người trả lời” thành trạng thái bền vững, thay vì buộc một terminal hoặc tiến trình agent phải mở liên tục.
README cho biết Claude Code, Codex và ACP đã được kiểm tra với hội thoại nhiều lượt và nối lại qua tiến trình. Feishu đã được kiểm tra cho việc gửi, callback nút và cập nhật card. Các mẫu webhook cho DingTalk, WeCom, Slack và Discord mới được xác thực bằng dịch vụ mô phỏng cục bộ.
Với SRE, cách triển khai phù hợp là bắt đầu nhỏ:
Triage chỉ đọc.
Approval bắt buộc cho mọi thay đổi.
Quyền tối thiểu theo từng rule và từng môi trường.
Lịch sử quyết định phục vụ audit và postmortem.
Khi bốn điều đó hoạt động ổn định, vòng lặp agent mới đáng được cân nhắc mở rộng sang delivery hoặc remediation có kiểm soát.